Re: lets settle the LED `function` property regarding the netdev trigger

[Andrew Lunn <andrew@lunn.ch>]

> 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