Hi!

> Many PHYs support various HW control modes for LEDs connected directly
> to them.
> 
> This code adds a new private LED trigger called phydev-hw-mode. When
> this trigger is enabled for a LED, the various HW control modes which
> the PHY supports for given LED can be get/set via hw_mode sysfs file.
> 
> A PHY driver wishing to utilize this API needs to register the LEDs on
> its own and set the .trigger_type member of LED classdev to
> &phy_hw_led_trig_type. It also needs to implement the methods
> .led_iter_hw_mode, .led_set_hw_mode and .led_get_hw_mode in struct
> phydev.
> 
> Signed-off-by: Marek Behún <marek.behun@nic.cz>

Nothing too wrong.

New sysfs file will require documentation.

Plus I wonder: should we have single hw_mode file? It seems many
different "bits" fit inside. Would it be possible to split it further,
and have bits saying:

"I want the LED to be on if link is 10Mbps".
"I want the LED to be on if link is 100Mbps".
"I want the LED to be on if link is 1000Mbps".
"I want the LED to blink on tx".
"I want the LED to blink on rx".

?

+       { "1Gbps/100Mbps/10Mbps",       { 0x2,  -1,  -1,  -1,  -1,
+       { "1Gbps",                      { 0x7,  -1,  -1,  -1,  -1,
+       { "100Mbps-fiber",              {  -1, 0x5,  -1,  -1,  -1,
+       { "100Mbps-10Mbps",             {  -1, 0x5,  -1,  -1,  -1,
+       { "1Gbps-100Mbps",              {  -1, 0x6,  -1,  -1,  -1,
+       { "1Gbps-10Mbps",               {  -1,  -1, 0x6, 0x6,  -1,
+       { "100Mbps",                    {  -1, 0x7,  -1,  -1,  -1,
+       { "10Mbps",                     {  -1,  -1, 0x7,  -1,  -1,

Best regards,
									Pavel

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