linux-kernel - Re: [PATCH net-next v2 1/2] net: enetc: Initialize SerDes for SGMII and SXGMII protocols

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: <20200527003320.GC782807@lunn.ch>
Date:   Wed, 27 May 2020 02:33:20 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Vladimir Oltean <olteanv@...il.com>,
        Alex Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>
Subject: Re: [PATCH net-next v2 1/2] net: enetc: Initialize SerDes for SGMII
 and SXGMII protocols

On Wed, May 27, 2020 at 12:50:49AM +0200, Michael Walle wrote:
> From: Claudiu Manoil <claudiu.manoil@....com>
> 
> ENETC has ethernet MACs capable of SGMII and SXGMII but in order to use
> these protocols some serdes configurations need to be performed. The
> SerDes is configurable via an internal MDIO bus connected to an internal
> PCS device, all reads/writes are performed at address 0.
> 
> This patch basically removes the dependency on bootloader regarding
> SerDes initialization.
> 
> Signed-off-by: Alex Marginean <alexandru.marginean@....com>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@....com>
> Signed-off-by: Michael Walle <michael@...le.cc>
> ---
>  .../net/ethernet/freescale/enetc/enetc_hw.h   | 17 ++++
>  .../net/ethernet/freescale/enetc/enetc_pf.c   | 98 +++++++++++++++++++
>  .../net/ethernet/freescale/enetc/enetc_pf.h   |  1 +
>  3 files changed, 116 insertions(+)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> index 6314051bc6c1..ee5851486388 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> @@ -224,6 +224,23 @@ enum enetc_bdr_type {TX, RX};
>  #define ENETC_PM0_MAXFRM	0x8014
>  #define ENETC_SET_TX_MTU(val)	((val) << 16)
>  #define ENETC_SET_MAXFRM(val)	((val) & 0xffff)
> +
> +#define ENETC_PM_IMDIO_BASE	0x8030
> +/* PCS registers */
> +#define ENETC_PCS_CR			0x0
> +#define ENETC_PCS_CR_RESET_AN		0x1200
> +#define ENETC_PCS_CR_DEF_VAL		0x0140
> +#define ENETC_PCS_CR_LANE_RESET		0x8000

Hi Michael

This looks like a standard BMCR. I know Russell King has pushed for
just using MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART, BMCR_FULLDPLX |
BMCR_SPEED1000, etc, since people understand what they mean.

> +#define ENETC_PCS_DEV_ABILITY		0x04
> +#define ENETC_PCS_DEV_ABILITY_SGMII	0x4001
> +#define ENETC_PCS_DEV_ABILITY_SXGMII	0x5001
> +#define ENETC_PCS_LINK_TIMER1		0x12
> +#define ENETC_PCS_LINK_TIMER1_VAL	0x06a0
> +#define ENETC_PCS_LINK_TIMER2		0x13
> +#define ENETC_PCS_LINK_TIMER2_VAL	0x0003
> +#define ENETC_PCS_IF_MODE		0x14
> +#define ENETC_PCS_IF_MODE_SGMII_AN	0x0003

It would be nice to document what these individual bits mean.

   Andrew