netdev - Re: Fixed PHY Device Tree usage?

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: <CAGVrzcasmv6KvEN+okkcQA9CHjCtuRqcd=AvKLiFbPXiyS-P=w@mail.gmail.com>
Date:	Wed, 10 Jul 2013 18:23:30 +0100
From:	Florian Fainelli <florian@...nwrt.org>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	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>,
	"grant.likely" <grant.likely@...retlab.ca>, afleming@...escale.com
Subject: Re: Fixed PHY Device Tree usage?

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.

>
> So that's really what I was asking: how is the fixed PHY driver going
> to know which DT nodes to look at. Is it a platform_driver, where the
> corresponding DT node has sub-nodes? Is it something else? Or a
> specific compatible string?

Without DT at play here, the usual way to register a fixed PHY is:

1) make your arch code or whatever runs before the fixed MDIO bus
probing to call fixed_phy_add() with the expected parameters
2) when your ethernet driver probes its PHY devices, format the phy
name to be bound to the fixed bus with the expected address by then
the fixed MDIO bus would have already been probed and would find the
fixed PHY nodes because of the first step
3) call of_phy_connect() from your driver to attach to the fixed PHY

>
>> What do you think? I suspect someone might rightfully say that the
>> "fixed-mdio" is not a real piece of hardware and is just a software
>> concept. A PHY in the real world may very well have a fixed link
>> speed/duplex/pause settings on the other end.
>
> I agree that the mdio-fixed idea is clearly moving away from the
> hardware representation. But see my question above: we need a way of
> letting the fixed PHY driver know which DT nodes it should have a look
> at. And just saying "those nodes will have property 'foo' is not
> sufficient".
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com



--
Florian
--
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