On Thu, 22 Jul 2021 03:45:21 +0200 Andrew Lunn <andrew@xxxxxxx> wrote: > On Thu, Jul 22, 2021 at 12:45:06AM +0200, Pavel Machek wrote: > > Hi! > > > > > Also, function is totally unclear. The whole reason we want to use > > > Linux LEDs is triggers, and it is the selected trigger which > > > determines the function. > > > > Usually, yes. But "function" is what _manufacturer_ wanted LED to > > mean > > So you are saying the function should be the reset default of the PHY, > or MAC? Pavel is talking about the manufacturer of the whole device, not just the controller. For example on Turris Omnia there are icons over the LEDs indicating their function. There are other devices, for example ethernet switches, with LEDs dedicated to indicate specific things, and these do not necessarily have to be the same as the LED controller default. Of course the problem is that we are not always able to determine this from kernel. In the case of ethernet PHYs I would not create LED classdevs unless they are defined in DTS/ACPI. In the case of igc I am not exactly sure if the driver should register these LEDs. What if they the manufacturer did not connected LEDs to all 3 pins, but only 1, for example? Or used the LED pin for some other funtion, like GPIO (if igc supports it)? Do we want to create LED classdevs for potentially nonexistent LEDs? If yes, then I guess the function should be the reset default. Marek
