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 6D365C2D0C2 for ; Sat, 4 Jan 2020 18:22:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 472FE222C4 for ; Sat, 4 Jan 2020 18:22:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="axyDCm8m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726135AbgADSWS (ORCPT ); Sat, 4 Jan 2020 13:22:18 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:38448 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726143AbgADSWS (ORCPT ); Sat, 4 Jan 2020 13:22:18 -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 A05D2A31; Sat, 4 Jan 2020 19:22:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1578162135; bh=SW2ZyqDEfgwUASqaFK+8qfjDaw34uxSE4X3GgiKnwyI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=axyDCm8m7kSBEtyJVDe6MyHwDEL2V6o/CA4l4g+4pLHjsEFiBtFsADgroPmDbA0h7 kmahtvexl5pizLnGSBjZcsXofCGJhKcBx2lHl/M9fQJVOnBto25k9tKq6XCktAUuGD QgqN0kqL3VYwBmyIUviolMU1rS44H3cGvdQPB+L8= Date: Sat, 4 Jan 2020 20:22:05 +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: <20200104182205.GB4906@pendragon.ideasonboard.com> References: <20200102231124.GH4843@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 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