(no subject)

[Ralf Beck]

Currently the usb core is disabling the use of and endpoint, if the endpoint address is present in two different USB interface descriptors within the same USB configuration.
This behaviour is obviously based on following passage in the USB specification:

"An endpoint is not shared among interfaces within a single configuration unless the endpoint is used by alternate settings of the same interface."

However, this behaviour prevents using some interfaces (in my case the Motu AVB audio devices) in their vendor specific mode.

They use a single USB configuration with tqo sets of interfaces, which use the same isochronous entpoint numbers.

One set with audio class specific interfaces for use by an audi class driver.
The other set with vendor specific interfaces for use by the vendor driver.
Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously.

There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode.

Sincerly,
Ralf Beck

Re:

[Greg KH]

On Mon, Dec 20, 2021 at 07:46:34AM +0100, Ralf Beck wrote:
> 
> Currently the usb core is disabling the use of and endpoint, if the endpoint address is present in two different USB interface descriptors within the same USB configuration.
> This behaviour is obviously based on following passage in the USB specification:
> 
> "An endpoint is not shared among interfaces within a single configuration unless the endpoint is used by alternate settings of the same interface."
> 
> However, this behaviour prevents using some interfaces (in my case the Motu AVB audio devices) in their vendor specific mode.
> 
> They use a single USB configuration with tqo sets of interfaces, which use the same isochronous entpoint numbers.
> 
> One set with audio class specific interfaces for use by an audi class driver.
> The other set with vendor specific interfaces for use by the vendor driver.
> Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously.
> 
> There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode.

The device sounds like it des not follow the USB specification, so how
does it work with any operating system?

What in-kernel driver binds to the device in vendor mode?

thanks,

greg k-h

Re:

[Oliver Neukum]

On 20.12.21 07:46, Ralf Beck wrote
> One set with audio class specific interfaces for use by an audi class driver.
> The other set with vendor specific interfaces for use by the vendor driver.
> Obviously the class specific interfaces and vendor specific interfaces are not intended to be use by a driver simultaniously.
Such devices are buggy. We usually define quirks for such devices.
> There must be another solution to deal with this. It is unacceptable to request a user of these devices to have to disablethe duplicate endpoint check and recompile the kernel on every update in order to be able to use their devices in vendor mode.
I suggest you write a patch to introduce a quirk that disables one of the
interfaces and disregards disabled interfaces for purposes of the check.

    Regards
        Oliver

PS: Please use a subject line when you post.

Duplicate endpoints (was: Re:)

[Johan Hovold]

On Mon, Dec 20, 2021 at 11:01:56AM +0100, Oliver Neukum wrote:
> 
> On 20.12.21 07:46, Ralf Beck wrote
> > One set with audio class specific interfaces for use by an audi
> > class driver.  The other set with vendor specific interfaces for use
> > by the vendor driver.  Obviously the class specific interfaces and
> > vendor specific interfaces are not intended to be use by a driver
> > simultaniously.

> Such devices are buggy. We usually define quirks for such devices.

> > There must be another solution to deal with this. It is unacceptable
> > to request a user of these devices to have to disablethe duplicate
> > endpoint check and recompile the kernel on every update in order to
> > be able to use their devices in vendor mode.

> I suggest you write a patch to introduce a quirk that disables one of the
> interfaces and disregards disabled interfaces for purposes of the check.

We already have USB_QUIRK_ENDPOINT_IGNORE (previously known as
USB_QUIRK_ENDPOINT_BLACKLIST) for this. See, for example:

	184eead057cc ("USB: core: Fix regression in Hercules audio card")

and

	bdd1b147b802 ("USB: quirks: blacklist duplicate ep on Sound Devices USBPre2")

Johan