Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6296113yba; Wed, 1 May 2019 09:28:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyAIGunw4NPb1eb3b5j3D/KP+e+ziC4/3hLF1gLaqp6IDAt08GLRwqPSrHTmIE2BR1AbaRS X-Received: by 2002:a62:1a0d:: with SMTP id a13mr79062804pfa.198.1556728103166; Wed, 01 May 2019 09:28:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556728103; cv=none; d=google.com; s=arc-20160816; b=eArWwuqVyUNMQRqtPeRwmZB9erVhvUHxq8CACu0xdDc3jHGxgF7rS6SYsoqO0luo9q G2kIxFOREyOuxD0m9SLhJ3eYDRJ2A6f7jnw8eSattkAYdeeit0oJpEYo3LDT3ig0296C piXopixuADl1zPxamTgGBEHUlKogPRoyWmx32eED554ZDAnxJw8qTehYIl9guR5VVoZN iUYYQxhqzH/vwGy4IEtl5f0hnDynq+tVbvjZEig7sPnZrL61xQ32vVoaPwzyp6vQQKiy qWhGEbmE+FV7OUC1J1rRMjDClzX7UF/dt9iy+HKC4jKTZ04E23g5hAfAH60FNs3/M9VU 3mFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wDOjl+22JHswyc+f80KyTLC8YrgA98P8QBgZgVAtz90=; b=IVhEpgUCncJO+iy7KqqvHirMpzzRaF4VSTihkNjwRJEBInj4XHtlSEdNTx60sYxQCE dXPu8qGKVIEirWr+T28DhExIHKA/GM2L+BUbYPHgRY5g9zXSyv6aHXU79YdpnkBpiHyk +5AUXXG6yp3cWdRa//5+QlhAagYnSul9WxRE0zczBzMz7JLaqFp0iAZllGWXSJklPlXs DgfkHwk6SlQfaV4kwvZ1YrCom6kc7vux3inmdTvo2nTIc6nOxuputXiXmiNE3wle32py Kl1er/mivY3hT4iuAcXCuVKG4I5K6+3qb/r14SpckrXPQMe6cUAhJMwNFGbKgoVepXiY FlWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sqp5SVDa; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si42630214pfr.150.2019.05.01.09.28.07; Wed, 01 May 2019 09:28:23 -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; dkim=pass header.i=@kernel.org header.s=default header.b=sqp5SVDa; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbfEAQ1Q (ORCPT + 99 others); Wed, 1 May 2019 12:27:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:35952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726388AbfEAQ1P (ORCPT ); Wed, 1 May 2019 12:27:15 -0400 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D2CA520835; Wed, 1 May 2019 16:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556728034; bh=QNpnCPkV3/b0tnrMUodSGF1+h/20QEARntDWcAUOpKM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sqp5SVDa4nhuGj8W5aMwN2LXkCdkQZqPMRHJ0VE6EbJWrWjaF0XZGB7QCW274ngeN zt8SRq8ojVn1IhRh/oZ3E0Wy07Izd3E5uDkZWFr/uBGJsx4yPe5DgRGTm9sOupSDwM ntW4IqK7hZ0hGVZgH9EWQzCtWQeGNe8R7Kt7YyZc= Received: by mail-qk1-f169.google.com with SMTP id d5so10443998qko.12; Wed, 01 May 2019 09:27:13 -0700 (PDT) X-Gm-Message-State: APjAAAW4DateloU5ER4cMe3XJxfJjHjGZTmVwvD/o38ts8iLpVZFsGff T4iT3mnuLUigZU3lOHwcg0JPUoolr1VqZA+U3Q== X-Received: by 2002:a37:4711:: with SMTP id u17mr19046164qka.326.1556728033039; Wed, 01 May 2019 09:27:13 -0700 (PDT) MIME-Version: 1.0 References: <20190420064019.57522-1-chenyu56@huawei.com> <20190420064019.57522-3-chenyu56@huawei.com> <20190425213532.GA32028@bogus> In-Reply-To: From: Rob Herring Date: Wed, 1 May 2019 11:27:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 02/13] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960 To: Chen Yu Cc: liuyu712@hisilicon.com, Linux USB List , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , John Stultz , Suzhuangluan , kongfei@hisilicon.com, wanghu17@hisilicon.com, butao@hisilicon.com, chenyao11@huawei.com, fangshengzhou@hisilicon.com, Li Pengcheng , Song Xiaowei , Yiping Xu , xuyoujun4@huawei.com, yudongbin@hisilicon.com, zangleigang , Kishon Vijay Abraham I , Sergei Shtylyov , Mark Rutland , Binghui Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 30, 2019 at 1:08 AM Chen Yu wrote: > > Hi Rob, > > On 2019/4/26 5:35, Rob Herring wrote: > > On Sat, Apr 20, 2019 at 02:40:08PM +0800, Yu Chen wrote: > >> This patch adds binding documentation to support usb hub and usb > >> data role switch of Hisilicon HiKey960 Board. > > > > Sorry I've been slow to really review this, but I needed to look at the > > schematics to see what exactly is going on here. > > > > I think this needs some changes to better reflect the h/w and utilize > > existing bindings. It should really be designed ignoring the muxing to > > start with. Define the binding for the TypeC connector and then the host > > hub and make sure they can coexist. Then overlay what you need to switch > > between the 2 modes which AFAICT is just a single GPIO. > > > >> > >> Cc: Kishon Vijay Abraham I > >> Cc: Sergei Shtylyov > >> Cc: Rob Herring > >> Cc: Mark Rutland > >> Cc: John Stultz > >> Cc: Binghui Wang > >> Signed-off-by: Yu Chen > >> --- > >> v1: > >> * Fix some format errors as suggested by Sergei. > >> * Modify gpio description to use gpiod API. > >> v2: > >> * Remove information about Hikey. > >> * Fix gpio description. > >> * Remove device_type of endpoint. > >> v3: > >> * Remove property typec-vbus-enable-val. > >> * Add description of pinctrl-names. > >> * Add example for "hisilicon,gpio-hubv1" > >> * Add flag in gpiod properties. > >> --- > >> --- > >> .../bindings/misc/hisilicon-hikey-usb.txt | 52 ++++++++++++++++++++++ > >> 1 file changed, 52 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt > >> > >> diff --git a/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt > >> new file mode 100644 > >> index 000000000000..422e844df719 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt > >> @@ -0,0 +1,52 @@ > >> +Support usb hub and usb data role switch of Hisilicon HiKey960 Board. > >> + > >> +----------------------------- > >> + > >> +Required properties: > >> +- compatible: "hisilicon,gpio-hubv1","hisilicon,hikey960-usb" > >> +- typec-vbus-gpios: gpio to control the vbus of typeC port > > > > This should be a gpio regulator and then connected to 'vbus-supply' in a > > usb-connector node (see .../bindings/connectors/usb-connector.txt). > Currently usb-connector node has no "vbus-supply" property and > I do not find process that handles vbus-supply in RT1711H TypeC driver. The patch[1] adding that is posted to the list and may not have landed yet. Whether the RT1711H TypeC driver handles it or not is not a binding problem. > > Then you also need the RT1711HWSC TypeC controller in DT. That is > > typically the parent device of the connector node. > > > >> +- otg-switch-gpios: gpio to switch DP & DM between the hub and typeC port > > > > This probably belongs in USB controller node. > > > The otg-switch-gpios controls a mux like fsusb30mux. It is related to > the board design of HiKey960. And the state of the mux is decided by > the typeC port state. So I think it is not so good to make it belongs > in USB controller node. Let me put it this way. The gpio property belongs wherever the mux is represented. In this case, I would expect the graph port representing the HS port to have 2 endpoints representing the 2 mux outputs. We don't generally put properties in the endpoint or port nodes, but the parent nodes. > >> +- hub-vdd33-en-gpios: gpio to enable the power of hub > > > > This too should be a gpio regulator and then in a hub node. We have 2 > > ways to represent hubs. Either as an I2C device or as a child of the > > host controller. The latter is preferred, but I'm not too sure how the > > OF graph connection linking the controller to the TypeC connector will > > work with the usb bus binding. > > > There is no particular code except the power control for the hub. > The i2c on the hub is not used. So it can not be an I2C device. > Is there such an example that make the hub as a child of the host controller > and control its power? Yes, bindings/usb/usb-device.txt. Rob [1] https://www.spinics.net/lists/kernel/msg3089136.html