netdev - [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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Sat,  6 Jan 2024 15:40:45 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: netdev@...r.kernel.org
Cc: linus.walleij@...aro.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: [RFC net-next 0/2] net: dsa: realtek: fix LED support for rtl8366rb

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.

This patch series has a minor conflict with the other realtek
refacatoring series at the priv->ds access.

-       dsa_switch_for_each_port(dp, priv->ds) {
+       dsa_switch_for_each_port(dp, &priv->ds) {