From: Andrew Lunn <andrew@lunn.ch>
To: Sky Huang <SkyLake.Huang@mediatek.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Daniel Golle <daniel@makrotopia.org>,
Qingfang Deng <dqfext@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Steven Liu <Steven.Liu@mediatek.com>
Subject: Re: [PATCH 3/3] net: phy: mediatek: add support for built-in 2.5G ethernet PHY on MT7988
Date: Thu, 25 Apr 2024 17:37:42 +0200 [thread overview]
Message-ID: <9241a551-1547-41c6-aae2-54dd45e49c2f@lunn.ch> (raw)
In-Reply-To: <20240425023325.15586-4-SkyLake.Huang@mediatek.com>
> +static int mt7988_2p5ge_phy_config_init(struct phy_device *phydev)
> +{
> + int ret, i;
> + const struct firmware *fw;
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *np;
> + void __iomem *pmb_addr;
> + void __iomem *md32_en_cfg_base;
> + struct mtk_i2p5ge_phy_priv *priv = phydev->priv;
> + u16 reg;
> + struct pinctrl *pinctrl;
Reverse Christmas Tree please.
> +static int mt7988_2p5ge_phy_config_aneg(struct phy_device *phydev)
> +{
> + bool changed = false;
> + u32 adv;
> + int ret;
> +
> + if (phydev->autoneg == AUTONEG_DISABLE) {
> + /* Configure half duplex with genphy_setup_forced,
> + * because genphy_c45_pma_setup_forced does not support.
> + */
The English in that comment is wrong.
Ah, it appears to be a copy/paste, e.g. from mxl-gpy.c. In fact, a lot
of this function is identical to gpy_config_aneg(). Maybe it should be
pulled out into a helper.
> +static int mt7988_2p5ge_phy_get_features(struct phy_device *phydev)
> +{
> + int ret;
> +
> + ret = genphy_read_abilities(phydev);
> + if (ret)
> + return ret;
> +
> + /* We don't support HDX at MAC layer on mt7988.
> + * So mask phy's HDX capabilities, too.
> + */
This comment seems to contradict the comment above?
Also, this code does not mask anything, it sets bits. What does
genphy_read_abilities() find out about the device? If the hardware
confirms to the standard, it should not indicate is supports 1/2
duplex, genphy_read_abilities() should then not return those link
modes, but it should return 10, 100 and 1000 full duplex.
> + linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT,
> + phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> + phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> + phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> + phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, phydev->supported);
What does genphy_c45_pma_read_abilities() report about the device?
> +static int mt7988_2p5ge_phy_read_status(struct phy_device *phydev)
> +{
> + int ret;
> +
> + ret = genphy_update_link(phydev);
> + if (ret)
> + return ret;
> +
> + phydev->speed = SPEED_UNKNOWN;
> + phydev->duplex = DUPLEX_UNKNOWN;
> + phydev->pause = 0;
> + phydev->asym_pause = 0;
> +
> + if (phydev->autoneg == AUTONEG_ENABLE) {
> + if (phydev->autoneg_complete) {
> + ret = genphy_c45_read_lpa(phydev);
> + if (ret < 0)
> + return ret;
> +
> + /* Read the link partner's 1G advertisement */
> + ret = phy_read(phydev, MII_STAT1000);
> + if (ret < 0)
> + return ret;
> + mii_stat1000_mod_linkmode_lpa_t(phydev->lp_advertising, ret);
> + } else if (!linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> + phydev->advertising) &&
> + linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> + phydev->advertising)) {
> + extend_an_new_lp_cnt_limit(phydev);
> + }
A comment about what is happening here would be good.
> + } else if (phydev->autoneg == AUTONEG_DISABLE) {
> + linkmode_zero(phydev->lp_advertising);
> + }
This if does not make much sense.
> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, MTK_PHY_LINK_STATUS_MISC);
> + if (ret < 0)
> + return ret;
> + phydev->duplex = (ret & MTK_PHY_FDX_ENABLE) ? DUPLEX_FULL : DUPLEX_HALF;
Do does it support half duplex or not?
Andrew
next prev parent reply other threads:[~2024-04-25 15:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 2:33 [PATCH 0/3] net: phy: mediatek: Integrate mtk-phy-lib and add 2.5Gphy support Sky Huang
2024-04-25 2:33 ` [PATCH 1/3] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers Sky Huang
2024-04-25 15:04 ` Andrew Lunn
2024-04-26 2:27 ` kernel test robot
2024-04-25 2:33 ` [PATCH 2/3] net: phy: mediatek: Add mtk phy lib for token ring access & LED/other manipulations Sky Huang
2024-04-25 15:13 ` Andrew Lunn
2024-04-25 18:05 ` kernel test robot
2024-05-07 14:40 ` Daniel Golle
2024-05-08 12:25 ` Andrew Lunn
2024-05-08 13:09 ` Russell King (Oracle)
2024-05-08 14:02 ` Daniel Golle
2024-04-25 2:33 ` [PATCH 3/3] net: phy: mediatek: add support for built-in 2.5G ethernet PHY on MT7988 Sky Huang
2024-04-25 9:01 ` Russell King (Oracle)
2024-05-08 10:56 ` SkyLake Huang (黃啟澤)
2024-05-08 12:30 ` Andrew Lunn
2024-05-08 16:21 ` Daniel Golle
2024-04-25 15:37 ` Andrew Lunn [this message]
2024-04-25 3:05 ` [PATCH 0/3] net: phy: mediatek: Integrate mtk-phy-lib and add 2.5Gphy support Daniel Golle
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=9241a551-1547-41c6-aae2-54dd45e49c2f@lunn.ch \
--to=andrew@lunn.ch \
--cc=SkyLake.Huang@mediatek.com \
--cc=Steven.Liu@mediatek.com \
--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 \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).