netdev - Re: [PATCH net 2/2] net: phylink: use USXGMII control-word format to parse Q-USGMII word

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]

Message-ID: <20230609100912.70a2bbc1@pc-7.home>
Date: Fri, 9 Jun 2023 10:09:12 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com, Andrew Lunn
 <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit
 <hkallweit1@...il.com>, linux-arm-kernel@...ts.infradead.org,
 Horatiu.Vultur@...rochip.com, Allan.Nielsen@...rochip.com,
 UNGLinuxDriver@...rochip.com, Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net 2/2] net: phylink: use USXGMII control-word format
 to parse Q-USGMII word

Hi Russell,

On Thu, 8 Jun 2023 18:30:41 +0100
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> On Thu, Jun 08, 2023 at 07:53:30PM +0200, Maxime Chevallier wrote:
> > Hi Russell,
> > 
> > On Thu, 8 Jun 2023 17:32:52 +0100
> > "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> >   
> > > On Thu, Jun 08, 2023 at 06:34:15PM +0200, Maxime Chevallier wrote:  
> > > > diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
> > > > index 256b463e47a6..1d20a9082507 100644
> > > > --- a/include/uapi/linux/mdio.h
> > > > +++ b/include/uapi/linux/mdio.h
> > > > @@ -444,4 +444,7 @@ static inline __u16 mdio_phy_id_c45(int prtad, int devad)
> > > >  #define MDIO_USXGMII_5000FULL		0x1a00	/* 5000Mbps full-duplex */
> > > >  #define MDIO_USXGMII_LINK		0x8000	/* PHY link with copper-side partner */
> > > >  
> > > > +/* Usgmii control word is based on Usxgmii, masking away 2.5, 5 and 10Gbps */
> > > > +#define MDIO_USGMII_SPD_MASK		0x0600    
> > > 
> > > This isn't correct:
> > > 
> > > 11:9	Speed: Bit 11, 10, 9:
> > > 	1 1 1 to 011 = Reserved
> > > 	0 1 0 = 1000 Mbps: 1000BASE-TX, 1000BASE-X
> > > 	0 0 1 = 100 Mbps: 100BASE-TX, 100BASE-FX
> > > 	0 0 0 = 10 Mbps: 10BASET, 10BASE2, 10BASE5
> > > 
> > > If we only look at bits 10 and 9, then we're interpreting the reserved
> > > combinations as valid as well.  
> > 
> > That's why I rewrote the decoding helper instead of simply masking away
> > the extra bit, so that we exclude the 0 1 1 combination ( 10G speed ).  
> 
> I don't think you've understood my comment properly. Here is what
> the code is doing:

Indeed :( thanks for the clarifications.

> +#define MDIO_USGMII_SPD_MASK             0x0600
> +       switch (lpa & MDIO_USGMII_SPD_MASK) {
> #define MDIO_USXGMII_10                 0x0000  /* 10Mbps */
> +       case MDIO_USXGMII_10:
> +               state->speed = SPEED_10;
> +               break;
> #define MDIO_USXGMII_100                0x0200  /* 100Mbps */
> +       case MDIO_USXGMII_100:
> +               state->speed = SPEED_100;
> +               break;
> #define MDIO_USXGMII_1000               0x0400  /* 1000Mbps */
> +       case MDIO_USXGMII_1000:
> +               state->speed = SPEED_1000;
> +               break;
> +       default:
> +               state->link = false;
> +               return;
> +       }
> 
> So, this will decode bits 11:9 as:
> 
> 000	10Mbps
> 001	100Mbps
> 010	1000Mgps
> 011	link = false
> 100	10Mbps
> 101	100Mbps
> 110	1000Mbps
> 111	link = false
> 
> Whereas, USGMII says the last four are all reserved. Why does this
> happen? Because the mask is defined as:
> 
> +#define MDIO_USGMII_SPD_MASK             0x0600
> 
> which only covers bits 10 and 9, masking off bit 11. However, bit 11
> is _still_ part of the field, and if it's set, then it is a "reserved"
> speed. We should not be just ignoring bit 11.
> 
> I hope that helps to clarify.
> 
 Indeed, thanks... I'll respin with a proper implementation this time.

Thanks for spotting this

Maxime