From: "M. Vefa Bicakci" <m.v.b@runbox.com>
To: Bastien Nocera <hadess@hadess.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Pany <pany@fedoraproject.org>,
linux-usb@vger.kernel.org
Subject: Re: Bug caused by 53965c79c2db (USB: Fix device driver race)
Date: Wed, 21 Oct 2020 16:49:09 -0400 [thread overview]
Message-ID: <4cc0e162-c607-3fdf-30c9-1b3a77f6cf20@runbox.com> (raw)
In-Reply-To: <5d2dc161951d0717d1ccfc88049c241c8ce8d1e6.camel@hadess.net>
On 21/10/2020 09.18, Bastien Nocera wrote:
> On Wed, 2020-10-21 at 09:08 -0400, M. Vefa Bicakci wrote:
>> On 21/10/2020 07.53, Bastien Nocera wrote:
>> [Snipped by Vefa]
>>>
>>> I have no idea why there isn't a match function. Patch v1 had a
>>> huge
>>> table:
>>> https://marc.info/?l=linux-usb&m=157062863431186&w=2
>>> and v2 already didn't had that comment, but no .match function:
>>> https://marc.info/?l=linux-usb&m=157114990905421&w=2
>>>
>>> I'll prepare a patch that adds a match function. I'll let you
>>> (Vefa)
>>> look at which of your patches need backporting though, as I'm
>>> really
>>> quite a bit lost in the different patch sets and branches :/
>>
>> Hello Bastien,
>>
>> Having found the root cause of the issue by going through Pany's
>> logs and having proposed a solution, I was hoping to get credit
>> for the resolution of the issue by authoring the patch.
>
> I don't care either way. Attached are the 2 patches I had made and was
> in the process of compiling and testing, feel free to adapt them,
> change the authorship, etc.
>
> Note that you mentioned you'd need to "replace the ID table with
> a match function", which will mean that the driver isn't automatically
> loaded when a device gets plugged in. So that wouldn't have worked.
>
> Let me know when you've made your patch, as I'll need to update this
> bug when there's something to test:
> https://bugzilla.redhat.com/show_bug.cgi?id=1878347
>
> Cheers
Hello Bastien,
Sorry about my delayed reply. Thank you, and I appreciate your understanding.
I intend to continue the work starting later today, and I will make
sure that you are credited by using the co-developed-by tag in the
patches, as you have mentioned in your more recent e-mail in this thread.
I will investigate/verify the ID table vs. match function aspect
as well; I understand that my suggestion could be incorrect.
Thanks again,
Vefa
next prev parent reply other threads:[~2020-10-21 20:49 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
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 [this message]
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=4cc0e162-c607-3fdf-30c9-1b3a77f6cf20@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