Message-ID: <a6c79128dca5b99951e95527bd2b51a4ae7b42fd.camel@mediatek.com>
Date: Thu, 13 Jun 2024 10:28:00 +0000
From: SkyLake Huang (黃啟澤)
	<SkyLake.Huang@...iatek.com>
To: "daniel@...rotopia.org" <daniel@...rotopia.org>
CC: "andrew@...n.ch" <andrew@...n.ch>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux@...linux.org.uk"
	<linux@...linux.org.uk>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"dqfext@...il.com" <dqfext@...il.com>,
	Steven Liu (劉人豪) <steven.liu@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "davem@...emloft.net"
	<davem@...emloft.net>, "hkallweit1@...il.com" <hkallweit1@...il.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH net-next v6 5/5] net: phy: add driver for built-in 2.5G
 ethernet PHY on MT7988

On Tue, 2024-06-04 at 14:50 +0100, Daniel Golle wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Tue, Jun 04, 2024 at 08:42:57AM +0000, SkyLake Huang (黃啟澤) wrote:
> > On Mon, 2024-06-03 at 19:30 +0100, Russell King (Oracle) wrote:
> > >   
> > > External email : Please do not click links or open attachments
> until
> > > you have verified the sender or the content.
> > >  On Mon, Jun 03, 2024 at 06:00:49PM +0100, Daniel Golle wrote:
> > > > On Mon, Jun 03, 2024 at 04:47:28PM +0100, Russell King (Oracle)
> > > wrote:
> > > > > On Mon, Jun 03, 2024 at 03:52:19PM +0100, Daniel Golle wrote:
> > > > > > On Mon, Jun 03, 2024 at 02:41:44PM +0100, Russell King
> (Oracle)
> > > wrote:
> > > > > > > On Mon, Jun 03, 2024 at 02:31:46PM +0100, Daniel Golle
> wrote:
> > > > > > > > On Mon, Jun 03, 2024 at 02:25:01PM +0100, Russell King
> > > (Oracle) wrote:
> > > > > > > > > On Mon, Jun 03, 2024 at 08:18:34PM +0800, Sky Huang
> > > wrote:
> > > > > > > > > > Add support for internal 2.5Gphy on MT7988. This
> driver
> > > will load
> > > > > > > > > > necessary firmware, add appropriate time delay and
> > > figure out LED.
> > > > > > > > > > Also, certain control registers will be set to fix
> > > link-up issues.
> > > > > > > > > 
> > > > > > > > > Based on our previous discussion, it may be worth
> > > checking in the
> > > > > > > > > .config_init() method whether phydev->interface is
> one of
> > > the
> > > > > > > > > PHY interface modes that this PHY supports. As I
> > > understand from one
> > > > > > > > > of your previous emails, the possibilities are XGMII,
> > > USXGMII or
> > > > > > > > > INTERNAL. Thus:
> > > > > > > > > 
> > > > > > > > > > +static int mt798x_2p5ge_phy_config_init(struct
> > > phy_device *phydev)
> > > > > > > > > > +{
> > > > > > > > > > +struct pinctrl *pinctrl;
> > > > > > > > > > +int ret;
> > > > > > > > > 
> > > > > > > > > /* Check that the PHY interface type is compatible */
> > > > > > > > > if (phydev->interface != PHY_INTERFACE_MODE_INTERNAL
> &&
> > > > > > > > >     phydev->interface != PHY_INTERFACE_MODE_XGMII &&
> > > > > > > > >     phydev->interface != PHY_INTERFACE_MODE_USXGMII)
> > > > > > > > > return -ENODEV;
> > > > > > > > 
> > > > > > > > The PHY is built-into the SoC, and as such the
> connection
> > > type should
> > > > > > > > always be "internal". The PHY does not exist as
> dedicated
> > > IC, only
> > > > > > > > as built-in part of the MT7988 SoC.
> > > > > > > 
> > > > > > > That's not how it was described to me by Sky.
> > > > > > > 
> > > > > > > If what you say is correct, then the implementation of
> > > > > > > mt798x_2p5ge_phy_get_rate_matching() which checks for
> > > interface modes
> > > > > > > other than INTERNAL is not correct. Also it means that
> > > config_init()
> > > > > > > should not permit anything but INTERNAL.
> > > > > > 
> > > > > > The way the PHY is connected to the MAC *inside the chip*
> is
> > > XGMII
> > > > > > according the MediaTek. So call it "internal" or "xgmii",
> > > however, up to
> > > > > > my knowledge it's a fact that there is **only one way**
> this
> > > PHY is
> > > > > > connected and used, and that is being an internal part of
> the
> > > MT7988 SoC.
> > > > > > 
> > > > > > Imho, as there are no actual XGMII signals exposed anywhere
> I'd
> > > use
> > > > > > "internal" to describe the link between MAC and PHY (which
> are
> > > both
> > > > > > inside the same chip package).
> > > > > 
> > > > > I don't care what gets decided about what's acceptable for
> the
> > > PHY to
> > > > > accept, just that it checks for the acceptable modes in
> > > .config_init()
> > > > > and the .get_rate_matching() method is not checking for
> interface
> > > > > modes that are not permitted.
> > > > 
> > > > What I meant to express is that there is no need for such a
> check,
> > > also
> > > > not in config_init. There is only one way and one MAC-side
> > > interface mode
> > > > to operate that PHY, so the value will anyway not be considered
> > > anywhere
> > > > in the driver.
> > > 
> > > No, it matters. With drivers using phylink, the PHY interface
> mode is
> > > used in certain circumstances to constrain what the net device
> can
> > > do.
> > > So, it makes sense for new PHY drivers to ensure that the PHY
> > > interface
> > > mode is one that they can support, rather than just accepting
> > > whatever
> > > is passed to them (which then can lead to maintainability issues
> for
> > > subsystems.)
> > > 
> > > So, excuse me for disagreeing with you, but I do want to see such
> a
> > > check in new PHY drivers.
> > > 
> > > -- 
> > > RMK's Patch system: 
> https://www.armlinux.org.uk/developer/patches/
> > > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> > 
> > Hi Russell/Daniel,
> >   IMO, we can check PHY_INTERFACE_MODE_INTERNAL &
> > PHY_INTERFACE_MODE_XGMII in config_init() or probe(). However,
> > PHY_INTERFACE_MODE_USXGMII isn't supported by this phy, and
> > drivers/net/ethernet/mediatek/mtk_eth_path.c uses
> > PHY_INTERFACE_MODE_USXGMII to switch netsys pcs mux (set
> > MUX_G2_USXGMII_SEL bit in TOP_MISC_NETSYS_PCS_MUX) so that XFI-MAC
> can
> > be connected to external 10Gphy.
> >   So, basically, for 1st XFI-MAC on mt7988:
> > - PHY_INTERFACE_MODE_XGMII/PHY_INTERFACE_MODE_INTERNAL: built-in
> > 2.5Gphy
> 
> Why both? Wouldn't just PHY_INTERFACE_MODE_INTERNAL be more clear?
> There is no XGMII interface exposed anywhere and both "internal" and
> "xgmii" would be used to express the exact same thing.
> 
Since I found out that there's phy-mode="gmii" in mt7981-rfb.dts on
openWRT, I thought maybe we need gmii&internal for mt7981's built-in
GbE and xgmii&internal for mt7988's built-in 2.5GbE.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7981-rfb.dts;h=b2bb6929562ebd58550477cdbf8838d8bb38d489;hb=refs/heads/main

However, that seems like a forgotten left-over as you mentioned.
So I'll follow your recommendation and remove XGMII check in v7 so that
mtk-ge-soc.c & mtk-2p5ge.c follow the same logic since these two
drivers are both for built-in ethernet phy.

Sky
> > - PHY_INTERFACE_MODE_USXGMII: external 10Gphy
> > 
> >   I add check in config_init():
> > /* Check if PHY interface type is compatible */
> > if (phydev->interface != PHY_INTERFACE_MODE_XGMII &&
> >     phydev->interface != PHY_INTERFACE_MODE_INTERNAL)
> > return -ENODEV;
> > 
> >   Also, test with different phy mode in dts:
> > [PHY_INTERFACE_MODE_USXGMII]
> > [   18.702102] mtk_soc_eth 15100000.ethernet eth1: mtk_open: could
> not
> > attach PHY: -19
> > root@...nWrt:/# cat /proc/device-tree/soc/ethernet@...00000/mac@1/p
> hy-c
> > onnection-type
> > usxgmii
> > 
> > [PHY_INTERFACE_MODE_INTERNAL]
> > [   18.329513] mtk_soc_eth 15100000.ethernet eth1: PHY [mdio-
> bus:0f]
> > driver [MediaTek MT7988 2.5GbE PHY] (irq=POLL)
> > [   18.339708] mtk_soc_eth 15100000.ethernet eth1: configuring for
> > phy/internal link mode
> > root@...nWrt:/# cat /proc/device-tree/soc/ethernet@...00000
> > /mac@...hy-connection-type
> > internal
> > 
> > Sky

Powered by blists - more mailing lists