On Wed, 9 Sep 2020 23:42:59 +0200 Andrew Lunn <andrew@xxxxxxx> wrote: > On Wed, Sep 09, 2020 at 06:25:45PM +0200, Marek Behún wrote: > > Hello Andrew and Pavel, > > > > please review these patches adding support for HW controlled LEDs. > > The main difference from previous version is that the API is now generalized > > and lives in drivers/leds, so that part needs to be reviewed (and maybe even > > applied) by Pavel. > > > > As discussed previously between you two, I made it so that the devicename > > part of the LED is now in the form `ethernet-phy%i` when the LED is probed > > for an ethernet PHY. Userspace utility wanting to control LEDs for a specific > > network interface can access them via /sys/class/net/eth0/phydev/leds: > > > > mox ~ # ls /sys/class/net/eth0/phydev/leds > > It is nice they are directly in /sys/class/net/eth0/phydev. Do they > also appear in /sys/class/led? They are in /sys/class/net/eth0/phydev/leds by default, because they are children of the PHY device and are of `leds` class, and the PHY subsystem creates a symlink `phydev` when PHY is attached to the interface. They are in /sys/class/leds/ as symlinks, because AFAIK everything in /sys/class/<CLASS>/ is a symlink... > Have you played with network namespaces? What happens with > > ip netns add ns1 > > ip link set eth0 netns ns1 > > Andrew If you move eth0 to other network namespace, naturally the /sys/class/net/eth0 symlink will disappear, as will the directory it pointed to. The symlink phydev does will disappear from /sys/class/net/eth0/ directory after eth0 is moved to ns1, and is lost. It does not return even if eth0 is moved back to root namespace. The LED will of course stay in ns1 and also in root namespace, as will the phydev the LED is a child to. But they are no longer accessible via /sys/class/net/eth0, instead you can access the LEDs either via /sys/class/leds or /sys/class/mdio_bus/<MDIO_BUS>/<PHY>/leds, or without symlinks via /sys/devices/ tree. Marek
