* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
[not found] ` <20200101175220.GA18140@suse.com>
@ 2020-01-01 18:35 ` Laurent Pinchart
2020-01-01 18:47 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-01 18:35 UTC (permalink / raw)
To: Roger Whittaker; +Cc: Takashi Iwai, Alan Stern, linux-usb
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]
Hi Roger,
(CCin'g Alan Stern and linux-usb)
On Wed, Jan 01, 2020 at 05:52:27PM +0000, Roger Whittaker wrote:
> On Wed, Jan 01, 2020 at 07:24:49PM +0200, Laurent Pinchart wrote:
>
> > The last message is worse. Could you send me the output of lsusb -v (you
> > can restrict it to the camera with -d), if possible running as root, for
> > both the working and non-working kernels ?
>
> Thanks very much for your reply.
>
> The lsusb outputs are attached - they are in fact identical to each
> other.
>
> Also attached, the dmesg lines when replugging the camera on both
> kernels.
Thank you for the information.
I had missed the following message:
[ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
This seems to be the culprit, and it points to the USB core. One
interface is ignored due to its wMaxPacketSize value, and the uvcvideo
driver then fails to find it.
The wMaxPacketSize check was added in
commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Oct 28 10:52:35 2019 -0400
USB: Skip endpoints with 0 maxpacket length
Endpoints with a maxpacket length of 0 are probably useless. They
can't transfer any data, and it's not at all unlikely that an HCD will
crash or hang when trying to handle an URB for such an endpoint.
Currently the USB core does not check for endpoints having a maxpacket
value of 0. This patch adds a check, printing a warning and skipping
over any endpoints it catches.
Now, the USB spec does not rule out endpoints having maxpacket = 0.
But since they wouldn't have any practical use, there doesn't seem to
be any good reason for us to accept them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit was merged in v5.4 and backported to v5.3.11 in
47aaab6377204cdbcd16f52a23c584f994fd0d15.
For reference for Alan and linux-usb, the issue being discussed is
described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
above commit seems to cause a regression with several cameras. I've
attached to this e-mail the lsusb output provided by Roger.
--
Regards,
Laurent Pinchart
[-- Attachment #2: lsusb-with-5.3.9-1-default --]
[-- Type: text/plain, Size: 9342 bytes --]
Bus 001 Device 010: ID 1778:0214
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1778
idProduct 0x0214
bcdDevice 7.07
iManufacturer 1 IPEVO Inc.
iProduct 2 IPEVO Point 2 View
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0299
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 64
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 IPEVO Point 2 View
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 IPEVO Point 2 View
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x0050
dwClockFrequency 6.000000MHz
bInCollection 1
baInterfaceNr( 0) 2
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x000200a2
Auto-Exposure Mode
Focus (Absolute)
Iris (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000147f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1d
None
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 29
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {5a215226-3289-4156-894a-5c557cdf9664}
bNumControl 4
bNrPins 1
baSourceID( 0) 3
bControlSize 4
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0xff
bmControls( 3) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
INTERFACE CLASS: 0f 24 01 02 ea 01 82 00 02 02 01 00 01 00 00
INTERFACE CLASS: 1b 24 04 01 07 59 55 59 32 00 00 10 00 80 00 00 aa 00 38 9b 71 10 01 00 00 00 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 02 00 40 01 f0 00 c0 00 03 4b c0 00 03 4b 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 03 00 20 03 58 02 70 00 14 99 70 00 14 99 00 a6 0e 00 9a 5b 06 00 01 9a 5b 06 00
INTERFACE CLASS: 1e 24 05 04 00 00 04 00 03 00 00 16 80 00 00 16 80 00 00 18 00 2a 2c 0a 00 01 2a 2c 0a 00
INTERFACE CLASS: 1e 24 05 05 00 00 05 00 04 00 00 12 c0 00 00 12 c0 00 00 28 00 d0 12 13 00 01 d0 12 13 00
INTERFACE CLASS: 1e 24 05 06 00 40 06 b0 04 00 00 0e a6 00 00 0e a6 00 98 3a 00 a0 25 26 00 01 a0 25 26 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 0b 24 03 00 01 80 02 e0 01 01 00
INTERFACE CLASS: 0b 24 06 02 07 00 01 00 00 00 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 02 00 40 01 f0 00 c0 00 03 4b c0 00 03 4b 00 58 02 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 03 00 20 03 58 02 70 00 14 99 70 00 14 99 00 a6 0e 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 04 00 00 04 00 03 00 00 16 80 00 00 16 80 00 00 18 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 05 00 00 05 00 04 00 00 12 c0 00 00 12 c0 00 00 28 00 2a 2c 0a 00 01 2a 2c 0a 00
INTERFACE CLASS: 1e 24 07 06 00 40 06 b0 04 00 00 0e a6 00 00 0e a6 00 98 3a 00 d0 12 13 00 01 d0 12 13 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 06 24 0d 00 00 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x13fc 3x 1020 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-01 18:35 ` Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels Laurent Pinchart
@ 2020-01-01 18:47 ` Greg KH
2020-01-01 20:09 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2020-01-01 18:47 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Roger Whittaker, Takashi Iwai, Alan Stern, linux-usb
On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
> Hi Roger,
>
> (CCin'g Alan Stern and linux-usb)
>
> On Wed, Jan 01, 2020 at 05:52:27PM +0000, Roger Whittaker wrote:
> > On Wed, Jan 01, 2020 at 07:24:49PM +0200, Laurent Pinchart wrote:
> >
> > > The last message is worse. Could you send me the output of lsusb -v (you
> > > can restrict it to the camera with -d), if possible running as root, for
> > > both the working and non-working kernels ?
> >
> > Thanks very much for your reply.
> >
> > The lsusb outputs are attached - they are in fact identical to each
> > other.
> >
> > Also attached, the dmesg lines when replugging the camera on both
> > kernels.
>
> Thank you for the information.
>
> I had missed the following message:
>
> [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
>
> This seems to be the culprit, and it points to the USB core. One
> interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> driver then fails to find it.
>
> The wMaxPacketSize check was added in
>
> commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date: Mon Oct 28 10:52:35 2019 -0400
>
> USB: Skip endpoints with 0 maxpacket length
>
> Endpoints with a maxpacket length of 0 are probably useless. They
> can't transfer any data, and it's not at all unlikely that an HCD will
> crash or hang when trying to handle an URB for such an endpoint.
>
> Currently the USB core does not check for endpoints having a maxpacket
> value of 0. This patch adds a check, printing a warning and skipping
> over any endpoints it catches.
>
> Now, the USB spec does not rule out endpoints having maxpacket = 0.
> But since they wouldn't have any practical use, there doesn't seem to
> be any good reason for us to accept them.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>
> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> The commit was merged in v5.4 and backported to v5.3.11 in
> 47aaab6377204cdbcd16f52a23c584f994fd0d15.
>
> For reference for Alan and linux-usb, the issue being discussed is
> described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> above commit seems to cause a regression with several cameras. I've
> attached to this e-mail the lsusb output provided by Roger.
How can a device work with an endpoint of 0 length?
What does the driver expect to do with those endpoints? Does it expect
it to be present but just ignore it?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-01 18:47 ` Greg KH
@ 2020-01-01 20:09 ` Alan Stern
2020-01-02 11:20 ` Johan Hovold
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2020-01-01 20:09 UTC (permalink / raw)
To: Greg KH; +Cc: Laurent Pinchart, Roger Whittaker, Takashi Iwai, linux-usb
On Wed, 1 Jan 2020, Greg KH wrote:
> On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
> > Hi Roger,
> >
> > (CCin'g Alan Stern and linux-usb)
> >
> > On Wed, Jan 01, 2020 at 05:52:27PM +0000, Roger Whittaker wrote:
> > > On Wed, Jan 01, 2020 at 07:24:49PM +0200, Laurent Pinchart wrote:
> > >
> > > > The last message is worse. Could you send me the output of lsusb -v (you
> > > > can restrict it to the camera with -d), if possible running as root, for
> > > > both the working and non-working kernels ?
> > >
> > > Thanks very much for your reply.
> > >
> > > The lsusb outputs are attached - they are in fact identical to each
> > > other.
> > >
> > > Also attached, the dmesg lines when replugging the camera on both
> > > kernels.
> >
> > Thank you for the information.
> >
> > I had missed the following message:
> >
> > [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> >
> > This seems to be the culprit, and it points to the USB core. One
> > interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> > driver then fails to find it.
> >
> > The wMaxPacketSize check was added in
> >
> > commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> > Author: Alan Stern <stern@rowland.harvard.edu>
> > Date: Mon Oct 28 10:52:35 2019 -0400
> >
> > USB: Skip endpoints with 0 maxpacket length
> >
> > Endpoints with a maxpacket length of 0 are probably useless. They
> > can't transfer any data, and it's not at all unlikely that an HCD will
> > crash or hang when trying to handle an URB for such an endpoint.
> >
> > Currently the USB core does not check for endpoints having a maxpacket
> > value of 0. This patch adds a check, printing a warning and skipping
> > over any endpoints it catches.
> >
> > Now, the USB spec does not rule out endpoints having maxpacket = 0.
> > But since they wouldn't have any practical use, there doesn't seem to
> > be any good reason for us to accept them.
> >
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> >
> > Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > The commit was merged in v5.4 and backported to v5.3.11 in
> > 47aaab6377204cdbcd16f52a23c584f994fd0d15.
> >
> > For reference for Alan and linux-usb, the issue being discussed is
> > described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> > above commit seems to cause a regression with several cameras. I've
> > attached to this e-mail the lsusb output provided by Roger.
>
> How can a device work with an endpoint of 0 length?
>
> What does the driver expect to do with those endpoints? Does it expect
> it to be present but just ignore it?
I see what's going on. The endpoint in question is isochronous, and
the bAlternateSetting value is 0, which makes this the default
altsetting for that interface. The USB spec says (at the end of
section 5.6.3):
All device default interface settings must not include any
isochronous endpoints with non-zero data payload sizes
(specified via wMaxPacketSize in the endpoint descriptor).
Alternate interface settings may specify non-zero data payload
sizes for isochronous endpoints.
That explains why the maxpacket size is set to 0.
So it looks like the endpoint-descriptor parsing code might want to
make a special case to accept isochronous endpoints with maxpacket 0 if
bAlternateSetting is 0. But whether we do this or not, I would expect
the uvcvideo driver to look for isochronous endpoints in the alternate
settings it will actually use, not in altsetting 0. Then the presence
or absence of that endpoint descriptor would make no difference to
uvcvideo.
(Unless the UVC spec _requires_ these endpoint descriptors to be
present. If it does then we should simply change the core parsing code
and leave uvcvideo alone.)
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-01 20:09 ` Alan Stern
@ 2020-01-02 11:20 ` Johan Hovold
2020-01-02 13:11 ` Takashi Iwai
0 siblings, 1 reply; 23+ messages in thread
From: Johan Hovold @ 2020-01-02 11:20 UTC (permalink / raw)
To: Alan Stern
Cc: Greg KH, Laurent Pinchart, Roger Whittaker, Takashi Iwai, linux-usb
On Wed, Jan 01, 2020 at 03:09:35PM -0500, Alan Stern wrote:
> On Wed, 1 Jan 2020, Greg KH wrote:
> > On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
> > > [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > >
> > > This seems to be the culprit, and it points to the USB core. One
> > > interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> > > driver then fails to find it.
> > >
> > > The wMaxPacketSize check was added in
> > >
> > > commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> > > Author: Alan Stern <stern@rowland.harvard.edu>
> > > Date: Mon Oct 28 10:52:35 2019 -0400
> > >
> > > USB: Skip endpoints with 0 maxpacket length
> > >
> > > Endpoints with a maxpacket length of 0 are probably useless. They
> > > can't transfer any data, and it's not at all unlikely that an HCD will
> > > crash or hang when trying to handle an URB for such an endpoint.
> > >
> > > Currently the USB core does not check for endpoints having a maxpacket
> > > value of 0. This patch adds a check, printing a warning and skipping
> > > over any endpoints it catches.
> > >
> > > Now, the USB spec does not rule out endpoints having maxpacket = 0.
> > > But since they wouldn't have any practical use, there doesn't seem to
> > > be any good reason for us to accept them.
> > >
> > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > >
> > > Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > The commit was merged in v5.4 and backported to v5.3.11 in
> > > 47aaab6377204cdbcd16f52a23c584f994fd0d15.
> > >
> > > For reference for Alan and linux-usb, the issue being discussed is
> > > described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> > > above commit seems to cause a regression with several cameras. I've
> > > attached to this e-mail the lsusb output provided by Roger.
> >
> > How can a device work with an endpoint of 0 length?
> >
> > What does the driver expect to do with those endpoints? Does it expect
> > it to be present but just ignore it?
>
> I see what's going on. The endpoint in question is isochronous, and
> the bAlternateSetting value is 0, which makes this the default
> altsetting for that interface. The USB spec says (at the end of
> section 5.6.3):
>
> All device default interface settings must not include any
> isochronous endpoints with non-zero data payload sizes
> (specified via wMaxPacketSize in the endpoint descriptor).
> Alternate interface settings may specify non-zero data payload
> sizes for isochronous endpoints.
>
> That explains why the maxpacket size is set to 0.
>
> So it looks like the endpoint-descriptor parsing code might want to
> make a special case to accept isochronous endpoints with maxpacket 0 if
> bAlternateSetting is 0. But whether we do this or not, I would expect
> the uvcvideo driver to look for isochronous endpoints in the alternate
> settings it will actually use, not in altsetting 0. Then the presence
> or absence of that endpoint descriptor would make no difference to
> uvcvideo.
>
> (Unless the UVC spec _requires_ these endpoint descriptors to be
> present. If it does then we should simply change the core parsing code
> and leave uvcvideo alone.)
Note that we also have this little gem in the ftdi usb-serial driver
(since 2009) overriding a zero max packet size for devices with broken
descriptors:
895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation")
Note sure how common those are but they will no longer work after the
new sanity check in core. I guess we could add quirks for them (to core)
in case we get any reports, but perhaps reverting the check should be
considered.
There doesn't seem to be any other drivers accepting and explicitly
handling zero max packet sizes like this in mainline however.
Johan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 11:20 ` Johan Hovold
@ 2020-01-02 13:11 ` Takashi Iwai
2020-01-02 15:06 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Takashi Iwai @ 2020-01-02 13:11 UTC (permalink / raw)
To: Johan Hovold
Cc: Alan Stern, Greg KH, Laurent Pinchart, Roger Whittaker,
Takashi Iwai, linux-usb
On Thu, 02 Jan 2020 12:20:45 +0100,
Johan Hovold wrote:
>
> On Wed, Jan 01, 2020 at 03:09:35PM -0500, Alan Stern wrote:
> > On Wed, 1 Jan 2020, Greg KH wrote:
> > > On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
>
> > > > [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > > >
> > > > This seems to be the culprit, and it points to the USB core. One
> > > > interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> > > > driver then fails to find it.
> > > >
> > > > The wMaxPacketSize check was added in
> > > >
> > > > commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> > > > Author: Alan Stern <stern@rowland.harvard.edu>
> > > > Date: Mon Oct 28 10:52:35 2019 -0400
> > > >
> > > > USB: Skip endpoints with 0 maxpacket length
> > > >
> > > > Endpoints with a maxpacket length of 0 are probably useless. They
> > > > can't transfer any data, and it's not at all unlikely that an HCD will
> > > > crash or hang when trying to handle an URB for such an endpoint.
> > > >
> > > > Currently the USB core does not check for endpoints having a maxpacket
> > > > value of 0. This patch adds a check, printing a warning and skipping
> > > > over any endpoints it catches.
> > > >
> > > > Now, the USB spec does not rule out endpoints having maxpacket = 0.
> > > > But since they wouldn't have any practical use, there doesn't seem to
> > > > be any good reason for us to accept them.
> > > >
> > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > >
> > > > Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > The commit was merged in v5.4 and backported to v5.3.11 in
> > > > 47aaab6377204cdbcd16f52a23c584f994fd0d15.
> > > >
> > > > For reference for Alan and linux-usb, the issue being discussed is
> > > > described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> > > > above commit seems to cause a regression with several cameras. I've
> > > > attached to this e-mail the lsusb output provided by Roger.
> > >
> > > How can a device work with an endpoint of 0 length?
> > >
> > > What does the driver expect to do with those endpoints? Does it expect
> > > it to be present but just ignore it?
> >
> > I see what's going on. The endpoint in question is isochronous, and
> > the bAlternateSetting value is 0, which makes this the default
> > altsetting for that interface. The USB spec says (at the end of
> > section 5.6.3):
> >
> > All device default interface settings must not include any
> > isochronous endpoints with non-zero data payload sizes
> > (specified via wMaxPacketSize in the endpoint descriptor).
> > Alternate interface settings may specify non-zero data payload
> > sizes for isochronous endpoints.
> >
> > That explains why the maxpacket size is set to 0.
> >
> > So it looks like the endpoint-descriptor parsing code might want to
> > make a special case to accept isochronous endpoints with maxpacket 0 if
> > bAlternateSetting is 0. But whether we do this or not, I would expect
> > the uvcvideo driver to look for isochronous endpoints in the alternate
> > settings it will actually use, not in altsetting 0. Then the presence
> > or absence of that endpoint descriptor would make no difference to
> > uvcvideo.
> >
> > (Unless the UVC spec _requires_ these endpoint descriptors to be
> > present. If it does then we should simply change the core parsing code
> > and leave uvcvideo alone.)
>
> Note that we also have this little gem in the ftdi usb-serial driver
> (since 2009) overriding a zero max packet size for devices with broken
> descriptors:
>
> 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation")
>
> Note sure how common those are but they will no longer work after the
> new sanity check in core. I guess we could add quirks for them (to core)
> in case we get any reports, but perhaps reverting the check should be
> considered.
FWIW, Roger confirmed that reverting the commit d482c7bb0541 does
indeed fix the issue (with the latest 5.4.y kernel).
thanks,
Takashi
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 13:11 ` Takashi Iwai
@ 2020-01-02 15:06 ` Alan Stern
2020-01-02 15:32 ` Johan Hovold
2020-01-02 16:38 ` Laurent Pinchart
0 siblings, 2 replies; 23+ messages in thread
From: Alan Stern @ 2020-01-02 15:06 UTC (permalink / raw)
To: Takashi Iwai
Cc: Johan Hovold, Greg KH, Laurent Pinchart, Roger Whittaker,
Takashi Iwai, linux-usb
On Thu, 2 Jan 2020, Takashi Iwai wrote:
> On Thu, 02 Jan 2020 12:20:45 +0100,
> Johan Hovold wrote:
> >
> > On Wed, Jan 01, 2020 at 03:09:35PM -0500, Alan Stern wrote:
> > > On Wed, 1 Jan 2020, Greg KH wrote:
> > > > On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
> >
> > > > > [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > > > >
> > > > > This seems to be the culprit, and it points to the USB core. One
> > > > > interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> > > > > driver then fails to find it.
> > > > >
> > > > > The wMaxPacketSize check was added in
> > > > >
> > > > > commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> > > > > Author: Alan Stern <stern@rowland.harvard.edu>
> > > > > Date: Mon Oct 28 10:52:35 2019 -0400
> > > > >
> > > > > USB: Skip endpoints with 0 maxpacket length
> > > > >
> > > > > Endpoints with a maxpacket length of 0 are probably useless. They
> > > > > can't transfer any data, and it's not at all unlikely that an HCD will
> > > > > crash or hang when trying to handle an URB for such an endpoint.
> > > > >
> > > > > Currently the USB core does not check for endpoints having a maxpacket
> > > > > value of 0. This patch adds a check, printing a warning and skipping
> > > > > over any endpoints it catches.
> > > > >
> > > > > Now, the USB spec does not rule out endpoints having maxpacket = 0.
> > > > > But since they wouldn't have any practical use, there doesn't seem to
> > > > > be any good reason for us to accept them.
> > > > >
> > > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > > >
> > > > > Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > >
> > > > > The commit was merged in v5.4 and backported to v5.3.11 in
> > > > > 47aaab6377204cdbcd16f52a23c584f994fd0d15.
> > > > >
> > > > > For reference for Alan and linux-usb, the issue being discussed is
> > > > > described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> > > > > above commit seems to cause a regression with several cameras. I've
> > > > > attached to this e-mail the lsusb output provided by Roger.
> > > >
> > > > How can a device work with an endpoint of 0 length?
> > > >
> > > > What does the driver expect to do with those endpoints? Does it expect
> > > > it to be present but just ignore it?
> > >
> > > I see what's going on. The endpoint in question is isochronous, and
> > > the bAlternateSetting value is 0, which makes this the default
> > > altsetting for that interface. The USB spec says (at the end of
> > > section 5.6.3):
> > >
> > > All device default interface settings must not include any
> > > isochronous endpoints with non-zero data payload sizes
> > > (specified via wMaxPacketSize in the endpoint descriptor).
> > > Alternate interface settings may specify non-zero data payload
> > > sizes for isochronous endpoints.
> > >
> > > That explains why the maxpacket size is set to 0.
> > >
> > > So it looks like the endpoint-descriptor parsing code might want to
> > > make a special case to accept isochronous endpoints with maxpacket 0 if
> > > bAlternateSetting is 0. But whether we do this or not, I would expect
> > > the uvcvideo driver to look for isochronous endpoints in the alternate
> > > settings it will actually use, not in altsetting 0. Then the presence
> > > or absence of that endpoint descriptor would make no difference to
> > > uvcvideo.
> > >
> > > (Unless the UVC spec _requires_ these endpoint descriptors to be
> > > present. If it does then we should simply change the core parsing code
> > > and leave uvcvideo alone.)
> >
> > Note that we also have this little gem in the ftdi usb-serial driver
> > (since 2009) overriding a zero max packet size for devices with broken
> > descriptors:
> >
> > 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation")
> >
> > Note sure how common those are but they will no longer work after the
> > new sanity check in core. I guess we could add quirks for them (to core)
> > in case we get any reports, but perhaps reverting the check should be
> > considered.
>
> FWIW, Roger confirmed that reverting the commit d482c7bb0541 does
> indeed fix the issue (with the latest 5.4.y kernel).
All right. Suppose instead of reverting that commit, I change the code
so that it only logs a warning when it finds an endpoint descriptor
with maxpacket = 0 (and it skips the warning for isochronous endpoints
in altsetting 0). At the same time, we can add a check to
usb_submit_urb() to refuse URBs if the endpoint's maxpacket is 0.
Sounds good?
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 15:06 ` Alan Stern
@ 2020-01-02 15:32 ` Johan Hovold
2020-01-02 18:24 ` Alan Stern
2020-01-02 16:38 ` Laurent Pinchart
1 sibling, 1 reply; 23+ messages in thread
From: Johan Hovold @ 2020-01-02 15:32 UTC (permalink / raw)
To: Alan Stern
Cc: Takashi Iwai, Johan Hovold, Greg KH, Laurent Pinchart,
Roger Whittaker, Takashi Iwai, linux-usb
On Thu, Jan 02, 2020 at 10:06:33AM -0500, Alan Stern wrote:
> On Thu, 2 Jan 2020, Takashi Iwai wrote:
> > On Thu, 02 Jan 2020 12:20:45 +0100, Johan Hovold wrote:
> > > Note that we also have this little gem in the ftdi usb-serial driver
> > > (since 2009) overriding a zero max packet size for devices with broken
> > > descriptors:
> > >
> > > 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation")
> > >
> > > Note sure how common those are but they will no longer work after the
> > > new sanity check in core. I guess we could add quirks for them (to core)
> > > in case we get any reports, but perhaps reverting the check should be
> > > considered.
> >
> > FWIW, Roger confirmed that reverting the commit d482c7bb0541 does
> > indeed fix the issue (with the latest 5.4.y kernel).
>
> All right. Suppose instead of reverting that commit, I change the code
> so that it only logs a warning when it finds an endpoint descriptor
> with maxpacket = 0 (and it skips the warning for isochronous endpoints
> in altsetting 0). At the same time, we can add a check to
> usb_submit_urb() to refuse URBs if the endpoint's maxpacket is 0.
>
> Sounds good?
Sounds good to me.
Just make sure not to add a WARN() in usb_submit_urb() so that we end up
having to add maxpacket checks to every USB driver when syzbot starts
hitting this (only driver's doing maxpacket divisions or similar should
need that).
Johan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 15:06 ` Alan Stern
2020-01-02 15:32 ` Johan Hovold
@ 2020-01-02 16:38 ` Laurent Pinchart
2020-01-02 16:57 ` Roger Whittaker
1 sibling, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-02 16:38 UTC (permalink / raw)
To: Alan Stern
Cc: Takashi Iwai, Johan Hovold, Greg KH, Roger Whittaker,
Takashi Iwai, linux-usb
Hi Alan,
On Thu, Jan 02, 2020 at 10:06:33AM -0500, Alan Stern wrote:
> On Thu, 2 Jan 2020, Takashi Iwai wrote:
> > On Thu, 02 Jan 2020 12:20:45 +0100, Johan Hovold wrote:
> > > On Wed, Jan 01, 2020 at 03:09:35PM -0500, Alan Stern wrote:
> > > > On Wed, 1 Jan 2020, Greg KH wrote:
> > > > > On Wed, Jan 01, 2020 at 08:35:59PM +0200, Laurent Pinchart wrote:
> > >
> > > > > > [ 470.351700] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > > > > >
> > > > > > This seems to be the culprit, and it points to the USB core. One
> > > > > > interface is ignored due to its wMaxPacketSize value, and the uvcvideo
> > > > > > driver then fails to find it.
> > > > > >
> > > > > > The wMaxPacketSize check was added in
> > > > > >
> > > > > > commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2
> > > > > > Author: Alan Stern <stern@rowland.harvard.edu>
> > > > > > Date: Mon Oct 28 10:52:35 2019 -0400
> > > > > >
> > > > > > USB: Skip endpoints with 0 maxpacket length
> > > > > >
> > > > > > Endpoints with a maxpacket length of 0 are probably useless. They
> > > > > > can't transfer any data, and it's not at all unlikely that an HCD will
> > > > > > crash or hang when trying to handle an URB for such an endpoint.
> > > > > >
> > > > > > Currently the USB core does not check for endpoints having a maxpacket
> > > > > > value of 0. This patch adds a check, printing a warning and skipping
> > > > > > over any endpoints it catches.
> > > > > >
> > > > > > Now, the USB spec does not rule out endpoints having maxpacket = 0.
> > > > > > But since they wouldn't have any practical use, there doesn't seem to
> > > > > > be any good reason for us to accept them.
> > > > > >
> > > > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > > > >
> > > > > > Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.org
> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > >
> > > > > > The commit was merged in v5.4 and backported to v5.3.11 in
> > > > > > 47aaab6377204cdbcd16f52a23c584f994fd0d15.
> > > > > >
> > > > > > For reference for Alan and linux-usb, the issue being discussed is
> > > > > > described in https://bugzilla.suse.com/show_bug.cgi?id=1159811. The
> > > > > > above commit seems to cause a regression with several cameras. I've
> > > > > > attached to this e-mail the lsusb output provided by Roger.
> > > > >
> > > > > How can a device work with an endpoint of 0 length?
> > > > >
> > > > > What does the driver expect to do with those endpoints? Does it expect
> > > > > it to be present but just ignore it?
> > > >
> > > > I see what's going on. The endpoint in question is isochronous, and
> > > > the bAlternateSetting value is 0, which makes this the default
> > > > altsetting for that interface. The USB spec says (at the end of
> > > > section 5.6.3):
> > > >
> > > > All device default interface settings must not include any
> > > > isochronous endpoints with non-zero data payload sizes
> > > > (specified via wMaxPacketSize in the endpoint descriptor).
> > > > Alternate interface settings may specify non-zero data payload
> > > > sizes for isochronous endpoints.
> > > >
> > > > That explains why the maxpacket size is set to 0.
> > > >
> > > > So it looks like the endpoint-descriptor parsing code might want to
> > > > make a special case to accept isochronous endpoints with maxpacket 0 if
> > > > bAlternateSetting is 0. But whether we do this or not, I would expect
> > > > the uvcvideo driver to look for isochronous endpoints in the alternate
> > > > settings it will actually use, not in altsetting 0. Then the presence
> > > > or absence of that endpoint descriptor would make no difference to
> > > > uvcvideo.
> > > >
> > > > (Unless the UVC spec _requires_ these endpoint descriptors to be
> > > > present. If it does then we should simply change the core parsing code
> > > > and leave uvcvideo alone.)
> > >
> > > Note that we also have this little gem in the ftdi usb-serial driver
> > > (since 2009) overriding a zero max packet size for devices with broken
> > > descriptors:
> > >
> > > 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size calculation")
> > >
> > > Note sure how common those are but they will no longer work after the
> > > new sanity check in core. I guess we could add quirks for them (to core)
> > > in case we get any reports, but perhaps reverting the check should be
> > > considered.
> >
> > FWIW, Roger confirmed that reverting the commit d482c7bb0541 does
> > indeed fix the issue (with the latest 5.4.y kernel).
>
> All right. Suppose instead of reverting that commit, I change the code
> so that it only logs a warning when it finds an endpoint descriptor
> with maxpacket = 0 (and it skips the warning for isochronous endpoints
> in altsetting 0). At the same time, we can add a check to
> usb_submit_urb() to refuse URBs if the endpoint's maxpacket is 0.
>
> Sounds good?
It makes it easier for me as I won't have to adapt the uvcvideo driver,
so it certainly sounds good :-)
The USB specification allows different endpoint settings in different
alternate settings, and unless I'm mistaken, it includes a different
number of endpoints and different endpoint numbers. The UVC
specification isn't very clear on this topic, but in practice most
isochronous devices don't include any isochronous endpoint in altsetting
0. Only 5 devices in my database of ~400 has an isochronous endpoint in
altsetting 0, all of them with a wMaxPacketSize value set to 0. The
above commit, if it only ignored the endpoint, should thus be fine, as
the uvcvideo driver checks for endpoints in other alternate settings
(the related code is the loop at the end of uvc_parse_streaming() in
drivers/media/usb/uvc/uvc_driver.c). I thus wonder what's going wrong,
and if the commit couldn't cause the interface to be mistakenly ignored
as a whole ?
Roger, would you be able to set the uvcvideo trace module parameter to
0xffff before plugging the device, and provide the messages printed by
the driver to the kernel log both with and without the above commit ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 16:38 ` Laurent Pinchart
@ 2020-01-02 16:57 ` Roger Whittaker
2020-01-02 17:03 ` Laurent Pinchart
0 siblings, 1 reply; 23+ messages in thread
From: Roger Whittaker @ 2020-01-02 16:57 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alan Stern, Takashi Iwai, Johan Hovold, Greg KH, Takashi Iwai, linux-usb
On Thu, Jan 02, 2020 at 06:38:07PM +0200, Laurent Pinchart wrote:
> Roger, would you be able to set the uvcvideo trace module parameter to
> 0xffff before plugging the device, and provide the messages printed by
> the driver to the kernel log both with and without the above commit ?
With 5.3.12-2-default, loading uvcvideo with
options uvcvideo trace=0xffff
On plugging:
[ 73.571566] usb 1-1.4.3.1: new high-speed USB device number 12 using xhci_hcd
[ 73.729180] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
[ 73.729552] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
[ 73.729558] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 73.729561] usb 1-1.4.3.1: Product: IPEVO Point 2 View
[ 73.729564] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
[ 73.732670] hid-generic 0003:1778:0214.0009: hiddev98,hidraw8: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
[ 73.781765] videodev: Linux video capture interface: v2.00
[ 73.807553] uvcvideo: Probing generic UVC device 1.4.3.1
[ 73.807693] uvcvideo: no class-specific streaming interface descriptors found.
[ 73.807728] uvcvideo: Found a Status endpoint (addr 81).
[ 73.807730] uvcvideo: Found UVC 1.00 device IPEVO Point 2 View (1778:0214)
[ 73.807759] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -32 (exp. 1).
[ 73.807832] uvcvideo: Control error 6
[ 73.807834] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/2 to device 1.4.3.1 entity 1
[ 73.807835] uvcvideo: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2.
[ 73.807876] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/6 to device 1.4.3.1 entity 1
[ 73.807877] uvcvideo: Adding mapping 'Focus (absolute)' to control 00000000-0000-0000-0000-000000000001/6.
[ 73.807918] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 1: -32 (exp. 1).
[ 73.807996] uvcvideo: Control error 6
[ 73.807997] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/9 to device 1.4.3.1 entity 1
[ 73.807998] uvcvideo: Adding mapping 'Iris, Absolute' to control 00000000-0000-0000-0000-000000000001/9.
[ 73.808037] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/8 to device 1.4.3.1 entity 1
[ 73.808038] uvcvideo: Adding mapping 'Focus, Auto' to control 00000000-0000-0000-0000-000000000001/8.
[ 73.808079] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/2 to device 1.4.3.1 entity 3
[ 73.808080] uvcvideo: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2.
[ 73.808119] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/3 to device 1.4.3.1 entity 3
[ 73.808120] uvcvideo: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3.
[ 73.808159] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/6 to device 1.4.3.1 entity 3
[ 73.808160] uvcvideo: Adding mapping 'Hue' to control 00000000-0000-0000-0000-000000000101/6.
[ 73.808205] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/7 to device 1.4.3.1 entity 3
[ 73.808206] uvcvideo: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7.
[ 73.808255] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/8 to device 1.4.3.1 entity 3
[ 73.808257] uvcvideo: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8.
[ 73.808308] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/9 to device 1.4.3.1 entity 3
[ 73.808309] uvcvideo: Adding mapping 'Gamma' to control 00000000-0000-0000-0000-000000000101/9.
[ 73.808349] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/10 to device 1.4.3.1 entity 3
[ 73.808350] uvcvideo: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10.
[ 73.808389] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/5 to device 1.4.3.1 entity 3
[ 73.808390] uvcvideo: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5.
[ 73.808431] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/11 to device 1.4.3.1 entity 3
[ 73.808432] uvcvideo: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11.
[ 73.808434] uvcvideo: Scanning UVC chain: OT 2 <- XU 4 <- PU 3 <- IT 1
[ 73.808437] uvcvideo: Found a valid video chain (1 -> 2).
[ 73.808438] uvcvideo: No streaming interface found for terminal 2.
[ 73.808442] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Extension 4 was not initialized!
[ 73.808444] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Processing 3 was not initialized!
[ 73.808446] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Camera 1 was not initialized!
[ 73.808542] input: IPEVO Point 2 View: IPEVO Point as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3.1/1-1.4.3.1:1.1/input/input21
[ 73.808590] uvcvideo: UVC device initialized.
[ 73.808636] usbcore: registered new interface driver uvcvideo
[ 73.808637] USB Video Class driver (1.1.1)
[ 75.899721] uvcvideo: Suspending interface 1
------------------------------------------------------------------------
With 5.4.7-1.g43720a7-default (the kernel Takashi built with commit
d482c7bb0541 reverted), loading uvcvideo with
options uvcvideo trace=0xffff
On plugging:
[ 267.765563] usb 1-1.4.3.1: new high-speed USB device number 13 using xhci_hcd
[ 267.879567] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
[ 267.879573] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 267.879577] usb 1-1.4.3.1: Product: IPEVO Point 2 View
[ 267.879580] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
[ 267.882718] hid-generic 0003:1778:0214.000A: hiddev98,hidraw7: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
[ 267.883135] uvcvideo: Probing generic UVC device 1.4.3.1
[ 267.883260] uvcvideo: trying extra data from endpoint 0.
[ 267.883265] uvcvideo: Found format YUV 4:2:2 (YUYV).
[ 267.883268] uvcvideo: - 640x480 (30.0 fps)
[ 267.883277] uvcvideo: - 320x240 (30.0 fps)
[ 267.883278] uvcvideo: - 800x600 (24.0 fps)
[ 267.883280] uvcvideo: - 1024x768 (15.0 fps)
[ 267.883282] uvcvideo: - 1280x1024 (8.0 fps)
[ 267.883284] uvcvideo: - 1600x1200 (4.0 fps)
[ 267.883286] uvcvideo: - 640x480 (30.0 fps)
[ 267.883288] uvcvideo: Found format MJPEG.
[ 267.883290] uvcvideo: - 640x480 (45.0 fps)
[ 267.883292] uvcvideo: - 320x240 (45.0 fps)
[ 267.883293] uvcvideo: - 800x600 (45.0 fps)
[ 267.883295] uvcvideo: - 1024x768 (30.0 fps)
[ 267.883297] uvcvideo: - 1280x1024 (15.0 fps)
[ 267.883299] uvcvideo: - 1600x1200 (8.0 fps)
[ 267.883301] uvcvideo: - 640x480 (45.0 fps)
[ 267.883310] uvcvideo: Found a Status endpoint (addr 81).
[ 267.883314] uvcvideo: Found UVC 1.00 device IPEVO Point 2 View (1778:0214)
[ 267.883380] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -32 (exp. 1).
[ 267.883411] uvcvideo: Control error 6
[ 267.883416] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/2 to device 1.4.3.1 entity 1
[ 267.883419] uvcvideo: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2.
[ 267.883468] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/6 to device 1.4.3.1 entity 1
[ 267.883471] uvcvideo: Adding mapping 'Focus (absolute)' to control 00000000-0000-0000-0000-000000000001/6.
[ 267.883512] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 1: -32 (exp. 1).
[ 267.883588] uvcvideo: Control error 6
[ 267.883590] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/9 to device 1.4.3.1 entity 1
[ 267.883593] uvcvideo: Adding mapping 'Iris, Absolute' to control 00000000-0000-0000-0000-000000000001/9.
[ 267.883642] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/8 to device 1.4.3.1 entity 1
[ 267.883645] uvcvideo: Adding mapping 'Focus, Auto' to control 00000000-0000-0000-0000-000000000001/8.
[ 267.883694] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/2 to device 1.4.3.1 entity 3
[ 267.883696] uvcvideo: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2.
[ 267.883745] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/3 to device 1.4.3.1 entity 3
[ 267.883747] uvcvideo: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3.
[ 267.883795] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/6 to device 1.4.3.1 entity 3
[ 267.883797] uvcvideo: Adding mapping 'Hue' to control 00000000-0000-0000-0000-000000000101/6.
[ 267.883846] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/7 to device 1.4.3.1 entity 3
[ 267.883848] uvcvideo: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7.
[ 267.883895] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/8 to device 1.4.3.1 entity 3
[ 267.883898] uvcvideo: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8.
[ 267.883947] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/9 to device 1.4.3.1 entity 3
[ 267.883949] uvcvideo: Adding mapping 'Gamma' to control 00000000-0000-0000-0000-000000000101/9.
[ 267.883999] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/10 to device 1.4.3.1 entity 3
[ 267.884002] uvcvideo: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10.
[ 267.884050] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/5 to device 1.4.3.1 entity 3
[ 267.884053] uvcvideo: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5.
[ 267.884101] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/11 to device 1.4.3.1 entity 3
[ 267.884104] uvcvideo: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11.
[ 267.884108] uvcvideo: Scanning UVC chain: OT 2 <- XU 4 <- PU 3 <- IT 1
[ 267.884117] uvcvideo: Found a valid video chain (1 -> 2).
[ 267.885020] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Extension 4 was not initialized!
[ 267.885025] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Processing 3 was not initialized!
[ 267.885028] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Camera 1 was not initialized!
[ 267.885188] input: IPEVO Point 2 View: IPEVO Point as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3.1/1-1.4.3.1:1.1/input/input22
[ 267.885266] uvcvideo: UVC device initialized.
[ 267.919845] uvcvideo: uvc_v4l2_open
[ 267.919884] uvcvideo: uvc_v4l2_release
[ 270.387236] uvcvideo: Suspending interface 2
[ 270.387241] uvcvideo: Suspending interface 1
--
============================================
Roger Whittaker
SUSE Linux Premium Support Engineer
roger.whittaker@suse.com
+44 7802 357081
SUSE Linux
One Station Square
Bracknell
RG12 1QB
United Kingdom
============================================
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 16:57 ` Roger Whittaker
@ 2020-01-02 17:03 ` Laurent Pinchart
2020-01-02 17:49 ` Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-02 17:03 UTC (permalink / raw)
To: Roger Whittaker
Cc: Alan Stern, Takashi Iwai, Johan Hovold, Greg KH, Takashi Iwai, linux-usb
Hi Roger,
On Thu, Jan 02, 2020 at 04:57:42PM +0000, Roger Whittaker wrote:
> On Thu, Jan 02, 2020 at 06:38:07PM +0200, Laurent Pinchart wrote:
>
> > Roger, would you be able to set the uvcvideo trace module parameter to
> > 0xffff before plugging the device, and provide the messages printed by
> > the driver to the kernel log both with and without the above commit ?
>
> With 5.3.12-2-default, loading uvcvideo with
>
> options uvcvideo trace=0xffff
Thank you.
> On plugging:
>
> [ 73.571566] usb 1-1.4.3.1: new high-speed USB device number 12 using xhci_hcd
> [ 73.729180] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> [ 73.729552] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
> [ 73.729558] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 73.729561] usb 1-1.4.3.1: Product: IPEVO Point 2 View
> [ 73.729564] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
> [ 73.732670] hid-generic 0003:1778:0214.0009: hiddev98,hidraw8: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
> [ 73.781765] videodev: Linux video capture interface: v2.00
> [ 73.807553] uvcvideo: Probing generic UVC device 1.4.3.1
> [ 73.807693] uvcvideo: no class-specific streaming interface descriptors found.
It seems that Alan's patch causes more than the endpoint to be ignored.
> [ 73.807728] uvcvideo: Found a Status endpoint (addr 81).
> [ 73.807730] uvcvideo: Found UVC 1.00 device IPEVO Point 2 View (1778:0214)
> [ 73.807759] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -32 (exp. 1).
> [ 73.807832] uvcvideo: Control error 6
> [ 73.807834] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/2 to device 1.4.3.1 entity 1
> [ 73.807835] uvcvideo: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2.
> [ 73.807876] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/6 to device 1.4.3.1 entity 1
> [ 73.807877] uvcvideo: Adding mapping 'Focus (absolute)' to control 00000000-0000-0000-0000-000000000001/6.
> [ 73.807918] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 1: -32 (exp. 1).
> [ 73.807996] uvcvideo: Control error 6
> [ 73.807997] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/9 to device 1.4.3.1 entity 1
> [ 73.807998] uvcvideo: Adding mapping 'Iris, Absolute' to control 00000000-0000-0000-0000-000000000001/9.
> [ 73.808037] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/8 to device 1.4.3.1 entity 1
> [ 73.808038] uvcvideo: Adding mapping 'Focus, Auto' to control 00000000-0000-0000-0000-000000000001/8.
> [ 73.808079] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/2 to device 1.4.3.1 entity 3
> [ 73.808080] uvcvideo: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2.
> [ 73.808119] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/3 to device 1.4.3.1 entity 3
> [ 73.808120] uvcvideo: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3.
> [ 73.808159] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/6 to device 1.4.3.1 entity 3
> [ 73.808160] uvcvideo: Adding mapping 'Hue' to control 00000000-0000-0000-0000-000000000101/6.
> [ 73.808205] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/7 to device 1.4.3.1 entity 3
> [ 73.808206] uvcvideo: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7.
> [ 73.808255] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/8 to device 1.4.3.1 entity 3
> [ 73.808257] uvcvideo: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8.
> [ 73.808308] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/9 to device 1.4.3.1 entity 3
> [ 73.808309] uvcvideo: Adding mapping 'Gamma' to control 00000000-0000-0000-0000-000000000101/9.
> [ 73.808349] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/10 to device 1.4.3.1 entity 3
> [ 73.808350] uvcvideo: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10.
> [ 73.808389] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/5 to device 1.4.3.1 entity 3
> [ 73.808390] uvcvideo: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5.
> [ 73.808431] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/11 to device 1.4.3.1 entity 3
> [ 73.808432] uvcvideo: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11.
> [ 73.808434] uvcvideo: Scanning UVC chain: OT 2 <- XU 4 <- PU 3 <- IT 1
> [ 73.808437] uvcvideo: Found a valid video chain (1 -> 2).
> [ 73.808438] uvcvideo: No streaming interface found for terminal 2.
> [ 73.808442] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Extension 4 was not initialized!
> [ 73.808444] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Processing 3 was not initialized!
> [ 73.808446] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Camera 1 was not initialized!
> [ 73.808542] input: IPEVO Point 2 View: IPEVO Point as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3.1/1-1.4.3.1:1.1/input/input21
> [ 73.808590] uvcvideo: UVC device initialized.
> [ 73.808636] usbcore: registered new interface driver uvcvideo
> [ 73.808637] USB Video Class driver (1.1.1)
> [ 75.899721] uvcvideo: Suspending interface 1
>
>
> ------------------------------------------------------------------------
>
> With 5.4.7-1.g43720a7-default (the kernel Takashi built with commit
> d482c7bb0541 reverted), loading uvcvideo with
>
> options uvcvideo trace=0xffff
>
> On plugging:
>
> [ 267.765563] usb 1-1.4.3.1: new high-speed USB device number 13 using xhci_hcd
> [ 267.879567] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
> [ 267.879573] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 267.879577] usb 1-1.4.3.1: Product: IPEVO Point 2 View
> [ 267.879580] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
> [ 267.882718] hid-generic 0003:1778:0214.000A: hiddev98,hidraw7: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
> [ 267.883135] uvcvideo: Probing generic UVC device 1.4.3.1
> [ 267.883260] uvcvideo: trying extra data from endpoint 0.
> [ 267.883265] uvcvideo: Found format YUV 4:2:2 (YUYV).
> [ 267.883268] uvcvideo: - 640x480 (30.0 fps)
> [ 267.883277] uvcvideo: - 320x240 (30.0 fps)
> [ 267.883278] uvcvideo: - 800x600 (24.0 fps)
> [ 267.883280] uvcvideo: - 1024x768 (15.0 fps)
> [ 267.883282] uvcvideo: - 1280x1024 (8.0 fps)
> [ 267.883284] uvcvideo: - 1600x1200 (4.0 fps)
> [ 267.883286] uvcvideo: - 640x480 (30.0 fps)
> [ 267.883288] uvcvideo: Found format MJPEG.
> [ 267.883290] uvcvideo: - 640x480 (45.0 fps)
> [ 267.883292] uvcvideo: - 320x240 (45.0 fps)
> [ 267.883293] uvcvideo: - 800x600 (45.0 fps)
> [ 267.883295] uvcvideo: - 1024x768 (30.0 fps)
> [ 267.883297] uvcvideo: - 1280x1024 (15.0 fps)
> [ 267.883299] uvcvideo: - 1600x1200 (8.0 fps)
> [ 267.883301] uvcvideo: - 640x480 (45.0 fps)
> [ 267.883310] uvcvideo: Found a Status endpoint (addr 81).
> [ 267.883314] uvcvideo: Found UVC 1.00 device IPEVO Point 2 View (1778:0214)
> [ 267.883380] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -32 (exp. 1).
> [ 267.883411] uvcvideo: Control error 6
> [ 267.883416] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/2 to device 1.4.3.1 entity 1
> [ 267.883419] uvcvideo: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2.
> [ 267.883468] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/6 to device 1.4.3.1 entity 1
> [ 267.883471] uvcvideo: Adding mapping 'Focus (absolute)' to control 00000000-0000-0000-0000-000000000001/6.
> [ 267.883512] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 1: -32 (exp. 1).
> [ 267.883588] uvcvideo: Control error 6
> [ 267.883590] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/9 to device 1.4.3.1 entity 1
> [ 267.883593] uvcvideo: Adding mapping 'Iris, Absolute' to control 00000000-0000-0000-0000-000000000001/9.
> [ 267.883642] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/8 to device 1.4.3.1 entity 1
> [ 267.883645] uvcvideo: Adding mapping 'Focus, Auto' to control 00000000-0000-0000-0000-000000000001/8.
> [ 267.883694] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/2 to device 1.4.3.1 entity 3
> [ 267.883696] uvcvideo: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2.
> [ 267.883745] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/3 to device 1.4.3.1 entity 3
> [ 267.883747] uvcvideo: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3.
> [ 267.883795] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/6 to device 1.4.3.1 entity 3
> [ 267.883797] uvcvideo: Adding mapping 'Hue' to control 00000000-0000-0000-0000-000000000101/6.
> [ 267.883846] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/7 to device 1.4.3.1 entity 3
> [ 267.883848] uvcvideo: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7.
> [ 267.883895] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/8 to device 1.4.3.1 entity 3
> [ 267.883898] uvcvideo: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8.
> [ 267.883947] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/9 to device 1.4.3.1 entity 3
> [ 267.883949] uvcvideo: Adding mapping 'Gamma' to control 00000000-0000-0000-0000-000000000101/9.
> [ 267.883999] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/10 to device 1.4.3.1 entity 3
> [ 267.884002] uvcvideo: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10.
> [ 267.884050] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/5 to device 1.4.3.1 entity 3
> [ 267.884053] uvcvideo: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5.
> [ 267.884101] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/11 to device 1.4.3.1 entity 3
> [ 267.884104] uvcvideo: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11.
> [ 267.884108] uvcvideo: Scanning UVC chain: OT 2 <- XU 4 <- PU 3 <- IT 1
> [ 267.884117] uvcvideo: Found a valid video chain (1 -> 2).
> [ 267.885020] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Extension 4 was not initialized!
> [ 267.885025] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Processing 3 was not initialized!
> [ 267.885028] uvcvideo 1-1.4.3.1:1.1: Entity type for entity Camera 1 was not initialized!
> [ 267.885188] input: IPEVO Point 2 View: IPEVO Point as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3.1/1-1.4.3.1:1.1/input/input22
> [ 267.885266] uvcvideo: UVC device initialized.
> [ 267.919845] uvcvideo: uvc_v4l2_open
> [ 267.919884] uvcvideo: uvc_v4l2_release
> [ 270.387236] uvcvideo: Suspending interface 2
> [ 270.387241] uvcvideo: Suspending interface 1
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 17:03 ` Laurent Pinchart
@ 2020-01-02 17:49 ` Alan Stern
2020-01-02 21:51 ` Roger Whittaker
2020-01-02 23:11 ` Laurent Pinchart
0 siblings, 2 replies; 23+ messages in thread
From: Alan Stern @ 2020-01-02 17:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Roger Whittaker, Takashi Iwai, Johan Hovold, Greg KH,
Takashi Iwai, linux-usb
On Thu, 2 Jan 2020, Laurent Pinchart wrote:
> Hi Roger,
>
> On Thu, Jan 02, 2020 at 04:57:42PM +0000, Roger Whittaker wrote:
> > On Thu, Jan 02, 2020 at 06:38:07PM +0200, Laurent Pinchart wrote:
> >
> > > Roger, would you be able to set the uvcvideo trace module parameter to
> > > 0xffff before plugging the device, and provide the messages printed by
> > > the driver to the kernel log both with and without the above commit ?
> >
> > With 5.3.12-2-default, loading uvcvideo with
> >
> > options uvcvideo trace=0xffff
>
> Thank you.
>
> > On plugging:
> >
> > [ 73.571566] usb 1-1.4.3.1: new high-speed USB device number 12 using xhci_hcd
> > [ 73.729180] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > [ 73.729552] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
> > [ 73.729558] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > [ 73.729561] usb 1-1.4.3.1: Product: IPEVO Point 2 View
> > [ 73.729564] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
> > [ 73.732670] hid-generic 0003:1778:0214.0009: hiddev98,hidraw8: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
> > [ 73.781765] videodev: Linux video capture interface: v2.00
> > [ 73.807553] uvcvideo: Probing generic UVC device 1.4.3.1
> > [ 73.807693] uvcvideo: no class-specific streaming interface descriptors found.
>
> It seems that Alan's patch causes more than the endpoint to be ignored.
Roger, you can get more information by plugging in the device and then
posting the contents of /sys/kernel/debug/usb/devices (or just the
portion that refers to the camera). It would be interesting to compare
the values from the kernel with the commit present and the kernel with
the commit reverted.
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 15:32 ` Johan Hovold
@ 2020-01-02 18:24 ` Alan Stern
0 siblings, 0 replies; 23+ messages in thread
From: Alan Stern @ 2020-01-02 18:24 UTC (permalink / raw)
To: Johan Hovold
Cc: Takashi Iwai, Greg KH, Laurent Pinchart, Roger Whittaker,
Takashi Iwai, linux-usb
On Thu, 2 Jan 2020, Johan Hovold wrote:
> > > FWIW, Roger confirmed that reverting the commit d482c7bb0541 does
> > > indeed fix the issue (with the latest 5.4.y kernel).
> >
> > All right. Suppose instead of reverting that commit, I change the code
> > so that it only logs a warning when it finds an endpoint descriptor
> > with maxpacket = 0 (and it skips the warning for isochronous endpoints
> > in altsetting 0). At the same time, we can add a check to
> > usb_submit_urb() to refuse URBs if the endpoint's maxpacket is 0.
> >
> > Sounds good?
>
> Sounds good to me.
>
> Just make sure not to add a WARN() in usb_submit_urb() so that we end up
> having to add maxpacket checks to every USB driver when syzbot starts
> hitting this (only driver's doing maxpacket divisions or similar should
> need that).
Heh. Yes, syzbot interprets WARN() very differently from dev_warn().
Okay, here's a patch for testing. This is meant to go on top of the
existing commit; instead of rejecting bogus endpoints entirely it just
issues a warning.
And it turns out that usb_submit_urb() already checks for maxpacket =
0, so no changes are needed there.
Alan Stern
Index: usb-devel/drivers/usb/core/config.c
===================================================================
--- usb-devel.orig/drivers/usb/core/config.c
+++ usb-devel/drivers/usb/core/config.c
@@ -346,12 +346,16 @@ static int usb_parse_endpoint(struct dev
endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
}
- /* Validate the wMaxPacketSize field */
+ /*
+ * Validate the wMaxPacketSize field.
+ * Some devices have isochronous endpoints in altsetting 0;
+ * the USB-2 spec requires such endpoints to have wMaxPacketSize = 0
+ * (see the end of section 5.6.3), so don't warn about them.
+ */
maxp = usb_endpoint_maxp(&endpoint->desc);
- if (maxp == 0) {
- dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has wMaxPacketSize 0, skipping\n",
+ if (maxp == 0 && !(usb_endpoint_xfer_isoc(d) && asnum == 0)) {
+ dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid wMaxPacketSize 0\n",
cfgno, inum, asnum, d->bEndpointAddress);
- goto skip_to_next_endpoint_or_interface_descriptor;
}
/* Find the highest legal maxpacket size for this endpoint */
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 17:49 ` Alan Stern
@ 2020-01-02 21:51 ` Roger Whittaker
2020-01-02 23:11 ` Laurent Pinchart
1 sibling, 0 replies; 23+ messages in thread
From: Roger Whittaker @ 2020-01-02 21:51 UTC (permalink / raw)
To: Alan Stern
Cc: Laurent Pinchart, Takashi Iwai, Johan Hovold, Greg KH,
Takashi Iwai, linux-usb
On Thu, Jan 02, 2020 at 12:49:00PM -0500, Alan Stern wrote:
> Roger, you can get more information by plugging in the device and
> then posting the contents of /sys/kernel/debug/usb/devices (or just
> the portion that refers to the camera). It would be interesting to
> compare the values from the kernel with the commit present and the
> kernel with the commit reverted.
5.3.12-2-default (commit present)
T: Bus=01 Lev=04 Prnt=08 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1778 ProdID=0214 Rev= 7.07
S: Manufacturer=IPEVO Inc.
S: Product=IPEVO Point 2 View
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
A: FirstIf#= 1 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=64ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=(none)
E: Ad=82(I) Atr=05(Isoc) MxPS= 0 Ivl=125us
I: If#= 2 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=(none)
E: Ad=82(I) Atr=05(Isoc) MxPS=3060 Ivl=125us
----------------
5.4.7-1.g43720a7-default (commit reverted)
T: Bus=01 Lev=04 Prnt=08 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1778 ProdID=0214 Rev= 7.07
S: Manufacturer=IPEVO Inc.
S: Product=IPEVO Point 2 View
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
A: FirstIf#= 1 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=64ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS= 0 Ivl=125us
I: If#= 2 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS=3060 Ivl=125us
--
============================================
Roger Whittaker
SUSE Linux Premium Support Engineer
roger.whittaker@suse.com
+44 7802 357081
SUSE Linux
One Station Square
Bracknell
RG12 1QB
United Kingdom
============================================
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 17:49 ` Alan Stern
2020-01-02 21:51 ` Roger Whittaker
@ 2020-01-02 23:11 ` Laurent Pinchart
2020-01-03 15:13 ` Alan Stern
1 sibling, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-02 23:11 UTC (permalink / raw)
To: Alan Stern
Cc: Roger Whittaker, Takashi Iwai, Johan Hovold, Greg KH,
Takashi Iwai, linux-usb
Hi Alan,
On Thu, Jan 02, 2020 at 12:49:00PM -0500, Alan Stern wrote:
> On Thu, 2 Jan 2020, Laurent Pinchart wrote:
> > On Thu, Jan 02, 2020 at 04:57:42PM +0000, Roger Whittaker wrote:
> > > On Thu, Jan 02, 2020 at 06:38:07PM +0200, Laurent Pinchart wrote:
> > >
> > > > Roger, would you be able to set the uvcvideo trace module parameter to
> > > > 0xffff before plugging the device, and provide the messages printed by
> > > > the driver to the kernel log both with and without the above commit ?
> > >
> > > With 5.3.12-2-default, loading uvcvideo with
> > >
> > > options uvcvideo trace=0xffff
> >
> > Thank you.
> >
> > > On plugging:
> > >
> > > [ 73.571566] usb 1-1.4.3.1: new high-speed USB device number 12 using xhci_hcd
> > > [ 73.729180] usb 1-1.4.3.1: config 1 interface 2 altsetting 0 endpoint 0x82 has wMaxPacketSize 0, skipping
> > > [ 73.729552] usb 1-1.4.3.1: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
> > > [ 73.729558] usb 1-1.4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > > [ 73.729561] usb 1-1.4.3.1: Product: IPEVO Point 2 View
> > > [ 73.729564] usb 1-1.4.3.1: Manufacturer: IPEVO Inc.
> > > [ 73.732670] hid-generic 0003:1778:0214.0009: hiddev98,hidraw8: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.1/input0
> > > [ 73.781765] videodev: Linux video capture interface: v2.00
> > > [ 73.807553] uvcvideo: Probing generic UVC device 1.4.3.1
> > > [ 73.807693] uvcvideo: no class-specific streaming interface descriptors found.
> >
> > It seems that Alan's patch causes more than the endpoint to be ignored.
>
> Roger, you can get more information by plugging in the device and then
> posting the contents of /sys/kernel/debug/usb/devices (or just the
> portion that refers to the camera). It would be interesting to compare
> the values from the kernel with the commit present and the kernel with
> the commit reverted.
I've investigated this a bit further.
UVC defines class-specific interface descriptors that are usually
located right after the standard interface descriptor in altsetting 0.
The uvcvideo driver accesses those descriptor through
intf->altsetting[0].extra. However, some devices insert an isochronous
endpoint descriptor with wMaxPAcketSize set to 0 between the standard
interface descriptor and the UVC class-specific interface descriptors.
Before your patch, these descriptors were recorded in the extra field of
the endpoint, as they're located right after it:
static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
int asnum, struct usb_host_interface *ifp, int num_ep,
unsigned char *buffer, int size)
{
...
/* Skip over any Class Specific or Vendor Specific descriptors;
* find the next endpoint or interface descriptor */
endpoint->extra = buffer;
i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,
USB_DT_INTERFACE, &n);
endpoint->extralen = i;
...
}
The uvcvideo driver looks at endpoint->extra when altsetting[0] has no
extra data.
With your patch, the endpoint is skipped, and the class-specific
interface descriptors are dropped with it. The uvcvideo driver can't
access them and fails.
One solution may be to add to altsetting[0].extra all the extra
class-specific descriptors, regardless of whether they're located before
or after endpoints. I however fear we may not always be able to identify
those descriptors properly, especially with the CS_INTERFACE descriptor
type being defined in class specifications, not in the USB core
specification. There's also a risk of breaking working devices if we do
so (the uvcvideo driver should be able to cope, but other drivers may
always look for descriptors in the endpoint).
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-02 23:11 ` Laurent Pinchart
@ 2020-01-03 15:13 ` Alan Stern
2020-01-04 18:22 ` Laurent Pinchart
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2020-01-03 15:13 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Roger Whittaker, Takashi Iwai, Johan Hovold, Greg KH,
Takashi Iwai, linux-usb
On Fri, 3 Jan 2020, Laurent Pinchart wrote:
> I've investigated this a bit further.
>
> UVC defines class-specific interface descriptors that are usually
> located right after the standard interface descriptor in altsetting 0.
> The uvcvideo driver accesses those descriptor through
> intf->altsetting[0].extra. However, some devices insert an isochronous
> endpoint descriptor with wMaxPAcketSize set to 0 between the standard
> interface descriptor and the UVC class-specific interface descriptors.
>
> Before your patch, these descriptors were recorded in the extra field of
> the endpoint, as they're located right after it:
>
> static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
> int asnum, struct usb_host_interface *ifp, int num_ep,
> unsigned char *buffer, int size)
> {
> ...
> /* Skip over any Class Specific or Vendor Specific descriptors;
> * find the next endpoint or interface descriptor */
> endpoint->extra = buffer;
> i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,
> USB_DT_INTERFACE, &n);
> endpoint->extralen = i;
> ...
> }
>
> The uvcvideo driver looks at endpoint->extra when altsetting[0] has no
> extra data.
>
> With your patch, the endpoint is skipped, and the class-specific
> interface descriptors are dropped with it. The uvcvideo driver can't
> access them and fails.
Ah, a very tricky and unexpected interaction!
> One solution may be to add to altsetting[0].extra all the extra
> class-specific descriptors, regardless of whether they're located before
> or after endpoints. I however fear we may not always be able to identify
> those descriptors properly, especially with the CS_INTERFACE descriptor
> type being defined in class specifications, not in the USB core
> specification. There's also a risk of breaking working devices if we do
> so (the uvcvideo driver should be able to cope, but other drivers may
> always look for descriptors in the endpoint).
With the patch I posted yesterday, everything should go back to working
the way it used to. Have you had a chance to test it?
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-03 15:13 ` Alan Stern
@ 2020-01-04 18:22 ` Laurent Pinchart
2020-01-05 12:28 ` Roger Whittaker
0 siblings, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-04 18:22 UTC (permalink / raw)
To: Alan Stern
Cc: Roger Whittaker, Takashi Iwai, Johan Hovold, Greg KH,
Takashi Iwai, linux-usb
Hi Alan,
On Fri, Jan 03, 2020 at 10:13:29AM -0500, Alan Stern wrote:
> On Fri, 3 Jan 2020, Laurent Pinchart wrote:
>
> > I've investigated this a bit further.
> >
> > UVC defines class-specific interface descriptors that are usually
> > located right after the standard interface descriptor in altsetting 0.
> > The uvcvideo driver accesses those descriptor through
> > intf->altsetting[0].extra. However, some devices insert an isochronous
> > endpoint descriptor with wMaxPAcketSize set to 0 between the standard
> > interface descriptor and the UVC class-specific interface descriptors.
> >
> > Before your patch, these descriptors were recorded in the extra field of
> > the endpoint, as they're located right after it:
> >
> > static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
> > int asnum, struct usb_host_interface *ifp, int num_ep,
> > unsigned char *buffer, int size)
> > {
> > ...
> > /* Skip over any Class Specific or Vendor Specific descriptors;
> > * find the next endpoint or interface descriptor */
> > endpoint->extra = buffer;
> > i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,
> > USB_DT_INTERFACE, &n);
> > endpoint->extralen = i;
> > ...
> > }
> >
> > The uvcvideo driver looks at endpoint->extra when altsetting[0] has no
> > extra data.
> >
> > With your patch, the endpoint is skipped, and the class-specific
> > interface descriptors are dropped with it. The uvcvideo driver can't
> > access them and fails.
>
> Ah, a very tricky and unexpected interaction!
>
> > One solution may be to add to altsetting[0].extra all the extra
> > class-specific descriptors, regardless of whether they're located before
> > or after endpoints. I however fear we may not always be able to identify
> > those descriptors properly, especially with the CS_INTERFACE descriptor
> > type being defined in class specifications, not in the USB core
> > specification. There's also a risk of breaking working devices if we do
> > so (the uvcvideo driver should be able to cope, but other drivers may
> > always look for descriptors in the endpoint).
>
> With the patch I posted yesterday, everything should go back to working
> the way it used to. Have you had a chance to test it?
I don't have any camera affected by this issue, so I can't test it I'm
afraid. Roger, would you be able to give it a try ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels
2020-01-04 18:22 ` Laurent Pinchart
@ 2020-01-05 12:28 ` Roger Whittaker
2020-01-06 15:43 ` [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0 Alan Stern
0 siblings, 1 reply; 23+ messages in thread
From: Roger Whittaker @ 2020-01-05 12:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Alan Stern, Takashi Iwai, Johan Hovold, Greg KH, Takashi Iwai, linux-usb
On Sat, Jan 04, 2020 at 08:22:05PM +0200, Laurent Pinchart wrote:
> [...]
> > With the patch I posted yesterday, everything should go back to working
> > the way it used to. Have you had a chance to test it?
>
> I don't have any camera affected by this issue, so I can't test it I'm
> afraid. Roger, would you be able to give it a try ?
With 5.4.7-1.g8211231-default that Takashi built with the patch
mentioned
(http://download.opensuse.org/repositories/home:/tiwai:/bsc1159811-fix2/standard/x86_64/)
output of lsusb -v -d 1778:0214
Bus 001 Device 013: ID 1778:0214
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1778
idProduct 0x0214
bcdDevice 7.07
iManufacturer 1 IPEVO Inc.
iProduct 2 IPEVO Point 2 View
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0299
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 64
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 IPEVO Point 2 View
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 IPEVO Point 2 View
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x0050
dwClockFrequency 6.000000MHz
bInCollection 1
baInterfaceNr( 0) 2
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x000200a2
Auto-Exposure Mode
Focus (Absolute)
Iris (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000147f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1d
None
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 29
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {5a215226-3289-4156-894a-5c557cdf9664}
bNumControl 4
bNrPins 1
baSourceID( 0) 3
bControlSize 4
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0xff
bmControls( 3) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
INTERFACE CLASS: 0f 24 01 02 ea 01 82 00 02 02 01 00 01 00 00
INTERFACE CLASS: 1b 24 04 01 07 59 55 59 32 00 00 10 00 80 00 00 aa 00 38 9b 71 10 01 00 00 00 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 02 00 40 01 f0 00 c0 00 03 4b c0 00 03 4b 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 03 00 20 03 58 02 70 00 14 99 70 00 14 99 00 a6 0e 00 9a 5b 06 00 01 9a 5b 06 00
INTERFACE CLASS: 1e 24 05 04 00 00 04 00 03 00 00 16 80 00 00 16 80 00 00 18 00 2a 2c 0a 00 01 2a 2c 0a 00
INTERFACE CLASS: 1e 24 05 05 00 00 05 00 04 00 00 12 c0 00 00 12 c0 00 00 28 00 d0 12 13 00 01 d0 12 13 00
INTERFACE CLASS: 1e 24 05 06 00 40 06 b0 04 00 00 0e a6 00 00 0e a6 00 98 3a 00 a0 25 26 00 01 a0 25 26 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 0b 24 03 00 01 80 02 e0 01 01 00
INTERFACE CLASS: 0b 24 06 02 07 00 01 00 00 00 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 02 00 40 01 f0 00 c0 00 03 4b c0 00 03 4b 00 58 02 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 03 00 20 03 58 02 70 00 14 99 70 00 14 99 00 a6 0e 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 1e 24 07 04 00 00 04 00 03 00 00 16 80 00 00 16 80 00 00 18 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 05 00 00 05 00 04 00 00 12 c0 00 00 12 c0 00 00 28 00 2a 2c 0a 00 01 2a 2c 0a 00
INTERFACE CLASS: 1e 24 07 06 00 40 06 b0 04 00 00 0e a6 00 00 0e a6 00 98 3a 00 d0 12 13 00 01 d0 12 13 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 0d 2f 00 00 0d 2f 00 60 09 00 0e 64 03 00 01 0e 64 03 00
INTERFACE CLASS: 06 24 0d 00 00 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x13fc 3x 1020 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
dmesg lines on plugging:
[ 95.016139] usb 1-1.4.3.3: new high-speed USB device number 13 using xhci_hcd
[ 95.130236] usb 1-1.4.3.3: New USB device found, idVendor=1778, idProduct=0214, bcdDevice= 7.07
[ 95.130241] usb 1-1.4.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 95.130244] usb 1-1.4.3.3: Product: IPEVO Point 2 View
[ 95.130246] usb 1-1.4.3.3: Manufacturer: IPEVO Inc.
[ 95.133103] hid-generic 0003:1778:0214.000A: hiddev97,hidraw6: USB HID v1.10 Device [IPEVO Inc. IPEVO Point 2 View] on usb-0000:00:14.0-1.4.3.3/input0
[ 95.133500] uvcvideo: Probing generic UVC device 1.4.3.3
[ 95.133618] uvcvideo: trying extra data from endpoint 0.
[ 95.133623] uvcvideo: Found format YUV 4:2:2 (YUYV).
[ 95.133626] uvcvideo: - 640x480 (30.0 fps)
[ 95.133629] uvcvideo: - 320x240 (30.0 fps)
[ 95.133631] uvcvideo: - 800x600 (24.0 fps)
[ 95.133633] uvcvideo: - 1024x768 (15.0 fps)
[ 95.133635] uvcvideo: - 1280x1024 (8.0 fps)
[ 95.133636] uvcvideo: - 1600x1200 (4.0 fps)
[ 95.133638] uvcvideo: - 640x480 (30.0 fps)
[ 95.133639] uvcvideo: Found format MJPEG.
[ 95.133641] uvcvideo: - 640x480 (45.0 fps)
[ 95.133642] uvcvideo: - 320x240 (45.0 fps)
[ 95.133644] uvcvideo: - 800x600 (45.0 fps)
[ 95.133645] uvcvideo: - 1024x768 (30.0 fps)
[ 95.133647] uvcvideo: - 1280x1024 (15.0 fps)
[ 95.133648] uvcvideo: - 1600x1200 (8.0 fps)
[ 95.133649] uvcvideo: - 640x480 (45.0 fps)
[ 95.133656] uvcvideo: Found a Status endpoint (addr 81).
[ 95.133658] uvcvideo: Found UVC 1.00 device IPEVO Point 2 View (1778:0214)
[ 95.133698] uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -32 (exp. 1).
[ 95.133763] uvcvideo: Control error 6
[ 95.133766] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/2 to device 1.4.3.3 entity 1
[ 95.133769] uvcvideo: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2.
[ 95.133815] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/6 to device 1.4.3.3 entity 1
[ 95.133818] uvcvideo: Adding mapping 'Focus (absolute)' to control 00000000-0000-0000-0000-000000000001/6.
[ 95.133860] uvcvideo: Failed to query (GET_INFO) UVC control 9 on unit 1: -32 (exp. 1).
[ 95.133934] uvcvideo: Control error 6
[ 95.133936] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/9 to device 1.4.3.3 entity 1
[ 95.133939] uvcvideo: Adding mapping 'Iris, Absolute' to control 00000000-0000-0000-0000-000000000001/9.
[ 95.133984] uvcvideo: Added control 00000000-0000-0000-0000-000000000001/8 to device 1.4.3.3 entity 1
[ 95.133986] uvcvideo: Adding mapping 'Focus, Auto' to control 00000000-0000-0000-0000-000000000001/8.
[ 95.134031] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/2 to device 1.4.3.3 entity 3
[ 95.134033] uvcvideo: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2.
[ 95.134078] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/3 to device 1.4.3.3 entity 3
[ 95.134080] uvcvideo: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3.
[ 95.134130] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/6 to device 1.4.3.3 entity 3
[ 95.134132] uvcvideo: Adding mapping 'Hue' to control 00000000-0000-0000-0000-000000000101/6.
[ 95.134178] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/7 to device 1.4.3.3 entity 3
[ 95.134180] uvcvideo: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7.
[ 95.134225] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/8 to device 1.4.3.3 entity 3
[ 95.134227] uvcvideo: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8.
[ 95.134266] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/9 to device 1.4.3.3 entity 3
[ 95.134269] uvcvideo: Adding mapping 'Gamma' to control 00000000-0000-0000-0000-000000000101/9.
[ 95.134313] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/10 to device 1.4.3.3 entity 3
[ 95.134316] uvcvideo: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10.
[ 95.134361] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/5 to device 1.4.3.3 entity 3
[ 95.134364] uvcvideo: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5.
[ 95.134409] uvcvideo: Added control 00000000-0000-0000-0000-000000000101/11 to device 1.4.3.3 entity 3
[ 95.134411] uvcvideo: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11.
[ 95.134415] uvcvideo: Scanning UVC chain: OT 2 <- XU 4 <- PU 3 <- IT 1
[ 95.134422] uvcvideo: Found a valid video chain (1 -> 2).
[ 95.135278] uvcvideo 1-1.4.3.3:1.1: Entity type for entity Extension 4 was not initialized!
[ 95.135284] uvcvideo 1-1.4.3.3:1.1: Entity type for entity Processing 3 was not initialized!
[ 95.135289] uvcvideo 1-1.4.3.3:1.1: Entity type for entity Camera 1 was not initialized!
[ 95.135468] input: IPEVO Point 2 View: IPEVO Point as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3.3/1-1.4.3.3:1.1/input/input22
[ 95.135632] uvcvideo: UVC device initialized.
[ 95.173185] uvcvideo: uvc_v4l2_open
[ 95.173224] uvcvideo: uvc_v4l2_release
[ 97.532205] uvcvideo: Suspending interface 2
[ 97.532210] uvcvideo: Suspending interface 1
# ls -l /dev/video*
crw-rw----+ 1 root video 81, 0 Jan 5 12:20 /dev/video0
crw-rw----+ 1 root video 81, 1 Jan 5 12:20 /dev/video1
Camera works.
--
============================================
Roger Whittaker
SUSE Linux Premium Support Engineer
roger.whittaker@suse.com
+44 7802 357081
SUSE Linux
One Station Square
Bracknell
RG12 1QB
United Kingdom
============================================
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-05 12:28 ` Roger Whittaker
@ 2020-01-06 15:43 ` Alan Stern
2020-01-06 16:03 ` Johan Hovold
2020-01-06 16:13 ` Laurent Pinchart
0 siblings, 2 replies; 23+ messages in thread
From: Alan Stern @ 2020-01-06 15:43 UTC (permalink / raw)
To: Greg KH
Cc: Roger Whittaker, Laurent Pinchart, Takashi Iwai, Johan Hovold, USB list
It turns out that even though endpoints with a maxpacket length of 0
aren't useful for data transfer, the descriptors do serve other
purposes. In particular, skipping them will also skip over other
class-specific descriptors for classes such as UVC. This unexpected
side effect has caused some UVC cameras to stop working.
In addition, the USB spec requires that when isochronous endpoint
descriptors are present in an interface's altsetting 0 (which is true
on some devices), the maxpacket size _must_ be set to 0. Warning
about such things seems like a bad idea.
This patch updates an earlier commit which would log a warning and
skip these endpoint descriptors. Now we only log a warning, and we
don't even do that for isochronous endpoints in altsetting 0.
We don't need to worry about preventing endpoints with maxpacket = 0
from ever being used for data transfers; usb_submit_urb() already
checks for this.
Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
---
[as1928]
drivers/usb/core/config.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
Index: usb-devel/drivers/usb/core/config.c
===================================================================
--- usb-devel.orig/drivers/usb/core/config.c
+++ usb-devel/drivers/usb/core/config.c
@@ -346,12 +346,16 @@ static int usb_parse_endpoint(struct dev
endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
}
- /* Validate the wMaxPacketSize field */
+ /*
+ * Validate the wMaxPacketSize field.
+ * Some devices have isochronous endpoints in altsetting 0;
+ * the USB-2 spec requires such endpoints to have wMaxPacketSize = 0
+ * (see the end of section 5.6.3), so don't warn about them.
+ */
maxp = usb_endpoint_maxp(&endpoint->desc);
- if (maxp == 0) {
- dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has wMaxPacketSize 0, skipping\n",
+ if (maxp == 0 && !(usb_endpoint_xfer_isoc(d) && asnum == 0)) {
+ dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid wMaxPacketSize 0\n",
cfgno, inum, asnum, d->bEndpointAddress);
- goto skip_to_next_endpoint_or_interface_descriptor;
}
/* Find the highest legal maxpacket size for this endpoint */
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-06 15:43 ` [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0 Alan Stern
@ 2020-01-06 16:03 ` Johan Hovold
2020-01-06 16:17 ` Alan Stern
2020-01-06 16:13 ` Laurent Pinchart
1 sibling, 1 reply; 23+ messages in thread
From: Johan Hovold @ 2020-01-06 16:03 UTC (permalink / raw)
To: Alan Stern
Cc: Greg KH, Roger Whittaker, Laurent Pinchart, Takashi Iwai,
Johan Hovold, USB list
On Mon, Jan 06, 2020 at 10:43:42AM -0500, Alan Stern wrote:
> It turns out that even though endpoints with a maxpacket length of 0
> aren't useful for data transfer, the descriptors do serve other
> purposes. In particular, skipping them will also skip over other
> class-specific descriptors for classes such as UVC. This unexpected
> side effect has caused some UVC cameras to stop working.
>
> In addition, the USB spec requires that when isochronous endpoint
> descriptors are present in an interface's altsetting 0 (which is true
> on some devices), the maxpacket size _must_ be set to 0. Warning
> about such things seems like a bad idea.
>
> This patch updates an earlier commit which would log a warning and
> skip these endpoint descriptors. Now we only log a warning, and we
> don't even do that for isochronous endpoints in altsetting 0.
>
> We don't need to worry about preventing endpoints with maxpacket = 0
> from ever being used for data transfers; usb_submit_urb() already
> checks for this.
>
> Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
> Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
Acked-by: Johan Hovold <johan@kernel.org>
We also need
Cc: stable <stable@vger.kernel.org>
as d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length") ended up
being (auto- ?) selected for stable.
Johan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-06 15:43 ` [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0 Alan Stern
2020-01-06 16:03 ` Johan Hovold
@ 2020-01-06 16:13 ` Laurent Pinchart
2020-01-06 16:21 ` Alan Stern
1 sibling, 1 reply; 23+ messages in thread
From: Laurent Pinchart @ 2020-01-06 16:13 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, Roger Whittaker, Takashi Iwai, Johan Hovold, USB list
Hi Alan,
Thank you for the patch.
On Mon, Jan 06, 2020 at 10:43:42AM -0500, Alan Stern wrote:
> It turns out that even though endpoints with a maxpacket length of 0
> aren't useful for data transfer, the descriptors do serve other
> purposes. In particular, skipping them will also skip over other
> class-specific descriptors for classes such as UVC. This unexpected
> side effect has caused some UVC cameras to stop working.
>
> In addition, the USB spec requires that when isochronous endpoint
> descriptors are present in an interface's altsetting 0 (which is true
> on some devices), the maxpacket size _must_ be set to 0. Warning
> about such things seems like a bad idea.
>
> This patch updates an earlier commit which would log a warning and
> skip these endpoint descriptors. Now we only log a warning, and we
> don't even do that for isochronous endpoints in altsetting 0.
>
> We don't need to worry about preventing endpoints with maxpacket = 0
> from ever being used for data transfers; usb_submit_urb() already
> checks for this.
>
> Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
> Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
The patch looks good to me, so
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
But shouldn't we also warn if maxp != 0 && usb_endpoint_xfer_isoc(d) &&
asnum == 0 ?
> ---
>
>
> [as1928]
>
>
> drivers/usb/core/config.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> Index: usb-devel/drivers/usb/core/config.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/core/config.c
> +++ usb-devel/drivers/usb/core/config.c
> @@ -346,12 +346,16 @@ static int usb_parse_endpoint(struct dev
> endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
> }
>
> - /* Validate the wMaxPacketSize field */
> + /*
> + * Validate the wMaxPacketSize field.
> + * Some devices have isochronous endpoints in altsetting 0;
> + * the USB-2 spec requires such endpoints to have wMaxPacketSize = 0
> + * (see the end of section 5.6.3), so don't warn about them.
> + */
> maxp = usb_endpoint_maxp(&endpoint->desc);
> - if (maxp == 0) {
> - dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has wMaxPacketSize 0, skipping\n",
> + if (maxp == 0 && !(usb_endpoint_xfer_isoc(d) && asnum == 0)) {
> + dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid wMaxPacketSize 0\n",
> cfgno, inum, asnum, d->bEndpointAddress);
> - goto skip_to_next_endpoint_or_interface_descriptor;
> }
>
> /* Find the highest legal maxpacket size for this endpoint */
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-06 16:03 ` Johan Hovold
@ 2020-01-06 16:17 ` Alan Stern
2020-01-06 19:12 ` Greg KH
0 siblings, 1 reply; 23+ messages in thread
From: Alan Stern @ 2020-01-06 16:17 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg KH, Roger Whittaker, Laurent Pinchart, Takashi Iwai, USB list
On Mon, 6 Jan 2020, Johan Hovold wrote:
> On Mon, Jan 06, 2020 at 10:43:42AM -0500, Alan Stern wrote:
> > It turns out that even though endpoints with a maxpacket length of 0
> > aren't useful for data transfer, the descriptors do serve other
> > purposes. In particular, skipping them will also skip over other
> > class-specific descriptors for classes such as UVC. This unexpected
> > side effect has caused some UVC cameras to stop working.
> >
> > In addition, the USB spec requires that when isochronous endpoint
> > descriptors are present in an interface's altsetting 0 (which is true
> > on some devices), the maxpacket size _must_ be set to 0. Warning
> > about such things seems like a bad idea.
> >
> > This patch updates an earlier commit which would log a warning and
> > skip these endpoint descriptors. Now we only log a warning, and we
> > don't even do that for isochronous endpoints in altsetting 0.
> >
> > We don't need to worry about preventing endpoints with maxpacket = 0
> > from ever being used for data transfers; usb_submit_urb() already
> > checks for this.
> >
> > Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
> > Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
>
> Acked-by: Johan Hovold <johan@kernel.org>
>
> We also need
>
> Cc: stable <stable@vger.kernel.org>
>
> as d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length") ended up
> being (auto- ?) selected for stable.
Absolutely -- I had intended to add that CC: but it slipped my mind
when the email was being prepared.
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-06 16:13 ` Laurent Pinchart
@ 2020-01-06 16:21 ` Alan Stern
0 siblings, 0 replies; 23+ messages in thread
From: Alan Stern @ 2020-01-06 16:21 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Greg KH, Roger Whittaker, Takashi Iwai, Johan Hovold, USB list
On Mon, 6 Jan 2020, Laurent Pinchart wrote:
> Hi Alan,
>
> Thank you for the patch.
>
> On Mon, Jan 06, 2020 at 10:43:42AM -0500, Alan Stern wrote:
> > It turns out that even though endpoints with a maxpacket length of 0
> > aren't useful for data transfer, the descriptors do serve other
> > purposes. In particular, skipping them will also skip over other
> > class-specific descriptors for classes such as UVC. This unexpected
> > side effect has caused some UVC cameras to stop working.
> >
> > In addition, the USB spec requires that when isochronous endpoint
> > descriptors are present in an interface's altsetting 0 (which is true
> > on some devices), the maxpacket size _must_ be set to 0. Warning
> > about such things seems like a bad idea.
> >
> > This patch updates an earlier commit which would log a warning and
> > skip these endpoint descriptors. Now we only log a warning, and we
> > don't even do that for isochronous endpoints in altsetting 0.
> >
> > We don't need to worry about preventing endpoints with maxpacket = 0
> > from ever being used for data transfers; usb_submit_urb() already
> > checks for this.
> >
> > Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
> > Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
>
> The patch looks good to me, so
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> But shouldn't we also warn if maxp != 0 && usb_endpoint_xfer_isoc(d) &&
> asnum == 0 ?
We could, but that's a different kind of issue. That would be more a
question of not adhering to the standard than of possibly failing to
work.
In theory the USBCV tests already check for this. Manufacturers that
don't run those tests probably also won't care if the Linux kernel
complains. But as far as I know, none of our drivers will malfunction
if there's an isochronous endpoint in altsetting 0 with maxpacket > 0.
Alan Stern
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0
2020-01-06 16:17 ` Alan Stern
@ 2020-01-06 19:12 ` Greg KH
0 siblings, 0 replies; 23+ messages in thread
From: Greg KH @ 2020-01-06 19:12 UTC (permalink / raw)
To: Alan Stern
Cc: Johan Hovold, Roger Whittaker, Laurent Pinchart, Takashi Iwai, USB list
On Mon, Jan 06, 2020 at 11:17:12AM -0500, Alan Stern wrote:
> On Mon, 6 Jan 2020, Johan Hovold wrote:
>
> > On Mon, Jan 06, 2020 at 10:43:42AM -0500, Alan Stern wrote:
> > > It turns out that even though endpoints with a maxpacket length of 0
> > > aren't useful for data transfer, the descriptors do serve other
> > > purposes. In particular, skipping them will also skip over other
> > > class-specific descriptors for classes such as UVC. This unexpected
> > > side effect has caused some UVC cameras to stop working.
> > >
> > > In addition, the USB spec requires that when isochronous endpoint
> > > descriptors are present in an interface's altsetting 0 (which is true
> > > on some devices), the maxpacket size _must_ be set to 0. Warning
> > > about such things seems like a bad idea.
> > >
> > > This patch updates an earlier commit which would log a warning and
> > > skip these endpoint descriptors. Now we only log a warning, and we
> > > don't even do that for isochronous endpoints in altsetting 0.
> > >
> > > We don't need to worry about preventing endpoints with maxpacket = 0
> > > from ever being used for data transfers; usb_submit_urb() already
> > > checks for this.
> > >
> > > Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com>
> > > Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
> > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2
> >
> > Acked-by: Johan Hovold <johan@kernel.org>
> >
> > We also need
> >
> > Cc: stable <stable@vger.kernel.org>
> >
> > as d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length") ended up
> > being (auto- ?) selected for stable.
>
> Absolutely -- I had intended to add that CC: but it slipped my mind
> when the email was being prepared.
I'll catch this when it hits Linus's tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-01-06 19:13 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200101144709.GA8389@suse.com>
[not found] ` <20200101172449.GF6226@pendragon.ideasonboard.com>
[not found] ` <20200101175220.GA18140@suse.com>
2020-01-01 18:35 ` Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels Laurent Pinchart
2020-01-01 18:47 ` Greg KH
2020-01-01 20:09 ` Alan Stern
2020-01-02 11:20 ` Johan Hovold
2020-01-02 13:11 ` Takashi Iwai
2020-01-02 15:06 ` Alan Stern
2020-01-02 15:32 ` Johan Hovold
2020-01-02 18:24 ` Alan Stern
2020-01-02 16:38 ` Laurent Pinchart
2020-01-02 16:57 ` Roger Whittaker
2020-01-02 17:03 ` Laurent Pinchart
2020-01-02 17:49 ` Alan Stern
2020-01-02 21:51 ` Roger Whittaker
2020-01-02 23:11 ` Laurent Pinchart
2020-01-03 15:13 ` Alan Stern
2020-01-04 18:22 ` Laurent Pinchart
2020-01-05 12:28 ` Roger Whittaker
2020-01-06 15:43 ` [PATCH] USB: Fix: Don't skip endpoint descriptors with maxpacket=0 Alan Stern
2020-01-06 16:03 ` Johan Hovold
2020-01-06 16:17 ` Alan Stern
2020-01-06 19:12 ` Greg KH
2020-01-06 16:13 ` Laurent Pinchart
2020-01-06 16:21 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).