netdev - Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

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: <6de72d4c-5634-f3d6-5bfd-fcc0acda0b83@gmail.com>
Date:   Tue, 11 Apr 2017 16:23:25 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

On 04/11/2017 04:14 PM, Andrew Lunn wrote:
>> To give some more background and rational for this change.
>>
>> On a platform where we have a parent MDIO bus, backed by the
>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through
>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an
>> assignment of of_node. This slave MII bus is created in order to
>> intercept reads/writes to problematic addresses (e.g: that clashes with
>> another piece of hardware).
>>
>> This means that the slave DSA MII bus inherits all child nodes from the
>> originating master MII bus. This also means that when the slave MII bus
>> is probed via of_mdiobus_register(), we probe the same devices twice:
>> once through the master, another time through the slave.
> 
> Ah, O.K. This makes more sense. On the hardware i have, we get three
> deep in MDIO busses. We have the FEC mdio bus. On top of that we have
> a gpio-mux-mdio, and on top of that we have the mv88e6xxx mdio
> bus. And i've never seen issues.
> 
> So your real problem here is you have two mdio busses using the same
> device tree properties. I would actually say that is just plain
> broken.

>From a Device Tree/HW representation perspective, we do have the
external BCM53125 switch physically attached to the 7445/7278
SWITCH_MDIO bus (backed by mdio-bcm-unimac) so in that regard the
representation is correct. There is also an integrated Gigabit PHY
(bcm7xxx) which is attached to that bus.

>From a SW perspective though, we want to talk to the integrated Gigabit
PHY using mdio-bcm-unimac but talk to the external BCM53125 switch using
the slave MII bus created by the bcm_sf2 driver in order to create an
isolation. We need to inherit some of the parent (mdio-bcm-unimac) child
DT nodes (such as the BCM53125), but not the GPHY. The easiest solution
I found was to use this patch.

Using mdiobus_register() instead of of_mdiobus_register() was
considered, but then, the child BCM53125 has no more "visbility" into
the OF world at all, and it matters, because this switch is also driven
via a DSA switch driver and its Ethernet data-path is connected to one
port of the bcm_sf2 switch..

Thankfully the HW bug was fixed eventually ;)
-- 
Florian