Pull driver core fixes from Danilo Krummrich:

 - 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

* tag 'driver-core-7.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
  driver core: Add kernel-doc for DEV_FLAG_COUNT enum value
  sysfs: attribute_group: Respect is_visible_const() when changing owner
  software node: return -ENOTCONN when referenced swnode is not registered yet
  driver core: Don't let a device probe until it's ready

Pull HID updates from Jiri Kosina:
 "Core:
   - fixed handling of 0-sized reports (Dmitry Torokhov)
   - convert core code to __free() (Dmitry Torokhov)
   - support for multiple batteries per HID device (Lucas Zampieri)

  Drivers:
   - support for rumble effects in winwing driver (Ivan Gorinov)
   - new support for a variety of Sony Rock Band and Sony DJ Hero
     Turntable devices (Rosalie Wanders)
   - new driver for Lenovo Legion Go / S devices (Derek J. Clark)
   - power management improvements to intel-thc-hid driver (Even Xu)

  ... other assorted cleanups, fixes and device-specific quirks"

* tag 'hid-for-linus-2026041601' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (73 commits)
  HID: core: clamp report_size in s32ton() to avoid undefined shift
  HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report
  HID: logitech-hidpp: fix race condition when accessing stale stack pointer
  HID: winwing: Enable rumble effects
  HID: core: do not allow parsing 0-sized reports
  HID: usbhid: refactor endpoint lookup
  HID: huawei: fix CD30 keyboard report descriptor issue
  HID: playstation: validate num_touch_reports in DualShock 4 reports
  HID: drop 'default !EXPERT' from tristate symbols
  HID: usbhid: fix deadlock in hid_post_reset()
  HID: apple: ensure the keyboard backlight is off if suspending
  HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
  HID: alps: fix NULL pointer dereference in alps_raw_event()
  HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
  HID: logitech-dj: Standardise hid_report_enum variable nomenclature
  HID: sony: update module description
  HID: logitech-hidpp: Check bounds when deleting force-feedback effects
  HID: sony: add battery status support for Rock Band 4 PS5 guitars
  HID: sony: fix style issues
  HID: quirks: update hid-sony supported devices
  ...

- new driver for Lenovo Legion Go / S devices (Derek J. Clark)

Even though nobody should use this value (except when declaring the
"flags" bitmap), kernel-doc still gets upset that it's not documented.
It reports:

  WARNING: ../include/linux/device.h:519
  Enum value 'DEV_FLAG_COUNT' not described in enum 'struct_device_flags'

Add the description of DEV_FLAG_COUNT.

Fixes: a2225b6e834a ("driver core: Don't let a device probe until it's ready")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/f318cd43-81fd-48b9-abf7-92af85f12f91@infradead.org
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260413195910.1.I23aca74fe2d3636a47df196a80920fecb2643220@changeid
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

The moment we link a "struct device" into the list of devices for the
bus, it's possible probe can happen. This is because another thread
can load the driver at any time and that can cause the device to
probe. This has been seen in practice with a stack crawl that looks
like this [1]:

  really_probe()
  __driver_probe_device()
  driver_probe_device()
  __driver_attach()
  bus_for_each_dev()
  driver_attach()
  bus_add_driver()
  driver_register()
  __platform_driver_register()
  init_module() [some module]
  do_one_initcall()
  do_init_module()
  load_module()
  __arm64_sys_finit_module()
  invoke_syscall()

As a result of the above, it was seen that device_links_driver_bound()
could be called for the device before "dev->fwnode->dev" was
assigned. This prevented __fw_devlink_pickup_dangling_consumers() from
being called which meant that other devices waiting on our driver's
sub-nodes were stuck deferring forever.

It's believed that this problem is showing up suddenly for two
reasons:
1. Android has recently (last ~1 year) implemented an optimization to
   the order it loads modules [2]. When devices opt-in to this faster
   loading, modules are loaded one-after-the-other very quickly. This
   is unlike how other distributions do it. The reproduction of this
   problem has only been seen on devices that opt-in to Android's
   "parallel module loading".
2. Android devices typically opt-in to fw_devlink, and the most
   noticeable issue is the NULL "dev->fwnode->dev" in
   device_links_driver_bound(). fw_devlink is somewhat new code and
   also not in use by all Linux devices.

Even though the specific symptom where "dev->fwnode->dev" wasn't
assigned could be fixed by moving that assignment higher in
device_add(), other parts of device_add() (like the call to
device_pm_add()) are also important to run before probe. Only moving
the "dev->fwnode->dev" assignment would likely fix the current
symptoms but lead to difficult-to-debug problems in the future.

Fix the problem by preventing probe until device_add() has run far
enough that the device is ready to probe. If somehow we end up trying
to probe before we're allowed, __driver_probe_device() will return
-EPROBE_DEFER which will make certain the device is noticed.

In the race condition that was seen with Android's faster module
loading, we will temporarily add the device to the deferred list and
then take it off immediately when device_add() probes the device.

Instead of adding another flag to the bitfields already in "struct
device", instead add a new "flags" field and use that. This allows us
to freely change the bit from different thread without worrying about
corrupting nearby bits (and means threads changing other bit won't
corrupt us).

[1] Captured on a machine running a downstream 6.6 kernel
[2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel

Cc: stable@vger.kernel.org
Fixes: 2023c610dc54 ("Driver core: add new device to bus's list before probing")
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Currently, there are 12 busses (including platform and PCI) that
duplicate the driver_override logic for their individual devices.

All of them seem to be prone to the bug described in [1].

While this could be solved for every bus individually using a separate
lock, solving this in the driver-core generically results in less (and
cleaner) changes overall.

Thus, move driver_override to struct device, provide corresponding
accessors for busses and handle locking with a separate lock internally.

In particular, add device_set_driver_override(),
device_has_driver_override(), device_match_driver_override() and
generalize the sysfs store() and show() callbacks via a driver_override
feature flag in struct bus_type.

Until all busses have migrated, keep driver_set_override() in place.

Note that we can't use the device lock for the reasons described in [2].

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789 [1]
Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [2]
Tested-by: Gui-Dong Han <hanguidong02@gmail.com>
Co-developed-by: Gui-Dong Han <hanguidong02@gmail.com>
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260303115720.48783-2-dakr@kernel.org
[ Use dev->bus instead of sp->bus for consistency; fix commit message to
  refer to the struct bus_type's driver_override feature flag. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

DEFINE_GUARD_COND() for device_lock_interruptible()

Introduce conditional guard version of device_lock() for scenarios that
require conditional device lock holding.

This is a stable tag for other trees to merge.

Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Now that sysfs_create_groups() and sysfs_remove_groups() allow to
pass constant groups arrays, we can constify the groups array argument
also here.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/8ea2d6d1-0adb-4d7f-92bc-751e93ce08d6@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce conditional guard version of device_lock() for scenarios that
require conditional device lock holding.

Suggested-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Li Ming <ming.li@zohomail.com>
Link: https://patch.msgid.link/20260310-fix_access_endpoint_without_drv_check-v1-1-94fe919a0b87@zohomail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>