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: <5421A28E.7060600@gmail.com>
Date:	Tue, 23 Sep 2014 18:40:46 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Arnd Bergmann <arnd@...db.de>, linux-arm-kernel@...ts.infradead.org
CC:	thomas.petazzoni@...e-electrons.com, zmxu@...vell.com,
	devicetree@...r.kernel.org, netdev@...r.kernel.org,
	Antoine Tenart <antoine.tenart@...e-electrons.com>,
	linux-kernel@...r.kernel.org, alexandre.belloni@...e-electrons.com,
	jszhang@...vell.com
Subject: Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell
 PXA168 Ethernet controller

On 09/23/2014 06:29 PM, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
>> For reference, this is what we have for MVEBU SoCs with multiple ports
>> per controller:
>>
>> eth: ethernet-ctrl@...00 {
>>          compatible = "marvell,orion-eth";
...
>>          reg = <0x72000 0x4000>;
...
>>
>>          ethernet-port@0 {
>>                  compatible = "marvell,orion-eth-port";
...
>>                  phy-handle = <&ethphy>;
>>          };
>> };
>>
>> mdio: mdio-bus@...04 {
>>          compatible = "marvell,orion-mdio";
...
>>          reg = <0x72004 0x84>;
..
>>          ethphy: ethernet-phy {
>>                  /* set phy address in board file */
>>          };
>> };

> But in this example, you have the same registers and the same
> clocks in two nodes, which are even used by the same device driver
> at the moment. It's not a big issue, but my feeling is that Antoine's
> approach was actually better because it more closely reflects
> the way that the hardware is built.

I was not referring to the separate mdio bus node, but putting the
ethernet-phy node as a child of ethernet-ctrl.

Anyway, I can live with the ethernet-phy being a child of the controller
node until we discover where it is hooked up.

For the internal MII PHY the controller node maybe is the only sane
place to put it in. The HEC PHY will reside within the CEC IP node but
that is compatible with Antoine's proposal.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ