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:	Fri, 12 Jul 2013 23:44:21 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Florian Fainelli <florian@...nwrt.org>
Cc:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	netdev <netdev@...r.kernel.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Gregory Clément 
	<gregory.clement@...e-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	Lior Amsalem <alior@...vell.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	Andy Fleming <afleming@...escale.com>
Subject: Re: Fixed PHY Device Tree usage?

On Wed, Jul 10, 2013 at 6:23 PM, Florian Fainelli <florian@...nwrt.org> wrote:
> Hello Thomas,
>
> 2013/7/10 Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>:
>> Dear Florian Fainelli,
>>
>> On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:
> [snip]
>
>>
>>> >                 };
>>> >
>>> >                 phy1: ethernet-phy@1 {
>>> >                         ... all the properties you listed ...
>>> >                         ... maybe the "id" property is not needed
>>> >                             because of the phandle ...
>>> >                 };
>>> >         };
>>> >
>>> >         soc {
>>> >                 ethernet@0 {
>>> >                         phy = <&phy0>;
>>> >                         ...
>>> >                 };
>>> >
>>> >                 ethernet@1 {
>>> >                         phy = <&phy1>;
>>> >                         ...
>>> >                 };
>>> >         };
>>> >
>>> > or do you have in mind another representation?
>>>
>>> Not really this is more or less what I had in mind. I am wondering
>>> whether we should really declare the "mdio-fixed" node, or if we
>>> should not rather make the following:
>>>
>>> - declare all PHY nodes in the system as sub nodes of their belonging
>>> real hardware MDIO bus node
>>> - flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
>>> - if we see that flag, make that specific PHY node bind to the
>>> fixed-phy driver instead
>>
>> So the fixed PHY driver is going to travel through *all* nodes of the
>> DT, and whenever some random node has a "fixed" property, it's going to
>> say it corresponds to a fixed PHY? That doesn't seem like a good idea.
>
> Why not? Since we are already have to scan the entire MDIO bus we are
> attached to, when we encounter such a PHY node with the special
> "fixed" properties, we just call fixed_phy_add() with the right
> parameters and voila. Which is also the reason why I was suggesting to
> put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that
> we have this logic only in one place.

Hi Florian,

I think this discussion is going in the wrong direction. The concept
of a dummy phy is really a Linux kernel internal detail. Creating some
kind of dummy MDIO bus node does not describe the hardware. There is
already support in the kernel for Ethernet MACs connected directly to
a switch or other device. It is far better to describe how the MAC
needs to be configured than to invent a non-existent phy. Search for
"fixed-link" in the kernel tree to see how it is used.

g.
--
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