From: "M. Vefa Bicakci" <m.v.b@runbox.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Pany <pany@fedoraproject.org>, Bastien Nocera <hadess@hadess.net>,
linux-usb@vger.kernel.org
Subject: Re: Bug caused by 53965c79c2db (USB: Fix device driver race)
Date: Wed, 21 Oct 2020 00:18:26 -0400 [thread overview]
Message-ID: <74e25095-53fa-b98c-6baf-c97eea574d1c@runbox.com> (raw)
In-Reply-To: <20201020152859.GA945128@rowland.harvard.edu>
On 20/10/2020 11.28, Alan Stern wrote:
> On Tue, Oct 20, 2020 at 08:03:23AM -0400, M. Vefa Bicakci wrote:
>> On 19/10/2020 13.40, Alan Stern wrote:
>>> On Mon, Oct 19, 2020 at 09:36:00AM +0000, Pany wrote:
[Snipped by Vefa]
>>
>> ... and Pany's system has multiple USB devices manufactured by Apple
>> (including the SD card reader), with the vendor code 0x05ac, which is
>> the value included by the id_table of the apple-mfi-fastcharge driver:
>>
>> Sep 29 15:22:48 fedora.local kernel: usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
>> Sep 29 15:22:48 fedora.local kernel: usb 2-3: New USB device found, idVendor=05ac, idProduct=8406, bcdDevice= 8.20
>> Sep 29 15:22:48 fedora.local kernel: usb 2-3: New USB device strings: Mfr=3, Product=4, SerialNumber=5
>> Sep 29 15:22:48 fedora.local kernel: usb 2-3: Product: Card Reader
>> Sep 29 15:22:48 fedora.local kernel: usb 2-3: Manufacturer: Apple
>> ...
>> Sep 29 15:22:48 fedora.local kernel: usb 1-5: new full-speed USB device number 3 using xhci_hcd
>> Sep 29 15:22:48 fedora.local kernel: usb 1-5: New USB device found, idVendor=05ac, idProduct=0273, bcdDevice= 6.22
>> Sep 29 15:22:48 fedora.local kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> Sep 29 15:22:48 fedora.local kernel: usb 1-5: Product: Apple Internal Keyboard / Trackpad
>> Sep 29 15:22:48 fedora.local kernel: usb 1-5: Manufacturer: Apple Inc.
>> ...
>>
>> One way to fix this issue would be to implement a match function in the
>> apple-mfi-fastcharge driver, possibly instead of an id_table, so that it
>> does not match devices that it cannot bind to. This may require other
>> changes in the USB core that I cannot fathom at the moment.
>
> How about matching on the vendor ID and the product ID? That would be
> an easy addition to the ID table. Do the fastcharge devices have a well
> known product ID?
>
> Alan Stern
Hello Alan,
Thank you for the feedback! Judging from the driver's code, it looks like
the product identifiers are known, but there unfortunately appear to be
256 possible product identifiers (i.e., 0x00->0xFF):
23 /* The product ID is defined as starting with 0x12nn, as per the
24 * "Choosing an Apple Device USB Configuration" section in
25 * release R9 (2012) of the "MFi Accessory Hardware Specification"
26 *
27 * To distinguish an Apple device, a USB host can check the device
28 * descriptor of attached USB devices for the following fields:
29 * - Vendor ID: 0x05AC
30 * - Product ID: 0x12nn
31 *
32 * Those checks will be done in .match() and .probe().
33 */
...
166 static int mfi_fc_probe(struct usb_device *udev)
167 {
...
171
172 idProduct = le16_to_cpu(udev->descriptor.idProduct);
173 /* See comment above mfi_fc_id_table[] */
174 if (idProduct < 0x1200 || idProduct > 0x12ff) {
175 return -ENODEV;
176 }
A quick look at drivers/usb/core/driver.c::usb_match_device indicates
that it is not yet possible to specify ranges in ID tables of USB
drivers, so I think that we would need to replace the ID table with
a match function. Interestingly enough, the comment block quoted
above mentions the use of a match function as well.
Thank you,
Vefa
As a reminder to myself, removing the ID table from the apple-mfi-fastcharge
driver and implementing a match function in this driver will likely require
cherry-picking the following commit to 5.8.y:
0ed9498f9ecf ("USB: Simplify USB ID table match")
next prev parent reply other threads:[~2020-10-21 4:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 16:07 Bug caused by 53965c79c2db (USB: Fix device driver race) Pany
2020-10-17 20:02 ` Alan Stern
2020-10-19 9:36 ` Pany
2020-10-19 17:40 ` Alan Stern
2020-10-20 12:03 ` M. Vefa Bicakci
2020-10-20 15:28 ` Alan Stern
2020-10-21 4:18 ` M. Vefa Bicakci [this message]
2020-10-21 11:53 ` Bastien Nocera
2020-10-21 12:02 ` Bastien Nocera
2020-10-21 12:29 ` Alan Stern
2020-10-21 12:31 ` Bastien Nocera
2020-10-21 13:01 ` Bastien Nocera
2020-10-21 13:08 ` M. Vefa Bicakci
2020-10-21 13:18 ` Bastien Nocera
2020-10-21 13:21 ` Bastien Nocera
2020-10-21 20:11 ` Alan Stern
2020-10-21 20:49 ` M. Vefa Bicakci
2020-10-21 20:49 ` M. Vefa Bicakci
2020-10-22 13:55 ` [PATCH 0/2] Patches to prevent re-probing all Apple USB devices on apple-mfi-fastcharge load M. Vefa Bicakci
2020-10-22 13:55 ` [PATCH 1/2] usbcore: Check both id_table and match() when both available M. Vefa Bicakci
2020-10-22 13:59 ` M. Vefa Bicakci
[not found] ` <CAHp75VeBgQ2ywLzU5PZEdfS+9M_niD0KoiEG=UMNH+4cPfsCNw@mail.gmail.com>
2020-10-23 12:51 ` M. Vefa Bicakci
2020-10-27 14:02 ` Bastien Nocera
2020-10-28 4:00 ` Pany
2020-10-29 3:33 ` M. Vefa Bicakci
2020-10-29 5:35 ` Pany
2020-10-22 13:55 ` [PATCH 2/2] USB: apple-mfi-fastcharge: don't probe unhandled devices M. Vefa Bicakci
2020-10-27 14:02 ` Bastien Nocera
2020-10-28 4:01 ` Pany
2020-10-21 3:17 ` Bug caused by 53965c79c2db (USB: Fix device driver race) Pany
2020-10-21 4:18 ` M. Vefa Bicakci
2020-10-21 5:19 ` Pany
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74e25095-53fa-b98c-6baf-c97eea574d1c@runbox.com \
--to=m.v.b@runbox.com \
--cc=hadess@hadess.net \
--cc=linux-usb@vger.kernel.org \
--cc=pany@fedoraproject.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox