Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp725127ybx; Tue, 5 Nov 2019 04:40:28 -0800 (PST) X-Google-Smtp-Source: APXvYqzR2iEY/hBvfFKchJ7H95R28+RrONSMQKHK+git+sPOOs3wIdHWniwi8tbGj3sq58SUZAQK X-Received: by 2002:a05:6402:713:: with SMTP id w19mr36082196edx.239.1572957627758; Tue, 05 Nov 2019 04:40:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572957627; cv=none; d=google.com; s=arc-20160816; b=RxjFbWpQiRsgwnRC+K/jnAYCjPfsyWg///Yxp+Mq/1mEqZ2oDFN8r6lB6kirc1SNXT wvZstCCJMjI/Cgt5lZnIfvU1fXG7OkwBsvBiTxU6+arSOCm4yuRRSnKPF/kWpYF+RQr+ w+om3VT1/VWM1lYsJjDepd8tSQEOR5c6ow7/LWFJloUEA4QmN4d2kra0eM9/vnRzX68S 02i2p3ttxRC8C38BHbhGVULbMuXSOxCKIBm6/FwcpT4X21wrmqUOl8codw0so5q5pC/+ haHx9P5W/0Ab7c0m0SP1fFjSizVXgxKJO/YsxnkdIVD3Ha/t3HH3Vf/3TqsUy+AID+Aq 1kvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=tK2IZTsk4PSTcMOc/KrllJ5fbVC0m6PhzIfcj+SC3ZA=; b=e+36RMzVB1yz4KmBAsBgIsZF/ZKLZH2v9SsijvCN9f+XNf0gSXINlQ7+7I5pZK7YF9 CxjCQqo1BWWVNqGYlktR5JzwLP+MCl3NCluR8Yol9zApnt8FcAkkIQopqjMT3ddaY1Pq LCx77FsMEpDinzIfWOzmh/vw2ZMsoaEEWXMVehCeTyfaKmXaZpo4USA7Sw+9xAJxp9ci bGiQsQjSbWZkHovqupEO7fgub+wApbPZtww1lv3K7+7bGbiB50qaWNV8gH6iVIXXk80B 2EmWZInXvzWpw+7QTsAaABBqFJOaJwTSYlWMPY/WUp2PDihh4W6PJkeyKcO0HJrjspz+ 8VRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z44si10729254edz.211.2019.11.05.04.40.04; Tue, 05 Nov 2019 04:40:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388770AbfKEMhe (ORCPT + 99 others); Tue, 5 Nov 2019 07:37:34 -0500 Received: from mga07.intel.com ([134.134.136.100]:17754 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388269AbfKEMhd (ORCPT ); Tue, 5 Nov 2019 07:37:33 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2019 04:37:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,271,1569308400"; d="scan'208";a="212533952" Received: from kuha.fi.intel.com ([10.237.72.53]) by fmsmga001.fm.intel.com with SMTP; 05 Nov 2019 04:37:28 -0800 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Tue, 05 Nov 2019 14:37:27 +0200 Date: Tue, 5 Nov 2019 14:37:27 +0200 From: Heikki Krogerus To: Thierry Reding Cc: Mao Wenan , felipe.balbi@linux.intel.com, gregkh@linuxfoundation.org, nkristam@nvidia.com, arnd@arndb.de, johan@kernel.org, krzk@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH -next] usb: gadget: Add dependency for USB_TEGRA_XUDC Message-ID: <20191105123727.GA12204@kuha.fi.intel.com> References: <20191104025945.172620-1-maowenan@huawei.com> <20191104100410.GB996639@ulmo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191104100410.GB996639@ulmo> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 04, 2019 at 11:04:10AM +0100, Thierry Reding wrote: > On Mon, Nov 04, 2019 at 10:59:45AM +0800, Mao Wenan wrote: > > If CONFIG_USB_TEGRA_XUDC=y and CONFIG_USB_ROLE_SWITCH=m, > > below erros can be seen: > > drivers/usb/gadget/udc/tegra-xudc.o: In function `tegra_xudc_remove': > > tegra-xudc.c:(.text+0x6b0): undefined reference to `usb_role_switch_unregister' > > drivers/usb/gadget/udc/tegra-xudc.o: In function `tegra_xudc_probe': > > tegra-xudc.c:(.text+0x1b88): undefined reference to `usb_role_switch_register' > > drivers/usb/gadget/udc/tegra-xudc.o: In function `tegra_xudc_usb_role_sw_work': > > tegra-xudc.c:(.text+0x5ecc): undefined reference to `usb_role_switch_get_role' > > > > This patch add dependency USB_ROLE_SWITCH for UDC driver. > > > > Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") > > Signed-off-by: Mao Wenan > > --- > > drivers/usb/gadget/udc/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > > index acaec3a..d103154 100644 > > --- a/drivers/usb/gadget/udc/Kconfig > > +++ b/drivers/usb/gadget/udc/Kconfig > > @@ -445,6 +445,7 @@ config USB_TEGRA_XUDC > > tristate "NVIDIA Tegra Superspeed USB 3.0 Device Controller" > > depends on ARCH_TEGRA || COMPILE_TEST > > depends on PHY_TEGRA_XUSB > > + depends on USB_ROLE_SWITCH > > It looks like most other drivers that use the USB role switch class do > "select" here. Now, that's suboptimal because USB_ROLE_SWITCH is a user- > visible symbol, which can lead to conflicts, so it should be avoided. I > think that in this case it might make sense to hide USB_ROLE_SWITCH and > then convert all "depends on USB_ROLE_SWITCH" occurrences to "select > USB_ROLE_SWITCH". The USB role switch class is, after all, not useful by > itself. It always needs a host and/or gadget driver to make use of it. USB host/gadget drivers actually never operate the role switches. If the USB controller on the system is dual-role capable, then the driver for that controller can supply the role switch, but it doesn't operate it. Note that on some systems the USB host and USB peripheral controllers are separate, and there is a mux (like the Intel USB role mux) between them and the connector. On those systems the driver for the mux represents the USB role switch. The operation of the switch is done from the USB Type-C drivers with USB Type-C connectors and from what ever driver can sense the ID-pin and VBUS with micro-B/AB connectors, but with other type of connectors the role swapping has to be done from user space. The use case for that is probable something like Apple CarPlay that requires the system to be able to swap the role even if the connector was good old Type-A connector. The point is in any case that the user of the switch is always separate from the supplier of the switch. I'm not sure hiding the option and converting all "depends on USB_ROLE_SWITCH" to "select USB_ROLE_SWITCH" is the correct thing to do. I would do the opposite and convert all "select USB_ROLE_SWTICH" to "depends on USB_ROLE_SWITCH", and leave the option user selectable. thanks, -- heikki