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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists