From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FF53C3276C for ; Thu, 2 Jan 2020 23:11:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F1B5421835 for ; Thu, 2 Jan 2020 23:11:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="hJNvEn/i" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727159AbgABXLh (ORCPT ); Thu, 2 Jan 2020 18:11:37 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:54936 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726647AbgABXLh (ORCPT ); Thu, 2 Jan 2020 18:11:37 -0500 Received: from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi [81.175.216.236]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id BF929516; Fri, 3 Jan 2020 00:11:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1578006694; bh=+8ka5EHYmQCUKqoahuGo9mz9keOCIa3B41PjQYozSV8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hJNvEn/iiIrXV7s2NCD5wT4zyR9xlU0EEXsMkRbxOxMXKGVqqyCesdHP/8zYY/fLc zsQzWbDnXjx2e1/UtSSwejpE0LD/gdFESRHU1d5xKAkaLLW1gq2rpgThkFEd+cupqc Z2tdsz9D65iFNmpHYh0yRX2JPzQamistoMSzTsm4= Date: Fri, 3 Jan 2020 01:11:24 +0200 From: Laurent Pinchart To: Alan Stern Cc: Roger Whittaker , Takashi Iwai , Johan Hovold , Greg KH , Takashi Iwai , "linux-usb@vger.kernel.org" Subject: Re: Certain cameras no longer working with uvcvideo on recent (openSUSE) kernels Message-ID: <20200102231124.GH4843@pendragon.ideasonboard.com> References: <20200102170310.GF4843@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org 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