Yet another ethernet PHY LED control proposal

Yet another ethernet PHY LED control proposal

[Marek Behun]

Hello,

I have been thinking about another way to implement ABI for HW control
of ethernet PHY connected LEDs.

This proposal is inspired by the fact that for some time there is a
movement in the kernel to do transparent HW offloading of things (DSA
is an example of that).

So currently we have the `netdev` trigger. When this is enabled for a
LED, new files will appear in that LED's sysfs directory:
  - `device_name` where user is supposed to write interface name
  - `link` if set to 1, the LED will be ON if the interface is linked
  - `rx` if set to 1, the LED will blink on receive event
  - `tx` if set to 1, the LED will blink on transmit event
  - `interval` specifies duration of the LED blink

Now what is interesting is that almost all combinations of link/rx/tx
settings are offloadable to a Marvell PHY! (Not to all LEDs, though...)

So what if we abandoned the idea of a `hw` trigger, and instead just
allowed a LED trigger to be offloadable, if that specific LED supports
it?

For the HW mode for different speed we can just expand the `link` sysfs
file ABI, so that if user writes a specific speed to this file, instead
of just "1", the LED will be on if the interface is linked on that
specific speed. Or maybe another sysfs file could be used for "light on
N mbps" setting...

Afterwards we can figure out other possible modes.

What do you think?

Marek

Re: Yet another ethernet PHY LED control proposal

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Hi!

> I have been thinking about another way to implement ABI for HW control
> of ethernet PHY connected LEDs.
> 
> This proposal is inspired by the fact that for some time there is a
> movement in the kernel to do transparent HW offloading of things (DSA
> is an example of that).

And it is good proposal.

> So currently we have the `netdev` trigger. When this is enabled for a
> LED, new files will appear in that LED's sysfs directory:
>   - `device_name` where user is supposed to write interface name
>   - `link` if set to 1, the LED will be ON if the interface is linked
>   - `rx` if set to 1, the LED will blink on receive event
>   - `tx` if set to 1, the LED will blink on transmit event
>   - `interval` specifies duration of the LED blink
> 
> Now what is interesting is that almost all combinations of link/rx/tx
> settings are offloadable to a Marvell PHY! (Not to all LEDs, though...)
> 
> So what if we abandoned the idea of a `hw` trigger, and instead just
> allowed a LED trigger to be offloadable, if that specific LED supports
> it?
> 
> For the HW mode for different speed we can just expand the `link` sysfs
> file ABI, so that if user writes a specific speed to this file, instead
> of just "1", the LED will be on if the interface is linked on that
> specific speed. Or maybe another sysfs file could be used for "light on
> N mbps" setting...
> 
> Afterwards we can figure out other possible modes.
> 
> What do you think?

If this can be implemented (and it probably can) it is the best
solution :-).

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]