Hi! > > > > > 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@xxxxxxx/ > > > and > > > https://lore.kernel.org/linux-leds/20210727172828.1529c764@thinkpad/ > > > > > > > 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
Attachment:
signature.asc
Description: PGP signature
