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

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

[Giuseppe Piscitelli]

USB device drivers can load from interface modaliases after a userspace
client has already configured the device. Loading apple-mfi-fastcharge
then reprobes the generic binding and interrupts usbmuxd transfers.

Emit a modalias on the device event, with unknown interface fields left
as wildcards. The existing udev module loader can load matching modules
before consumers receive the processed device event. Keep interface
modaliases and the driver teardown paths unchanged.

Signed-off-by: Giuseppe Piscitelli <ooonea@gmail.com>
Assisted-by: OpenAI Codex
---
Tested on x86_64 with Linux 7.2.9 and an iPhone (05ac:12a8). With no
Apple module preload, the first insertion after boot loads the module,
keeps configuration 4 and works with iLoader without restarting usbmuxd.
The current usb_uevent function also passes 18 source-extracted cases.

 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

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

[Alan Stern]

On Wed, Oct 07, 2026 at 06:17:21PM +0200, Giuseppe Piscitelli wrote:
> USB device drivers can load from interface modaliases after a userspace
> client has already configured the device. Loading apple-mfi-fastcharge
> then reprobes the generic binding and interrupts usbmuxd transfers.

This description is very confusing for anyone who doesn't already know 
what you're talking about.  Are you referring to some particular type of 
device?  If not, why mention apple-mfi-fastcharge and usbmuxd?  If yes, 
you should say what type of device and why apple-mfi-fastcharge and 
usbmuxd would get loaded in the first place.

> Emit a modalias on the device event, with unknown interface fields left
> as wildcards.

Why?  What does this accomplish?  How does it prevent 
apple-mfi-fastcharge from interrupting usbmuxd transfers?

>  The existing udev module loader can load matching modules
> before consumers receive the processed device event.

Why do you say "_existing_ udev module loader"?  Are you trying to 
reassure people who might think there was a _nonexistent_ udev module 
loader?

What processed device event?  Is this the uevent added by the patch or 
is it something else?  In what way does it get "processed"?

Sure, the udev module loader _can_ load matching modules before 
consumers receive the processed device event.  But udev might run slowly 
and not get around to loading matching modules until later.  What will 
happen then?

Alan Stern

>  Keep interface
> modaliases and the driver teardown paths unchanged.
> 
> Signed-off-by: Giuseppe Piscitelli <ooonea@gmail.com>
> Assisted-by: OpenAI Codex
> ---
> Tested on x86_64 with Linux 7.2.9 and an iPhone (05ac:12a8). With no
> Apple module preload, the first insertion after boot loads the module,
> keeps configuration 4 and works with iLoader without restarting usbmuxd.
> The current usb_uevent function also passes 18 source-extracted cases.
> 
>  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
> 

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

[Giuseppe Piscitelli]

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 <ooonea@gmail.com>
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/

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

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

[Alan Stern]

On Wed, Oct 07, 2026 at 09:11:30PM +0200, Giuseppe Piscitelli wrote:
> 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 <ooonea@gmail.com>
> 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.

Much better, thank you.

Alan Stern

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

[Michal Pecio]

On Wed,  7 Oct 2026 21:11:30 +0200, Giuseppe Piscitelli wrote:
> 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.

What is actually the appeal of apple-mfi-fastcharge?

It seems to just issues some control requests to the device when
commanded by userspace. Userspace could do the same with libusb,
apparently without unbinding drivers, changing configurations or
even claiming USB interfaces. I just tried a simple program that
queries GET_CONFIGURATION, with no disruption to kernel drivers
or other libusb applications using the same device concurrently.

Then simply blacklist the kernel module and all its problems are
gone forever without one line of kernel code?

Regards,
Michal