Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3474446ybk; Tue, 19 May 2020 05:44:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzj+7Flfrarw/vx3v90H/dSEae7rujJ9Fy92qxRL/GTHRtuYA01FHjJHQWE7JrvD9Rtkch3 X-Received: by 2002:a17:906:1751:: with SMTP id d17mr18416896eje.314.1589892254663; Tue, 19 May 2020 05:44:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589892254; cv=none; d=google.com; s=arc-20160816; b=TtAfNfxO4Cnmk7ZEPk92kZYMgFQdu88aNkQwBUFqwqZuJEz6PStB13R2n+b5tqAwJG hCkfGFI+ZlMic9rSpuNL3AnuelWGS+x7CQyCvw4cW4gywnPSi2zTmCil/E/9F/kfzHJG C5V0FDOSwn8/jmKsAUDRmhM5eS6JROqeWfV45Kk0QPXFTOeFfFF8xCPxe/lhXAEUr0dJ 3SQMn+1Gg432LpkULdyhJz7rAk+LYorVaFa59k8TQzfCmQBK7PGsOlr7wZpQ+DbRzpd7 CA111vzGwTaJyk7KG7jiZ7k8enu3K9+RxcmiA5tmYMJk9bnOYtpmG6NCL/1qyUppxIlc BRLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=K15UQ6ID5a2AZH3mGtEdsm6tvvzWPlBimAnbvK7a88U=; b=f9Rb+oR/4mkGw3mUpDQ7o9w46wfCZ/3kNEACn1Hcz7LVZEoFz3iPkaW6i1TGToJIep QX1gaTKXCB+o/axwbi+L8XCercLq6lXGTZngBuuWF6TKubws8KsZ58Xq4c3xFbT31yLW acfckwA4riAFre3PFeICv7hO+Lfqvd8qasC2uJyZ74IHNVm6nyQoYJnjml//mXFd7HpA 77coCW0K9GIMI5olhbFUUfdFaud3roXWpgLRTl3us4xU+eRipunx+8fwjxGBzWJHgGyn dU/aWlxv9+p0Xvw4RzW2Wu4TcehO+cRvDtrcaHzr3kOsa6oq+PEswQOro7eK5RfIQ7V7 T8VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aLgW8ezP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t23si7915967eje.111.2020.05.19.05.43.51; Tue, 19 May 2020 05:44:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aLgW8ezP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728822AbgESMmW (ORCPT + 99 others); Tue, 19 May 2020 08:42:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:45354 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726471AbgESMmW (ORCPT ); Tue, 19 May 2020 08:42:22 -0400 Received: from localhost (unknown [122.182.207.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 31BE620657; Tue, 19 May 2020 12:42:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589892141; bh=f5OsPgAe/ppTyyXK8XOFW0ghBuiEYD4TKNC7dZ+SMYo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aLgW8ezP3WXZsCBJ9YpVI+t2yYJcDhVdasfgkMqharhG8o4/zk+c3tx28FK3UxjpI lHuxb+ps3r9VMQW4psb191jw15agyIHojlR7xJrhDxZYc4OIWjkc0RrKxjnY9anQSi BEbM/E9wNXMphi3G5bOUK6AkbFJS8lJkAKfYoAn0= Date: Tue, 19 May 2020 18:12:16 +0530 From: Vinod Koul To: Arnd Bergmann Cc: Anders Roxell , Mathias Nyman , Greg Kroah-Hartman , linux-arm-msm , Bjorn Andersson , Yoshihiro Shimoda , Christian Lamparter , John Stultz , Alan Stern , Andreas =?iso-8859-1?Q?B=F6hler?= , USB list , Linux Kernel Mailing List Subject: Re: [PATCH v13 3/5] usb: xhci: Add support for Renesas controller with memory Message-ID: <20200519124216.GO374218@vkoul-mobl.Dlink> References: <20200506060025.1535960-1-vkoul@kernel.org> <20200506060025.1535960-4-vkoul@kernel.org> <20200518195719.GG374218@vkoul-mobl.Dlink> <20200519045336.GH374218@vkoul-mobl.Dlink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org HI Arnd, On 19-05-20, 09:44, Arnd Bergmann wrote: > On Tue, May 19, 2020 at 6:53 AM Vinod Koul wrote: > > On 19-05-20, 00:37, Anders Roxell wrote: > > > On Mon, 18 May 2020 at 21:57, Vinod Koul wrote: > > > > On 18-05-20, 19:53, Anders Roxell wrote: > > > > > On Wed, 6 May 2020 at 08:01, Vinod Koul wrote: > > > > > > > > > > > > Some rensas controller like uPD720201 and uPD720202 need firmware to be > > > > > > loaded. Add these devices in pci table and invoke renesas firmware loader > > > > > > functions to check and load the firmware into device memory when > > > > > > required. > > > > > > > > > > > > Signed-off-by: Vinod Koul > > > > > > > > > > Hi, I got a build error when I built an arm64 allmodconfig kernel. > > > > > > > > Thanks for this. This is happening as we have default y for USB_XHCI_PCI > > > > and then we make USB_XHCI_PCI_RENESAS=m. That should be not allowed as > > > > we export as symbol so both can be inbuilt or modules but USB_XHCI_PCI=y > > > > and USB_XHCI_PCI_RENESAS=m cant. While it is valid that USB_XHCI_PCI=y|m > > > > and USB_XHCI_PCI_RENESAS=n > > > > > > > > So this seems to get fixed by below for me. I have tested with > > > > - both y and m (easy) > > > > - make USB_XHCI_PCI_RENESAS=n, USB_XHCI_PCI=y|m works > > > > - try making USB_XHCI_PCI=y and USB_XHCI_PCI_RENESAS=m, then > > > > USB_XHCI_PCI=m by kbuild :) > > > > - try making USB_XHCI_PCI=m and USB_XHCI_PCI_RENESAS=y, kbuild gives > > > > error prompt that it will be m due to depends > > > > > > > > Thanks to all the fixes done by Arnd which pointed me to this. Pls > > > > verify > > > > > > I was able to build an arm64 allmodconfig kernel with this change. > > > > I will send the formal patch and add your name in reported and > > tested. Thanks for the quick verification > > I just checked the patch and I think this will work correctly in all cases, > but it still seems a bit backwards: > > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > > > index b5c542d6a1c5..92783d175b3f 100644 > > > > --- a/drivers/usb/host/Kconfig > > > > +++ b/drivers/usb/host/Kconfig > > > > @@ -40,11 +40,11 @@ config USB_XHCI_DBGCAP > > > > config USB_XHCI_PCI > > > > tristate > > > > depends on USB_PCI > > > > + depends on USB_XHCI_PCI_RENESAS || !USB_XHCI_PCI_RENESAS > > > > default y > > > > > > > > config USB_XHCI_PCI_RENESAS > > > > tristate "Support for additional Renesas xHCI controller with firwmare" > > > > - depends on USB_XHCI_PCI > > > > ---help--- > > > > Say 'Y' to enable the support for the Renesas xHCI controller with > > > > firwmare. Make sure you have the firwmare for the device and > > > > > > I think it would have been better to follow the normal driver abstraction here > and make the renesas xhci a specialized version of the xhci driver with > its own platform_driver instance that calls into the generic xhci_pci module, > rather than having the generic code treat it as a quirk. > > That would be more like how we handle all the ehci and ohci variants, though > I'm not sure how exactly it would work with two drivers having pci_device_id > tables with non-exclusive members. Presumably the generic driver would > still have to know that it needs to fail its probe() function on devices that > need the firmware. Yeah one of the earlier versions did try this and it wasn't nice. The xhci driver claims the devices as it registers for the class. Now only solution is to ensure we load the renesas first and resort to makefile hacks.. -- ~Vinod