netdev - Re: [BISECTED] v4.5-rc1 phylib regression

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: <56A7DB27.6080203@gmail.com>
Date:	Tue, 26 Jan 2016 12:46:31 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Olof Johansson <olof@...om.net>, Andrew Lunn <andrew@...n.ch>
CC:	Aaro Koskinen <aaro.koskinen@...ia.com>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [BISECTED] v4.5-rc1 phylib regression

On 26/01/16 10:14, Olof Johansson wrote:
> +devicetree@...r.kernel.org instead.
> 
> On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson <olof@...om.net> wrote:
>> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn <andrew@...n.ch> wrote:
>>>> I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
>>>> generic? Will someone writing a DT be thinking "well, this is a
>>>> generic mdio PHY, I should set it"?  "mdio-device"?
>>>> "generic-nonphy-mdio"? Neither of those seem much better.
>>>
>>> How about 'not-a-phy'?
>>
>> "mdio,not-a-phy" or "mdio,non-phy" will scope it a bit, especially if
>> you expect other generic mdio properties that can do with a namespace.

Really not a fan of having to add an additional boolean property to
differentiate an Ethernet PHY from something else, the proper solution
would really be to enforce the use of the c22 or c45 compatible string
as the least compatible string to be used, but I am assuming this is not
necessarily an option here with DTBs out there.

What plays in favor of this boolean property is that the very concept of
MDIO devices has been recently introduced, so presumably, there are not
that many DTBs out there which would be affected...

The only other idea I had was to force the MDIO device creation to be
dependent on finding a matching compatible string provided by a driver
(yikes).
-- 
Florian