netdev - [PATCH net-next 0/4] net: dsa: realtek: fix LED support for rtl8366

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-next>] [day] [month] [year] [list]

Message-Id: <20240310-realtek-led-v1-0-4d9813ce938e@gmail.com>
Date: Sun, 10 Mar 2024 01:51:57 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>, 
 Alvin Šipraga <alsi@...g-olufsen.dk>, 
 Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, 
 Vladimir Oltean <olteanv@...il.com>, 
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Luiz Angelo Daros de Luca <luizluca@...il.com>, devicetree@...r.kernel.org
Subject: [PATCH net-next 0/4] net: dsa: realtek: fix LED support for
 rtl8366

This series fixes the LED support for rtl8366. The existing code was not
tested in a device with switch LEDs and it was using a flawed logic.

The driver now keeps the default LED configuration if nothing requests a
different behavior. This may be enough for most devices. This can be
achieved either by omitting the LED from the device-tree or configuring
all LEDs in a group with the default state set to "keep".

The hardware trigger for LEDs in Realtek switches is shared among all
LEDs in a group. This behavior doesn't align well with the Linux LED
API, which controls LEDs individually. Once the OS changes the
brightness of a LED in a group still triggered by the hardware, the
entire group switches to software-controlled LEDs. This shared behavior
also prevents offloading the trigger to the hardware as it would require
an orchestration between LEDs in a group, not currently present in the
LED API.

The assertion of device hardware reset during driver removal was removed
because it was causing an issue with the LED release code. Devres
devices are released after the driver's removal is executed. Asserting
the reset at that point was causing timeout errors during LED release
when it attempted to turn off the LED.

Signed-off-by: Luiz Angelo Daros de Luca <luizluca@...il.com>
---
Changes in v1:
- Rebased on new relatek DSA drivers
- Improved commit messages
- Added commit to remove the reset assert during .remove
- Link to RFC: https://lore.kernel.org/r/20240106184651.3665-1-luizluca@gmail.com

---
Luiz Angelo Daros de Luca (4):
      dt-bindings: net: dsa: realtek: describe LED usage
      net: dsa: realtek: keep default LED state in rtl8366rb
      net: dsa: realtek: do not assert reset on remove
      net: dsa: realtek: add LED drivers for rtl8366rb

 .../devicetree/bindings/net/dsa/realtek.yaml       |  46 +++
 drivers/net/dsa/realtek/rtl8366rb.c                | 341 ++++++++++++++++-----
 drivers/net/dsa/realtek/rtl83xx.c                  |   7 +-
 3 files changed, 306 insertions(+), 88 deletions(-)
---
base-commit: d7e14e534493328cc5f67baaff2b0c23d32b0a57
change-id: 20240212-realtek-led-a665ae39a9c5

Best regards,
-- 
Luiz Angelo Daros de Luca <luizluca@...il.com>