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

[Giuseppe Piscitelli]

Thanks, I switched to that approach: blacklisted the charging driver,
dropped the device-modalias backport, and booted the stock nixpkgs kernel.

I tested an existing libusb utility that does not claim interfaces [1].
Its optional charging request succeeded, and iLoader continued working.
I have not measured the actual charging current. The command remains
manual, rather than running on device arrival.

[1] https://github.com/FD-/usb_charge/blob/e957bcfc47262f8a47d652d7d417723578560b23/usb_charge.c#L42

Assisted-by: OpenAI Codex


On Wed, 07 Oct 2026 22:41:15 +0200, Michal Pecio <michal.pecio@xxxxxxxxx> wrote:
> 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