Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1661897imc; Mon, 11 Mar 2019 20:20:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxlS7VCB0wNjXRZcwAzIgUF0DQesP5hVnfTSAd0UGUoy+A8lrPqS0nnomlc186h6N1nUfZo X-Received: by 2002:a63:2bcd:: with SMTP id r196mr32395792pgr.355.1552360837562; Mon, 11 Mar 2019 20:20:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552360837; cv=none; d=google.com; s=arc-20160816; b=UmM5XLSKTDMNURy4clR0YyuiQ46fm7iivzmg9xWQUSIYfStnbWUOdPick/5jcAqWua QldYhebcxIaJQFoUUAe6AyZIrIdaiQE9BB7/BCc9VGg8gV9aO6chXlLahwdvtzYGi8E3 kTQThUYj/+WCj5G3rP0tnlLJAxup+1i4Xhm/saC7qmMc9+4CXW7TyF9s5lUuvD8UHp4Q nNUkHsa1lsNSmpFYxY2DvjGerjSv/xE9LT6uygL/5g2sCAhbbvdghJ92CUYCIrjZLPYM LP/lg6mOqrj3dRC/42nkAvYpyXBs2JElePIY57jV3X2WiOqidPfcWTtDUQ6ox3JeZ3ui mWNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=pnl9cjGaIWP1C6bOXsRnv0KucKOjbCuQGig9P+ob0Ds=; b=r/eTrvAKfAnUD3uaTCWDQ6r+CDTcIl0OFTC0IgvE3uFMcGISdCL4EkOAHQJZv7fOp6 rwdsnqIrW8rGe+fJuUTpwZT11fi4kyslgrfMh3GMkSGtjAzkudk85VrfNFH6/tOmVrKc hXDFaki3hZuK3wo5CnCDzhAyo4VHAWgpiqFADPIQLPTVqaTHo6VI5LRROf0/MHzwzNj0 zf7nNjP1nsPRPc9ZQwV8NhSNJrg5M1phnkWCg7sTBH9YNc2srpskeJ8CKZHExs9x7x5J 3sS5lyJor1FQX/tQlYLkfHNUg0sETh3gzasNAbdfMP9ZH7MGwhVMS5yGOjp1cdUdEfVp 5CEQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j16si6543598pfe.152.2019.03.11.20.20.21; Mon, 11 Mar 2019 20:20:37 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726964AbfCLDSP (ORCPT + 99 others); Mon, 11 Mar 2019 23:18:15 -0400 Received: from Mailgw01.mediatek.com ([1.203.163.78]:16715 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726789AbfCLDSP (ORCPT ); Mon, 11 Mar 2019 23:18:15 -0400 X-UUID: 491e3b8309b4438c8441825f71f14c55-20190312 X-UUID: 491e3b8309b4438c8441825f71f14c55-20190312 Received: from mtkcas36.mediatek.inc [(172.27.4.253)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 376617760; Tue, 12 Mar 2019 11:18:10 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS31N2.mediatek.inc (172.27.4.87) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Mar 2019 11:18:09 +0800 Received: from [10.17.3.153] (172.27.4.253) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 12 Mar 2019 11:18:08 +0800 Message-ID: <1552360688.10179.55.camel@mhfsdcap03> Subject: Re: [PATCH 1/5] dt-bindings: connector: add optional properties for Type-B From: Chunfeng Yun To: Hans de Goede CC: Rob Herring , Greg Kroah-Hartman , Heikki Krogerus , Mark Rutland , Matthias Brugger , Adam Thomson , Li Jun , "Badhri Jagan Sridharan" , Andy Shevchenko , Min Guo , , , , , Date: Tue, 12 Mar 2019 11:18:08 +0800 In-Reply-To: References: <1552025622-15582-1-git-send-email-chunfeng.yun@mediatek.com> <1552025622-15582-2-git-send-email-chunfeng.yun@mediatek.com> <693b11e7-fa9e-ab1f-561a-beb758b1872f@redhat.com> <1552282383.10179.21.camel@mhfsdcap03> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, 2019-03-11 at 09:06 +0100, Hans de Goede wrote: > Hi, > > On 11-03-19 06:33, Chunfeng Yun wrote: > > Hi, > > > > On Fri, 2019-03-08 at 13:07 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 08-03-19 07:13, Chunfeng Yun wrote: > >>> Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for > >>> usb-b-connector > >>> > >>> Signed-off-by: Chunfeng Yun > >>> --- > >>> .../devicetree/bindings/connector/usb-connector.txt | 10 ++++++++++ > >>> 1 file changed, 10 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt > >>> index a9a2f2fc44f2..7a07b0f4f973 100644 > >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt > >>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt > >>> @@ -17,6 +17,16 @@ Optional properties: > >>> - self-powered: Set this property if the usb device that has its own power > >>> source. > >>> > >>> +Optional properties for usb-b-connector: > >>> +- id-gpios: gpio for USB ID pin. > >> > >> What about boards where the ID pin is *not* connected to a GPIO, > >> but e.g. to a special pin on the PMIC which can also detect > >> an ACA adapter ? Currently this case is handled by extcon > >> drivers, but we have no way to set e.g. vbus-supply for the > >> connector. Maybe in this case the usb-connector node should > >> be a child of the PMIC node ? > > Yes, it would be, PMIC is in charger of detecting the status of ID pin > > Ok, then I think this should be documented too. > > >> And in many cases there also is a mux to switch the datalines > >> between the host and device(gadget) controllers, how should > >> that be described in this model? See the new usb-role-switch > >> code under drivers/usb/roles > >> > >> In some cases the mux is controlled through a gpio, so we > >> may want to add a "mux-gpios" here in which case we also > >> need to define what 0/1 means. > > I'm not sure, the mux seems not belong to this connector, > > and may need another driver to register usb-role-switch, > > similar to: > > > > [v2,2/2] usb: typec: add typec switch via GPIO control > > https://patchwork.kernel.org/patch/10834327/ > > Right the mux/role-switch will need a driver, but the "owner" > of the usb_connector, e.g. the PMIC or the owner of the > id GPIO pin needs to know which device is the role-switch so > that it can set the role correctly based on the id-pin. > > Your binding already contains Vbus info, allowing the owner > of the usb_connector to enable/disable Vbus based on the id-pin, > but the owner will also be responsible for setting the role-switch. In this patch series, I make usb_connector driver enable/disable Vbus, but not the parent(USB controller) of usb_connector which registers a usb-role-switch, which way do you think it is better? Thanks > > Note we cannot simply assume there will be only one role-switch, > we really need some link from the usb_connector to the role-switch > (or if it is a GPIO driven role-switch simply a role-switch-gpios > member in the usb_connector). > > Regards, > > Hans >