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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.