Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size

[Linus Walleij]

On Sat, Dec 30, 2023 at 6:19 AM Luiz Angelo Daros de Luca
<luizluca@xxxxxxxxx> wrote:

> I took a look at the LED code. It looks like you got it a little bit wrong.

You are right...

> If LEDs are not disabled, it will use the RTL8366RB_LED_FORCE for all
> 4 LED groups. That RTL8366RB_LED_FORCE keeps the LEDs on. I would use
> RTL8366RB_LED_LINK_ACT by default to make it blink on link activity
> (or make it configurable as the comment suggests) but it is not wrong.
> I cannot evaluate the RTL8366RB_INTERRUPT_CONTROL_REG usage when you
> disable the LEDs but it seems to be odd.

The problem is that since I don't have a device with LEDs connected
to tHE RTL8366RB it is all just dry coding.

I would suggest if you can test it just make a basic patch that will
at least turn on the LEDs to some default setting that works for
you?

> I though that maybe we could setup a LED driver to expose the LEDs
> status in sysfs. However, I'm not sure it is worth it. If you change a
> LED behavior, it would break the HW triggering rule for all the group.
> I'm not sure the LED API is ready to expose LEDs with related fate. It
> would, indeed, be useful as a readonly source or just to
> enable/disable a LED.

The LED subsystem supports hardware triggering etc thanks to the
elaborate work by Christian (ansuel). You can see an example of how
this is done in:
drivers/net/dsa/qca/qca8k-leds.c

Christian also extended the LEDs subsystem with the necessary
callbacks to support HW-backed LED control.

This can be used already to achieve HW triggers for the LEDs
from sysfs. (See callbacks .hw_control_is_supported,
.hw_control_set etc etc).

I was working to implement this for the Marvell switches but Andrew
wanted to do some more structured approach with a LED library
for DSA switches.

Yours,
Linus Walleij