Re: [PATCH net-next 5/5] igc: Export LEDs

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 19.07.2021 02:40, Andrew Lunn wrote:
>> In general I'm not sure using the LED API provides a benefit here.
>> The brightness attribute is simply misused. Maybe better add
>> a sysfs attribute like led_mode under the netdev sysfs entry?
> 
> I _think_ you can put LED sys files other places than
> /sys/class/led. It should be possible to put them into netdev sysfs
> directory. However you need to consider what affect network name
> spaces have on this and what happens when an interface changes
> namespace.
> 

I checked the LED subsystem and didn't find a way to place the LED
sysfs files in a place other than /sys/class/leds. Maybe Pavel can
comment on whether I just missed something.
To avoid the network namespace issues we could use the PCI device
name in the LED name, but this would be quite unfriendly to the
user.

For r8169 I'm facing a similar challenge like Kurt. Most family
members support three LED's:
- Per LED a mode 0 .. 15 can be set that defines which link speed(s)
  and/or activity is indicated.
- Period and duty cycle for blinking can be controlled, but this
  setting applies to all three LED's.

For testing purposes I created sysfs attributes led0, led1, led2,
period, duty and assigned the attribute group to netdev->sysfs_groups[0].
This works fine and all attributes are under /sys/class/net/<ifname>.
Only drawback is that you need to know which trigger mode is set by
values 0..15. However this can be documented in sysfs attribute
documentation under Documentation/ABI/testing.

For using the LED subsystem and triggers two things would have to be
solved:
- How to deal with network device name changes so that the user still
  can identify that a LED belongs to a certain network device.
- How to properly deal with attributes that are shared by a group of
  LED's?

>      Andrew
> .
> 
Heiner

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> I checked the LED subsystem and didn't find a way to place the LED
> sysfs files in a place other than /sys/class/leds. Maybe Pavel can
> comment on whether I just missed something.

https://lwn.net/ml/linux-kernel/20200908000300.6982-1-marek.behun@nic.cz/

It comments the sys files appear under
/sys/class/net/<ifname>/phydev/leds/. phydev is a symbolic link to the
phy devices, provided by the phydev subsystem. So they are actually
attached to the PHY device. And this appears to be due to:

	ret = devm_led_classdev_register_ext(&phydev->mdio.dev, &led->cdev, &init_data);

The LEDs are parented to the phy device. This has the nice side affect
that PHYs are not part of the network name space. You can rename the
interface, /sys/class/net/<ifname> changes, but the symbolic link
still points to the phy device.

When not using phydev, it probably gets trickier. You probably want
the LEDs parented to the PCI device, and you need to follow a
different symbolic link out of /sys/class/net/<ifname>/ to find the
LED.

There was talk of adding an ledtool, which knows about these
links. But i pushed for it to be added to ethtool. Until we get an
implementation actually merged, that is academic.

> For r8169 I'm facing a similar challenge like Kurt. Most family
> members support three LED's:
> - Per LED a mode 0 .. 15 can be set that defines which link speed(s)
>   and/or activity is indicated.
> - Period and duty cycle for blinking can be controlled, but this
>   setting applies to all three LED's.

Cross LED settings is a problem. The Marvell PHYs have a number of
independent modes. Plus they have some shared modes which cross LEDs.
At the moment, there is no good model for these shared modes.

We have to look at the trade offs here. At the moment we have at least
3 different ways of setting PHY LEDs via DT. Because each driver does
it its own way, it probably allows full access to all features. But it
is very unfriendly. Adopting Linux LEDs allows us to have a single
uniform API for all these PHY LEDs, and probably all MAC drivers which
don't use PHY drivers. But at the expense of probably not supporting
all features of the hardware. My opinion is, we should ignore some of
the hardware features in order to get a simple to use uniform
interface for all LEDs, which probably covers the features most people
are interested in anyway.

	Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 20.07.2021 17:42, Andrew Lunn wrote:
>> I checked the LED subsystem and didn't find a way to place the LED
>> sysfs files in a place other than /sys/class/leds. Maybe Pavel can
>> comment on whether I just missed something.
> 
> https://lwn.net/ml/linux-kernel/20200908000300.6982-1-marek.behun@nic.cz/
> 
> It comments the sys files appear under
> /sys/class/net/<ifname>/phydev/leds/. phydev is a symbolic link to the
> phy devices, provided by the phydev subsystem. So they are actually
> attached to the PHY device. And this appears to be due to:
> 
> 	ret = devm_led_classdev_register_ext(&phydev->mdio.dev, &led->cdev, &init_data);
> 
> The LEDs are parented to the phy device. This has the nice side affect
> that PHYs are not part of the network name space. You can rename the
> interface, /sys/class/net/<ifname> changes, but the symbolic link
> still points to the phy device.
> 
> When not using phydev, it probably gets trickier. You probably want
> the LEDs parented to the PCI device, and you need to follow a
> different symbolic link out of /sys/class/net/<ifname>/ to find the
> LED.
> 
> There was talk of adding an ledtool, which knows about these
> links. But i pushed for it to be added to ethtool. Until we get an
> implementation actually merged, that is academic.
> 
>> For r8169 I'm facing a similar challenge like Kurt. Most family
>> members support three LED's:
>> - Per LED a mode 0 .. 15 can be set that defines which link speed(s)
>>   and/or activity is indicated.
>> - Period and duty cycle for blinking can be controlled, but this
>>   setting applies to all three LED's.
> 
> Cross LED settings is a problem. The Marvell PHYs have a number of
> independent modes. Plus they have some shared modes which cross LEDs.
> At the moment, there is no good model for these shared modes.
> 
> We have to look at the trade offs here. At the moment we have at least
> 3 different ways of setting PHY LEDs via DT. Because each driver does
> it its own way, it probably allows full access to all features. But it
> is very unfriendly. Adopting Linux LEDs allows us to have a single
> uniform API for all these PHY LEDs, and probably all MAC drivers which
> don't use PHY drivers. But at the expense of probably not supporting
> all features of the hardware. My opinion is, we should ignore some of
> the hardware features in order to get a simple to use uniform
> interface for all LEDs, which probably covers the features most people
> are interested in anyway.
> 

Thanks for the hint, Andrew. If I make &netdev->dev the parent,
then I get:

ll /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2

Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
the primary LED devices are under /sys/class/leds and their names have
to be unique therefore. The LED subsystem takes care of unique names,
but in case of a second network interface the LED device name suddenly
would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
that's not what we want.
We could use something like led0_<pci_id>, but then userspace would have
to do echo foo > /sys/class/net/<ifname>/led0*/bar, and that's also not
nice.

> 	Andrew
> 
Heiner

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> Thanks for the hint, Andrew. If I make &netdev->dev the parent,
> then I get:
> 
> ll /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2
> 
> Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
> the primary LED devices are under /sys/class/leds and their names have
> to be unique therefore. The LED subsystem takes care of unique names,
> but in case of a second network interface the LED device name suddenly
> would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
> that's not what we want.

We need input from the LED maintainers, but do we actually need the
symbolic links in /sys/class/leds/? For this specific use case, not
generally. Allow an LED to opt out of the /sys/class/leds symlink.

If we could drop those, we can relax the naming requirements so that
the names is unique to a parent device, not globally unique.

    Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 21.07.2021 16:35, Andrew Lunn wrote:
>> Thanks for the hint, Andrew. If I make &netdev->dev the parent,
>> then I get:
>>
>> ll /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2
>>
>> Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
>> the primary LED devices are under /sys/class/leds and their names have
>> to be unique therefore. The LED subsystem takes care of unique names,
>> but in case of a second network interface the LED device name suddenly
>> would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
>> that's not what we want.
> 
> We need input from the LED maintainers, but do we actually need the
> symbolic links in /sys/class/leds/? For this specific use case, not
> generally. Allow an LED to opt out of the /sys/class/leds symlink.
> 

The links are created here:

led_classdev_register_ext()
-> device_create_with_groups()
   -> device_add()
      -> device_add_class_symlinks()

So it seems we'd need an extension to the device core to support
class link opt-out.

> If we could drop those, we can relax the naming requirements so that
> the names is unique to a parent device, not globally unique.
> 
>     Andrew
> 
Heiner

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Wed 2021-07-21 16:35:27, Andrew Lunn wrote:
> > Thanks for the hint, Andrew. If I make &netdev->dev the parent,
> > then I get:
> > 
> > ll /sys/class/leds/
> > total 0
> > lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
> > lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
> > lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2
> > 
> > Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
> > the primary LED devices are under /sys/class/leds and their names have
> > to be unique therefore. The LED subsystem takes care of unique names,
> > but in case of a second network interface the LED device name suddenly
> > would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
> > that's not what we want.
> 
> We need input from the LED maintainers, but do we actually need the
> symbolic links in /sys/class/leds/? For this specific use case, not
> generally. Allow an LED to opt out of the /sys/class/leds symlink.
> 
> If we could drop those, we can relax the naming requirements so that
> the names is unique to a parent device, not globally unique.

Well, I believe we already negotiated acceptable naming with
Marek... Is it unsuitable for some reason?



-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Hi!

> > > Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
> > > the primary LED devices are under /sys/class/leds and their names have
> > > to be unique therefore. The LED subsystem takes care of unique names,
> > > but in case of a second network interface the LED device name suddenly
> > > would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
> > > that's not what we want.
> > 
> > We need input from the LED maintainers, but do we actually need the
> > symbolic links in /sys/class/leds/? For this specific use case, not
> > generally. Allow an LED to opt out of the /sys/class/leds symlink.
> > 
> > If we could drop those, we can relax the naming requirements so that
> > the names is unique to a parent device, not globally unique.
> 
> Well, I believe we already negotiated acceptable naming with
> Marek... Is it unsuitable for some reason?

Sorry, hit send too soon.. Marek is now in cc list.

								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Tue, 20 Jul 2021 22:29:21 +0200
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> On 20.07.2021 17:42, Andrew Lunn wrote:
> >> I checked the LED subsystem and didn't find a way to place the LED
> >> sysfs files in a place other than /sys/class/leds. Maybe Pavel can
> >> comment on whether I just missed something.  
> > 
> > https://lwn.net/ml/linux-kernel/20200908000300.6982-1-marek.behun@nic.cz/
> > 
> > It comments the sys files appear under
> > /sys/class/net/<ifname>/phydev/leds/. phydev is a symbolic link to the
> > phy devices, provided by the phydev subsystem. So they are actually
> > attached to the PHY device. And this appears to be due to:
> > 
> > 	ret = devm_led_classdev_register_ext(&phydev->mdio.dev, &led->cdev, &init_data);
> > 
> > The LEDs are parented to the phy device. This has the nice side affect
> > that PHYs are not part of the network name space. You can rename the
> > interface, /sys/class/net/<ifname> changes, but the symbolic link
> > still points to the phy device.
> > 
> > When not using phydev, it probably gets trickier. You probably want
> > the LEDs parented to the PCI device, and you need to follow a
> > different symbolic link out of /sys/class/net/<ifname>/ to find the
> > LED.
> > 
> > There was talk of adding an ledtool, which knows about these
> > links. But i pushed for it to be added to ethtool. Until we get an
> > implementation actually merged, that is academic.
> >   
> >> For r8169 I'm facing a similar challenge like Kurt. Most family
> >> members support three LED's:
> >> - Per LED a mode 0 .. 15 can be set that defines which link speed(s)
> >>   and/or activity is indicated.
> >> - Period and duty cycle for blinking can be controlled, but this
> >>   setting applies to all three LED's.  
> > 
> > Cross LED settings is a problem. The Marvell PHYs have a number of
> > independent modes. Plus they have some shared modes which cross LEDs.
> > At the moment, there is no good model for these shared modes.
> > 
> > We have to look at the trade offs here. At the moment we have at least
> > 3 different ways of setting PHY LEDs via DT. Because each driver does
> > it its own way, it probably allows full access to all features. But it
> > is very unfriendly. Adopting Linux LEDs allows us to have a single
> > uniform API for all these PHY LEDs, and probably all MAC drivers which
> > don't use PHY drivers. But at the expense of probably not supporting
> > all features of the hardware. My opinion is, we should ignore some of
> > the hardware features in order to get a simple to use uniform
> > interface for all LEDs, which probably covers the features most people
> > are interested in anyway.
> >   
> 
> Thanks for the hint, Andrew. If I make &netdev->dev the parent,
> then I get:
> 
> ll /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2
> 
> Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
> the primary LED devices are under /sys/class/leds and their names have
> to be unique therefore. The LED subsystem takes care of unique names,
> but in case of a second network interface the LED device name suddenly
> would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
> that's not what we want.
> We could use something like led0_<pci_id>, but then userspace would have
> to do echo foo > /sys/class/net/<ifname>/led0*/bar, and that's also not
> nice.

Hi Heiner,

in sysfs, all devices registered under LED class will have symlinks in
/sys/class/leds. This is how device classes work in Linux.

There is a standardized format for LED device names, please look at
Documentation/leds/leds-class.rst.

Basically the LED name is of the format
  devicename:color:function

The list of colors and functions is defined in
  include/dt-bindings/leds/common.h

The function part of the LED is also supposed to (in the future)
specify trigger, i.e. something like:
  if the function is "activity", the LED should blink on network
  activity
(Note that there is not yet a consensus. Jacek, for example, is of the
 opinion that the "activity" function should imply the CPU activity
 trigger. I think that "activity" function together with trigger-source
 defined to be a network device should imply network activity.)

Does your driver register the LEDs based on device-tree?

If so, then LED core will compose the name for the device for you.

If not, then you need to compose the name (in the above format)
yourself.

Are your LEDs controlled by an ethernet PHY, or by the MAC itself?

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> Hi Heiner,
> 
> in sysfs, all devices registered under LED class will have symlinks in
> /sys/class/leds. This is how device classes work in Linux.
> 
> There is a standardized format for LED device names, please look at
> Documentation/leds/leds-class.rst.
> 
> Basically the LED name is of the format
>   devicename:color:function

The interesting part here is, what does devicename mean, in this
context?

We cannot use the interface name, because it is not unique, and user
space can change it whenever it wants. So we probably need to build
something around the bus ID, e.g. pci_id. Which is not very friendly
:-(

	Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Wed, 21 Jul 2021 21:50:07 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > Hi Heiner,
> > 
> > in sysfs, all devices registered under LED class will have symlinks in
> > /sys/class/leds. This is how device classes work in Linux.
> > 
> > There is a standardized format for LED device names, please look at
> > Documentation/leds/leds-class.rst.
> > 
> > Basically the LED name is of the format
> >   devicename:color:function  
> 
> The interesting part here is, what does devicename mean, in this
> context?
> 
> We cannot use the interface name, because it is not unique, and user
> space can change it whenever it wants. So we probably need to build
> something around the bus ID, e.g. pci_id. Which is not very friendly
> :-(

Unfortunately there isn't consensus about what the devicename should
mean. There are two "schools of thought":

1. device name of the trigger source for the LED, i.e. if the LED
   blinks on activity on mmc0, the devicename should be mmc0. We have
   talked about this in the discussions about ethernet PHYs.
   In the case of the igc driver if the LEDs are controlled by the MAC,
   I guess some PCI identifier would be OK. Or maybe ethernet-mac
   identifier, if we have something like that? (Since we can't use
   interface names due to the possibility of renaming.)

   Pavel and I are supporters of this scheme.

2. device name of the LED controller. For example LEDs controlled by
   the maxim,max77650-led controller (leds-max77650.c) define device
   name as "max77650"

   Jacek supports this scheme.

The complication is that both these schemes are used already in
upstream kernel, and we have to maintain backwards compatibility of
sysfs ABI, so we can't change that.

I have been thinking for some time that maybe we should poll Linux
kernel developers about these two schemes, so that a consensus is
reached. Afterwards we can deprecate the other scheme and add a Kconfig
option (default n for backwards compatibility) to use the new scheme.

What do you think?

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> > > Basically the LED name is of the format
> > >   devicename:color:function  

> Unfortunately there isn't consensus about what the devicename should
> mean. There are two "schools of thought":
> 
> 1. device name of the trigger source for the LED, i.e. if the LED
>    blinks on activity on mmc0, the devicename should be mmc0. We have
>    talked about this in the discussions about ethernet PHYs.
>    In the case of the igc driver if the LEDs are controlled by the MAC,
>    I guess some PCI identifier would be OK.

I guess this is most likely for Ethernet LEDs, some sort of bus
identifier. But Ethernet makes use of all sorts of busses, so you will
also see USB, memory mapped for SOCs, MDIO, SPI, etc.

> 2. device name of the LED controller. For example LEDs controlled by
>    the maxim,max77650-led controller (leds-max77650.c) define device
>    name as "max77650"

And what happens when the controller is just a tiny bit of silicon in
the corner of something else, not a standalone device? Would this be
'igc', for LEDs controlled by the IGC Ethernet controller? 'mv88e6xxx'
for Marvell Ethernet switches? 

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.

Colour is also an issue. The IGC Ethernet controller has no idea what
colour the LEDs are in the RG-45 socket. And this is generic to
Ethernet MAC and PHY chips. The data sheets never mention colour.  You
might know the colour in DT (and maybe ACPI) systems where you have
specific information about the board. But in for PCIe card, USB
dongles, etc, colour is unknown.

So very little of the naming scheme actually makes sense in this
context.

	 Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Wed, 21 Jul 2021 22:54:36 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > > > Basically the LED name is of the format
> > > >   devicename:color:function    
> 
> > Unfortunately there isn't consensus about what the devicename should
> > mean. There are two "schools of thought":
> > 
> > 1. device name of the trigger source for the LED, i.e. if the LED
> >    blinks on activity on mmc0, the devicename should be mmc0. We have
> >    talked about this in the discussions about ethernet PHYs.
> >    In the case of the igc driver if the LEDs are controlled by the MAC,
> >    I guess some PCI identifier would be OK.  
> 
> I guess this is most likely for Ethernet LEDs, some sort of bus
> identifier. But Ethernet makes use of all sorts of busses, so you will
> also see USB, memory mapped for SOCs, MDIO, SPI, etc.

That's why I think we should group them all under a name like ethmac0,
ethmac1, ... We want to do this for PHY controlled LEDs (ethphy0,
ethphy1, ...)

> > 2. device name of the LED controller. For example LEDs controlled by
> >    the maxim,max77650-led controller (leds-max77650.c) define device
> >    name as "max77650"  
> 
> And what happens when the controller is just a tiny bit of silicon in
> the corner of something else, not a standalone device? Would this be
> 'igc', for LEDs controlled by the IGC Ethernet controller? 'mv88e6xxx'
> for Marvell Ethernet switches? 

This is one of the reasons why I prefer the first scheme.

> 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.

As I said there are two "schools of thought" for this as well.
Devicetree deprecated the `linux,default-trigger` DT property and
`function` property should be used instead. Jacek's then defined some
function definition constants in include/dt-bindings/leds/common.h and
sent a proposal for function to trigger mappings
  https://lore.kernel.org/linux-leds/20200920162625.14754-1-jacek.anaszewski@gmail.com/
But this was not implemented, and I together with Pavel do not agree
with this proposal, and I proposed something different:
  https://lore.kernel.org/linux-leds/20200920184422.60c04194@nic.cz/
Since function to trigger mappings is not yet implemented in the code,
we can still decide.

Do you think I should a poll more kernel developers about their
opinions?

> Colour is also an issue. The IGC Ethernet controller has no idea what
> colour the LEDs are in the RG-45 socket. And this is generic to
> Ethernet MAC and PHY chips. The data sheets never mention colour.  You
> might know the colour in DT (and maybe ACPI) systems where you have
> specific information about the board. But in for PCIe card, USB
> dongles, etc, colour is unknown.

The LED core (function led_compose_name in drivers/leds/led-core.c)
skips color and function if they are not present in fwnode, i.e.
  "mmc0::"

I guess in the case of igc, if the color is not known, and if we can
agree on the first scheme for choosing the devicename part, then the
LED names could be, depending on the scheme for function, either
  "ethmac0::lan-0"
  "ethmac0::lan-1"
  "ethmac0::lan-2"
or
  "ethmac0::link"
  "ethmac0::activity"
  "ethmac0::rx"

(If there is color defined in ACPI / DTS though, it should be also
 used.)

So basically we need to decide on these two things:
- scheme for device name
- scheme for function to default trigger mappings

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Hi!

> 2. device name of the LED controller. For example LEDs controlled by
>    the maxim,max77650-led controller (leds-max77650.c) define device
>    name as "max77650"

This one is deprecated. Please don't introduce new cases of it.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

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, and "trigger" is how user is using it. I have currently disk
activity LED mapped on scrollock.

There are some mini desktops which have skull LED, probably meant to
be user defined LED. In such cases, user will have to select trigger.

> Colour is also an issue. The IGC Ethernet controller has no idea what
> colour the LEDs are in the RG-45 socket. And this is generic to
> Ethernet MAC and PHY chips. The data sheets never mention colour.

Maybe datasheet does not mention color, but the LED _has_ color.

> might know the colour in DT (and maybe ACPI) systems where you have
> specific information about the board. But in for PCIe card, USB
> dongles, etc, colour is unknown.

Not.. really. You don't know from chip specificiations, but you should
know the color as soon as you have USB IDs (because they should tell
you exact hardware). And I believe same is true for PCIe cards. It may
be more tricky if no actual PCIe card exists and it is just a chip
built into generic notebook. (But then, you should have notebook's DMI
id etc...?)

Anyway, you can leave the color field empty if you don't know.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

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?

> > Colour is also an issue. The IGC Ethernet controller has no idea what
> > colour the LEDs are in the RG-45 socket. And this is generic to
> > Ethernet MAC and PHY chips. The data sheets never mention colour.
> 
> Maybe datasheet does not mention color, but the LED _has_ color.

Sure it does, but the driver is for the LED controller, not the
LED. The controller does not care what colour the LED is. At least for
this application.

> > might know the colour in DT (and maybe ACPI) systems where you have
> > specific information about the board. But in for PCIe card, USB
> > dongles, etc, colour is unknown.
> 
> Not.. really. You don't know from chip specificiations, but you should
> know the color as soon as you have USB IDs (because they should tell
> you exact hardware).

No. All it tells you is what the controller is. The dongle manufacture
can pair any RJ-45 socket with the controller, and it is the RJ-45
socket which provides the LED.

> And I believe same is true for PCIe cards.

Also not true. The PCIe IDs tell you the controller. What RJ-45 socket
is connected is up to the board manufacture.

> Anyway, you can leave the color field empty if you don't know.

That is the more likely case.

     Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Thu, 22 Jul 2021 03:45:21 +0200
Andrew Lunn <andrew@lunn.ch> 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

Re: [PATCH net-next 5/5] igc: Export LEDs

[Florian Fainelli]

On 7/21/2021 1:07 PM, Marek Behún wrote:
> On Wed, 21 Jul 2021 21:50:07 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
>>> Hi Heiner,
>>>
>>> in sysfs, all devices registered under LED class will have symlinks in
>>> /sys/class/leds. This is how device classes work in Linux.
>>>
>>> There is a standardized format for LED device names, please look at
>>> Documentation/leds/leds-class.rst.
>>>
>>> Basically the LED name is of the format
>>>    devicename:color:function
>>
>> The interesting part here is, what does devicename mean, in this
>> context?
>>
>> We cannot use the interface name, because it is not unique, and user
>> space can change it whenever it wants. So we probably need to build
>> something around the bus ID, e.g. pci_id. Which is not very friendly
>> :-(
> 
> Unfortunately there isn't consensus about what the devicename should
> mean. There are two "schools of thought":
> 
> 1. device name of the trigger source for the LED, i.e. if the LED
>     blinks on activity on mmc0, the devicename should be mmc0. We have
>     talked about this in the discussions about ethernet PHYs.
>     In the case of the igc driver if the LEDs are controlled by the MAC,
>     I guess some PCI identifier would be OK. Or maybe ethernet-mac
>     identifier, if we have something like that? (Since we can't use
>     interface names due to the possibility of renaming.)
> 
>     Pavel and I are supporters of this scheme.
> 
> 2. device name of the LED controller. For example LEDs controlled by
>     the maxim,max77650-led controller (leds-max77650.c) define device
>     name as "max77650"
> 
>     Jacek supports this scheme.
> 
> The complication is that both these schemes are used already in
> upstream kernel, and we have to maintain backwards compatibility of
> sysfs ABI, so we can't change that.
> 
> I have been thinking for some time that maybe we should poll Linux
> kernel developers about these two schemes, so that a consensus is
> reached. Afterwards we can deprecate the other scheme and add a Kconfig
> option (default n for backwards compatibility) to use the new scheme.
> 
> What do you think?

FWIW, dev_name() should be the "devicename" from what you described 
above. This is foundational property for all devices that Linux 
registers that is used for logging, name spacing within /sys/, uniqe, 
ABI stable, etc. Anything different would be virtually impossible to 
maintain and would lead to ABI breakage down the road, guaranteed.

Yes it can be long (especially with PCI devices), and unfriendly, but 
hey, udev to the rescue then, rename based on user preferences.
-- 
Florian

Re: [PATCH net-next 5/5] igc: Export LEDs

[Jacek Anaszewski]

Hi Marek,

On 7/21/21 10:07 PM, Marek Behún wrote:
> On Wed, 21 Jul 2021 21:50:07 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
>>> Hi Heiner,
>>>
>>> in sysfs, all devices registered under LED class will have symlinks in
>>> /sys/class/leds. This is how device classes work in Linux.
>>>
>>> There is a standardized format for LED device names, please look at
>>> Documentation/leds/leds-class.rst.
>>>
>>> Basically the LED name is of the format
>>>    devicename:color:function
>>
>> The interesting part here is, what does devicename mean, in this
>> context?
>>
>> We cannot use the interface name, because it is not unique, and user
>> space can change it whenever it wants. So we probably need to build
>> something around the bus ID, e.g. pci_id. Which is not very friendly
>> :-(
> 
> Unfortunately there isn't consensus about what the devicename should
> mean. There are two "schools of thought":
> 
> 1. device name of the trigger source for the LED, i.e. if the LED
>     blinks on activity on mmc0, the devicename should be mmc0. We have
>     talked about this in the discussions about ethernet PHYs.
>     In the case of the igc driver if the LEDs are controlled by the MAC,
>     I guess some PCI identifier would be OK. Or maybe ethernet-mac
>     identifier, if we have something like that? (Since we can't use
>     interface names due to the possibility of renaming.)
> 
>     Pavel and I are supporters of this scheme.
> 
> 2. device name of the LED controller. For example LEDs controlled by
>     the maxim,max77650-led controller (leds-max77650.c) define device
>     name as "max77650"
> 
>     Jacek supports this scheme.

I believe you must have misinterpreted some my of my statements.
The whole effort behind LED naming unification was getting rid of
hardware device names in favour of Linux provided device names.
See e.g. the excerpt from Documentation/leds/leds-class.rst:

- devicename:
         it should refer to a unique identifier created by the kernel,
         like e.g. phyN for network devices or inputN for input devices, 
rather
         than to the hardware; the information related to the product 
and the bus
         to which given device is hooked is available in sysfs and can be
         retrieved using get_led_device_info.sh script from tools/leds; 
generally
         this section is expected mostly for LEDs that are somehow 
associated with
         other devices.


-- 
Best regards,
Jacek Anaszewski

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Mon, 26 Jul 2021 19:42:04 +0200
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:

> I believe you must have misinterpreted some my of my statements.
> The whole effort behind LED naming unification was getting rid of
> hardware device names in favour of Linux provided device names.

Hi Jacek,

sorry about that. I don't know how this could have happened :D

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 26.07.2021 19:42, Jacek Anaszewski wrote:
> Hi Marek,
> 
> On 7/21/21 10:07 PM, Marek Behún wrote:
>> On Wed, 21 Jul 2021 21:50:07 +0200
>> Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>>> Hi Heiner,
>>>>
>>>> in sysfs, all devices registered under LED class will have symlinks in
>>>> /sys/class/leds. This is how device classes work in Linux.
>>>>
>>>> There is a standardized format for LED device names, please look at
>>>> Documentation/leds/leds-class.rst.
>>>>
>>>> Basically the LED name is of the format
>>>>    devicename:color:function
>>>
>>> The interesting part here is, what does devicename mean, in this
>>> context?
>>>
>>> We cannot use the interface name, because it is not unique, and user
>>> space can change it whenever it wants. So we probably need to build
>>> something around the bus ID, e.g. pci_id. Which is not very friendly
>>> :-(
>>
>> Unfortunately there isn't consensus about what the devicename should
>> mean. There are two "schools of thought":
>>
>> 1. device name of the trigger source for the LED, i.e. if the LED
>>     blinks on activity on mmc0, the devicename should be mmc0. We have
>>     talked about this in the discussions about ethernet PHYs.
>>     In the case of the igc driver if the LEDs are controlled by the MAC,
>>     I guess some PCI identifier would be OK. Or maybe ethernet-mac
>>     identifier, if we have something like that? (Since we can't use
>>     interface names due to the possibility of renaming.)
>>
>>     Pavel and I are supporters of this scheme.
>>
>> 2. device name of the LED controller. For example LEDs controlled by
>>     the maxim,max77650-led controller (leds-max77650.c) define device
>>     name as "max77650"
>>
>>     Jacek supports this scheme.
> 
> I believe you must have misinterpreted some my of my statements.
> The whole effort behind LED naming unification was getting rid of
> hardware device names in favour of Linux provided device names.
> See e.g. the excerpt from Documentation/leds/leds-class.rst:
> 
> - devicename:
>         it should refer to a unique identifier created by the kernel,
>         like e.g. phyN for network devices or inputN for input devices, rather
>         than to the hardware; the information related to the product and the bus
>         to which given device is hooked is available in sysfs and can be
>         retrieved using get_led_device_info.sh script from tools/leds; generally
>         this section is expected mostly for LEDs that are somehow associated with
>         other devices.
> 
> 
The issue with this is mentioned by Andrew a few lines before. At least in
network subsystem the kernel identifiers can be changed from userspace.
Typical example is the interface renaming from eth0 to e.g. enp1s0.
Then a LED eth0-led1 would have to be automagically renamed to enp1s0-led1.
An option for this could be to make a LED renaming function subscribe to
interface name change notifications. But this looks to me to like using a
quite big hammer for a rather small nail.

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hi Heiner (and Pavel and Florian and others),

On Mon, 26 Jul 2021 22:59:05 +0200
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> The issue with this is mentioned by Andrew a few lines before. At least in
> network subsystem the kernel identifiers can be changed from userspace.
> Typical example is the interface renaming from eth0 to e.g. enp1s0.
> Then a LED eth0-led1 would have to be automagically renamed to enp1s0-led1.
> An option for this could be to make a LED renaming function subscribe to
> interface name change notifications. But this looks to me to like using a
> quite big hammer for a rather small nail.

We are not going to be renaming LEDs on inteface rename, that can
introduce a set of problems on it's own.

Yes, if network interface renaming were not possible, the best option
would be to use interface names. It is not possible.

The last time we discussed this (Andrew, Pavel and I), we've decided
that for ethernet PHY controlled LEDs we want the devicename part
should be something like
   phyN  or  ethphyN  or  ethernet-phyN
with N a number unique for every PHY (a simple atomically increased
integer for every ethernet PHY). (This is because the LED pin is
physically connected to the PHY.)

But we can't do this here, because in the case of this igc driver, the
LEDs are controlled by the MAC, not the PHY (as far as I understand).
Which means that the LED is connected to a pin on the SOC or MAC chip.

Florian's suggestion is to use dev_name(), he says:
  FWIW, dev_name() should be the "devicename" from what you described 
  above. This is foundational property for all devices that Linux 
  registers that is used for logging, name spacing within /sys/, uniqe, 
  ABI stable, etc. Anything different would be virtually impossible to 
  maintain and would lead to ABI breakage down the road, guaranteed.

I understand this point of view, since the purpose of dev_name() is
to represent devices in userspace. And for the purpose of LED devicename
part it works beautifully sometimes, for block devices for example,
where the dev_name() is be mmc0, sda1, ...

The problem is that for other kind of devices dev_name() may contain the
':' character (and often it does), which can break parsing LED names,
since the LED name format also contains colons:
  devicename:color:function
So in the case of a block device, it works:
  mmc0::
  sda:red:read
  dm-0::write
But for a PCIe network controller it may contain too many colons:
  0000:02:00.0:yellow:activity

So basically this LED device naming scheme is the reason why we are
trying to make prettier names for LED trigger sources / controllers.

The possible solutions here are the following (the list is not
exhaustive):
- allow using devicenames containing ':' characters, i.e.
    0000:02:00.0:yellow:activity
  This can break existing userspace utilities (there are no official
  ones, though). But IMO it should be a viable solution since we can
  extract the devicename part, because we know that the color and
  function parts do not contain colons.

- substitute ':' characters with a different character in the devicename
  part

- use a prettier name, like we wanted to do with ethernet PHYs.

  The question is what do we want to do for MAC (instead of PHY)
  controlled LEDs, as is the case in this igc driver. We could introduce
  a simple atomically increased integer for every MAC, the same we want
  to do in the PHY case, so the devicename could be something like
  macN (or ethmacN or ethernet-macN)

I confess that I am growing a little frustrated here, because there
seems to be no optimal solution with given constraints and no official
consensus for a suboptimal yet acceptable solution.

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> The last time we discussed this (Andrew, Pavel and I), we've decided
> that for ethernet PHY controlled LEDs we want the devicename part
> should be something like
>    phyN  or  ethphyN  or  ethernet-phyN
> with N a number unique for every PHY (a simple atomically increased
> integer for every ethernet PHY).

We might want to rethink this. PHYs typically have 2 or 3 LEDs. So we
want a way to indicate which LED of a PHY it is. So i suspect we will
want something like

ethphyN-led0, ethphyN-led1, ethphyN-led2.

I would also suggest N starts at 42, in order to make it clear it is a
made up arbitrary number, it has no meaning other than it is
unique. What we don't want is people thinking ethphy0-led0 has
anything to do with eth0.

> I confess that I am growing a little frustrated here, because there
> seems to be no optimal solution with given constraints and no official
> consensus for a suboptimal yet acceptable solution.

I do think it is clear that the base name is mostly irrelevant and not
going to be used in any meaningful way. You are unlikely to access
these LEDs via /sys/class/leds. You are going to go into
/sys/class/net/<ifname> and then either follow the device symlink, or
the phydev symlink and look for LEDs there. And then only the -ledM
part of the name might be useful. Since the name is mostly
meaningless, we should just decide and move on.

     Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Michael Walle]

>> The last time we discussed this (Andrew, Pavel and I), we've decided
>> that for ethernet PHY controlled LEDs we want the devicename part
>> should be something like
>>    phyN  or  ethphyN  or  ethernet-phyN
>> with N a number unique for every PHY (a simple atomically increased
>> integer for every ethernet PHY).
>
> We might want to rethink this. PHYs typically have 2 or 3 LEDs. So we
> want a way to indicate which LED of a PHY it is. So i suspect we will
> want something like
>
> ethphyN-led0, ethphyN-led1, ethphyN-led2.
>
> I would also suggest N starts at 42, in order to make it clear it is a
> made up arbitrary number, it has no meaning other than it is
> unique. What we don't want is people thinking ethphy0-led0 has
> anything to do with eth0.

Why do we have to distiguish between LEDs connected to the PHY and LEDs
connected to the MAC at all? Why not just name it ethN either if its behind
the PHY or the MAC? Does it really matter from the users POV?

>> I confess that I am growing a little frustrated here, because there
>> seems to be no optimal solution with given constraints and no official
>> consensus for a suboptimal yet acceptable solution.
>
> I do think it is clear that the base name is mostly irrelevant and not
> going to be used in any meaningful way. You are unlikely to access
> these LEDs via /sys/class/leds. You are going to go into
> /sys/class/net/<ifname> and then either follow the device symlink, or
> the phydev symlink and look for LEDs there. And then only the -ledM
> part of the name might be useful. Since the name is mostly
> meaningless, we should just decide and move on.

Even more if it is not relevant ;)

-michael

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hi Andrew,

On Tue, 27 Jul 2021 03:57:13 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > The last time we discussed this (Andrew, Pavel and I), we've decided
> > that for ethernet PHY controlled LEDs we want the devicename part
> > should be something like
> >    phyN  or  ethphyN  or  ethernet-phyN
> > with N a number unique for every PHY (a simple atomically increased
> > integer for every ethernet PHY).  
> 
> We might want to rethink this. PHYs typically have 2 or 3 LEDs. So we
> want a way to indicate which LED of a PHY it is. So i suspect we will
> want something like
> 
> ethphyN-led0, ethphyN-led1, ethphyN-led2.

But... there is still color and function and possibly function-numerator
to differentiate them. I was talking only about the devicename part. So
for three LEDs you can have, for example:
  ethphyN:green:link
  ethphyN:yellow:activity
Even if you don't have information about color, the default function
(on chip reset) should be different. And even if it is not, the
function enumerator would fix this:
  ethphyN::link-1
  ethphyN::link-2

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hi Michael,

On Tue, 27 Jul 2021 10:15:28 +0200
Michael Walle <michael@walle.cc> wrote:

> Why do we have to distiguish between LEDs connected to the PHY and LEDs
> connected to the MAC at all? Why not just name it ethN either if its behind
> the PHY or the MAC? Does it really matter from the users POV?

Because
1. network interfaces can be renamed
2. network interfaces can be moved between network namespaces. The LED
   subsystem is agnostic to network namespaces
So it can for example happen that within a network namespace you
have only one interface, eth0, but in /sys/class/leds you would see
  eth0:green:activity
  eth1:green:activity
So you would know that there are at least 2 network interfaces on the
system, and also with renaming it can happen that the first LED is not
in fact connected to the eth0 interface in your network namespace.

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Michael Walle]

Hi,

Am 2021-07-27 16:56, schrieb Marek Behún:
> On Tue, 27 Jul 2021 10:15:28 +0200
> Michael Walle <michael@walle.cc> wrote:
> 
>> Why do we have to distiguish between LEDs connected to the PHY and 
>> LEDs
>> connected to the MAC at all? Why not just name it ethN either if its 
>> behind
>> the PHY or the MAC? Does it really matter from the users POV?
> 
> Because
> 1. network interfaces can be renamed
> 2. network interfaces can be moved between network namespaces. The LED
>    subsystem is agnostic to network namespaces

I wasn't talking about ethN being same as the network interface name.
For clarity I'll use ethernetN now. My question was why would you
use ethmacN or ethphyN instead if just ethernetN for both. What is
the reason for having two different names? I'm not sure who is using
that name anyway. If it is for an user, I don't think he is interested
in knowing wether that LED is controlled by the PHY or by the MAC.

> So it can for example happen that within a network namespace you
> have only one interface, eth0, but in /sys/class/leds you would see
>   eth0:green:activity
>   eth1:green:activity
> So you would know that there are at least 2 network interfaces on the
> system, and also with renaming it can happen that the first LED is not
> in fact connected to the eth0 interface in your network namespace.

But the first problem persists wether its named ethernetN or ethphyN,
no?

-michael

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> I wasn't talking about ethN being same as the network interface name.
> For clarity I'll use ethernetN now. My question was why would you
> use ethmacN or ethphyN instead if just ethernetN for both. What is
> the reason for having two different names?

We can get into the situation where both the MAC and the PHY have LED
controllers. So we need to ensure the infrastructure we put in place
handles this, we don't get any name clashes.

	Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hi,

On Tue, 27 Jul 2021 17:03:53 +0200
Michael Walle <michael@walle.cc> wrote:

> I wasn't talking about ethN being same as the network interface name.
> For clarity I'll use ethernetN now. My question was why would you
> use ethmacN or ethphyN instead if just ethernetN for both. What is
> the reason for having two different names? I'm not sure who is using
> that name anyway. If it is for an user, I don't think he is interested
> in knowing wether that LED is controlled by the PHY or by the MAC.

Suppose that the system has 2 ethernet MACs, each with an attached PHY.
Each MAC-PHY pair has one LED, but one MAC-PHY pair has the LED
attached to the MAC, and the second pair has the LED attached to the
PHY:
     +------+        +------+
     | macA |        | macB |
     +-+--+-+        +-+----+
       |  |            |
      /   +------+   +-+----+
   ledA   | phyA |   | phyB |
          +------+   +----+-+
                          |
                           \
                            ledB

Now suppose that during system initialization the system enumerates
MACs and PHYs in different order:
   macA -> 0      phyA -> 1
   macB -> 1      phyB -> 0

If we used the devicename as you are suggesting, then for the two LEDs
the devicename part would be the same:
  ledA -> macA -> ethernet0
  ledB -> phyB -> ethernet0
although they are clearly on different MACs.

We could create a simple atomically increasing index only for MACs, and
for a LED connected to a PHY, instead of using the PHY's index, we
would look at the attached MAC and use the MAC index.
The problem is that PHYs and MACs are not always attached, and are not
necessarily mapped 1-to-1. It is possible to have a board where one PHY
can connect to 2 different MACs and you can switch between them, and
also vice versa.

> > So it can for example happen that within a network namespace you
> > have only one interface, eth0, but in /sys/class/leds you would see
> >   eth0:green:activity
> >   eth1:green:activity
> > So you would know that there are at least 2 network interfaces on the
> > system, and also with renaming it can happen that the first LED is not
> > in fact connected to the eth0 interface in your network namespace.  
> 
> But the first problem persists wether its named ethernetN or ethphyN,
> no?

No. The N in the "ethphyN" for etherent PHYs is supposed to be unrelated
to the N in "ethN" for interface names. So if you have eth0 network
interface with attached phy ethphy0, this is a coincidence. (That is
why Andrew is proposing to start the index for PHYs at a different
number, like 42.)

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Michael Walle]

Hi,

Am 2021-07-27 17:28, schrieb Marek Behún:
> On Tue, 27 Jul 2021 17:03:53 +0200
> Michael Walle <michael@walle.cc> wrote:
> 
>> I wasn't talking about ethN being same as the network interface name.
>> For clarity I'll use ethernetN now. My question was why would you
>> use ethmacN or ethphyN instead if just ethernetN for both. What is
>> the reason for having two different names? I'm not sure who is using
>> that name anyway. If it is for an user, I don't think he is interested
>> in knowing wether that LED is controlled by the PHY or by the MAC.
> 
> Suppose that the system has 2 ethernet MACs, each with an attached PHY.
> Each MAC-PHY pair has one LED, but one MAC-PHY pair has the LED
> attached to the MAC, and the second pair has the LED attached to the
> PHY:
>      +------+        +------+
>      | macA |        | macB |
>      +-+--+-+        +-+----+
>        |  |            |
>       /   +------+   +-+----+
>    ledA   | phyA |   | phyB |
>           +------+   +----+-+
>                           |
>                            \
>                             ledB
> 
> Now suppose that during system initialization the system enumerates
> MACs and PHYs in different order:
>    macA -> 0      phyA -> 1
>    macB -> 1      phyB -> 0
> 
> If we used the devicename as you are suggesting, then for the two LEDs
> the devicename part would be the same:
>   ledA -> macA -> ethernet0
>   ledB -> phyB -> ethernet0
> although they are clearly on different MACs.

Why is that the case? Why can't both the MAC and the PHY request a 
unique
name from the same namespace? As Andrew pointed out, the names in
/sys/class/leds don't really matter. Ok, it will still depend on the
probe order which might not be the case if you split it between ethmac
and ethphy.

Sorry, if I may ask stupid questions here. I don't want to cause much
trouble, here. I was just wondering why we have to make up two different
(totally unrelated names to the network interface names) instead of just
one (again totally unrelated to the interface name and index).

> We could create a simple atomically increasing index only for MACs, and
> for a LED connected to a PHY, instead of using the PHY's index, we
> would look at the attached MAC and use the MAC index.

Oh, I see. I was assuming we are talking about "just a number" not
related to anything.

> The problem is that PHYs and MACs are not always attached, and are not
> necessarily mapped 1-to-1. It is possible to have a board where one PHY
> can connect to 2 different MACs and you can switch between them, and
> also vice versa.
> 
>> > So it can for example happen that within a network namespace you
>> > have only one interface, eth0, but in /sys/class/leds you would see
>> >   eth0:green:activity
>> >   eth1:green:activity
>> > So you would know that there are at least 2 network interfaces on the
>> > system, and also with renaming it can happen that the first LED is not
>> > in fact connected to the eth0 interface in your network namespace.
>> 
>> But the first problem persists wether its named ethernetN or ethphyN,
>> no?
> 
> No. The N in the "ethphyN" for etherent PHYs is supposed to be 
> unrelated
> to the N in "ethN" for interface names. So if you have eth0 network
> interface with attached phy ethphy0, this is a coincidence. (That is
> why Andrew is proposing to start the index for PHYs at a different
> number, like 42.)

Yes, in my case ethernet0 has nothing to do with eth0, either.

But I was actually referring to your "you see the leds in /sys/ of all
the network adapters". That problem still persists, right?

-michael

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> But I was actually referring to your "you see the leds in /sys/ of all
> the network adapters". That problem still persists, right?

It is not really a problem. You see all the PHYs in /sys. You see all
the PCI devices in /sys. Because these all have globally unique names,
it is not a problem.

What is not globally unique is interface names. Those are only unique
to a network name space. And /sys/class/net is network name space
aware. It only contains the interfaces in the current network name
space.

	Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hi,

On Tue, 27 Jul 2021 17:53:58 +0200
Michael Walle <michael@walle.cc> wrote:

> > If we used the devicename as you are suggesting, then for the two LEDs
> > the devicename part would be the same:
> >   ledA -> macA -> ethernet0
> >   ledB -> phyB -> ethernet0
> > although they are clearly on different MACs.  
> 
> Why is that the case? Why can't both the MAC and the PHY request a 
> unique name from the same namespace?

So all the network related devices should request a unique network
relate device ID? Should also wireless PHY devices do this? WWAN modems?
And all these should have the same template for devicename part withing
/sys/class/leds? What should be the template for the devicename, if
wireless PHYs and WWAN modems could also be part of this? It cannot be
"ethernet" anymore.

It seems a better idea to me to just some nice identifier for the LED
controller.

> As Andrew pointed out, the names in
> /sys/class/leds don't really matter. Ok, it will still depend on the
> probe order which might not be the case if you split it between ethmac
> and ethphy.

Yes, the LED name does not matter. But the LED subsystem requires names
in a specific format, this is already decided and documented, we are
not going to be changing this. The only reasonable thing we can do now
is to choose a sane devicename.

> Sorry, if I may ask stupid questions here. I don't want to cause much
> trouble, here. I was just wondering why we have to make up two different
> (totally unrelated names to the network interface names) instead of just
> one (again totally unrelated to the interface name and index).

It seems more logical to me from kernel's point of view.

> But I was actually referring to your "you see the leds in /sys/ of all
> the network adapters". That problem still persists, right?

Yes, this still persists. But we really do not want to start
introducing namespaces to the LED subsystem.

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> Yes, this still persists. But we really do not want to start
> introducing namespaces to the LED subsystem.

Agreed. LED names need to be globally unique, so we don't need to
worry about network name spaces.

      Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Michael Walle]

Am 2021-07-27 18:32, schrieb Marek Behún:
> On Tue, 27 Jul 2021 17:53:58 +0200
> Michael Walle <michael@walle.cc> wrote:
> 
>> > If we used the devicename as you are suggesting, then for the two LEDs
>> > the devicename part would be the same:
>> >   ledA -> macA -> ethernet0
>> >   ledB -> phyB -> ethernet0
>> > although they are clearly on different MACs.
>> 
>> Why is that the case? Why can't both the MAC and the PHY request a
>> unique name from the same namespace?
> 
> So all the network related devices should request a unique network
> relate device ID?  Should also wireless PHY devices do this? WWAN 
> modems?
> And all these should have the same template for devicename part withing
> /sys/class/leds? What should be the template for the devicename, if
> wireless PHYs and WWAN modems could also be part of this? It cannot be
> "ethernet" anymore.

I don't suggest using ethernet for everything. I just questioned
wether the distinction between ethmac and ethphy makes any sense from
a (human) user point of view; if the devicename part is visible to an
user at all.

-michael

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 27.07.2021 18:32, Marek Behún wrote:
> Hi,
> 
> On Tue, 27 Jul 2021 17:53:58 +0200
> Michael Walle <michael@walle.cc> wrote:
> 
>>> If we used the devicename as you are suggesting, then for the two LEDs
>>> the devicename part would be the same:
>>>   ledA -> macA -> ethernet0
>>>   ledB -> phyB -> ethernet0
>>> although they are clearly on different MACs.  
>>
>> Why is that the case? Why can't both the MAC and the PHY request a 
>> unique name from the same namespace?
> 
> So all the network related devices should request a unique network
> relate device ID? Should also wireless PHY devices do this? WWAN modems?
> And all these should have the same template for devicename part withing
> /sys/class/leds? What should be the template for the devicename, if
> wireless PHYs and WWAN modems could also be part of this? It cannot be
> "ethernet" anymore.
> 
> It seems a better idea to me to just some nice identifier for the LED
> controller.
> 
>> As Andrew pointed out, the names in
>> /sys/class/leds don't really matter. Ok, it will still depend on the
>> probe order which might not be the case if you split it between ethmac
>> and ethphy.
> 
> Yes, the LED name does not matter. But the LED subsystem requires names
> in a specific format, this is already decided and documented, we are
> not going to be changing this. The only reasonable thing we can do now
> is to choose a sane devicename.
> 
>> Sorry, if I may ask stupid questions here. I don't want to cause much
>> trouble, here. I was just wondering why we have to make up two different
>> (totally unrelated names to the network interface names) instead of just
>> one (again totally unrelated to the interface name and index).
> 
> It seems more logical to me from kernel's point of view.
> 
>> But I was actually referring to your "you see the leds in /sys/ of all
>> the network adapters". That problem still persists, right?
> 
> Yes, this still persists. But we really do not want to start
> introducing namespaces to the LED subsystem.
> 
> Marek
> 

Did we come to any conclusion?

My preliminary r8169 implementation now creates the following LED names:

lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300

I understood that LEDs should at least be renamed to r8169-0300::link-0
to link-2 Is this correct? Or do we have to wait with any network LED support
for a name discussion outcome?

For the different LED modes I defined private hw triggers (using trigger_type
to make the triggers usable with r8169 LEDs only). The trigger attribute now
looks like this:

[none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT

Nice, or? Issue is just that these trigger names really should be made a
standard for all network LEDs. I don't care about the exact naming, important
is just that trigger names are the same, no matter whether it's about a r8169-
or igc- or whatever network chip controlled LEDs.

And I don't have a good solution for initialization yet. LED mode is whatever
BIOS sets, but initial trigger value is "none". I would have to read the
initial LED control register values, iterate over the triggers to find the
matching one, and call led_trigger_set() to properly set this trigger as
current trigger. Most likely this would need some LED core extensions:
- enable iterating over all triggers with a particular trigger_type
- enable triggers to have private data
Quite some hassle for a small functionality.

Re: [PATCH net-next 5/5] igc: Export LEDs

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Wed Jul 28 2021, Heiner Kallweit wrote:
> Did we come to any conclusion?
>
> My preliminary r8169 implementation now creates the following LED
> names:

Is that implementation somewhere available?

>
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300
>
> I understood that LEDs should at least be renamed to r8169-0300::link-0
> to link-2 Is this correct? Or do we have to wait with any network LED support
> for a name discussion outcome?
>
> For the different LED modes I defined private hw triggers (using trigger_type
> to make the triggers usable with r8169 LEDs only). The trigger attribute now
> looks like this:
>
> [none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT
>
> Nice, or? Issue is just that these trigger names really should be made a
> standard for all network LEDs. I don't care about the exact naming, important
> is just that trigger names are the same, no matter whether it's about a r8169-
> or igc- or whatever network chip controlled LEDs.

Your above trigger definitions are OK for the igc as well. Except it
supports up to 2500 Mbit/s. For igc there's also more triggers available
such as filter activity, paused and spd mode.

However, what about the cross LED settings which are common to all LEDs?
The igc has one attribute to control the blink rate of all three LEDs.

>
> And I don't have a good solution for initialization yet. LED mode is whatever
> BIOS sets, but initial trigger value is "none". I would have to read the
> initial LED control register values, iterate over the triggers to find the
> matching one, and call led_trigger_set() to properly set this trigger as
> current trigger.

Yes, there needs to be a way to determine the default state.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

Hello Heiner,

On Wed, 28 Jul 2021 22:43:30 +0200
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> Did we come to any conclusion?
> 
> My preliminary r8169 implementation now creates the following LED names:
> 
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300
> 
> I understood that LEDs should at least be renamed to r8169-0300::link-0
> to link-2 Is this correct? Or do we have to wait with any network LED support
> for a name discussion outcome?

I would expect some of the LEDs to, by default, indicate activity.
So maybe look at the settings BIOS left, and if the setting is to
indicate link, use the "link" function, and if activity, use the
"activity" function? 

> For the different LED modes I defined private hw triggers (using trigger_type
> to make the triggers usable with r8169 LEDs only). The trigger attribute now
> looks like this:
> 
> [none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT
>
> Nice, or? Issue is just that these trigger names really should be made a
> standard for all network LEDs. I don't care about the exact naming, important
> is just that trigger names are the same, no matter whether it's about a r8169-
> or igc- or whatever network chip controlled LEDs.

This is how I at first proposed doing this, last year. But this is
WRONG!

First, we do not want a different trigger for each possible
configuration. We want one trigger, and then choose configuration via
other sysfs file. I.e. a "hw" trigger, which, when activated, would
create sysfs files "link" and "act", via which you can configure those
options.

Second, we already have a standard LED trigger for network devices,
netdev! So what we should do is use the netdev trigger, and offload
blinking to the LED controller if it supports it. The problems with
this are:
1. not yet implemented in upstream, see my latest version
   https://lore.kernel.org/linux-leds/20210601005155.27997-1-kabel@kernel.org/
2. netdev trigger currently does not support all these different link
   functions. We have these settings:
     device_name: network interface name, i.e. eth0
     link: 0 - do not indicate link
           1 - indicate link (ON when linked)
     tx: 0 - do not blink on transmit
         1 - blink on transmit
     rx: 0 - do not blink on receive
         1 - blink on receive
     interval: duration of LED blink in ms

I would like to extend netdev trigger to support different
configurations. Currently my ideas are as follows:
- a new sysfs file, "advanced", will show up when netdev trigger is
  enabled (and if support is compiled in)
- when advanced is set to 1, for each possible link mode (10base-t,
  100base-t, 1000base-t, ...) a new sysfs directory will show up, and
  in each of these directories the following files:
    rx, tx, link, interval, brightness
    multi_intensity (if the LED is a multi-color LED)
  and possibly even
    pattern
With this, the user can configure more complicated configurations:
- different LED color for different link speeds
- different blink speed for different link speeds
And if some of the configurations are offloadable to the HW, the drivers
can be written to support such offloading. (Maybe even add a read-only
file "offloaded" to indicate if the trigger was offloaded.)

I will work on these ideas in the following weeks and will sent
proposals to linux-leds.

> And I don't have a good solution for initialization yet. LED mode is whatever
> BIOS sets, but initial trigger value is "none". I would have to read the
> initial LED control register values, iterate over the triggers to find the
> matching one, and call led_trigger_set() to properly set this trigger as
> current trigger.

You can set led_cdev->default_trigger prior registering the LED. But
this is moot: we do not want a different trigger for each PHY interface
mode.

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 29.07.2021 10:59, Marek Behún wrote:
> Hello Heiner,
> 
> On Wed, 28 Jul 2021 22:43:30 +0200
> Heiner Kallweit <hkallweit1@gmail.com> wrote:
> 
>> Did we come to any conclusion?
>>
>> My preliminary r8169 implementation now creates the following LED names:
>>
>> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
>> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
>> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300
>>
>> I understood that LEDs should at least be renamed to r8169-0300::link-0
>> to link-2 Is this correct? Or do we have to wait with any network LED support
>> for a name discussion outcome?
> 
> I would expect some of the LEDs to, by default, indicate activity.
> So maybe look at the settings BIOS left, and if the setting is to
> indicate link, use the "link" function, and if activity, use the
> "activity" function? 
> 

The function may be changed by the user. Then what? Rename the LED device?
A typical use case is also that one LED indicates both, link and activity.

>> For the different LED modes I defined private hw triggers (using trigger_type
>> to make the triggers usable with r8169 LEDs only). The trigger attribute now
>> looks like this:
>>
>> [none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT
>>
>> Nice, or? Issue is just that these trigger names really should be made a
>> standard for all network LEDs. I don't care about the exact naming, important
>> is just that trigger names are the same, no matter whether it's about a r8169-
>> or igc- or whatever network chip controlled LEDs.
> 
> This is how I at first proposed doing this, last year. But this is
> WRONG!
> 
> First, we do not want a different trigger for each possible
> configuration. We want one trigger, and then choose configuration via
> other sysfs file. I.e. a "hw" trigger, which, when activated, would
> create sysfs files "link" and "act", via which you can configure those
> options.
> 
> Second, we already have a standard LED trigger for network devices,
> netdev! So what we should do is use the netdev trigger, and offload
> blinking to the LED controller if it supports it. The problems with
> this are:
> 1. not yet implemented in upstream, see my latest version
>    https://lore.kernel.org/linux-leds/20210601005155.27997-1-kabel@kernel.org/
> 2. netdev trigger currently does not support all these different link
>    functions. We have these settings:
>      device_name: network interface name, i.e. eth0
>      link: 0 - do not indicate link
>            1 - indicate link (ON when linked)
>      tx: 0 - do not blink on transmit
>          1 - blink on transmit
>      rx: 0 - do not blink on receive
>          1 - blink on receive
>      interval: duration of LED blink in ms
> 
> I would like to extend netdev trigger to support different
> configurations. Currently my ideas are as follows:
> - a new sysfs file, "advanced", will show up when netdev trigger is
>   enabled (and if support is compiled in)
> - when advanced is set to 1, for each possible link mode (10base-t,
>   100base-t, 1000base-t, ...) a new sysfs directory will show up, and

This leads to new questions like: How do you know what the possible
link modes are? In a spare minute you could have a look at enum
ethtool_link_mode_bit_indices. Even with standard multi-gig hw
meanwhile you have: 10M, 100M, 1G, 2.5G, 5G, 10G.
Supposedly the information about possible link modes would have to be
stored in led_classdev so that it can generate the appropriate sysfs
directories during registration.

>   in each of these directories the following files:
>     rx, tx, link, interval, brightness
>     multi_intensity (if the LED is a multi-color LED)
>   and possibly even
>     pattern
> With this, the user can configure more complicated configurations:
> - different LED color for different link speeds
> - different blink speed for different link speeds
> And if some of the configurations are offloadable to the HW, the drivers
> can be written to support such offloading. (Maybe even add a read-only
> file "offloaded" to indicate if the trigger was offloaded.)
> 

For a fully hw-offloaded LED like in my case then more or less the only
benefit of led_classdev + netdev trigger is the unified location of
link speed + tx/rx attributes. The brightness attribute has no meaning
because brightness can't be controlled.
Overall quite some overhead for a small functionality. At least in a
simple case like mine I'd use custom attributes under the net_dev like
this if I had to invent something on my own:
led0/speed: where you can say: "echo +100 > led0/speed" to enable 100M link indication
led0/activity: bool

> I will work on these ideas in the following weeks and will sent
> proposals to linux-leds.
> 

I don't want to be the one always saying: Nice framework, but heh:
How about my special case xyz?

I understand that it can be a frustrating job, that needs quite some
patience, to create a framework that you consider to be clean and
that covers the needs of (almost) everybody. I failed with some early
attempts to establish RGB LED support using the HSV color model.

>> And I don't have a good solution for initialization yet. LED mode is whatever
>> BIOS sets, but initial trigger value is "none". I would have to read the
>> initial LED control register values, iterate over the triggers to find the
>> matching one, and call led_trigger_set() to properly set this trigger as
>> current trigger.
> 
> You can set led_cdev->default_trigger prior registering the LED. But
> this is moot: we do not want a different trigger for each PHY interface
> mode.
> 
> Marek
> 

Documentation for naming LEDs was Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

Hi!

> > > The last time we discussed this (Andrew, Pavel and I), we've decided
> > > that for ethernet PHY controlled LEDs we want the devicename part
> > > should be something like
> > >    phyN  or  ethphyN  or  ethernet-phyN
> > > with N a number unique for every PHY (a simple atomically increased
> > > integer for every ethernet PHY).  
> > 
> > We might want to rethink this. PHYs typically have 2 or 3 LEDs. So we
> > want a way to indicate which LED of a PHY it is. So i suspect we will
> > want something like
> > 
> > ethphyN-led0, ethphyN-led1, ethphyN-led2.
> 
> But... there is still color and function and possibly function-numerator
> to differentiate them. I was talking only about the devicename part. So
> for three LEDs you can have, for example:
>   ethphyN:green:link
>   ethphyN:yellow:activity

For the record, this is the solution I'd like to see. Plus, we do want
it consistent between drivers, and I believe we need more than
list of functions provided by dt-bindings/leds/common.h -- we want
people to set something reasonable for "device" part, too.

Thus, I'm proposing this:

Rules will be simple -- when new type of LED is added to the
system, it will need to come with documentation explaining what the
LED does, and people will be expected to use existing names when
possible.

We'll also want to list "known bad" names in the file, so that there's
central place to search for aliases.

Thoughts?

Best regards,
								Pavel

--- /dev/null	2021-08-08 09:30:15.272028621 +0200
+++ Documentation/leds/well-known-leds.txt	2021-07-03 14:33:45.573718655 +0200
@@ -0,0 +1,57 @@
+-*- org -*-
+
+It is somehow important to provide consistent interface to the
+userland. LED devices have one problem there, and that is naming of
+directories in /sys/class/leds. It would be nice if userland would
+just know right "name" for given LED function, but situation got more
+complex.
+
+Anyway, if backwards compatibility is not an issue, new code should
+use one of the "good" names from this list, and you should extend the
+list where applicable.
+
+Bad names are listed, too; in case you are writing application that
+wants to use particular feature, you should probe for good name, first,
+but then try the bad ones, too.
+
+* Keyboards
+  
+Good: "input*:*:capslock"
+Good: "input*:*:scrolllock"
+Good: "input*:*:numlock"
+Bad: "shift-key-light" (Motorola Droid 4, capslock)
+
+Set of common keyboard LEDs, going back to PC AT or so.
+
+Good: "platform::kbd_backlight"
+Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
+Bad: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900)
+
+Frontlight/backlight of main keyboard.
+
+Bad: "button-backlight" (Motorola Droid 4)
+
+Some phones have touch buttons below screen; it is different from main
+keyboard. And this is their backlight.
+
+* Sound subsystem
+
+Good: "platform:*:mute"
+Good: "platform:*:micmute"
+
+LEDs on notebook body, indicating that sound input / output is muted.
+
+* System notification
+
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+
+Phones usually have multi-color status LED.
+
+* Power management
+
+Good: "platform:*:charging" (allwinner sun50i)
+
+* Screen
+
+Good: ":backlight" (Motorola Droid 4)


-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hi!

> > Yes, this still persists. But we really do not want to start
> > introducing namespaces to the LED subsystem.
> 
> Did we come to any conclusion?
> 
> My preliminary r8169 implementation now creates the following LED names:
> 
> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 ->
> > ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300

So "r8159-0300:green:activity" would be closer to the naming we want,
but lets not do that, we really want this to be similar to what others
are doing, and that probably means "ethphy3:green:activity" AFAICT.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Tue, 10 Aug 2021 19:29:27 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> So "r8159-0300:green:activity" would be closer to the naming we want,
> but lets not do that, we really want this to be similar to what others
> are doing, and that probably means "ethphy3:green:activity" AFAICT.

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").

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Hi!

> > So "r8159-0300:green:activity" would be closer to the naming we want,
> > but lets not do that, we really want this to be similar to what others
> > are doing, and that probably means "ethphy3:green:activity" AFAICT.
> 
> 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?

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Heiner Kallweit]

On 10.08.2021 19:29, Pavel Machek wrote:
> Hi!
> 
>>> Yes, this still persists. But we really do not want to start
>>> introducing namespaces to the LED subsystem.
>>
>> Did we come to any conclusion?
>>
>> My preliminary r8169 implementation now creates the following LED names:
>>
>> lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 ->
>>> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
> 
> So "r8159-0300:green:activity" would be closer to the naming we want,

The LED ports in the network chip are multi-function. You can select activity
or link or both. Supposedly renaming the device on function switch is not an
attractive option. Any proposal on how to handle this?

Also the NIC has no clue about the color of the LEDs in the RJ45 port.
Realtek network chips driven by r8169 can be found on basically every
consumer mainboard. Determining LED color would need hundreds of DMI
match entries and would be a maintenance nightmare.
So color would need to be empty?

> but lets not do that, we really want this to be similar to what others
> are doing, and that probably means "ethphy3:green:activity" AFAICT.
> 
A challenge here would be unique numbering if there are multiple
network interfaces with LED support (especially if the interfaces
use different drivers). So the numbering service would have to be
in LED subsystem core or network subsystem core.

> Best regards,
> 								Pavel
> 

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Tue, 10 Aug 2021 21:53:35 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> > 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@lunn.ch/
and
  https://lore.kernel.org/linux-leds/20210727172828.1529c764@thinkpad/

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Andrew Lunn]

> A challenge here would be unique numbering if there are multiple
> network interfaces with LED support (especially if the interfaces
> use different drivers). So the numbering service would have to be
> in LED subsystem core or network subsystem core.

Yes, it needs to be somewhere common.

We also need to document that the number is meaningless and
arbitrary. It can change from boot to boot. Also, LEDs from the same
PHY or MAC are not guaranteed to be contiguous, since multiple
PHYs/MACs can be enumerating their LEDs at the same time.

     Andrew

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Tue 2021-08-10 22:53:53, Marek Behún wrote:
> On Tue, 10 Aug 2021 21:53:35 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > > 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@lunn.ch/
> 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.

Best regards,
							Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH net-next 5/5] igc: Export LEDs

[Marek Behún]

On Tue, 17 Aug 2021 21:02:42 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> On Tue 2021-08-10 22:53:53, Marek Behún wrote:
> > On Tue, 10 Aug 2021 21:53:35 +0200
> > Pavel Machek <pavel@ucw.cz> wrote:
> >   
> > > > 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@lunn.ch/
> > 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:

- we create LED classdevs only after PHY is attached (which will make
  us unable to blink the LEDs when the PHY is not attached yet) and
  destroy them when PHY is detached. I find this solution wrong - the
  LEDs will be unavailable for example if the MAC driver fails to probe
  for some reason

- or we add a mechanism to reprobe LEDs upon request (which also seems
  a rather unsatisfactory solution to me...)

- maybe some other solution?

Marek

Re: [PATCH net-next 5/5] igc: Export LEDs

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

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@lunn.ch/
> > > 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]