[GIT PULL] Driver core changes for 7.0-rc1

[GIT PULL] Driver core changes for 7.0-rc1

[Danilo Krummrich]

Hi Linus,

Please pull these driver-core changes.

All commits have been in linux-next for a couple rounds; no conflicts expected.

In the -rc7 PR [1] I held back a driver-core fix (now included), as it
uncovered potential deadlocks that required a few driver fixes.

You should have received one of those for -rc8 through the gpio tree [2];
another one is included in this PR [3], and the latest one [4] should reach you
via a -fixes PR from the clk tree.

I spent significant effort catching those cases, but they are a bit tricky to
spot. However, all known ones have been addressed.

[1] https://lore.kernel.org/driver-core/DFWVL46MM928.V9LOBRWI8BLZ@kernel.org/
[2] https://lore.kernel.org/all/20260127201725.35883-1-dakr@kernel.org/
[3] https://lore.kernel.org/all/20260121141215.29658-1-dakr@kernel.org/
[4] https://lore.kernel.org/all/20260211142321.55404-1-dakr@kernel.org/

The following changes since commit 63804fed149a6750ffd28610c5c1c98cce6bd377:

  Linux 6.19-rc7 (2026-01-25 14:11:24 -0800)

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.0-rc1

for you to fetch changes up to ba268514ea14b44570030e8ed2aef92a38679e85:

  rust: devres: fix race condition due to nesting (2026-02-07 01:03:49 +0100)

----------------------------------------------------------------
Driver core changes for 7.0-rc1

- Bus:
  - Ensure bus->match() is consistently called with the device lock held
  - Improve type safety of bus_find_device_by_acpi_dev()

- Devtmpfs:
  - Parse 'devtmpfs.mount=' boot parameter with kstrtoint() instead of
    simple_strtoul()
  - Avoid sparse warning by making devtmpfs_context_ops static

- IOMMU:
  - Do not register the qcom_smmu_tbu_driver in arm_smmu_device_probe()

- MAINTAINERS:
  - Add the new driver-core mailing list (driver-core@lists.linux.dev)
    to all relevant entries
  - Add missing tree location for "FIRMWARE LOADER (request_firmware)"
  - Add driver-model documentation to the "DRIVER CORE" entry
  - Add missing driver-core maintainers to the "AUXILIARY BUS" entry

- Misc:
  - Change return type of attribute_container_register() to void; it has
    always been infallible
  - Do not export sysfs_change_owner(), sysfs_file_change_owner() and
    device_change_owner()
  - Move devres_for_each_res() from the public devres header to
    drivers/base/base.h
  - Do not use a static struct device for the faux bus; allocate it
    dynamically

- Revocable:
  - Patches for the revocable synchronization primitive have been
    scheduled for v7.0-rc1, but have been reverted as they need some
    more refinement

- Rust:
  - Device:
    - Support dev_printk on all device types, not just the core Device
      struct; remove now-redundant .as_ref() calls in dev_* print calls

  - Devres:
    - Introduce an internal reference count in Devres<T> to avoid a
      deadlock condition in case of (indirect) nesting

  - DMA:
    - Allow drivers to tune the maximum DMA segment size via
      dma_set_max_seg_size()

  - I/O:
    - Introduce the concept of generic I/O backends to handle different
      kinds of device shared memory through a common interface.

      This enables higher-level concepts such as register abstractions,
      I/O slices, and field projections to be built generically on top.

      In a first step, introduce the Io, IoCapable<T>, and IoKnownSize
      trait hierarchy for sharing a common interface supporting offset
      validation and bound-checking logic between I/O backends.

    - Refactor MMIO to use the common I/O backend infrastructure

  - Misc:
    - Add __rust_helper annotations to C helpers for inlining into Rust
      code
    - Use "kernel vertical" style for imports
    - Replace kernel::c_str! with C string literals
    - Update ARef imports to use sync::aref
    - Use pin_init::zeroed() for struct auxiliary_device_id and debugfs
      file_operations initialization
    - Use LKMM atomic types in debugfs doc-tests
    - Various minor comment and documentation fixes

  - PCI:
    - Implement PCI configuration space accessors using the common I/O
      backend infrastructure
    - Document pci::Bar device endianness assumptions

  - SoC:
    - Abstractions for struct soc_device and struct soc_device_attribute
    - Sample driver for soc::Device

----------------------------------------------------------------
Alexandre Courbot (1):
      rust: io: move MIN_SIZE and io_addr_assert to IoKnownSize

Alice Ryhl (9):
      rust: auxiliary: add __rust_helper to helpers
      rust: device: add __rust_helper to helpers
      rust: dma: add __rust_helper to helpers
      rust: io: add __rust_helper to helpers
      rust: irq: add __rust_helper to helpers
      rust: pci: add __rust_helper to helpers
      rust: platform: add __rust_helper to helpers
      rust: property: add __rust_helper to helpers
      rust: scatterlist: add __rust_helper to helpers

Alok Tiwari (2):
      rust: auxiliary: fix remove_callback invariant comment
      rust: platform: fix remove_callback invariant comment

Andy Shevchenko (1):
      driver core: make bus_find_device_by_acpi_dev() stub prototype aligned

Atharv Dubey (1):
      rust: auxiliary: use `pin_init::zeroed()` for device ID

Beata Michalska (1):
      rust: dma: allow drivers to tune max segment size

Ben Dooks (1):
      devtmpfs: make 'devtmpfs_context_ops' static

Daniel Gomez (1):
      driver core: attribute_container: change return type to void

Danilo Krummrich (18):
      rust: debugfs: use "kernel vertical" style for imports
      Merge tag 'v6.19-rc3' into driver-core-next
      rust: auxiliary: use "kernel vertical" style for imports
      rust: platform: use "kernel vertical" style for imports
      rust: driver-core: use "kernel vertical" style for imports
      rust: faux: use "kernel vertical" style for imports
      Merge tag 'v6.19-rc5' into driver-core-next
      MAINTAINERS: update auxiliary bus entry
      MAINTAINERS: driver-core: add driver-model documentation
      revocable: fix missing module license and description
      iommu/arm-smmu-qcom: do not register driver in probe()
      driver-core: move devres_for_each_res() to base.h
      MAINTAINERS: Add driver-core mailing list
      MAINTAINERS: Add missing T: entry for FIRMWARE LOADER
      Merge tag 'v6.19-rc7' into driver-core-next
      Merge tag 'driver-core-6.19-rc7-deferred' into driver-core-next
      driver core: fix inverted "locked" suffix of driver_match_device()
      rust: devres: fix race condition due to nesting

Dirk Behme (2):
      samples: rust: pci: Remove some additional `.as_ref()` for `dev_*` print
      rust: dma: add missing __rust_helper annotations

FUJITA Tomonori (1):
      rust: debugfs: Use kernel Atomic type in docs example

Gary Guo (5):
      rust: device: support `dev_printk` on all devices
      rust: pci: remove redundant `.as_ref()` for `dev_*` print
      rust: samples: driver-core: remove redundant `.as_ref()` for `dev_*` print
      rust: samples: dma: remove redundant `.as_ref()` for `dev_*` print
      gpu: tyr: remove redundant `.as_ref()` for `dev_*` print

Greg Kroah-Hartman (4):
      driver core: faux: stop using static struct device
      driver core: disable revocable code from build
      sysfs: remove exports of sysfs_*change_owner()
      driver core: remove device_change_owner() export

Gui-Dong Han (1):
      driver core: enforce device_lock for driver_match_device()

Johan Hovold (3):
      Revert "selftests: revocable: Add kselftest cases"
      Revert "revocable: Add Kunit test cases"
      Revert "revocable: Revocable resource management"

Ke Sun (1):
      rust: debugfs: use pin_init::zeroed() for file_operations

Marko Turk (2):
      rust: pci: document Bar's endianness conversion
      rust: io: remove square brackets from pci::Bar reference

Matthew Maurer (2):
      rust: Add soc_device support
      rust: Add SoC Driver Sample

Shankari Anand (3):
      rust: device: Update ARef and AlwaysRefCounted imports from sync::aref
      rust: scatterlist: Update ARef imports to use sync::aref
      samples: rust: debugfs: Update ARef imports to use sync::aref

Tamir Duberstein (9):
      rust: auxiliary: replace `kernel::c_str!` with C-Strings
      rust: device: replace `kernel::c_str!` with C-Strings
      rust: platform: replace `kernel::c_str!` with C-Strings
      rust: io: replace `kernel::c_str!` with C-Strings
      rust: irq: replace `kernel::c_str!` with C-Strings
      rust: debugfs: replace `kernel::c_str!` with C-Strings
      samples: rust: debugfs: replace `kernel::c_str!` with C-Strings
      samples: rust: pci: replace `kernel::c_str!` with C-Strings
      samples: rust: faux: replace `kernel::c_str!` with C-Strings

Thorsten Blum (1):
      devtmpfs: Replace simple_strtoul with kstrtoint in mount_param

Tzung-Bi Shih (8):
      revocable: Revocable resource management
      revocable: Add Kunit test cases
      selftests: revocable: Add kselftest cases
      revocable: Remove redundant synchronize_srcu() call
      revocable: Fix races in revocable_alloc() using RCU
      revocable: Add KUnit test for provider lifetime races
      revocable: fix SRCU index corruption by requiring caller-provided storage
      revocable: Add KUnit test for concurrent access

Zhi Wang (5):
      rust: devres: style for imports
      rust: io: separate generic I/O helpers from MMIO implementation
      rust: io: factor out MMIO read/write macros
      rust: pci: add config space read/write support
      sample: rust: pci: add tests for config space routines

Zijing Zhang (1):
      rust: pci: re-export ConfigSpace

 MAINTAINERS                                |  15 +++-
 drivers/base/attribute_container.c         |   4 +-
 drivers/base/base.h                        |  15 +++-
 drivers/base/core.c                        |   1 -
 drivers/base/dd.c                          |   2 +-
 drivers/base/devtmpfs.c                    |   5 +-
 drivers/base/faux.c                        |  18 +++--
 drivers/base/transport_class.c             |   8 +-
 drivers/gpu/drm/tyr/driver.rs              |   2 +-
 drivers/gpu/drm/tyr/gpu.rs                 |   6 +-
 drivers/gpu/drm/tyr/regs.rs                |   1 +
 drivers/gpu/nova-core/gsp/sequencer.rs     |   5 +-
 drivers/gpu/nova-core/regs/macros.rs       |  90 ++++++++++++---------
 drivers/gpu/nova-core/vbios.rs             |   1 +
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  14 ++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c |  14 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c      |  24 +++++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h      |   5 ++
 drivers/pwm/pwm_th1520.rs                  |   5 +-
 drivers/scsi/scsi_transport_spi.c          |   2 +-
 fs/sysfs/file.c                            |   2 -
 include/linux/attribute_container.h        |   2 +-
 include/linux/device/bus.h                 |   4 +-
 include/linux/device/devres.h              |   4 -
 include/linux/transport_class.h            |   6 +-
 rust/bindings/bindings_helper.h            |   1 +
 rust/helpers/auxiliary.c                   |   6 +-
 rust/helpers/device.c                      |  16 ++--
 rust/helpers/dma.c                         |  31 ++++---
 rust/helpers/io.c                          |  64 ++++++++-------
 rust/helpers/irq.c                         |   6 +-
 rust/helpers/pci.c                         |  23 +++---
 rust/helpers/platform.c                    |   2 +-
 rust/helpers/property.c                    |   2 +-
 rust/helpers/scatterlist.c                 |  12 +--
 rust/kernel/auxiliary.rs                   |  30 ++++---
 rust/kernel/debugfs.rs                     |  86 +++++++++++++-------
 rust/kernel/debugfs/callback_adapters.rs   |  21 +++--
 rust/kernel/debugfs/entry.rs               |  14 +++-
 rust/kernel/debugfs/file_ops.rs            |  43 +++++-----
 rust/kernel/debugfs/traits.rs              |  43 +++++++---
 rust/kernel/device.rs                      |  32 +++++---
 rust/kernel/device/property.rs             |  11 +--
 rust/kernel/devres.rs                      | 197 ++++++++++++++++++---------------------------
 rust/kernel/dma.rs                         |  17 ++++
 rust/kernel/driver.rs                      |  12 ++-
 rust/kernel/faux.rs                        |  13 ++-
 rust/kernel/io.rs                          | 479 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
 rust/kernel/io/mem.rs                      |  33 +++++---
 rust/kernel/io/poll.rs                     |  16 +++-
 rust/kernel/irq/request.rs                 |   6 +-
 rust/kernel/lib.rs                         |   2 +
 rust/kernel/pci.rs                         |  11 ++-
 rust/kernel/pci/id.rs                      |   2 +-
 rust/kernel/pci/io.rs                      | 210 ++++++++++++++++++++++++++++++++++++++++++++++--
 rust/kernel/platform.rs                    |  46 ++++++++---
 rust/kernel/scatterlist.rs                 |   3 +-
 rust/kernel/soc.rs                         | 135 +++++++++++++++++++++++++++++++
 samples/rust/Kconfig                       |  11 +++
 samples/rust/Makefile                      |   1 +
 samples/rust/rust_debugfs.rs               |  46 +++++++----
 samples/rust/rust_debugfs_scoped.rs        |  38 +++++----
 samples/rust/rust_dma.rs                   |  13 +--
 samples/rust/rust_driver_auxiliary.rs      |  14 ++--
 samples/rust/rust_driver_faux.rs           |  10 ++-
 samples/rust/rust_driver_pci.rs            |  43 ++++++++--
 samples/rust/rust_driver_platform.rs       |  42 +++++-----
 samples/rust/rust_soc.rs                   |  79 ++++++++++++++++++
 68 files changed, 1604 insertions(+), 573 deletions(-)
 create mode 100644 rust/kernel/soc.rs
 create mode 100644 samples/rust/rust_soc.rs

Re: [GIT PULL] Driver core changes for 7.0-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 12 Feb 2026 00:04:46 +0100:

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

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

Thank you!

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

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Linus Torvalds]

On Wed, 11 Feb 2026 at 15:04, Danilo Krummrich <dakr@kernel.org> wrote:
>
> Driver core changes for 7.0-rc1
>
> - Bus:
>   - Ensure bus->match() is consistently called with the device lock held

So I'm coming back to this, because it turns out this sounds like a
horrible mistake in the end.

You document it as being about consistent locking, but it appears this
change is what made the "firewire oops at driver attach" turn an oops
into just a silently dead machine.

In other words, it makes fragile drivers go from "you get an oops" to
something much worse. The oops becomes unrecoverable - with typically
a black screen at boot - because the probe is holding a lock that then
makes everything else come to a grinding halt when the driver fails.

And yes, this obviously only happens for buggy driver and doesn't
matter for _correct_ code, but about half of the kernel code is
drivers, and that half of the kernel code is also the typically the
most badly tested and often questionably implemented half.

No, not all drivers a bad, but there are a lot of drivers, and some of
them have problems.

So if a driver problem causes problems for the whole machine, the
driver core design is bad.

I really think this should be re-thought. Perhaps just reverted
outright. Instead of saying

  "This inconsistency means that
    bus match() callbacks are not guaranteed to be called with the lock
    held"

as if it's automatically a bad thing, just don't depend on the device
match having to be called with a lock held if that lock has this
problem.

It's not clear why anybody should *care* about the lock at driver
attach time, when nothing else can access the device that hasn't been
brought up yet.

Put another way: the downsides seem worse than the upsides.
"Consistency" is not an upside if it causes problems.

             Linus

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Linus Torvalds]

On Sat, 28 Feb 2026 at 23:44, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> In other words, it makes fragile drivers go from "you get an oops" to
> something much worse. The oops becomes unrecoverable - with typically
> a black screen at boot - because the probe is holding a lock that then
> makes everything else come to a grinding halt when the driver fails.

See this message:

    https://lore.kernel.org/all/67f655bb-4d81-4609-b008-68d200255dd2@davidgow.net/

on the interaction with the driver core merge with the firewire oops bug.

In this case we were actually somewhat lucky, in that the hardware is
fairly common, but seldom actually used - a combination that meant tht
wer had several people who caught it fairly quickly and were willing
and able to bisect it. I had the first report the day after -rc1 was
released.

IOW, it could have been *so* much worse. Imagine some random driver
bug on hardware that isn't common and just causes inexplicable boot
failures for the people who see it and are likely using distro
kernels.

              Linus

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Gary Guo]

On Sun Mar 1, 2026 at 7:44 AM GMT, Linus Torvalds wrote:
> On Wed, 11 Feb 2026 at 15:04, Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> Driver core changes for 7.0-rc1
>>
>> - Bus:
>>   - Ensure bus->match() is consistently called with the device lock held
>
> So I'm coming back to this, because it turns out this sounds like a
> horrible mistake in the end.
>
> You document it as being about consistent locking, but it appears this
> change is what made the "firewire oops at driver attach" turn an oops
> into just a silently dead machine.
>
> In other words, it makes fragile drivers go from "you get an oops" to
> something much worse. The oops becomes unrecoverable - with typically
> a black screen at boot - because the probe is holding a lock that then
> makes everything else come to a grinding halt when the driver fails.
>
> And yes, this obviously only happens for buggy driver and doesn't
> matter for _correct_ code, but about half of the kernel code is
> drivers, and that half of the kernel code is also the typically the
> most badly tested and often questionably implemented half.
>
> No, not all drivers a bad, but there are a lot of drivers, and some of
> them have problems.
>
> So if a driver problem causes problems for the whole machine, the
> driver core design is bad.
>
> I really think this should be re-thought. Perhaps just reverted
> outright. Instead of saying
>
>   "This inconsistency means that
>     bus match() callbacks are not guaranteed to be called with the lock
>     held"
>
> as if it's automatically a bad thing, just don't depend on the device
> match having to be called with a lock held if that lock has this
> problem.

Note that taking lock on match() fixes a real bug where data race can lead to
use-after-free https://bugzilla.kernel.org/show_bug.cgi?id=220789. It is
mentioned in the patch
https://lore.kernel.org/lkml/20260113162843.12712-1-hanguidong02@gmail.com/.

>
> It's not clear why anybody should *care* about the lock at driver
> attach time, when nothing else can access the device that hasn't been
> brought up yet.

We have always been taking the device lock when probing. This is needed as
obviously you don't want to have two drivers attaching to the same device at the
same time. When probing oops, the device lock is never going to be unlocked
again.

However, before matching starts to take the lock, we're "fine" in a sense that,
everything else keeps working as unless a device is matched and would actually
require probing, the device lock is not touched.

Perhaps what we should do is to defend against drivers oopsing inside probe and
have a mechanism so that device locks are unlocked even when probe oops. Another
option is to have `driver_override` protected by a different lock so match()
takes that lock instead of the device lock.

Best,
Gary

>
> Put another way: the downsides seem worse than the upsides.
> "Consistency" is not an upside if it causes problems.
>
>              Linus

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Danilo Krummrich]

On Sun Mar 1, 2026 at 8:44 AM CET, Linus Torvalds wrote:
> So I'm coming back to this, because it turns out this sounds like a
> horrible mistake in the end.

I came to the same conclusion following the discussion around the firewire oops.

> You document it as being about consistent locking

It happens that quite a few busses rely on this, and there is a possible race
condition that can lead to UAF bugs in the context of driver_override.

I think it is rather unlikely to happen though, as it would require a user to
change a device's driver_override field through sysfs while the device is
matched with a driver.

In any case, this can easily be solved with a separate lock.

> In other words, it makes fragile drivers go from "you get an oops" to
> something much worse. The oops becomes unrecoverable - with typically
> a black screen at boot - because the probe is holding a lock that then
> makes everything else come to a grinding halt when the driver fails.

Yes, the problem is that when a device is already present in the system and a
driver is registered on the same bus, we iterate over all devices registered on
this bus to see if one of them matches. If we come across an already bound one
where the corresponding driver crashed while holding the device lock (e.g. in
probe()) we can't make any progress anymore.

Obviously, this is not an issue the other way around, i.e. when the driver is
present in the system first and the device is added subsequently.

> And yes, this obviously only happens for buggy driver and doesn't
> matter for _correct_ code, but about half of the kernel code is
> drivers, and that half of the kernel code is also the typically the
> most badly tested and often questionably implemented half.

I agree, it is a case that will happen regularly, and besides hurting developer
ergonomics, it potentially decreases chances of shutting things down cleanly and
obtaining logs in a production environment as well.

> I really think this should be re-thought. Perhaps just reverted
> outright.

Yes, I agree and in fact I already have a few local changes to move
driver_override to struct device, provide corresponding accessors for busses and
handle locking with a separate lock.

(Technically, the "move driver_override to struct device" part is orthogonal,
but doing it right away results in less (and much cleaner) changes.)

I do not consider those changes to be complicated and risky, but I'm not sure
you want to see those for one of the upcoming -rc releases (probably -rc4/5).

Independently, I can send a revert for -rc3.

Thanks,
Danilo

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Linus Torvalds]

On Sun, 1 Mar 2026 at 05:04, Danilo Krummrich <dakr@kernel.org> wrote:
>
> It happens that quite a few busses rely on this, and there is a possible race
> condition that can lead to UAF bugs in the context of driver_override.
>
> I think it is rather unlikely to happen though, as it would require a user to
> change a device's driver_override field through sysfs while the device is
> matched with a driver.
>
> In any case, this can easily be solved with a separate lock.

Yes, if it's literally just about driver_override, please just fix the locking.

Use some really simple local spinlock lock to just copy the string
into a local copy when accessing it - it's not like it's even some
arbitrarily long string afaik (how long can driver names be?)

Don't use a huge sleeping lock that has other semantics for something
trivial like this.

(Or is there some other driver_override thing I'm not aware of?)

             Linus

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Danilo Krummrich]

On Sun Mar 1, 2026 at 2:04 PM CET, Danilo Krummrich wrote:
> Yes, I agree and in fact I already have a few local changes to move
> driver_override to struct device, provide corresponding accessors for busses and
> handle locking with a separate lock.
>
> (Technically, the "move driver_override to struct device" part is orthogonal,
> but doing it right away results in less (and much cleaner) changes.)
>
> I do not consider those changes to be complicated and risky, but I'm not sure
> you want to see those for one of the upcoming -rc releases (probably -rc4/5).

This is roughly what I have in mind [1] (partially compile and runtime tested).

Given that we agree that the driver_match_device() change should be reverted, it
may make sense to land the first patch in an upcoming -rc, split up the treewide
one, and let subsystems follow-up with those fixes individually.

Please let me know what you prefer.

- Danilo

[1] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=driver_override

> Independently, I can send a revert for -rc3.

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Danilo Krummrich]

On Sun Mar 1, 2026 at 7:17 PM CET, Linus Torvalds wrote:
> Use some really simple local spinlock lock to just copy the string
> into a local copy when accessing it - it's not like it's even some
> arbitrarily long string afaik (how long can driver names be?)

Yes, that's what my code in [1] already does. Actually, I think we don't even
need a local copy for accessing the string. We should be good with something
like

	int device_match_driver_override(struct device *dev,
					 const struct device_driver *drv)

which internally compares the strings holding the spinlock.

Otherwise, since you asked, the string length is currently limited to
PAGE_SIZE - 1 as it will be copied with sysfs_emit(). But as mentioned, we
shouldn't need a copy anyways.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=driver_override

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Linus Torvalds]

On Sun, 1 Mar 2026 at 12:21, Danilo Krummrich <dakr@kernel.org> wrote:
>
> Otherwise, since you asked, the string length is currently limited to
> PAGE_SIZE - 1 as it will be copied with sysfs_emit().

Well, the string length from /proc itself might be long, but do we *care*?

It's only meaningful when it matches a driver name, so anything longer
than the longest driver name is irrelevant - it's not going to match.

So the thing that would matter is the longest actual real driver name.
Aren't those typically just a few bytes (eg "regulator-bus-drv" or
"__typec_altmode_driver" being long ones I find with a bad grep
pattern that might miss millions of other cases)

IOW, it looks like it would be fine to just say "use just a 32-byte
buffer" if a buffer is needed.

Of course, if no buffer is needed that's even better.

             Linus

Re: [GIT PULL] Driver core changes for 7.0-rc1

[Danilo Krummrich]

On Sun Mar 1, 2026 at 10:01 PM CET, Linus Torvalds wrote:
> So the thing that would matter is the longest actual real driver name.
> Aren't those typically just a few bytes (eg "regulator-bus-drv" or
> "__typec_altmode_driver" being long ones I find with a bad grep
> pattern that might miss millions of other cases)

Yes, generally they should be pretty short.

OOC, I asked an LLM to figure it out (so take this with the necessary grain of
salt):

	Out of ~7,560 unique driver names:
	
	┌────────────┬───────────┐
	│ Threshold  │   Count   │
	├────────────┼───────────┤
	│ > 32 chars │ 6 (0.08%) │
	├────────────┼───────────┤
	│ > 48 chars │ 1 (0.01%) │
	├────────────┼───────────┤
	│ > 64 chars │ 0         │
	└────────────┴───────────┘
	
	Length distribution
	
	 1-10 chars:  3,513  (46.5%)
	11-16 chars:  3,111  (41.1%)
	17-24 chars:    880  (11.6%)
	25-32 chars:     50  ( 0.7%)
	33-49 chars:      6  ( 0.1%)

> IOW, it looks like it would be fine to just say "use just a 32-byte
> buffer" if a buffer is needed.

Assuming the above is roughly correct, you are pretty close. :)

> Of course, if no buffer is needed that's even better.

Yes, I don't think we ever need to obtain a copy other than through
sysfs_emit().