fixup! docs: Add wired split config docs.

docs/docs/config/split.md

@@ -43,6 +43,13 @@ Following wired [split keyboard](../features/split-keyboards.md) settings are de
 
 Hardware UARTs have a few different modes/approaches to sending and receiving data, with different levels of complexity and performance. Not all hardware nor drivers support all modes, so ZMK has code to support different interaction modes with the UART as needed. The default mode should be properly selected based on the platform's report support, but you can choose to override the mode if needed.
 
+- Polling Mode - The least efficient mode, this requires the MCU to constantly poll the UART to see if more data has been received, taking time away from other processing. This is basic mode supported by all UART drivers.
+- Interrupt Mode - This mode allows the MCU to do other processing until the UART raises an interrupt to signal new data has been received. On platforms where this is combined with a FIFO, there is even less superfluous processing, and high speeds can be achieved while allowing other processing to continue. Examples:
+  - RP2040
+- Async (DMA) Mode - Similar to interrupt mode, data reception can occur without involving the MCU. Additionally, larger volumes can be copied directly into accessible memory without the use of the MCU, allowing even further efficiency/rates without tying up the MCU. Only some drivers support this mode (and the current Zephyr 3.5 version of the nRF52 UART has some bugs that prevent its use). Examples:
+  - SAM0 (e.g. SAMD21)
+  - STM32 (e.g. stm32f072)
+
 :::
 
 | Config                                       | Type | Description                                                       | Default                                                       |

docs/docs/development/hardware-integration/new-shield.mdx

@@ -511,7 +511,7 @@ If all of your physical layouts use the same `kscan` node under the hood, you ca
 
 :::
 
-Additionally, if testing the experimental [wired split](../../features/split-keyboards.md) support, you should assign a [pinctrl configured](./pinctrl.mdx) UART to the `zmk,split-uart` chosen property:
+Additionally, if testing the experimental [wired split](../../features/split-keyboards.md) support, you should assign a [predefined](./pinctrl.mdx#predefined-nodes) or [pinctrl configured](./pinctrl.mdx) UART to the `zmk,split-uart` chosen property:
 
 ```dts
 / {

docs/docs/features/split-keyboards.md

@@ -6,7 +6,7 @@ sidebar_label: Split Keyboards
 ZMK supports setups where a keyboard is split into two or more physical parts (also called "sides" or "halves" when split in two), each with their own controller running ZMK. The parts communicate with each other to work as a single keyboard device.
 
 :::note[Split communication protocols]
-Currently ZMK only supports split keyboards that communicate with each other wirelessly over BLE.
+ZMK supports split keyboards that communicate with each other wirelessly over BLE, and includes experimental wired split support.
 
 Full-duplex UART, wired split support is currently experimental, and is available for advanced/technical users to test.