Hi!

quoted

quoted

quoted

quoted

Pavel, one point of the discussion is that in this case the LED
is controlled by MAC, not PHY. So the question is whether we
want to do "ethmacN" (in addition to "ethphyN").    

Sorry, I missed that. I guess that yes, ethmacX is okay, too.

Even better would be to find common term that could be used for
both ethmacN and ethphyN and just use that. (Except that we want
to avoid ethX). Maybe "ethportX" would be suitable?  

See
  https://lore.kernel.org/linux-leds/YQAlPrF2uu3Gr+0d@lunn.ch/ (local)
and
  https://lore.kernel.org/linux-leds/20210727172828.1529c764@thinkpad/ (local)
 

Ok, I guess I'd preffer all LEDs corresponding to one port to be
grouped, but that may be hard to do.

Hi Pavel (and Andrew),

The thing is that normally we are creating LED classdevs when the
parent device is probed. In this case when the PHY is probed. But we
will know the corresponding MAC only once the PHY is attached to it's
network interface.

Also, a PHY may be theoretically attached to multiple different
interfaces during it's lifetime. I guess there isn't many boards
currently that have such a configuration wired (maybe none), but
kernel's API is prepared for this.

So we really can't group them under one parent device, unless:

Ok, I guess my proposal is just too complex to implement. Let's go
with "ethmacN" + "ethphyN".

Best regards,

								Pavel
-- 
http://www.livejournal.com/~pavelmachek