From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
To: "Linus Walleij" <linus.walleij@linaro.org>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Andrew Lunn" <andrew@lunn.ch>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org,
Luiz Angelo Daros de Luca <luizluca@gmail.com>
Subject: [PATCH net-next v2 0/3] net: dsa: realtek: fix LED support for rtl8366
Date: Sat, 27 Apr 2024 02:11:27 -0300 [thread overview]
Message-ID: <20240427-realtek-led-v2-0-5abaddc32cf6@gmail.com> (raw)
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, even for those not
metioned in the device-tree. 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.
To: Linus Walleij <linus.walleij@linaro.org>
To: Alvin Šipraga <alsi@bang-olufsen.dk>
To: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
To: David S. Miller <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Rob Herring <robh+dt@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Changes in v2:
- Fixed commit message formatting
- Added GROUP to LED group enum values. With that, moved the code that
disables LED into a new function to keep 80-collumn limit.
- Dropped unused enable argument in rb8366rb_get_port_led()
- Fixed variable order in rtl8366rb_setup_led()
- Removed redundant led group test in rb8366rb_{g,s}et_port_led()
- Initialize ret as 0 in rtl8366rb_setup_leds()
- Updated comments related to LED blinking and setup
- Link to v1: https://lore.kernel.org/r/20240310-realtek-led-v1-0-4d9813ce938e@gmail.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 (3):
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
drivers/net/dsa/realtek/rtl8366rb.c | 363 +++++++++++++++++++++++++++---------
drivers/net/dsa/realtek/rtl83xx.c | 7 +-
2 files changed, 273 insertions(+), 97 deletions(-)
---
base-commit: 5c4c0edca68a5841a8d53ccd49596fe199c8334c
change-id: 20240212-realtek-led-a665ae39a9c5
Best regards,
--
Luiz Angelo Daros de Luca <luizluca@gmail.com>
next reply other threads:[~2024-04-27 5:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-27 5:11 Luiz Angelo Daros de Luca [this message]
2024-04-27 5:11 ` [PATCH net-next v2 1/3] net: dsa: realtek: keep default LED state in rtl8366rb Luiz Angelo Daros de Luca
2024-04-27 5:11 ` [PATCH net-next v2 2/3] net: dsa: realtek: do not assert reset on remove Luiz Angelo Daros de Luca
2024-04-27 5:11 ` [PATCH net-next v2 3/3] net: dsa: realtek: add LED drivers for rtl8366rb Luiz Angelo Daros de Luca
2024-04-29 13:39 ` Jakub Kicinski
2024-05-16 17:30 ` Luiz Angelo Daros de Luca
2024-05-16 21:05 ` Linus Walleij
2024-05-16 21:16 ` Linus Walleij
2024-04-29 12:40 ` [PATCH net-next v2 0/3] net: dsa: realtek: fix LED support for rtl8366 patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240427-realtek-led-v2-0-5abaddc32cf6@gmail.com \
--to=luizluca@gmail.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).