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]
Message-ID: <20240106184651.3665-1-luizluca@gmail.com>
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) {



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ