Re: [PATCH RFC net-next 6/7] net: dsa: mv88e6xxx: provide software node for default settings

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Mar 28, 2023 at 03:09:56PM +0300, Heikki Krogerus wrote:
> The problem is that the function you are proposing will be exploited
> silently - people will use NULL as the parent without anybody
> noticing. Everything will work for a while, because everybody will
> first only have a single device for that driver. But as time goes by
> and new hardware appears, suddenly there are multiple devices for
> those drivers, and the conflict start to appear.

So, an easy solution would be to reject a call to
fwnode_create_named_software_node() when parent is NULL, thereby
preventing named nodes at the root level.

> At that point the changes that added the function call will have
> trickled down to the stable trees, so the distros are affected. Now we
> are no longer talking about a simple cleanup that fixes the issue. In
> the unlikely, but possible case, this will turn into ABI problem if

There is no such thing as stable APIs for internal kernel interfaces.

Documentation/process/stable-api-nonsense.rst

> As you pointed out, this kind of risks we have to live with kbojects,
> struct device stuff and many others, but the thing is, with the
> software node and device property APIs right now we don't. So the fact
> that a risk exists in one place just isn't justification to accept the
> same risk absolutely everywhere.

Meanwhile, firmware descriptions explicitly permit looking up nodes by
their names, but here we are, with the software node maintainers
basically stating that they don't wish to support creating software
nodes with explicit names.

> Russell, if you have some good arguments for accepting your proposal,
> I assure you I will agree with you, but so far all you have given are
> attacks on a sketch details and statements like that "I think you're
> making a mountain out of a mole". Those just are not good enough.

Basically, I think you are outright wrong for all the reasons I have
given in all my emails on this subject.

Yes, I accept there is a *slight* risk of abuse, but I see it as no
different from the risk from incorrect usage of any other kernel
internal interface. Therefore I just do not accept your argument
that we should not have this function, and I do not accept your
reasoning.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!