USB reset problem

USB reset problem

[Bollinger, Seth]

Hello All,

Recently we saw a problem where the device reset will fail due to a configuration descriptor check in hub.c:5600.

        if (memcmp(buf, udev->rawdescriptors[index], old_length)
                != 0) {
            dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
                index,
                ((struct usb_config_descriptor *) buf)->
                    bConfigurationValue);
            changed = 1;
            break;
        }

The descriptors returned from the device have a different iInterface.  I checked the usb spec and couldn’t find anything that says iInterface can’t change.  I don’t have the source for the device, but I think it’s probably generating the interface string each reset and returning a different index for it (“ADB interface”).

Has anyone else seen this?  Does the spec guarantee that iInterface should never change between device resets?

Thanks,

Seth

Re: USB reset problem

[Greg KH]

On Thu, Jun 06, 2019 at 01:55:37PM +0000, Bollinger, Seth wrote:
> Hello All,
> 
> Recently we saw a problem where the device reset will fail due to a configuration descriptor check in hub.c:5600.
> 
>         if (memcmp(buf, udev->rawdescriptors[index], old_length)
>                 != 0) {
>             dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
>                 index,
>                 ((struct usb_config_descriptor *) buf)->
>                     bConfigurationValue);
>             changed = 1;
>             break;
>         }
> 
> The descriptors returned from the device have a different iInterface.  I checked the usb spec and couldn’t find anything that says iInterface can’t change.  I don’t have the source for the device, but I think it’s probably generating the interface string each reset and returning a different index for it (“ADB interface”).
> 
> Has anyone else seen this?  Does the spec guarantee that iInterface should never change between device resets?

If the descriptor changes between resets, that means that something
changed and we need to start over with it.  What is the problem that
this is causing?

thanks,

greg k-h

Re: USB reset problem

[Alan Stern]

On Thu, 6 Jun 2019, Bollinger, Seth wrote:

> Hello All,
> 
> Recently we saw a problem where the device reset will fail due to a
> configuration descriptor check in hub.c:5600.
> 
>         if (memcmp(buf, udev->rawdescriptors[index], old_length)
>                 != 0) {
>             dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
>                 index,
>                 ((struct usb_config_descriptor *) buf)->
>                     bConfigurationValue);
>             changed = 1;
>             break;
>         }
> 
> The descriptors returned from the device have a different iInterface.  
> I checked the usb spec and couldn’t find anything that says
> iInterface can’t change.  I don’t have the source for the device,
> but I think it’s probably generating the interface string each
> reset and returning a different index for it (“ADB interface”).
> 
> Has anyone else seen this?  Does the spec guarantee that iInterface
> should never change between device resets?

I have not seen this, and the spec doesn't really guarantee anything 
about what happens between device resets.

On the other hand, saying the reset failed in this case is not 
unreasonable.  The end result is that the device will be re-enumerated 
with its new iInterface value.

If this is really a problem we can change the code so that the 
iManufacturer, iProduct, iSerialNumber, iConfiguration, and iInterface 
descriptor values are exempt from the change check.  It would be a 
little difficult, though, because we would have to parse the 
descriptors to find out where the iInterface values are.

Alan Stern

Re: USB reset problem

[Bollinger, Seth]

> On Jun 6, 2019, at 9:36 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> If the descriptor changes between resets, that means that something
> changed and we need to start over with it.  What is the problem that
> this is causing

We have code doing a USBDEVFS_RESET that fails when the ioctl returns EPERM.

I think the solution might be to simply not do the reset for this device, but wanted to check if anyone else had encountered this issue.

Thanks!

Seth

Re: USB reset problem

[Bollinger, Seth]

> On Jun 6, 2019, at 9:37 AM, Alan Stern <stern@rowland.harvard.edu<mailto:stern@rowland.harvard.edu>> wrote:
>
> If this is really a problem we can change the code so that the
> iManufacturer, iProduct, iSerialNumber, iConfiguration, and iInterface
> descriptor values are exempt from the change check.  It would be a
> little difficult, though, because we would have to parse the
> descriptors to find out where the iInterface values are.

It seems like this is a legitimate protection.  It wouldn’t feel right to me pushing for a change that would only fix my particular device.

If I find we _really_ need it, I can patch our specific kernel.

Thanks for the quick responses!

Seth

Re: USB reset problem

[Alan Stern]

On Thu, 6 Jun 2019, Bollinger, Seth wrote:

> > On Jun 6, 2019, at 9:36 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > If the descriptor changes between resets, that means that something
> > changed and we need to start over with it.  What is the problem that
> > this is causing
> 
> We have code doing a USBDEVFS_RESET that fails when the ioctl returns EPERM.

EPERM means that the file descriptor was not opened with write access.  
It has nothing to do with reset failures.

> I think the solution might be to simply not do the reset for this device, but wanted to check if anyone else had encountered this issue.

It's true that many programs using usbfs do unnecessary resets.  If you 
don't need it, don't do it!

Alan Stern

Re: USB reset problem

[Bollinger, Seth]

> On Jun 6, 2019, at 10:03 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> EPERM means that the file descriptor was not opened with write access.  
> It has nothing to do with reset failures.

Yes, I was confused by that as well so spent some time instrumenting the kernel.  It definitely is open for writing, and get’s by the initial f_mode check in devio.c:usbdev_do_ioctl.

Is it possibly a default error that’s returned when some deeper error is encountered?  Unfortunately I was unable to determine exactly where it was coming from...

Seth

Re: USB reset problem

[Greg KH]

On Thu, Jun 06, 2019 at 03:19:14PM +0000, Bollinger, Seth wrote:
> > On Jun 6, 2019, at 10:03 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > EPERM means that the file descriptor was not opened with write access.  
> > It has nothing to do with reset failures.
> 
> Yes, I was confused by that as well so spent some time instrumenting the kernel.  It definitely is open for writing, and get’s by the initial f_mode check in devio.c:usbdev_do_ioctl.
> 
> Is it possibly a default error that’s returned when some deeper error is encountered?  Unfortunately I was unable to determine exactly where it was coming from...

ftrace is your friend :)