[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230203150014.ugkasp4rq5arqs6s@skbuf>
Date: Fri, 3 Feb 2023 17:00:14 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Daniel Golle <daniel@...rotopia.org>, netdev@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Russell King <linux@...linux.org.uk>,
Heiner Kallweit <hkallweit1@...il.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
John Crispin <john@...ozen.org>, Felix Fietkau <nbd@....name>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Matthias Brugger <matthias.bgg@...il.com>,
DENG Qingfang <dqfext@...il.com>,
Landen Chao <Landen.Chao@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
Paolo Abeni <pabeni@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Jianhui Zhao <zhaojh329@...il.com>,
Bjørn Mork <bjorn@...k.no>
Subject: Re: [PATCH 7/9] net: pcs: add driver for MediaTek SGMII PCS
On Fri, Feb 03, 2023 at 03:14:29PM +0100, Andrew Lunn wrote:
> > index 6e7e6c346a3e..cf65646656e9 100644
> > --- a/drivers/net/pcs/Kconfig
> > +++ b/drivers/net/pcs/Kconfig
> > @@ -18,6 +18,12 @@ config PCS_LYNX
> > This module provides helpers to phylink for managing the Lynx PCS
> > which is part of the Layerscape and QorIQ Ethernet SERDES.
> >
> > +config PCS_MTK
> > + tristate
> > + help
> > + This module provides helpers to phylink for managing the LynxI PCS
> > + which is part of MediaTek's SoC and Ethernet switch ICs.
>
> You should probably have a more specific name, for when MTK produces a
> new PCS which is completely different.
>
> Also, how similar is this LynxI PCS to the Lynx PCS?
Probably not very similar. Here's the Mediatek 32-bit memory map,
translated by me to a 16-bit MDIO memory map:
/* SGMII subsystem config registers */
/* BMCR (low 16) BMSR (high 16) */
#define SGMSYS_PCS_CONTROL_1 0x0 // BMCR at MDIO addr 0x0, BMSR at 0x1, aka standard
#define SGMSYS_PCS_DEVICE_ID 0x4 // PHYSID1 at 0x2, PHYSID2 at 0x3, aka standard
#define SGMSYS_PCS_ADVERTISE 0x8 // MII_ADV at 0x4, MII_LPA at 0x5
#define SGMSYS_PCS_SCRATCH 0x14 // MDIO address 0xa
/* Register to programmable link timer, the unit in 2 * 8ns */
#define SGMSYS_PCS_LINK_TIMER 0x18 // MDIO address 0xc
/* Register to control remote fault */
#define SGMSYS_SGMII_MODE 0x20 // MDIO address 0x10
/* Register to reset SGMII design */
#define SGMII_RESERVED_0 0x34 // MDIO address 0x1a
/* Register to set SGMII speed, ANA RG_ Control Signals III */
#define SGMSYS_ANA_RG_CS3 0x2028 // not sure how to access this through C22, OTOH not used?
/* Register to power up QPHY */
#define SGMSYS_QPHY_PWR_STATE_CTRL 0xe8 // again, not sure how to access through C22
Compared to these definitions for Lynx, the rest being standard regs:
#define LINK_TIMER_LO 0x12
#define LINK_TIMER_HI 0x13
#define IF_MODE 0x14
So the standard bits appear to be common, the vendor extensions different.
When I say common, I only take into consideration the memory map, not
the differences in handling. For example, what Lynx handles as a single
call to phylink_mii_c22_pcs_get_state(), the Mediatek PCS handles as a
call to mtk_pcs_get_state().
Powered by blists - more mailing lists