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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 21 Jan 2014 12:05:25 -0800
From:	Florian Fainelli <>
To:	Rob Herring <>
Cc:	Sergei Shtylyov <>,
	netdev <>,
	Rob Herring <>,
	Pawel Moll <>,
	Mark Rutland <>,
	Ian Campbell <>,
	Kumar Gala <>,
	"" <>,
	Rob Landley <>,
	"" <>,
	Grant Likely <>
Subject: Re: [PATCH] DT: net: document Ethernet bindings in one place

2014/1/21 Florian Fainelli <>:
>>>    I'm afraid that's too late, it has spread very far, so that
>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>> Uggg, I guess this is a case of a defacto standard then if the kernel
>> doesn't even support it.
> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
> while ago for of_get_phy_mode() to look for both "phy-mode" and
> "phy-connection-type" since the former has been a Linux invention, but
> the latter is ePAPR specified.

Here is a link to the actual patch in question, not sure which tree
Grant applied it to though:

>>>>> +- phy-connection-type: the same as "phy-mode" property (but described in
>>>>> ePAPR);
>>>>> +- phy-handle: phandle, specifies a reference to a node representing a
>>>>> PHY
>>>>> +  device (this property is described in ePAPR);
>>>>> +- phy: the same as "phy-handle" property (but actually ad-hoc one).
>>>> Mark this as deprecated in favor of phy-handle.
>>>    Here situation is more optimistic. Quite many drivers still use
>>> "phy-handle", though some use even more exotic props I didn't document here.
>> Perhaps flagging as "Not recommended for new bindings" would be nicer wording...
> Ok, so what's the deal here, can't we use phy-handle? There is
> currently no infrastructure in drivers/net/ or drivers/of/ to look for
> the "phy-handle" nor "phy" properties as phandles to fetch an Ethernet
> PHY device tree node. If we are to provide one common place where we
> want to do this, we will have to look for both properties, why can't
> we mandate the use of "phy-handle" since this is the ePAPR compliant
> one?
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to
>> More majordomo info at
> --
> Florian

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists