netdev - Re: [PATCH] dt: net: enhance DWC EQoS binding to support Tegra186

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] [day] [month] [year] [list]

Message-ID: <80149ae2-2b4a-9b8a-b261-e37ebdcafb57@wwwdotorg.org>
Date:   Wed, 24 Aug 2016 14:43:29 -0600
From:   Stephen Warren <swarren@...dotorg.org>
To:     Lars Persson <lars.persson@...s.com>
Cc:     Lars Persson <larper@...s.com>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        linux-tegra@...r.kernel.org, Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] dt: net: enhance DWC EQoS binding to support Tegra186

On 08/24/2016 02:10 AM, Lars Persson wrote:
> On 08/23/2016 10:47 PM, Stephen Warren wrote:
>> The Synopsys DWC EQoS is a configurable IP block which supports multiple
>> options for bus type, clocking and reset structure, and feature list.
>> Extend the DT binding to define a "compatible value" for the
>> configuration
>> contained in NVIDIA's Tegra186 SoC, and define some new properties and
>> list property entries required by that configuration.

>> diff --git
>> a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
>> b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt

>>  Optional properties:

>> +- phy-reset-gpios: Phandle and specifier for any GPIO used to reset
>> the PHY.
>> +  See ../gpio/gpio.txt.
>
> IMHO the phy reset gpio belongs in the binding for the PHY. I notice
> some other ethernet drivers have this, but the PHY should be managed
> entirely through the phylib and any special handling for reset can be
> hidden in phy specific drivers.

I can see that argument; this GPIO certainly does control the PHY so 
seems part of it. However, presumably this GPIO must be manipulated 
before being able to communicate with the PHY at all, and hence 
instantiate any driver that might control the PHY. As such, this seems 
more like a property of the MDIO bus than the PHY itself, even if it 
electrically is part of the PHY. Also, 
Documentation/devicetree/bindings/net/phy.txt doesn't contain any 
phy-reset-gpios property or similar, so we'd have to add that if we 
wanted to rely upon it.

For now I'll post V2 without changing this, but I can always post V3 if 
needed.