[PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
From: Andrew Bresticker <hidden>
Date: 2014-10-29 16:37:19
Also in:
linux-devicetree, linux-tegra, lkml
On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding [off-list ref] wrote:
On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote: [...]quoted
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt[...]quoted
+Optional properties: +------------------- +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad. +- vddio-hsic-supply: VDDIO regulator for the HSIC pads. +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding USB3 + port is mapped. See <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the list + of valid values.I dislike how we now need to provide a list of all pins in the header file, where previously we used strings for this. This could become very ugly if the set of pins changes in future generations of this IP block. Could we instead derive this from the pinmux nodes? For example you have this in the example below: usb3p0 { nvidia,lanes = "pcie-0"; ... }; Perhaps what we need is to either key off the node name or add another property, such as: nvidia,usb3-port = <0>; This would match the nvidia,usb2-port property that you've added below.
That is actually how I described the USB3 port to SS lane mapping originally, but in review of an earlier version of this series, Stephen suggested that I make it a separate, not pinconfig property since it wasn't a value written directly to the hardware. I'm fine with changing it back as the pinconfig property makes more sense to me as well.