Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 4 Oct 2021 09:25:24 +0200
From:   Marek =?UTF-8?B?QmVow7pu?= <kabel@kernel.org>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Andrew Lunn <andrew@lunn.ch>, Pavel Machek <pavel@ucw.cz>,
        "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
        netdev@vger.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: are device names part of sysfs ABI? (was Re: devicename part of
 LEDs under ethernet MAC / PHY)
Message-ID: <20211004092524.023df950@thinkpad>
In-Reply-To: <YVqo64vS4ox9P9hk@kroah.com>
References: <20211001133057.5287f150@thinkpad>
        <YVb/HSLqcOM6drr1@lunn.ch>
        <20211001144053.3952474a@thinkpad>
        <20211003225338.76092ec3@thinkpad>
        <YVqhMeuDI0IZL/zY@kroah.com>
        <20211004090438.588a8a89@thinkpad>
        <YVqo64vS4ox9P9hk@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 4 Oct 2021 09:10:35 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Beh=C3=BAn wrote:
> > Hi Greg,
> >=20
> > On Mon, 4 Oct 2021 08:37:37 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >  =20
> > > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Beh=C3=BAn wrote: =20
> > > > Hello Greg,
> > > >=20
> > > > could you give your opinion on this discussion?   =20
> > >=20
> > > What discussion?  Top posting ruins that :( =20
> >=20
> > Sorry, the discussion is here
> > https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> > But the basic question is below, so you don't need to read the
> > discussion.
> >  =20
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?   =20
> > >=20
> > > Stable in what exact way? =20
> >=20
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> >   has stable sysfs path (derived from DT path), something like
> >     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01 =20
>=20
> None of the numbers there are "stable", right?
>=20
> > - The PHY has a subnode describing a LED.
> >   The LED subsystem has a different naming scheme (it uses DT node name
> >   as a last resort). When everything is okay, the dev_name() of the LED
> >   will be something like
> >     ethphy42:green:link =20
>=20
> Wonderful, but the "42" means nothing.
>=20
> > - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> >   sysfs path is unchanged, but the LED will now be named
> >     ethphy43:green:link
> >=20
> > Is this OK? =20
>=20
> Yup!
>=20
> The "link" should point to the device it is associated with, right?  You
> need to have some way to refer to the device.
>=20
> > > Numbering of devices (where a dynamic value is part of a name, like t=
he
> > > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > > part of the name (like "usb" is in "usb42") is stable, as that is what
> > > you have properly documented in the Documentation/ABI/ files defining
> > > the bus and class devices, right? =20
> >=20
> > It does make sense for removable devices like USB. What I am asking
> > is whether it is also OK for devices that have stable DT nodes. =20
>=20
> Any device can be "removed" from the system and added back thanks to the
> joy of the driver model :)
>=20
> Also, what prevents your DT from renumbering things in an update to it
> in the future?  The kernel doesn't care, and userspace should be able to
> handle it.
>=20
> Again, any numbering scheme is NEVER stable, just because it feels like
> it is at the moment for your device, you should NEVER rely on that, but
> instead rely on the attributes of the device to determine what it is and
> where it is in the device hierarchy (serial number, position location,
> partition name, etc.) in order to know what it associated with.
>=20
> And again, this is 1/2 of the whole reason _why_ we created the unified
> driver model in the kernel.  Don't try to go back to the nightmare that
> we had in the 2.4 and earlier kernel days please.

OK, thanks Greg. This simplifies things. I shall send another version
of LEDs under ethernet PHYs soon :)

Marek