From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Doug Anderson <dianders@chromium.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Robin Murphy <robin.murphy@arm.com>,
Leon Romanovsky <leon@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Eric Dumazet <edumazet@google.com>,
Christoph Hellwig <hch@lst.de>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
Johan Hovold <johan@kernel.org>,
stable@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/9] driver core: Don't let a device probe until it's ready
Date: Fri, 3 Apr 2026 17:44:26 +0200 [thread overview]
Message-ID: <2026040353-glamour-repacking-0e53@gregkh> (raw)
In-Reply-To: <CAD=FV=XmnWjVzQcr13GmRKX3cvRortA==5C8TH5D-jRBe0VBqw@mail.gmail.com>
On Fri, Apr 03, 2026 at 08:34:20AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 3, 2026 at 12:04 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > > @@ -458,6 +458,18 @@ struct device_physical_location {
> > > bool lid;
> > > };
> > >
> > > +/**
> > > + * enum struct_device_flags - Flags in struct device
> > > + *
> > > + * Should be accessed with thread-safe bitops.
> > > + *
> > > + * @DEV_FLAG_READY_TO_PROBE: If set then device_add() has finished enough
> > > + * initialization that probe could be called.
> > > + */
> > > +enum struct_device_flags {
> > > + DEV_FLAG_READY_TO_PROBE,
> > > +};
> >
> > If you are going to want this to be a bit value, please use BIT(X) and
> > not an enum, as that's going to just get confusing over time.
>
> I don't believe I can do that. BIT(x) is not compatible with the
> atomic bitops API. BIT(x) will turn the bit number (x) into a hex
> value, but the atomic bitops API needs the bit number.
Ah, yeah, sorry, missed that.
> If you wish, I can turn this into something like:
>
> #define DEV_FLAG_READY_TO_PROBE 0
> #define DEV_FLAG_CAN_MATCH 1
> #define DEV_FLAG_DMA_IOMMU 2
> ...
>
> ...but that seemed worse (to me) than the enum. Please shout if I
> misunderstood or you disagree.
If you make it a numbered enum, that's fine (I hate unnumbered ones),
and a comment somewhere saying we will "max out" at 63, or have a
DEV_FLAG_MAX_BIT entry in there.
> > Also, none of this manual test_bit()/set_bit() stuff, please give us
> > real "accessors" for this like:
> > bool device_ready_to_probe(struct device *dev);
> >
> > so that it's obvious what is happening.
>
> Sure, that matches Rafael's request and is a nice improvement. To keep
> from having to replicate a bunch of boilerplate code, I'll have macros
> define the accessors:
>
> #define __create_dev_flag_accessors(accessor_name, flag_name) \
> static inline bool dev_##accessor_name(const struct device *dev) { \
> return test_bit(flag_name, &dev->flags); \
> } \
> static inline void dev_set_##accessor_name(struct device *dev) { \
> set_bit(flag_name, &dev->flags); \
> } \
> static inline void dev_clear_##accessor_name(struct device *dev) { \
> clear_bit(flag_name, &dev->flags); \
> } \
> static inline void dev_assign_##accessor_name(struct device *dev, bool
> value) { \
> assign_bit(flag_name, &dev->flags, value); \
> } \
> static inline bool dev_test_and_set_##accessor_name(struct device *dev) { \
> return test_and_set_bit(flag_name, &dev->flags); \
> }
>
> __create_dev_flag_accessors(ready_to_probe, DEV_FLAG_READY_TO_PROBE);
> __create_dev_flag_accessors(can_match, DEV_FLAG_CAN_MATCH);
> __create_dev_flag_accessors(dma_iommu, DEV_FLAG_DMA_IOMMU);
> __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
> __create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
> __create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
> __create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
> __create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
> __create_dev_flag_accessors(offline_disabled, DEV_FLAG_OFFLINE_DISABLED);
> __create_dev_flag_accessors(offline, DEV_FLAG_OFFLINE);
>
> Happy to tweak the above if desired.
Sure, that works, thanks!
greg k-h
next prev parent reply other threads:[~2026-04-03 15:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 0:49 [PATCH v3 0/9] driver core: Fix some race conditions Douglas Anderson
2026-04-03 0:49 ` Douglas Anderson
2026-04-03 0:49 ` Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 1/9] driver core: Don't let a device probe until it's ready Douglas Anderson
2026-04-03 7:04 ` Greg Kroah-Hartman
2026-04-03 15:34 ` Doug Anderson
2026-04-03 15:44 ` Greg Kroah-Hartman [this message]
2026-04-03 16:26 ` Doug Anderson
2026-04-03 17:23 ` Greg Kroah-Hartman
2026-04-03 0:49 ` [PATCH v3 2/9] driver core: Replace dev->can_match with DEV_FLAG_CAN_MATCH Douglas Anderson
2026-04-03 10:52 ` Rafael J. Wysocki
2026-04-03 0:49 ` [PATCH v3 3/9] driver core: Replace dev->dma_iommu with DEV_FLAG_DMA_IOMMU Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 4/9] driver core: Replace dev->dma_skip_sync with DEV_FLAG_DMA_SKIP_SYNC Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 5/9] driver core: Replace dev->dma_ops_bypass with DEV_FLAG_DMA_OPS_BYPASS Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 6/9] driver core: Replace dev->state_synced with DEV_FLAG_STATE_SYNCED Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 7/9] driver core: Replace dev->dma_coherent with DEV_FLAG_DMA_COHERENT Douglas Anderson
2026-04-03 0:49 ` Douglas Anderson
2026-04-03 0:49 ` Douglas Anderson
2026-04-03 0:49 ` [PATCH v3 8/9] driver core: Replace dev->of_node_reused with DEV_FLAG_OF_NODE_REUSED Douglas Anderson
2026-04-03 11:56 ` Mark Brown
2026-04-03 0:49 ` [PATCH v3 9/9] driver core: Replace dev->offline + ->offline_disabled with DEV_FLAGs Douglas Anderson
2026-04-03 11:56 ` Mark Brown
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=2026040353-glamour-repacking-0e53@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=aik@ozlabs.ru \
--cc=aleksander.lobakin@intel.com \
--cc=dakr@kernel.org \
--cc=dianders@chromium.org \
--cc=driver-core@lists.linux.dev \
--cc=edumazet@google.com \
--cc=hch@lst.de \
--cc=johan@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.