From: Herve Codina <herve.codina@bootlin.com>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Saravana Kannan <saravanak@google.com>,
Lizhi Hou <lizhi.hou@amd.com>, Max Zhen <max.zhen@amd.com>,
Sonal Santan <sonal.santan@amd.com>,
Stefano Stabellini <stefano.stabellini@xilinx.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Allan Nielsen <allan.nielsen@microchip.com>,
Horatiu Vultur <horatiu.vultur@microchip.com>,
Steen Hegelund <steen.hegelund@microchip.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Nuno Sa <nuno.sa@analog.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v4 1/2] driver core: Introduce device_link_wait_removal()
Date: Wed, 6 Mar 2024 16:01:01 +0100 [thread overview]
Message-ID: <20240306160101.25b45335@bootlin.com> (raw)
In-Reply-To: <86a0f91675197a00bbd921d6e57d2f3c57796e68.camel@gmail.com>
Hi Nuno,
On Wed, 06 Mar 2024 15:50:44 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
...
> > > > >
> > > > > That makes sense but then the only thing I still don't fully get is why
> > > > > we
> > > > > have
> > > > > a separate devlink_class_init() initcall for registering the devlink
> > > > > class
> > > > > (which can also fail)...
> > > >
> > > > Well, I haven't added it. :-)
> > > >
> > > > > What I take from the above is that we should fail the
> > > > > driver model if one of it's fundamental components fails so I would say
> > > > > we
> > > > > should merge devlink_class_init() with device_init() otherwise it's a
> > > > > bit
> > > > > confusing (at least to me) and gives the idea that it's ok for the
> > > > > driver
> > > > > model
> > > > > to exist without the links (unless I'm missing some other reason for the
> > > > > devlink
> > > > > init function).
> > > >
> > > > +1
> > > >
> > > > Feel free to send a patch along these lines, chances are that it will
> > > > be popular. ;-)
> > >
> > > I was actually thinking about that but I think I encountered the reason why
> > > we
> > > have it like this... devices_init() is called from driver_init() and there
> > > we
> > > have:
> > >
> > > ...
> > >
> > > devices_init();
> > > buses_init();
> > > classes_init();
> > >
> > > ...
> > >
> > > So classes are initialized after devices which means we can't really do
> > > class_register(&devlink_class) from devices_init(). Unless, of course, we
> > > re-
> > > order things in driver_init() but that would be a questionable change at the
> > > very least.
> > >
> > > So, while I agree with what you've said, I'm still not sure if mixing
> > > devlink
> > > stuff between devices_init() and devlink_class_init() is the best thing to
> > > do
> > > given that we already have the case where devlink_class_init() can fail
> > > while
> > > the driver model is up.
> >
> > So why don't you make devlink_class_init() do a BUG() on failure
> > instead of returning an error? IMO crashing early is better than
> > crashing later or otherwise failing in a subtle way due to a missed
> > dependency.
>
> Well, I do agree with that... Maybe that's something that Herve can sneak in
> this patch? Otherwise, I can later (after this one is applied) send a patch for
> it.
Well, I don't thing that this have to be part of this current series.
It is an other topic and should be handled out of this current series.
Hervé
next prev parent reply other threads:[~2024-03-06 15:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 8:50 [PATCH v4 0/2] Synchronize DT overlay removal with devlink removals Herve Codina
2024-03-06 8:50 ` [PATCH v4 1/2] driver core: Introduce device_link_wait_removal() Herve Codina
2024-03-06 9:20 ` Nuno Sá
2024-03-06 12:43 ` Rafael J. Wysocki
2024-03-06 13:05 ` Nuno Sá
2024-03-06 13:05 ` Rafael J. Wysocki
2024-03-06 14:11 ` Nuno Sá
2024-03-06 14:37 ` Rafael J. Wysocki
2024-03-06 14:50 ` Nuno Sá
2024-03-06 15:01 ` Herve Codina [this message]
2024-03-06 15:13 ` Nuno Sá
2024-03-06 21:26 ` Saravana Kannan
2024-03-06 11:07 ` Luca Ceresoli
2024-03-06 12:48 ` Rafael J. Wysocki
2024-03-06 15:24 ` Herve Codina
2024-03-06 15:56 ` Rafael J. Wysocki
2024-03-06 21:14 ` Saravana Kannan
2024-03-06 8:50 ` [PATCH v4 2/2] of: dynamic: Synchronize of_changeset_destroy() with the devlink removals Herve Codina
2024-03-06 9:21 ` Nuno Sá
2024-03-06 11:07 ` Luca Ceresoli
2024-03-06 21:35 ` Saravana Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240306160101.25b45335@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=allan.nielsen@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=horatiu.vultur@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhi.hou@amd.com \
--cc=luca.ceresoli@bootlin.com \
--cc=max.zhen@amd.com \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=sonal.santan@amd.com \
--cc=stable@vger.kernel.org \
--cc=steen.hegelund@microchip.com \
--cc=stefano.stabellini@xilinx.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).