From: "SkyLake Huang (黃啟澤)" <SkyLake.Huang@mediatek.com>
To: "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"daniel@makrotopia.org" <daniel@makrotopia.org>
Cc: "andrew@lunn.ch" <andrew@lunn.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"edumazet@google.com" <edumazet@google.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"dqfext@gmail.com" <dqfext@gmail.com>,
"Steven Liu (劉人豪)" <steven.liu@mediatek.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH net-next v6 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988
Date: Tue, 4 Jun 2024 08:42:57 +0000 [thread overview]
Message-ID: <864a09b213169bc20f33af2f35239c6154ca81e3.camel@mediatek.com> (raw)
In-Reply-To: <Zl4LvKlhty/9o38y@shell.armlinux.org.uk>
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
- 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@OpenWrt:/# cat /proc/device-tree/soc/ethernet@15100000/mac@1/phy-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@OpenWrt:/# cat /proc/device-tree/soc/ethernet@15100000
/mac@1/phy-connection-type
internal
Sky
next prev parent reply other threads:[~2024-06-04 8:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 12:18 [PATCH net-next v6 0/5] net: phy: mediatek: Introduce mtk-phy-lib and add 2.5Gphy support Sky Huang
2024-06-03 12:18 ` [PATCH net-next v6 1/5] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers Sky Huang
2024-06-03 12:18 ` [PATCH net-next v6 2/5] net: phy: mediatek: Move LED and read/write page helper functions into mtk phy lib Sky Huang
2024-06-03 12:18 ` [PATCH net-next v6 3/5] net: phy: mediatek: Add token ring access helper functions in mtk-phy-lib Sky Huang
2024-06-03 12:18 ` [PATCH net-next v6 4/5] net: phy: mediatek: Extend 1G TX/RX link pulse time Sky Huang
2024-06-03 12:18 ` [PATCH net-next v6 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988 Sky Huang
2024-06-03 13:25 ` Russell King (Oracle)
2024-06-03 13:31 ` Daniel Golle
2024-06-03 13:41 ` Russell King (Oracle)
2024-06-03 14:52 ` Daniel Golle
2024-06-03 15:47 ` Russell King (Oracle)
2024-06-03 17:00 ` Daniel Golle
2024-06-03 18:30 ` Russell King (Oracle)
2024-06-04 8:42 ` SkyLake Huang (黃啟澤) [this message]
2024-06-04 13:50 ` Daniel Golle
2024-06-13 10:28 ` SkyLake Huang (黃啟澤)
2024-06-13 13:33 ` Andrew Lunn
2024-06-03 19:40 ` Daniel Golle
2024-06-04 8:57 ` SkyLake Huang (黃啟澤)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=864a09b213169bc20f33af2f35239c6154ca81e3.camel@mediatek.com \
--to=skylake.huang@mediatek.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steven.liu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®