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: <940b53a1-3fbe-46c3-29dd-677c11a7cf8e@gmail.com>
Date:   Wed, 27 Mar 2019 01:44:07 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org
Cc:     andrew@...n.ch, vivien.didelot@...il.com, linus.walleij@...aro.org
Subject: Re: [RFC PATCH net-next 13/13] dt-bindings: net: dsa: Add
 documentation for NXP SJA1105 driver

On 3/26/19 4:24 AM, Florian Fainelli wrote:
> 
> 
> On 3/23/2019 8:23 PM, Vladimir Oltean wrote:
>> Signed-off-by: Vladimir Oltean <olteanv@...il.com>
>> ---
>>   .../devicetree/bindings/net/dsa/sja1105.txt   | 123 ++++++++++++++++++
>>   1 file changed, 123 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/net/dsa/sja1105.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt
>> new file mode 100644
>> index 000000000000..2c82b6fc37e3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/dsa/sja1105.txt
>> @@ -0,0 +1,123 @@
>> +NXP SJA1105 switch driver
>> +=========================
>> +
>> +Required properties:
>> +
>> +- compatible: Must be "nxp,sja1105". Device ID identification (one of
>> +  E/T/P/Q/R/S) is performed by driver at probe time. Swapping pin-compatible
>> +  parts is possible with no DTS change.
>> +
>> +Optional properties:
>> +
>> +- sja1105,mac-mode, sja1105,phy-mode: Boolean properties that can be assigned
>> +  under each port node that is MII or RMII (has no effect for RGMII).  By
>> +  default (unless otherwise specified) a port is configured as MAC if it is
>> +  driving a PHY (phy-handle is present) or as PHY if it is PHY-less (fixed-link
>> +  specified, presumably because it is connected to a MAC).  These properties
>> +  are required in the case where SJA1105 ports are at both ends of an MII/RMII
>> +  PHY-less setup. One end would need to have sja1105,mac-mode, while the other
>> +  sja1105,phy-mode.
> 
> Typically we would be using a fixed-link with an appropriate 'phy-mode'
> property to describe a MAC to MAC connection, this may be seen as a
> re-purposing PHY-oriented properties though, so I am fine with that binding:
> 
> Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
> 

Hi Florian,

I don't feel amazing about my solution either, but I don't think I'm 
understanding what you propose. Something like phy-mode = "rmii-mac" or 
"rmii-phy" or "mii-mac" or "mii-phy"?
Would that require an update of the phy_modes() function and strings?
I think the last time when an interface type was split into further 
subdivisions (RGMII with all its internal delay flavors) it didn't go 
too well - with lots of bugs introduced simply because drivers failed to 
grok the newly introduced subtypes as still being RGMII.

Thank you,
-Vladimir

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ