Hey there.
Sorry to nag, but it seems we came to the conclusion that there's
indeed a problem with the current code, and then collectively decided
that we're done. Can I do something to expedite this? Are there any
issues with my proposed patch? If there are, what can I do to fix
those? Alternativ
> The result is this:
> Before f13912d3f014a, if an RNDIS device has non-vendor-specific
> configurations after the first one, that one would be selected.
> After ff2a8c532c14, the first configuration would always be selected
> for RNDIS devices. Besides, there are several redundant checks in this
On Wed, 16 Jan 2019 at 07:24, Gopal, Saranya wrote:
>
> Hi Yakimov,
>
> As per UAC3 configuration, the first configuration will always be
> backward-compatible.
> So, there cannot be any UAC3-compatible device which has first configuration
> as UAC3.
Thanks for the clarification. I would argue
Hi Yakimov,
As per UAC3 configuration, the first configuration will always be
backward-compatible.
So, there cannot be any UAC3-compatible device which has first configuration as
UAC3.
And secondly, the commit ff2a8c532c14 does not break the pre-existing logic.
I also thought so much about movin
tue, 15 jan. 2019 at 19:53, Greg Kroah-Hartman :
> Were you able to test this on one of the devices that ff2a8c532c14
> ("usbcore: Select only first configuration for non-UAC3 compliant
> devices") was created to fix?
Yes, owning such a device (non-UAC3 with multiple configurations) was
the motiva
On Tue, Jan 15, 2019 at 07:13:54PM +0300, Nikolay Yakimov wrote:
> Commit f13912d3f014a introduced changes to the usb_choose_configuration
> function
> to better support USB Audio UAC3-compatible devices. However, there are a few
> problems with this patch. First of all, it adds new "if" clauses i
6 matches
Mail list logo
