On Tue, Sep 21, 2021 at 6:15 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Sep 19, 2021 at 03:16:34AM +0200, Andrew Lunn wrote: > > > > diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h > > > > index 59828516ebaf..9f4ad719bfe3 100644 > > > > --- a/include/linux/fwnode.h > > > > +++ b/include/linux/fwnode.h > > > > @@ -22,10 +22,15 @@ struct device; > > > > * LINKS_ADDED: The fwnode has already be parsed to add fwnode links. > > > > * NOT_DEVICE: The fwnode will never be populated as a struct device. > > > > * INITIALIZED: The hardware corresponding to fwnode has been initialized. > > > > + * NEEDS_CHILD_BOUND_ON_ADD: For this fwnode/device to probe successfully, its > > > > + * driver needs its child devices to be bound with > > > > + * their respective drivers as soon as they are > > > > + * added. > > > > > > The fact that this requires so much comment text here is a clear > > > band-aid indication to me. > > > > This whole patchset is a band aid, but it is for stable, to fix things > > which are currently broken. So we need to answer the question, is a > > bad aid good enough for stable, with the assumption a real fix will > > come along later? > > Fix it properly first, don't worry about stable. > > But what is wrong with this as-is? What needs to be done that is not > happening here that you feels still needs to be addressed? The existing code attempts to "enforce" device links where the supplier is a direct ancestor of the consumer (e.g. its parent), which is questionable by itself (why do that?) and that's the source of the underlying issue (self-inflicted circular dependencies that cause devices to wait for a deferred probe forever) which this patchest attempts to avoid by adding an extra flag to the driver core and expecting specific drivers to mark their devices as "special". And that's "until we have a real fix".
