Enhancement request: moving hardcoded hardware setting to device tree.

[hlyi]

@jnilo1 to be support different platform with some codebase, could we move hardware related settings to device-tree? There are a few that I have identified:

1. Status LED, it is already in device tree, but rtl8196e_hw.c does not use the information and have hardcoded value for MUX_SEL_2
2. Lan port LED, it can be derived from member-ports in device-tree, but hardcoded in rtl8196e_hw.c
3. Reset button, currently, it is hardcoded in s40button.c
4. nRST pin for Radio, it is in rtl8196e_uart_bridge_main.c
5. blmode pin for Radio, not available for all platforms, ( suggested in nrst_pulse toggle in rtl8196e_uart_bridge_main.c #121)
6. flow control type for radio, ( hardware or software based upon wiring between radio chip and RTL8196E)

Thanks for your consideration!

[jnilo1]

Hi @hlyi,

Good list — it pushed us to draw a clean line, and most of it is now implemented (next release). The principle we adopted:

Board facts (pins, wiring) go to the device tree. SoC-level register recipes stay in code.

The G4 is the same RTL8196E silicon, so things like the UART1 pin-mux bits or the MII field clears are identical on every board and gain nothing from being data. What differs per board — pins, the Ethernet port, memory size, flow-control wiring — is now (or already was) DT.

Your six items

1. Status LED — already fully DT, actually. The gpio-leds-pwm node in the board DTS owns the pin (GPIO 11 on the Lidl board) and the gpio driver applies the pad-mux on claim. What you saw in rtl8196e_hw.c is the Ethernet driver preserving the LED mux fields while clearing unrelated SoC-level ones (MII/legacy-nRST) — it carries no LED configuration of its own. Nothing left to move.
2. LAN port LED — driven by the switch ASIC (LEDCREG direct link/activity mode), not by a GPIO. The ASIC drives its per-port LED outputs and the board wires whichever pad it uses; from your Port to different hub #119 findings the G4 uses the same mechanism. Until a port demonstrates a real per-board difference we're leaving this alone — parameterizing on speculation is how DT bindings rot.
3. Reset button — done: s40button v2 + gpio-line-names (details in Enhance to not directly access GPIO register #122; the kernel-side pad-mux on claim also fixes your B6 button).
4. nRST pin — done: nrst-gpios in a new optional /radio-bridge node, seeded at boot, nrst_gpio module param still overrides at runtime.
5. blmode pin — deferred until your pin probing confirms a board that actually wires it. The property slot is reserved in the same radio-bridge node (blmode-gpios); it is a small addition to the bridge once there is hardware to test against.
6. Flow-control type — done: flow-control = "hw" | "sw" | "none" in the same node (details in Enhance rtl8196e_uart_bridge_main to support SW Flow control #123).

Porting recipe (the whole kernel-side surface for a new board)

1. Write rtl8196e-<board>.dts next to rtl8196e.dts: include rtl819x.dtsi, then override what differs — memory@0 size, gpio-line-names, the radio-bridge node, the leds node, and the ethernet interface@0 (member-ports, phy-id).
2. Add a CONFIG_DTB_RTL8196E_<BOARD> entry to the Kconfig devicetree choice and the matching dtb-$(...) line in arch/mips/boot/dts/realtek/Makefile (the recipe is documented in both files).
3. Build with BOARD=<board> ./build_kernel.sh.

Userdata side, nothing is board-specific anymore: s40button discovers its pin from your DTS.

What we deliberately did not do

No pinctrl driver, no gpio-keys/input subsystem, no devicetree YAML bindings, no conversion of the bridge into a platform driver. Each would add kernel bytes or churn to a field-stable driver without making a port easier than the recipe above. If the G4 port hits a wall that one of these would genuinely solve, that's the moment to revisit.

[hlyi]

@jnilo1 , wow, you are so fast and efficient 👍👍. Do you mind push your changes into the repo, so I can test it out? Thanks!

[jnilo1]

@hlyi — pushed: v3.10.0 is out and contains everything described above (device-tree board description, s40button v2, bridge v1.2 with DT seeding, plus the #125 NTP fix). The porting recipe from my previous comment is now the released workflow: BOARD=<board> ./build_kernel.sh with your own DTS. Have fun with the G4 port, and open issues for whatever the recipe gets wrong on real hardware.

[hlyi]

@jnilo1 Thanks for releasing new codes. quick feedback on items:

1. Status LED, it is addressed in new release. confirmed in my setup. Thanks !
2. LAN port LED. This is not fully addressed yet. please see my comment item 3 in Enhancement request: add --board or BOARD= to scripts (for Main SOC) #126 (comment)
3. Reset button. This one is being addressed, confirmed in my setup. Thank you!
4. nRST pin, this one is being addressed, not test yet due to missing item 5. Thanks!
5. blmode pin, need your help implementing it. more details at comments in Enhance rtl8196e_uart_bridge_main to support SW Flow control #123 (comment)
6. Flow-control type, thanks for address it! Need get bootloader working ( item5) before I can test it. will report back when it is available.

[jnilo1]

Thanks for the scorecard, @hlyi — great to see the status LED and reset button confirmed on real G4 hardware; that's the first external validation of the v3.10.0 board mechanism.

Where each open item is being handled:

• Item 2 (LAN port LED) → answered in Enhancement request: add --board or BOARD= to scripts (for Main SOC) #126 (item 3 there): the ethernet driver's PIN_MUX_SEL_2 handling becomes DT-aware (gpio-line-names → hands-off, member-ports → ASIC LED, otherwise default). Planned for the next release.
• Item 5 (blmode pin) → answered in Enhance rtl8196e_uart_bridge_main to support SW Flow control #123: implemented as a new blmode_pulse trigger in the bridge (your exact sequence), kept separate from nrst_pulse so plain application resets keep working. Next release as well.
• Items 4 and 6 (nRST, flow control) → already shipped in v3.10.0; both become testable on your side once blmode_pulse lands and you can flash your custom firmware. Looking forward to the report — especially the xoff/xon counters under real load.

[hlyi]

This request has been broken down to multiple sub-requests. Closing this one.