From: Felipe Balbi <balbi@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Pawel Laszczak <pawell@cadence.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"ruslan.bilovol@gmail.com" <ruslan.bilovol@gmail.com>,
"jbrunet@baylibre.com" <jbrunet@baylibre.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Rahul Kumar <kurahul@cadence.com>,
"peter.chen@kernel.org" <peter.chen@kernel.org>
Subject: Re: [PATCH v2 1/2] usb: gadget: f_uac2: Stop endpoint before enabling it.
Date: Mon, 26 Apr 2021 17:54:37 +0300 [thread overview]
Message-ID: <87zgxljdua.fsf@kernel.org> (raw)
In-Reply-To: <20210426145047.GB365717@rowland.harvard.edu>
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
Hi,
Alan Stern <stern@rowland.harvard.edu> writes:
> On Mon, Apr 26, 2021 at 03:52:46PM +0300, Felipe Balbi wrote:
>> yeah, this is a requirement by the spec, IIRC. A SetAlt to the same
>> interface/altSetting means the host wants to reset that altSetting. From
>> the peripheral point of view that means disabling the endpoints and
>> reenabling them.
>>
>> I'm just not entirely sure if we should do this in u_audio or
>> f_uac[12].c. Arguably, composite.c could detect this and disable the
>> altSetting, but that would require a huge refactor on the framework.
>>
>> My gut feeling is that for the minimal bug fix, we should patch
>> f_uac[12].c, but all audio function drivers have the same exact bug, so
>> I don't know.
>>
>> If we follow the "standard" of patching the relevant set_alt functions
>> in the function drivers, the moment we decide to go for a refactoring,
>> it'll be easier to see common constructs.
>
> FWIW, f_mass_storage.c handles this in its do_set_interface() routine.
> That routine first deallocates any related request buffers and disables
> any enabled endpoints in the interface. It then goes on to enable
> endpoints for the new alternate setting and allocate request buffers.
>
> The audio function drivers could follow this approach.
right, that's what all other drivers do, in fact. Only audio seems to be
different. The question here is whether to patch every f_uac*.c (there
are three of them) or patch it in the generic u_audio.c
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
next prev parent reply other threads:[~2021-04-26 14:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 4:48 [PATCH v2 1/2] usb: gadget: f_uac2: Stop endpoint before enabling it Pawel Laszczak
2021-04-26 10:22 ` Felipe Balbi
2021-04-26 10:47 ` Pawel Laszczak
2021-04-26 12:52 ` Felipe Balbi
2021-04-26 14:50 ` Alan Stern
2021-04-26 14:54 ` Felipe Balbi [this message]
2021-04-27 4:35 ` Pawel Laszczak
2021-04-28 10:33 ` Felipe Balbi
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=87zgxljdua.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jbrunet@baylibre.com \
--cc=kurahul@cadence.com \
--cc=linux-usb@vger.kernel.org \
--cc=pawell@cadence.com \
--cc=peter.chen@kernel.org \
--cc=ruslan.bilovol@gmail.com \
--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.