linux-kernel - Re: [PATCH v1 net] net: ethernet: mscc: ocelot: bug fix when writing MAC speed

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210916113713.eaquhezzoxheqkxg@skbuf>
Date:   Thu, 16 Sep 2021 11:37:14 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Colin Foster <colin.foster@...advantage.com>
CC:     Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 net] net: ethernet: mscc: ocelot: bug fix when writing
 MAC speed

On Wed, Sep 15, 2021 at 05:29:57PM -0700, Colin Foster wrote:
> On Wed, Sep 15, 2021 at 12:25:52PM +0000, Vladimir Oltean wrote:
> > On Tue, Sep 14, 2021 at 11:21:02PM -0700, Colin Foster wrote:
> > > Converting the ocelot driver to use phylink, commit e6e12df625f2, uses mac_speed
> > > in ocelot_phylink_mac_link_up instead of the local variable speed. Stale
> > > references to the old variable were missed, and so were always performing
> > > invalid second writes to the DEV_CLOCK_CFG and ANA_PFC_CFG registers.
> > > 
> > > Signed-off-by: Colin Foster <colin.foster@...advantage.com>
> > > ---
> > >  drivers/net/ethernet/mscc/ocelot.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
> > > index c581b955efb3..91a31523be8f 100644
> > > --- a/drivers/net/ethernet/mscc/ocelot.c
> > > +++ b/drivers/net/ethernet/mscc/ocelot.c
> > > @@ -566,11 +566,11 @@ void ocelot_phylink_mac_link_up(struct ocelot *ocelot, int port,
> > >  	/* Take MAC, Port, Phy (intern) and PCS (SGMII/Serdes) clock out of
> > >  	 * reset
> > >  	 */
> > > -	ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(speed),
> > > +	ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed),
> > >  			   DEV_CLOCK_CFG);
> > 
> > Oh wow, I don't know how this piece did not get deleted. We write twice
> > to DEV_CLOCK_CFG, once with a good value and once with a bad value.
> > Please delete the second write entirely.
> 
> It seemed odd to me at first, but I looked into the datasheet and saw
> that multiple writes to the DEV_CLOCK_CFG register in section 5.2.1
> https://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10491.pdf
> 
> 11. Set up the switch port to the new mode of operation. Keep the reset bits in CLOCK_CFG set.
> 12. Release the switch port from reset by clearing the reset bits in CLOCK_CFG.
> 
> From that it seems like maybe the routine must be two-fold. First a
> write to set up the link speed with:
> ocelot_port_rmwl(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed), 
>                  DEV_CLOCK_CFG_LINK_SPEED_M, DEV_CLK_CFG);
> ocelot_port_writel(ocelot_port, DEV_CLOCK_CFG_LINK_SPEED(mac_speed),
>                    DEV_CLK_CFG);

Yes, that cycle is supposed to be completed by ocelot_phylink_mac_link_down
which does put the port in reset, and ocelot_phylink_mac_link_up puts it
back out of it. The third write to DEV_CLOCK_CFG is simply nonsensical.

> Of note: I'm currently only using the VSC7512 ports 0-3, which don't
> have a PCS and therefore don't have the PCS_RATE_ADAPTATION requirement.

Observation: as long as Alex's original code is correct, then the
PCS_RATE_ADAPTATION quirk is only needed for an _NXP_ PCS. The VSC7514
family uses a Microchip PCS1G block and the code unconditionally changes
the DEV_CLOCK_CFG_LINK_SPEED, so if this is correct, it means that
different PCS blocks have different requirements.