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]

Date:	Tue, 26 Jan 2016 13:48:07 -0800
From:	Olof Johansson <olof@...om.net>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	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 Tue, Jan 26, 2016 at 1:36 PM, Andrew Lunn <andrew@...n.ch> wrote:
> On Tue, Jan 26, 2016 at 12:46:31PM -0800, Florian Fainelli wrote:
>> 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.
>
> Nope, not an option. Only a small number of DTB actually use c22 or
> c45. The majority of devices have no compatible at all. Why should
> they, the binding documentation says it is optional!

So one thing that can be done is to just have a whitelist in the
driver that we add the known phy compatibles to, with a nice comment
above that this should only be for legacy device trees. I.e. in
addition to the c22 or c45 strings.

You can even fix up existing trees, and do a pr_warn() for these cases
to ask people to update their DT. There's no strict requirement to do
so though, so the kernel still *has* to work with the old ones.

>> 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...
>
> In kernel, 0. I have one out of kernel, which i hope to contribute
> once we decide on the new binding for DSA.
>
>> 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).
>
> Complex. There are ordering issues, since the driver can be loaded a
> long time after of_mdiobus_register() is called, yet it needs to be
> of_mdiobus_register() which decides if a device is a PHY or not.
>
> I think the bool is the only practical solution.


-Olof