| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20251104-sandal-playset-6f4ad0665c7b@thorsis.com>
Date: Tue, 4 Nov 2025 11:24:05 +0100
From: Alexander Dahl <ada@...rsis.com>
To: Josua Mayer <josua@...id-run.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Jessica Zhang <jessica.zhang@....qualcomm.com>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Jon Nettleton <jon@...id-run.com>,
Mikhail Anikin <mikhail.anikin@...id-run.com>,
Yazan Shhady <yazan.shhady@...id-run.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH 08/10] arm64: dts: add description for solidrun imx8mp
hummingboard-iiot
Hello Josua,
Am Thu, Oct 30, 2025 at 04:44:40PM +0000 schrieb Josua Mayer:
> Hi Alex,
>
> Am 29.10.25 um 10:23 schrieb Alexander Dahl:
> > Hello Josua,
> >
> > Am Tue, Oct 28, 2025 at 12:24:36PM +0000 schrieb Josua Mayer:
> >> 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 <josua@...id-run.com>
> >>> ---
> >>> 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?
> > The sysfs names are auto-generated based on the attributes "color",
> > "function", and "label" with the last being discouraged for new
> > designs.
> Thank you for reminding me of this one!
> > If the "ti,lp5562" driver does nothing special,you could
> > add "function" to the multi-led node and see if that fits your needs.
> The board is not a complete product by itself so we have not chosen
> a specific function for each led.
> Therefore only color and label are actually applicable.
In such cases I use a generic function and the enumerator,
something like this (in this case for a different led driver):
led_11_red: led-0 {
function = LED_FUNCTION_INDICATOR;
function-enumerator = <0>;
color = <LED_COLOR_ID_RED>;
gpios = <&pioC 18 GPIO_ACTIVE_HIGH>;
};
…
led_13_red: led-2 {
function = LED_FUNCTION_INDICATOR;
function-enumerator = <1>;
color = <LED_COLOR_ID_RED>;
gpios = <&pioC 20 GPIO_ACTIVE_HIGH>;
};
This gives stable sysfs paths like this:
/sys/class/leds/red:indicator-0
/sys/class/leds/red:indicator-1
Of course only with a LED driver supporting that automatic naming
scheme.
> After testing on v6.18-rc1 I can state that leds-lp5562 driver does
> something special - function and label properties do not have any
> impact on the names in sysfs.
>
> However I could set label on both LEDs regardless?
When using the 'label' attribute, color and function attributes are
more or less informational only, because label determines the sysfs
path. Someone could change the leds-lp5562 driver to behave like the
other drivers, but then I would advise to explicitly set label in this
case, so you won't end up with changed sysfs paths after the driver is
changed.
Not sure if this helps you. Sorry.
Greets
Alex
>
> >
> > Adding linux-leds to Cc, because this is a LED related question.
> >
> > Greets
> > Alex
> >
> >> 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>;
> >>> + };
> >>> + };
Powered by blists - more mailing lists