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: <CAGVrzcbt302tTM3pprnhJz7YykUzcW=XSMCr_W=m1zWiVBX8kw@mail.gmail.com>
Date:	Wed, 10 Jul 2013 17:29:44 +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@...retlab.ca,
	afleming@...escale.com
Subject: Re: Fixed PHY Device Tree usage?

Hello Thomas,

2013/7/10 Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>:

[snip]

>> >
>> > It has the same properties as the binding described in:
>> > Documentation/devicetree/bindings/net/fsl-tsec-phy.txt but expressed in a
>> > more explicit way instead of using an array of integers.
>
> And so the fixed-phy driver would look for what exactly in the Device
> Tree to find which fixed PHYs to create?
>
> Should we have something like:
>
>         mdio-fixed {
>                 compatible = "generic,mdio-fixed";
>                 phy0: ethernet-phy@0 {
>                         ... all the properties you listed ...
>                         ... maybe the "id" property is not needed
>                             because of the phandle ...

In the "fixed-phy" terminology "id" is unfortunately ambiguous, the
driver internally uses "phy_id" which is nothing more than a PHY
address, but it also supports being assigned an "id" as in
Identification register 2 & 3. I was refering to the identification
register by "id".

>                 };
>
>                 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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ