> I really don't think we should be registering any LEDs in the PHY driver > if the driver does not know whether there are LEDs connected to the PHY. > > If this information is not available (via device-tree or some other > method, for example USB vendor/device table), then we can't register a > LED and let user control it. > > What if the pin is used for something different on a board? There is some danger here. Some hardware misuse LED outputs for WoL interrupts. There is even m88e1318_set_wol() which sets up LED2 for WoL. So i will need to review the PHY drivers to look out for this, and maybe add some restrictions. But i think we have little choice but to export all the LEDs a PHY supports. USB vendor/product, PCI vendor/product does not give us anything useful. How many OEMs take a lan78xx chip, created a USB dongle and shipped it using USB enumeration data: LAN78XX_USB_VENDOR_ID:LAN7800_USB_PRODUCT_ID. How many motherboards have a r8169 PCIe device using realteks PCI enumeration data? There is no useful source of information in devices like this. But what we do know is that the PHY can control X LED output pins, and we know what patterns it can blink those LED pins. So we export them, and let the user figure it out. This is the general case. If we have DT, or ACPI, or some other source, we can then refine this representation. If we have LED information, but a specific LED is missing from DT, don't export it. If the colour is available, use that in the name. If the default mode information is available, configure it that way, etc. Now, it could be we don't start with this, we just export those that do have DT. But i will want to ensure that the API/ABI we define is generic enough to support this. We need to start somewhere, get some basic support merged, and then do incremental improvements. Andrew
