linux-kernel - Re: [PATCH V6 00/12] Tegra xHCI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Feb 2015 22:15:45 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Andrew Bresticker <abrestic@...omium.org>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Alexandre Courbot <gnurou@...il.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Jassi Brar <jassisinghbrar@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Grant Likely <grant.likely@...aro.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Kishon Vijay Abraham I <kishon@...com>,
	Felipe Balbi <balbi@...com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH V6 00/12] Tegra xHCI support

On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote:
> Hi Thierry,
> 
> > Sorry for taking so awfully long to look at this. I've spent some time
> > looking at various pieces of documentation and I concluded that
> > representing the port assignment as muxing options doesn't seem right
> > after all. Instead I've come up with an alternate proposal (attached).
> > Could you take a look and see if that sounds reasonable to you?
> 
> Thanks for taking a look at this.  I've been meaning to pick this
> series back up, but haven't had quite enough bandwidth lately.
> 
> This all looks good to me, just one comment below:
> 
> > +PHY nodes:
> > +----------
> > +
> > +An optional child node named "phys" can contain nodes describing additional
> > +properties of each PHY. Only USB3 and UTMI PHYs can be complemented in this
> > +way, in which case the name of each node must match one of the following:
> > +
> > +  usb3-0, usb3-1, utmi-0, utmi-1, utmi-2
> > +
> > +Required properties for USB3 PHYs:
> > +- nvidia,lanes: specifies the name of the lane that this USB3 PHY uses
> > +- nvidia,port: specifies the number of the USB2 port that is used for this
> > +  USB3 PHY
> > +
> > +Optional properties for UTMI PHYs:
> > +- vbus-supply: regulator providing the VBUS voltage for the UTMI pad
> 
> What about the HSIC PHYs?  Shouldn't they be represented as PHY nodes as well?

Yes, they could. The PCIe and SATA PHYs could as well. I haven't
included them because they currently don't take any properties. In
addition to that, perhaps some of the nvidia,hsic-* properties could be
moved into the PHY nodes, too. But they're also properties of the pin,
so keeping them in the pinmux nodes seems fine as well.

On a slightly different topic, I've been trying to wrap my head around
the use of the nvidia,port property and my conclusion was that in fact
one of the physical ports is shared between USB2 and USB3. That is the
utmi-2 PHY and usb3-0 PHY go to the very same port. The vbus-supply
specified in the Jetson TK1 DTS would support that (it's associated with
utmi-2 but named vdd_usb3_reg, and the USB3 port doesn't work without
it). Can you confirm that?

Thierry

Content of type "application/pgp-signature" skipped