netdev - Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for FWNODE_FLAG_BROKEN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 Aug 2021 19:01:48 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Len Brown <lenb@...nel.org>,
        Alvin Sipraga <ALSI@...g-olufsen.dk>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for
 FWNODE_FLAG_BROKEN_PARENT

On Fri, Aug 27, 2021 at 02:33:02PM -0700, Saravana Kannan wrote:
> On Fri, Aug 27, 2021 at 1:11 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > > I've not yet looked at plain Ethernet drivers. This pattern could also
> > > > exist there. And i wonder about other complex structures, i2c bus
> > > > multiplexors, you can have interrupt controllers as i2c devices,
> > > > etc. So the general case could exist in other places.
> > >
> > > I haven't seen any generic issues like this reported so far. It's only
> > > after adding phy-handle that we are hitting these issues with DSA
> > > switches.
> >
> > Can you run your parser over the 2250 DTB blobs and see how many
> > children have dependencies on a parent? That could give us an idea how
> > many moles need whacking. And maybe, where in the tree they are
> > hiding?
> 
> You are only responding to part of my email. As I said in my previous
> email: "There are plenty of cases where it's better to delay the child
> device's probe until the parent finishes. You even gave an example[7]
> where it would help avoid unnecessary deferred probes." Can you please
> give your thoughts on the rest of the points I made too?

I must admit, my main problem at the moment is -rc1 in two weeks
time. It seems like a number of board with Ethernet switches will be
broken, that worked before. phy-handle is not limited to switch
drivers, it is also used for Ethernet drivers. So it could be, a
number of Ethernet drivers are also going to be broken in -rc1?

But the issues sounds not to be specific to phy-handle, but any
phandle that points back to a parent. So it could be drivers outside
of networking are also going to be broken with -rc1?

You have been very focused on one or two drivers. I would much rather
see you getting an idea of how wide spread this problem is, and what
should we do for -rc1?

Even if modifying DSA drivers to component drivers is possible, while
not breaking backwards compatibility with DT, it is not going to
happen over night. That is something for the next merge window, not
this merge window.

So reverting the phy-handle seems like part of the fix for -rc1. But
until you look at those 2250 DTB blobs, we have no idea if that is
sufficient for -rc1.

    Andrew