Am 27.10.25 um 18:48 schrieb Josua Mayer: > Add description for the SolidRun i.MX8MP HummingBoard IIoT. > The board is a new design around the i.MX8MP System on Module, not > sharing much with previous HummingBoards. > > It comes with some common features: > - 3x USB-3.0 Type A connector > - 2x 1Gbps RJ45 Ethernet > - USB Type-C Console Port > - microSD connector > - RTC with backup battery > - RGB Status LED > - 1x M.2 M-Key connector with PCI-E Gen. 3 x1 > - 1x M.2 B-Key connector with USB-2.0/3.0 + SIM card holder > - 1x LVDS Display Connector > - 1x DSI Display Connector > - GPIO header > - 2x RS232/RS485 ports (configurable) > - 2x CAN > > In addition there is a board-to-board expansion connector to support > custom daughter boards with access to SPI, a range of GPIOs and - > notably - CAN and UART. Both 2x CAN and 2x UART can be muxed either > to this b2b connector, or a termianl block connector on the base board. > > The routing choice for UART and CAN is expressed through gpio > mux-controllers in DT and can be changed by applying dtb addons. > > Four dtb addons are provided: > > - dsi panel Winstar WJ70N3TYJHMNG0 > - lvds panel Winstar WF70A8SYJHLNGA > - RS485 on UART port "A" (default rs232) > - RS485 on UART port "B" (default rs232) > > Signed-off-by: Josua Mayer <[email protected]> > --- > arch/arm64/boot/dts/freescale/Makefile | 6 + > ...hummingboard-iiot-panel-dsi-WJ70N3TYJHMNG0.dtso | 70 ++ > ...ummingboard-iiot-panel-lvds-WF70A8SYJHLNGA.dtso | 105 +++ > .../imx8mp-hummingboard-iiot-rs485-a.dtso | 18 + > .../imx8mp-hummingboard-iiot-rs485-b.dtso | 18 + > .../dts/freescale/imx8mp-hummingboard-iiot.dts | 710 > +++++++++++++++++++++ > 6 files changed, 927 insertions(+) cut > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts > b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts > new file mode 100644 > index 0000000000000..2e4cb676bc9da > --- /dev/null > +++ b/arch/arm64/boot/dts/freescale/imx8mp-hummingboard-iiot.dts cut > + led-controller@30 { > + compatible = "ti,lp5562"; > + reg = <0x30>; > + /* use internal clock, could use external generated by rtc */ > + clock-mode = /bits/ 8 <1>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + multi-led@0 { > + reg = <0x0>; > + color = <LED_COLOR_ID_RGB>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + led@0 { > + reg = <0x0>; > + color = <LED_COLOR_ID_RED>; > + led-cur = /bits/ 8 <0x32>; > + max-cur = /bits/ 8 <0x64>; > + }; > + > + led@1 { > + reg = <0x1>; > + color = <LED_COLOR_ID_GREEN>; > + led-cur = /bits/ 8 <0x19>; > + max-cur = /bits/ 8 <0x32>; > + }; > + > + led@2 { > + reg = <0x2>; > + color = <LED_COLOR_ID_BLUE>; > + led-cur = /bits/ 8 <0x19>; > + max-cur = /bits/ 8 <0x32>; > + }; > + }; > + > + led@3 { > + reg = <3>; > + chan-name = "D8";
chan-name gives the led the name D6 in sysfs. The bindings do not allow however setting chan-name on the multi-led, and it has an auto-generated name in sysfs. Am I missing something? Can multi-leds have a custom name? In v6.6 leds-lp5562 driver if I set in each multi-led led@[0-2] sub-node chan-name to the same string "D7" - then the sysfs name becomes D7. > + color = <LED_COLOR_ID_GREEN>; > + led-cur = /bits/ 8 <0x19>; > + max-cur = /bits/ 8 <0x64>; > + }; > + };
