netdev - Re: [RFC net-next 0/2] net: dsa: realtek: fix LED support for rtl8366rb

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkda8tQ2u4+jCrpOQXbBd84oW98vmiDgU+GgdYCHuZfn49A@mail.gmail.com>
Date: Sun, 7 Jan 2024 21:16:54 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: netdev@...r.kernel.org, alsi@...g-olufsen.dk, andrew@...n.ch, 
	f.fainelli@...il.com, olteanv@...il.com, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	arinc.unal@...nc9.com, ansuelsmth@...il.com
Subject: Re: [RFC net-next 0/2] net: dsa: realtek: fix LED support for rtl8366rb

Hi Luiz,

On Sat, Jan 6, 2024 at 7:47 PM Luiz Angelo Daros de Luca
<luizluca@...il.com> wrote:

> The rtl8366rb switch family has 4 LED groups, with one LED from each
> group for each of its 6 ports. LEDs in this family can be controlled
> manually using a bitmap or triggered by hardware. It's important to note
> that hardware triggers are configured at the LED group level, meaning
> all LEDs in the same group share the same hardware triggers settings.
>
> The first part of this series involves dropping most of the existing
> code, as, except for disabling the LEDs, it was not working as expected.
> If not disabled, the LEDs will retain their default settings after a
> switch reset, which may be sufficient for many devices.
>
> The second part introduces the LED driver to control the switch LEDs
> from sysfs or device-tree. This driver still allows the LEDs to retain
> their default settings, but it will shift to the software-based OS LED
> triggers if any configuration is changed. Subsequently, the LEDs will
> operate as normal LEDs until the switch undergoes another reset.
>
> Netdev LED trigger supports offloading to hardware triggers.
> Unfortunately, this isn't possible with the current LED API for this
> switch family. When the hardware trigger is enabled, it applies to all
> LEDs in the LED group while the LED API decides to offload based on only
> the state of a single LED. To avoid inconsistency between LEDs,
> offloading would need to check if all LEDs in the group share the same
> compatible settings and atomically enable offload for all LEDs.

I think these patches look great, and the driver certainly look better
after these changes than before them so if you resend without
RFC, please feel free to add my:

Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

HW triggers may be hard to implement but plain software control
is not bad either so this is already way better than what we had
before.

HW control can always be discussed and added later.

Yours,
Linus Walleij