[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <724eff11-c6d1-40e1-a99f-205f5426a07d@lunn.ch>
Date: Wed, 19 Feb 2025 16:47:51 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sky Huang <SkyLake.Huang@...iatek.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Daniel Golle <daniel@...rotopia.org>,
Qingfang Deng <dqfext@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Steven Liu <Steven.Liu@...iatek.com>
Subject: Re: [PATCH net-next v2 3/3] net: phy: mediatek: add driver for
built-in 2.5G ethernet PHY on MT7988
> +config MEDIATEK_2P5GE_PHY
> + tristate "MediaTek 2.5Gb Ethernet PHYs"
> + depends on (ARM64 && ARCH_MEDIATEK) || COMPILE_TEST
> + select MTK_NET_PHYLIB
> + help
> + Supports MediaTek SoC built-in 2.5Gb Ethernet PHYs.
> +
> + This will load necessary firmware and add appropriate time delay.
> + Accelerate this procedure through internal pbus instead of MDIO
> + bus. Certain link-up issues will also be fixed here.
Please keep the file sorted, this should be the first entry.
> diff --git a/drivers/net/phy/mediatek/Makefile b/drivers/net/phy/mediatek/Makefile
> index 814879d0abe5..c6db8abd2c9c 100644
> --- a/drivers/net/phy/mediatek/Makefile
> +++ b/drivers/net/phy/mediatek/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_MTK_NET_PHYLIB) += mtk-phy-lib.o
> obj-$(CONFIG_MEDIATEK_GE_PHY) += mtk-ge.o
> obj-$(CONFIG_MEDIATEK_GE_SOC_PHY) += mtk-ge-soc.o
> +obj-$(CONFIG_MEDIATEK_2P5GE_PHY) += mtk-2p5ge.o
I suppose you could say this file is sorted in reverse order so is
correct?
> diff --git a/drivers/net/phy/mediatek/mtk-2p5ge.c b/drivers/net/phy/mediatek/mtk-2p5ge.c
> new file mode 100644
> index 000000000000..adb03df331ab
> --- /dev/null
> +++ b/drivers/net/phy/mediatek/mtk-2p5ge.c
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +#include <linux/bitfield.h>
> +#include <linux/firmware.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
Is this header needed?
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/phy.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
And these two? Please only use those that are needed.
> +static int mt798x_2p5ge_phy_load_fw(struct phy_device *phydev)
> +{
> +
> + writew(reg & ~MD32_EN, mcu_csr_base + MD32_EN_CFG);
> + writew(reg | MD32_EN, mcu_csr_base + MD32_EN_CFG);
> + phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
> + /* We need a delay here to stabilize initialization of MCU */
> + usleep_range(7000, 8000);
Does the reset bit clear when the MCU is ready? That is what 802.3
defines. phy_poll_reset() might do what you need.
> + dev_info(dev, "Firmware loading/trigger ok.\n");
dev_dbg(), if at all. You have already spammed the log with the
firmware version, so this adds nothing useful.
> + phydev->duplex = DUPLEX_FULL;
> + /* FIXME:
> + * The current firmware always enables rate adaptation mode.
> + */
> + phydev->rate_matching = RATE_MATCH_PAUSE;
Can we tell current firmware for future firmware? Is this actually
fixable?
> + }
> +
> + return 0;
> +}
> +
> +static int mt798x_2p5ge_phy_probe(struct phy_device *phydev)
> +{
> + struct mtk_i2p5ge_phy_priv *priv;
> +
> + priv = devm_kzalloc(&phydev->mdio.dev,
> + sizeof(struct mtk_i2p5ge_phy_priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + switch (phydev->drv->phy_id) {
> + case MTK_2P5GPHY_ID_MT7988:
> + /* The original hardware only sets MDIO_DEVS_PMAPMD */
What do you mean by "original hardware"?
You use PHY_ID_MATCH_MODEL(MTK_2P5GPHY_ID_MT7988), so do you mean
revision 0 is broken, but revision 1 fixed it?
> + phydev->c45_ids.mmds_present |= MDIO_DEVS_PCS |
> + MDIO_DEVS_AN |
> + MDIO_DEVS_VEND1 |
> + MDIO_DEVS_VEND2;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + priv->fw_loaded = false;
> + phydev->priv = priv;
> +
> + mtk_phy_leds_state_init(phydev);
The LEDs work without firmware?
Andrew
---
pw-bot: cr
Powered by blists - more mailing lists