linux-kernel - Re: [RFC PATCH] dt: Tegra XUSB padctl: per-lane PHYs and USB lane map

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]

Message-ID: <5627F131.7070008@ti.com>
Date:	Thu, 22 Oct 2015 01:40:25 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>
CC:	Jon Hunter <jonathanh@...dia.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Andrew Bresticker <abrestic@...omium.org>,
	<linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [RFC PATCH] dt: Tegra XUSB padctl: per-lane PHYs and USB lane map

Hi,

On Wednesday 21 October 2015 11:10 PM, Stephen Warren wrote:
> On 10/21/2015 06:15 AM, Thierry Reding wrote:
>> On Mon, Oct 19, 2015 at 05:30:42PM -0600, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@...dia.com>
>>>
>>> Convert the binding to provide a PHY per lane, rather than a PHY per
>>> "pad" block in the hardware. This will allow the driver to easily know
>>> which lanes are used by clients, and thus only enable those lanes, and
>>> generally better aligns with the fact the hardware has configuration per
>>> lane rather than solely configuration per "pad" block.
>>>
>>> Add entries to pinctrl-tegra-xusb.h to enumerate all "pad" blocks on
>>> Tegra210, which will allow an XUSB DT node to reference the PHYs it
>>> needs.
>>>
>>> Add an nvidia,ss-port-map register to allow configuration of the
>>> XUSB_PADCTL_SS_PORT_MAP register.
> 
>> According to Kishon's latest recommendation, the padctl binding should
>> probably look more like this:
>>
>>     padctl@0,7009f000 {
>>         ...
>>
>>         phys {
>>             pcie {
>>                 /* 5 subnodes on Tegra124, 7 on Tegra210 */
>>                 pcie-0 {
>>                     ...
>>                 };
>>
>>                 ...
>>             };
> 
> I noticed that he mentioned a separate node per PHY brick or PHY.
> 
> That seems like an odd requirement, or even recommendation, since the
> PHY bindings, like (almost?) all other DT provider/consumer bindings,
> use a phandle+specifier to indicate which resource is being provided. As

A lot of that was added before PHY core was better able to handle multi
phy PHY provider. Using phandle+specifier makes the driver code do lot
of stuff just to find the PHY which was unnecessary. This can be avoided
just by modeling the dt node properly and using the correct phandle in
the controller dt node.

> such, there's no absolute need to represent objects as DT nodes,
> although there may be other good arguments for doing so.

yeah, that would be a better representation of the hw and avoid lot of
useless stuff in the driver.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/