[GIT PULL] Driver core fixes for 7.1-rc1

[GIT PULL] Driver core fixes for 7.1-rc1

[Danilo Krummrich]

Hi Linus,

Please pull these driver-core fixes.

All commits have been in linux-next for 5 rounds (4 for the kernel-doc fix); no
conflicts expected.

I also included a software node patch from Bartosz; it's not strictly a fix, but
he has follow-up patches building on it across various trees, so including it
for -rc1 still seemed like the pragmatic choice. I hope this is fine with you.

- Danilo

The following changes since commit c369299895a591d96745d6492d4888259b004a9e:

  Linux 7.0-rc5 (2026-03-22 14:42:17 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git tags/driver-core-7.1-rc1-2

for you to fetch changes up to 5b484311507b5d403c1f7a45f6aa3778549e268b:

  driver core: Add kernel-doc for DEV_FLAG_COUNT enum value (2026-04-14 11:27:27 +0200)

----------------------------------------------------------------
Driver core fixes for 7.1-rc1

- Prevent a device from being probed before device_add() has finished
  initializing it; gate probe with a "ready_to_probe" device flag to
  avoid races with concurrent driver_register() calls

- Fix a kernel-doc warning for DEV_FLAG_COUNT introduced by the above

- Return -ENOTCONN from software_node_get_reference_args() when a
  referenced software node is known but not yet registered, allowing
  callers to defer probe

- In sysfs_group_attrs_change_owner(), also check is_visible_const();
  missed when the const variant was introduced

----------------------------------------------------------------
Bartosz Golaszewski (1):
      software node: return -ENOTCONN when referenced swnode is not registered yet

Douglas Anderson (2):
      driver core: Don't let a device probe until it's ready
      driver core: Add kernel-doc for DEV_FLAG_COUNT enum value

Thomas Weißschuh (1):
      sysfs: attribute_group: Respect is_visible_const() when changing owner

 drivers/base/core.c     | 15 +++++++++++++++
 drivers/base/dd.c       | 20 ++++++++++++++++++++
 drivers/base/property.c |  2 ++
 drivers/base/swnode.c   |  2 +-
 fs/sysfs/group.c        |  7 +++++--
 include/linux/device.h  | 45 +++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 88 insertions(+), 3 deletions(-)

Re: [GIT PULL] Driver core fixes for 7.1-rc1

[Linus Torvalds]

On Sun, 19 Apr 2026 at 08:43, Danilo Krummrich <dakr@kernel.org> wrote:
>
> - Prevent a device from being probed before device_add() has finished
>   initializing it; gate probe with a "ready_to_probe" device flag to
>   avoid races with concurrent driver_register() calls

Ugh. This just looks disgusting:

        device_lock(dev);
        dev_set_ready_to_probe(dev);
        device_unlock(dev);

when all it does is to just set a single bit.

Sadly, I think despite being disgusting, our bitop memory ordering
models are incomplete.

But I think dev_set_ready_to_probe() could/should use
'test_and_set_bit()', which turns the bit setting into strongly
ordered (it only needs "release" consistency, but we don't have that).

And the dev_ready_to_probe() should use "test_bit_acquire()".

Then it wouldn't rely on the lock just to give memory ordering guarantees.

And yes, we should have better memory ordering for bit setting and
clearing, but sadly we don't. This has come up before, but it is what
it is.

             Linus

Re: [GIT PULL] Driver core fixes for 7.1-rc1

[Danilo Krummrich]

On Sun Apr 19, 2026 at 10:28 PM CEST, Linus Torvalds wrote:
> Ugh. This just looks disgusting:
>
>         device_lock(dev);
>         dev_set_ready_to_probe(dev);
>         device_unlock(dev);
>
> when all it does is to just set a single bit.

It does look ugly indeed, but I think apart from that it is not that bad; the
device lock - except for the exact case where dev_ready_to_probe() is checked -
should otherwise be uncontended.

For context, in the original version of the patch it was just another C bitfield
at the end of struct device.

I noticed that this is racy as adjacent bitfield members are not all protected
by the same lock; subsequent patches from Doug (queued for 7.2) convert the C
bitfield over to this bitmap.

IOW, the atomic bitops are primarily an implementation detail to prevent
concurrent modifications of different flags from corrupting each other.

> Sadly, I think despite being disgusting, our bitop memory ordering
> models are incomplete.
>
> But I think dev_set_ready_to_probe() could/should use
> 'test_and_set_bit()', which turns the bit setting into strongly
> ordered (it only needs "release" consistency, but we don't have that).
>
> And the dev_ready_to_probe() should use "test_bit_acquire()".

To be honest, I did not consider this as we generate all accessors with a macro
and all other bits that we convert over from the struct device's C bitfields
would inherit these semantics.

Maybe that's not necessarily a bad thing though -- another option would be to
add dev_set_##accessor_name##_release() and dev_##accessor_name##_acquire().

- Danilo

Re: [GIT PULL] Driver core fixes for 7.1-rc1

[pr-tracker-bot]

The pull request you sent on Sun, 19 Apr 2026 17:43:18 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git tags/driver-core-7.1-rc1-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c2bf4a2e5cb4b325e328cc8808858a68616067c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html