All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Sky Huang <SkyLake.Huang@mediatek.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	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 net-next v5 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988
Date: Sat, 1 Jun 2024 13:51:05 +0100	[thread overview]
Message-ID: <20240601125105.GJ491852@kernel.org> (raw)
In-Reply-To: <20240530034844.11176-6-SkyLake.Huang@mediatek.com>

On Thu, May 30, 2024 at 11:48:44AM +0800, Sky Huang wrote:
> From: "SkyLake.Huang" <skylake.huang@mediatek.com>
> 
> v1:
> 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.
> 
> v2:
> 1. Move md32_en_cfg_base & pmb_addr detection in probe function.
> 2. Do not read PMB & MD32_EN_CFG base addresses from dts. We won't
> change that from board to board. Leave them in driver code. Also,
> release those addresses after firmware is triggered.
> 3. Remove half duplex code which leads to ambiguity. Those are for
> testing & developing previously.
> 4. Use correct BMCR definitions.
> 5. Correct config_aneg / get_features / read_status functions.
> 6. Change mt7988_2p5ge prefix to mt798x_2p5ge in case that our next
> platform uses this 2.5Gphy driver.
> 
> v3:
> 1. Add range check for firmware.
> 2. Fix c45_ids.mmds_present in probe function.
> 3. Still use genphy_update_link() in read_status because
> genphy_c45_read_link() can't correct detect link on this phy.
> 
> v4:
> 1. Move firmware loading function to mt798x_2p5ge_phy_load_fw()
> 2. Add AN disable warning in mt798x_2p5ge_phy_config_aneg()
> 3. Clarify the HDX comments in mt798x_2p5ge_phy_get_features()
> 
> v5:
> 1. Move md32_en_cfg_base & pmb_addr to local variables to achieve
> symmetric code.
> 2. Print out firmware date code & version.
> 3. Don't return error if LED pinctrl switching fails. Also, add
> comments to this unusual operations.
> 4. Return -EOPNOTSUPP for AN off case in config_aneg().
> 

Hi Sky,

This is a somewhat unusual way to arrange a patch description.

Usually the description describes the change, particularly why
the change is being made.

While the per-version changes are listed below the scissors ("---").

> Signed-off-by: SkyLake.Huang <skylake.huang@mediatek.com>

...

> diff --git a/drivers/net/phy/mediatek/mtk-2p5ge.c b/drivers/net/phy/mediatek/mtk-2p5ge.c

...

> +static int mt798x_2p5ge_phy_load_fw(struct phy_device *phydev)
> +{
> +	struct mtk_i2p5ge_phy_priv *priv = phydev->priv;
> +	void __iomem *md32_en_cfg_base, *pmb_addr;
> +	struct device *dev = &phydev->mdio.dev;
> +	const struct firmware *fw;
> +	int ret, i;
> +	u16 reg;
> +
> +	if (priv->fw_loaded)
> +		return 0;
> +
> +	pmb_addr = ioremap(MT7988_2P5GE_PMB_BASE, MT7988_2P5GE_PMB_LEN);
> +	if (!pmb_addr)
> +		return -ENOMEM;
> +	md32_en_cfg_base = ioremap(MT7988_2P5GE_MD32_EN_CFG_BASE, MT7988_2P5GE_MD32_EN_CFG_LEN);

nit: Networking still prefers code to be 80 columns wide or less.
     It looks like that can be trivially achieved here and
     several other places in this patch.

     OTOH, I don't think there is no need to break lines to meet this
     requirement where it is particularly awkward to do so.

     Flagged by checkpatch.pl --max-line-length=80

> +	if (!md32_en_cfg_base) {
> +		ret = -ENOMEM;
> +		goto free_pmb;
> +	}
> +
> +	ret = request_firmware(&fw, MT7988_2P5GE_PMB, dev);
> +	if (ret) {
> +		dev_err(dev, "failed to load firmware: %s, ret: %d\n",
> +			MT7988_2P5GE_PMB, ret);
> +		goto free;
> +	}
> +
> +	if (fw->size != MT7988_2P5GE_PMB_SIZE) {
> +		dev_err(dev, "Firmware size 0x%zx != 0x%x\n",
> +			fw->size, MT7988_2P5GE_PMB_SIZE);
> +		ret = -EINVAL;
> +		goto free;
> +	}
> +
> +	reg = readw(md32_en_cfg_base);
> +	if (reg & MD32_EN) {
> +		phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
> +		usleep_range(10000, 11000);
> +	}
> +	phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN);
> +
> +	/* Write magic number to safely stall MCU */
> +	phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x800e, 0x1100);
> +	phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x800f, 0x00df);
> +
> +	for (i = 0; i < MT7988_2P5GE_PMB_SIZE - 1; i += 4)
> +		writel(*((uint32_t *)(fw->data + i)), pmb_addr + i);
> +	release_firmware(fw);
> +	dev_info(dev, "Firmware date code: %x/%x/%x, version: %x.%x\n",
> +		 be16_to_cpu(*((uint16_t *)(fw->data + MT7988_2P5GE_PMB_SIZE - 8))),

If the data at fw->data + MT7988_2P5GE_PMB_SIZE - 8 is a 16-bit
Big Endian value, then I think the cast should be to __be16 rather
than uint16_t (and in any case u16 would be preferred to uint16_t
as this is Kernel code).

Flagged by Sparse.

> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 6),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 5),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 2),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 1));
> +
> +	writew(reg & ~MD32_EN, md32_en_cfg_base);
> +	writew(reg | MD32_EN, md32_en_cfg_base);
> +	phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
> +	/* We need a delay here to stabilize initialization of MCU */
> +	usleep_range(7000, 8000);
> +	dev_info(dev, "Firmware loading/trigger ok.\n");
> +
> +	priv->fw_loaded = true;
> +
> +free:
> +	iounmap(md32_en_cfg_base);
> +free_pmb:
> +	iounmap(pmb_addr);
> +
> +	return ret ? ret : 0;
> +}

...

> +static int mt798x_2p5ge_phy_led_blink_set(struct phy_device *phydev, u8 index,
> +					  unsigned long *delay_on,
> +					  unsigned long *delay_off)
> +{
> +	bool blinking = false;
> +	int err = 0;
> +	struct mtk_i2p5ge_phy_priv *priv = phydev->priv;

nit: Please consider arranging local variables in reverse xmas tree order - 
     longest line to shortest.

     Edward Cree's tool can be helpful:
     https://github.com/ecree-solarflare/xmastree

> +
> +	if (index > 1)
> +		return -EINVAL;
> +
> +	if (delay_on && delay_off && (*delay_on > 0) && (*delay_off > 0)) {
> +		blinking = true;
> +		*delay_on = 50;
> +		*delay_off = 50;
> +	}
> +
> +	err = mtk_phy_hw_led_blink_set(phydev, index, &priv->led_state, blinking);
> +	if (err)
> +		return err;
> +
> +	return mtk_phy_hw_led_on_set(phydev, index, &priv->led_state,
> +				     MTK_2P5GPHY_LED_ON_MASK, false);
> +}

...


WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Sky Huang <SkyLake.Huang@mediatek.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	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 net-next v5 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988
Date: Sat, 1 Jun 2024 13:51:05 +0100	[thread overview]
Message-ID: <20240601125105.GJ491852@kernel.org> (raw)
In-Reply-To: <20240530034844.11176-6-SkyLake.Huang@mediatek.com>

On Thu, May 30, 2024 at 11:48:44AM +0800, Sky Huang wrote:
> From: "SkyLake.Huang" <skylake.huang@mediatek.com>
> 
> v1:
> 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.
> 
> v2:
> 1. Move md32_en_cfg_base & pmb_addr detection in probe function.
> 2. Do not read PMB & MD32_EN_CFG base addresses from dts. We won't
> change that from board to board. Leave them in driver code. Also,
> release those addresses after firmware is triggered.
> 3. Remove half duplex code which leads to ambiguity. Those are for
> testing & developing previously.
> 4. Use correct BMCR definitions.
> 5. Correct config_aneg / get_features / read_status functions.
> 6. Change mt7988_2p5ge prefix to mt798x_2p5ge in case that our next
> platform uses this 2.5Gphy driver.
> 
> v3:
> 1. Add range check for firmware.
> 2. Fix c45_ids.mmds_present in probe function.
> 3. Still use genphy_update_link() in read_status because
> genphy_c45_read_link() can't correct detect link on this phy.
> 
> v4:
> 1. Move firmware loading function to mt798x_2p5ge_phy_load_fw()
> 2. Add AN disable warning in mt798x_2p5ge_phy_config_aneg()
> 3. Clarify the HDX comments in mt798x_2p5ge_phy_get_features()
> 
> v5:
> 1. Move md32_en_cfg_base & pmb_addr to local variables to achieve
> symmetric code.
> 2. Print out firmware date code & version.
> 3. Don't return error if LED pinctrl switching fails. Also, add
> comments to this unusual operations.
> 4. Return -EOPNOTSUPP for AN off case in config_aneg().
> 

Hi Sky,

This is a somewhat unusual way to arrange a patch description.

Usually the description describes the change, particularly why
the change is being made.

While the per-version changes are listed below the scissors ("---").

> Signed-off-by: SkyLake.Huang <skylake.huang@mediatek.com>

...

> diff --git a/drivers/net/phy/mediatek/mtk-2p5ge.c b/drivers/net/phy/mediatek/mtk-2p5ge.c

...

> +static int mt798x_2p5ge_phy_load_fw(struct phy_device *phydev)
> +{
> +	struct mtk_i2p5ge_phy_priv *priv = phydev->priv;
> +	void __iomem *md32_en_cfg_base, *pmb_addr;
> +	struct device *dev = &phydev->mdio.dev;
> +	const struct firmware *fw;
> +	int ret, i;
> +	u16 reg;
> +
> +	if (priv->fw_loaded)
> +		return 0;
> +
> +	pmb_addr = ioremap(MT7988_2P5GE_PMB_BASE, MT7988_2P5GE_PMB_LEN);
> +	if (!pmb_addr)
> +		return -ENOMEM;
> +	md32_en_cfg_base = ioremap(MT7988_2P5GE_MD32_EN_CFG_BASE, MT7988_2P5GE_MD32_EN_CFG_LEN);

nit: Networking still prefers code to be 80 columns wide or less.
     It looks like that can be trivially achieved here and
     several other places in this patch.

     OTOH, I don't think there is no need to break lines to meet this
     requirement where it is particularly awkward to do so.

     Flagged by checkpatch.pl --max-line-length=80

> +	if (!md32_en_cfg_base) {
> +		ret = -ENOMEM;
> +		goto free_pmb;
> +	}
> +
> +	ret = request_firmware(&fw, MT7988_2P5GE_PMB, dev);
> +	if (ret) {
> +		dev_err(dev, "failed to load firmware: %s, ret: %d\n",
> +			MT7988_2P5GE_PMB, ret);
> +		goto free;
> +	}
> +
> +	if (fw->size != MT7988_2P5GE_PMB_SIZE) {
> +		dev_err(dev, "Firmware size 0x%zx != 0x%x\n",
> +			fw->size, MT7988_2P5GE_PMB_SIZE);
> +		ret = -EINVAL;
> +		goto free;
> +	}
> +
> +	reg = readw(md32_en_cfg_base);
> +	if (reg & MD32_EN) {
> +		phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
> +		usleep_range(10000, 11000);
> +	}
> +	phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN);
> +
> +	/* Write magic number to safely stall MCU */
> +	phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x800e, 0x1100);
> +	phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x800f, 0x00df);
> +
> +	for (i = 0; i < MT7988_2P5GE_PMB_SIZE - 1; i += 4)
> +		writel(*((uint32_t *)(fw->data + i)), pmb_addr + i);
> +	release_firmware(fw);
> +	dev_info(dev, "Firmware date code: %x/%x/%x, version: %x.%x\n",
> +		 be16_to_cpu(*((uint16_t *)(fw->data + MT7988_2P5GE_PMB_SIZE - 8))),

If the data at fw->data + MT7988_2P5GE_PMB_SIZE - 8 is a 16-bit
Big Endian value, then I think the cast should be to __be16 rather
than uint16_t (and in any case u16 would be preferred to uint16_t
as this is Kernel code).

Flagged by Sparse.

> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 6),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 5),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 2),
> +		 *(fw->data + MT7988_2P5GE_PMB_SIZE - 1));
> +
> +	writew(reg & ~MD32_EN, md32_en_cfg_base);
> +	writew(reg | MD32_EN, md32_en_cfg_base);
> +	phy_set_bits(phydev, MII_BMCR, BMCR_RESET);
> +	/* We need a delay here to stabilize initialization of MCU */
> +	usleep_range(7000, 8000);
> +	dev_info(dev, "Firmware loading/trigger ok.\n");
> +
> +	priv->fw_loaded = true;
> +
> +free:
> +	iounmap(md32_en_cfg_base);
> +free_pmb:
> +	iounmap(pmb_addr);
> +
> +	return ret ? ret : 0;
> +}

...

> +static int mt798x_2p5ge_phy_led_blink_set(struct phy_device *phydev, u8 index,
> +					  unsigned long *delay_on,
> +					  unsigned long *delay_off)
> +{
> +	bool blinking = false;
> +	int err = 0;
> +	struct mtk_i2p5ge_phy_priv *priv = phydev->priv;

nit: Please consider arranging local variables in reverse xmas tree order - 
     longest line to shortest.

     Edward Cree's tool can be helpful:
     https://github.com/ecree-solarflare/xmastree

> +
> +	if (index > 1)
> +		return -EINVAL;
> +
> +	if (delay_on && delay_off && (*delay_on > 0) && (*delay_off > 0)) {
> +		blinking = true;
> +		*delay_on = 50;
> +		*delay_off = 50;
> +	}
> +
> +	err = mtk_phy_hw_led_blink_set(phydev, index, &priv->led_state, blinking);
> +	if (err)
> +		return err;
> +
> +	return mtk_phy_hw_led_on_set(phydev, index, &priv->led_state,
> +				     MTK_2P5GPHY_LED_ON_MASK, false);
> +}

...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2024-06-01 12:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30  3:48 [PATCH net-next v5 0/5] net: phy: mediatek: Introduce mtk-phy-lib and add 2.5Gphy support Sky Huang
2024-05-30  3:48 ` Sky Huang
2024-05-30  3:48 ` [PATCH net-next v5 1/5] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers Sky Huang
2024-05-30  3:48   ` Sky Huang
2024-05-30  3:48 ` [PATCH net-next v5 2/5] net: phy: mediatek: Move LED and read/write page helper functions into mtk phy lib Sky Huang
2024-05-30  3:48   ` Sky Huang
2024-05-30  3:48 ` [PATCH net-next v5 3/5] net: phy: mediatek: Add token ring access helper functions in mtk-phy-lib Sky Huang
2024-05-30  3:48   ` Sky Huang
2024-05-30  3:48 ` [PATCH net-next v5 4/5] net: phy: mediatek: Extend 1G TX/RX link pulse time Sky Huang
2024-05-30  3:48   ` Sky Huang
2024-05-30 10:23   ` Russell King (Oracle)
2024-05-30 10:23     ` Russell King (Oracle)
2024-05-30 16:01     ` SkyLake Huang (黃啟澤)
2024-05-30 16:01       ` SkyLake Huang (黃啟澤)
2024-05-30 16:10       ` Russell King (Oracle)
2024-05-30 16:10         ` Russell King (Oracle)
2024-06-03  3:15         ` SkyLake Huang (黃啟澤)
2024-06-03  3:15           ` SkyLake Huang (黃啟澤)
2024-06-03  8:06           ` Russell King (Oracle)
2024-06-03  8:06             ` Russell King (Oracle)
2024-06-03 11:51             ` SkyLake Huang (黃啟澤)
2024-06-03 11:51               ` SkyLake Huang (黃啟澤)
2024-05-30  3:48 ` [PATCH net-next v5 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988 Sky Huang
2024-05-30  3:48   ` Sky Huang
2024-05-30 10:35   ` Russell King (Oracle)
2024-05-30 10:35     ` Russell King (Oracle)
2024-05-30 16:25     ` SkyLake Huang (黃啟澤)
2024-05-30 16:25       ` SkyLake Huang (黃啟澤)
2024-05-30 16:55       ` Russell King (Oracle)
2024-05-30 16:55         ` Russell King (Oracle)
2024-06-03  7:19         ` SkyLake Huang (黃啟澤)
2024-06-03  7:19           ` SkyLake Huang (黃啟澤)
2024-05-31  1:00   ` kernel test robot
2024-05-31  1:00     ` kernel test robot
2024-06-01 12:51   ` Simon Horman [this message]
2024-06-01 12:51     ` Simon Horman
2024-06-03  7:41     ` SkyLake Huang (黃啟澤)
2024-06-03  7:41       ` 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=20240601125105.GJ491852@kernel.org \
    --to=horms@kernel.org \
    --cc=SkyLake.Huang@mediatek.com \
    --cc=Steven.Liu@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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.