[RFC PATCH v2] USB: core: emit a device-level modalias

On the first insertion of an iPhone (05ac:12a8) after boot, an already
running usbmuxd can select USB configuration 4 before the charging driver
apple-mfi-fastcharge loads. usbmuxd is a userspace daemon that uses libusb
to communicate with Apple devices; apple-mfi-fastcharge is a USB device
driver that enables their higher charging current.

USB device uevents have no MODALIAS. The charging module instead loads
from an interface uevent. Its registration reprobes the device, unbinds
the generic driver and calls usb_set_configuration(udev, -1), tearing down
the interfaces and interrupting usbmuxd's transfers.

Emit a modalias in the USB device uevent, using wildcards for interface
fields because no particular interface is described by this event. This
allows udev's kmod builtin to load matching device drivers while handling
the device add event, before broadcasting that event to libudev listeners.
libusb's udev hotplug backend listens for this broadcast, so usbmuxd sees
the arrival after the charging module has finished loading and reprobed
the device, rather than before a later interface event loads it.

A slow udev worker delays both module loading and the broadcast; it does
not reverse this ordering. This addresses hotplug through the udev
backend, not clients reading raw kernel events or scanning devices before
udev has finished, and does not synchronize later manual module loading.

Signed-off-by: Giuseppe Piscitelli <redacted>
Assisted-by: OpenAI Codex
---
v2:
- Explain the iPhone, charging driver and usbmuxd interaction.
- Describe synchronous module loading before the libudev broadcast,
  including the ordering when udev runs slowly and its scope limits.
- No code changes.

v1: https://lore.kernel.org/linux-usb/20261007161721.60593-1-ooonea@gmail.com/ (local)

Tested on x86_64 with Linux 7.2.9 and an iPhone (05ac:12a8): first
insertion after boot without module preload loads the charging driver,
keeps configuration 4 and works with iLoader. Tracing the earlier udev
builtin experiment showed driver registration before usbmuxd selected
configuration 4. No delayed-udev runtime test has been performed.
The usb-next function passes 18 source-extracted cases; a full usb-next
kernel has not been built. OpenAI Codex assisted with diagnosis, the
patch, the test harness and this description.

 drivers/usb/core/driver.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 3c3bbaf89..29d1acba9 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c

@@ -954,6 +954,17 @@ static int usb_uevent(const struct device *dev, struct kobj_uevent_env *env)
 			   usb_dev->descriptor.bDeviceProtocol))
 		return -ENOMEM;
 
+	if (is_usb_device(dev) &&
+	    add_uevent_var(env,
+			   "MODALIAS=usb:v%04Xp%04Xd%04Xdc%02Xdsc%02Xdp%02Xic*isc*ip*in*",
+			   le16_to_cpu(usb_dev->descriptor.idVendor),
+			   le16_to_cpu(usb_dev->descriptor.idProduct),
+			   le16_to_cpu(usb_dev->descriptor.bcdDevice),
+			   usb_dev->descriptor.bDeviceClass,
+			   usb_dev->descriptor.bDeviceSubClass,
+			   usb_dev->descriptor.bDeviceProtocol))
+		return -ENOMEM;
+
 	return 0;
 }
 

base-commit: 42bcac323cc3b16566fed8c5b250318ad02a0de0
-- 
2.54.0