Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934845AbcCPSIL (ORCPT ); Wed, 16 Mar 2016 14:08:11 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:36354 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933380AbcCPSII (ORCPT ); Wed, 16 Mar 2016 14:08:08 -0400 Subject: Re: [PATCH v10 6/9] dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding To: Thierry Reding References: <1457108379-20794-1-git-send-email-thierry.reding@gmail.com> <1457108379-20794-6-git-send-email-thierry.reding@gmail.com> Cc: Greg Kroah-Hartman , Mathias Nyman , Alexandre Courbot , Andrew Bresticker , linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala From: Stephen Warren Message-ID: <56E9A105.9010408@wwwdotorg.org> Date: Wed, 16 Mar 2016 12:08:05 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1457108379-20794-6-git-send-email-thierry.reding@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1642 Lines: 36 On 03/04/2016 09:19 AM, Thierry Reding wrote: > From: Thierry Reding > > Add device-tree binding documentation for the XUSB controller present > on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI > compliant interface. > > Based on work by Andrew Bresticker . > diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt > +Required properties: > +- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to > + configure the USB pads used by the XHCI controller Is "global" access to the PADCTL DT node/driver required? I rather would have expected this binding to reference the port objects in the PADCTL node. Perhaps the intent is that drivers can use this property to go and read the port information directly from the PADCTL node and interpret it themselves without requiring the PADCTL driver to provide an interface for ports? I guess that would also explain why this binding references only PHYs and not ports: > +Optional properties: > +-------------------- > +- phys: Must contain an entry for each entry in phy-names. > + See ../phy/phy-bindings.txt for details. > +- phy-names: Should include an entry for each PHY used by the controller. The > + following PHYs are available: > + - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 > + - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 If that's how this works (which might be worth mentioning in the binding doc), then: Acked-by: Stephen Warren