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:
signature.asc
Description: PGP signature
