linux-kernel - Re: [PATCH net-next] net: dsa: bcm_sf2: Ensure that MDIO diversion is used

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] [day] [month] [year] [list]

Date:   Fri, 4 Sep 2020 15:35:26 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: dsa: bcm_sf2: Ensure that MDIO diversion
 is used

On Thu, Sep 03, 2020 at 09:00:13PM -0700, Florian Fainelli wrote:
> 
> 
> On 9/3/2020 3:03 PM, Andrew Lunn wrote:
> > > The firmware provides the Device Tree but here is the relevant section for
> > > you pasted below. The problematic device is a particular revision of the
> > > silicon (D0) which got later fixed (E0) however the Device Tree was created
> > > after the fixed platform, not the problematic one. Both revisions of the
> > > silicon are in production.
> > > 
> > > There should have been an internal MDIO bus created for that chip revision
> > > such that we could have correctly parented phy@0 (bcm53125 below) as child
> > > node of the internal MDIO bus, but you have to realize that this was done
> > > back in 2014 when DSA was barely revived as an active subsystem. The
> > > BCM53125 node should have have been converted to an actual switch node at
> > > some point, I use a mdio_boardinfo overlay downstream to support the switch
> > > as a proper b53/DSA switch, anyway.
> > 
> > I was expecting something like that. I think this patch needs a
> > comment in the code explaining it is a workaround for a DT blob which
> > cannot be changed. Maybe also make it conditional on the board
> > compatible string?
> 
> It is already targeted at the Broadcom pseudo PHY address (30) which is the
> one that needs diversion, I will update the patch description accordingly
> though.

O.K, looking at the patch, it was not clear to me it was already
restricted. 

	    Andrew