> Thanks for the quick clarification. Because you mention this, I realised that > the RTL8382's LED controller is actually not in the PHYs. These SoCs use > external PHYs, which may have their own, independent, LED controllers. For > example the RTL8212D [1]. > > [1] > https://datasheet.lcsc.com/lcsc/2203252253_Realtek-Semicon-RTL8218D-CG_C2901898.pdf > > > > > But the point is, the PHYs will probe if listed. They don't have to > > have a MAC pointing to them with a phandle. So the phydev will exist, > > and that should be enough to get the LED class device registered. If > > there is basic on/off support, that should be enough for you to attach > > the Morse code panic trigger, the heartbeat handler, or any other LED > > trigger. > > OK, this makes sense for (external) PHYs which need to be probed anyway to have > access to the LEDs. > > Looking at the RTL8212D's datasheet (Table 11, p. 24), it appears to be possible > to assign an LED to any of the eight PHYs. Perhaps to allow more freedom in the > board layout. Maybe I'm just not seeing it, but I don't think the example with > an 'leds' node under a PHY contains enough information to perform such a non- > trivial mapping. On the other hand, I'm not sure where else that info might go. The binding is defining all the generic properties need for generic PHY LED. For most PHYs, it is probably sufficient. However, there is nothing stopping you from adding PHY specific properties. So for example, for each PHY LED you could have a property which maps it to a LED00-LED35. So propose a binding for the RTL8218D with whatever extra properties you think are needed, and it will be reviewed in the normal way. Andrew
