From: netdev-bot+sashiko@kernel.org
To: bartosz.golaszewski@oss.qualcomm.com
Cc: andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com, vkoul@kernel.org,
peppe.cavallaro@st.com, wens@kernel.org,
jernej.skrabec@gmail.com, neil.armstrong@linaro.org,
khilman@baylibre.com, jbrunet@baylibre.com, shawnguo@kernel.org,
festevam@gmail.com, jan.petrous@oss.nxp.com, s32@nxp.com,
mohd.anwar@oss.qualcomm.com, romain.gantois@bootlin.com,
geert+renesas@glider.be, magnus.damm@gmail.com,
mripard@kernel.org, christophe.roullier@foss.st.com,
brgl@kernel.org, radu@rendec.net, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, dfustini@tenstorrent.com,
linux-sunxi@lists.linux.dev, linux-amlogic@lists.infradead.org,
linux-mips@vger.kernel.org, imx@lists.linux.dev,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org, sophgo@lists.linux.dev,
linux-riscv@lists.infradead.org, bartosz.golaszewski@linaro.org
Subject: Re: [PATCH net-next v15 8/9] net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function
Date: Sun, 27 Sep 2026 16:29:18 +0000 [thread overview]
Message-ID: <179052655862.2160803.476962840384562724@kernel.org> (raw)
In-Reply-To: <20260923-qcom-sa8255p-emac-v15-8-e82f33720737@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] The commit message does not describe the refactor boundary
accurately.
- [Low] The patch deletes the comment that justified the hard-coded MDC
divider ('The clocks are controlled by firmware, so we don't know for…
--
net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function
This patch adds a setup() callback to struct ethqos_emac_driver_data. It
implements the callback as ethqos_hlos_setup() for the existing EMAC
variants. The rgmii mapping, link clock handling and several plat_dat
callbacks move from qcom_ethqos_probe() into it, ahead of support for
firmware-controlled (SCMI) EMAC variants.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index ab1bcb7eb18e2..509a5368e69a8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
[ ... ]
> @@ -692,6 +704,58 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
> netdev_dbg(priv->dev, "PTP rate %lu\n", plat_dat->clk_ptp_rate);
> }
>
> +static int ethqos_hlos_setup(struct qcom_ethqos *ethqos,
> + struct plat_stmmacenet_data *plat_dat)
> +{
> + struct platform_device *pdev = ethqos->pdev;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + ethqos->rgmii_base = devm_platform_ioremap_resource_byname(pdev, "rgmii");
> + if (IS_ERR(ethqos->rgmii_base))
> + return dev_err_probe(dev, PTR_ERR(ethqos->rgmii_base),
> + "Failed to map rgmii resource\n");
> +
> + ethqos->link_clk = devm_clk_get(dev, ethqos->data->link_clk_name ?: "rgmii");
> + if (IS_ERR(ethqos->link_clk))
> + return dev_err_probe(dev, PTR_ERR(ethqos->link_clk),
> + "Failed to get link_clk\n");
> +
> + plat_dat->clks_config = ethqos_clks_config;
> +
> + ret = ethqos_clks_config(ethqos, true);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, ethqos_clks_disable, ethqos);
> + if (ret)
> + return ret;
> +
[ ... ]
> + case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_SGMII:
> + plat_dat->fix_mac_speed = ethqos_fix_mac_speed_sgmii;
> + break;
> + default:
> + break;
> + }
[Severity: Low]
This isn't a bug, but is the commit message accurate about what moves into
the callback? It says the patch will:
"move all operations not required in SCMI mode into it."
SCMI mode also needs several of the steps moved into ethqos_hlos_setup():
- mapping the "rgmii" wrapper
- setting plat_dat->clks_config
- the first ethqos_clks_config(ethqos, true) call, along with its
devm_add_action_or_reset(dev, ethqos_clks_disable, ethqos) cleanup
- selecting ethqos_fix_mac_speed_sgmii for SGMII/2500BASEX
Later in the series, the ethqos_scmi_setup() added by "net: stmmac:
qcom-ethqos: add support for sa8255p" repeats each of these steps. Its own
comment says the wrapper loopback and functional clock bits are required.
Without them, the DMA SW-reset in dwmac4_dma_reset() never completes.
As a result, the same setup code exists in two places instead of once in
qcom_ethqos_probe().
Could the shared steps stay in qcom_ethqos_probe() or move to a common
helper, leaving only the HLOS-only parts in ethqos_hlos_setup()? If not,
could the commit message describe the split more precisely?
[ ... ]
> @@ -765,21 +815,8 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> return dev_err_probe(dev, PTR_ERR(ethqos->serdes_phy),
> "Failed to get serdes phy\n");
>
> - ethqos_set_clk_tx_rate(ethqos, NULL, plat_dat->phy_interface,
> - SPEED_1000);
> -
> - qcom_ethqos_set_sgmii_loopback(ethqos, true);
> - ethqos_set_func_clk_en(ethqos);
> -
> - /* The clocks are controlled by firmware, so we don't know for certain
> - * what clock rate is being used. Hardware documentation mentions that
> - * the AHB slave clock will be in the range of 50 to 100MHz, which
> - * equates to a MDC between 1.19 and 2.38MHz.
> - */
> plat_dat->clk_csr = STMMAC_CSR_60_100M;
[Severity: Low]
Was this comment meant to be removed?
qcom_ethqos_probe() still sets plat_dat->clk_csr = STMMAC_CSR_60_100M for
every variant, but the comment explaining the hard-coded MDC divider is
gone.
The commit message describes the change as code motion and does not
mention removing the comment. No later patch in the series restores it.
Could the comment be kept above the clk_csr assignment?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260923-qcom-sa8255p-emac-v15-0-e82f33720737%40oss.qualcomm.com
next prev parent reply other threads:[~2026-09-27 16:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 15:14 [PATCH net-next v15 0/9] net: stmmac: qcom-ethqos: add support for SCMI power domains Bartosz Golaszewski
2026-09-23 15:14 ` [PATCH net-next v15 1/9] net: phy: aquantia: fix system interface type not updated in forced mode Bartosz Golaszewski
2026-09-23 15:14 ` [PATCH net-next v15 2/9] dt-bindings: phy: document the serdes PHY on sa8255p Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
2026-09-23 15:14 ` [PATCH net-next v15 3/9] phy: qcom: add the SGMII SerDes PHY driver for SCMI systems Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
2026-09-23 15:14 ` [PATCH net-next v15 4/9] dt-bindings: net: qcom: document the ethqos device for SCMI-based systems Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
2026-09-23 15:14 ` [PATCH net-next v15 5/9] net: stmmac: qcom-ethqos: set serdes mode before powerup Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
2026-09-23 15:14 ` [PATCH net-next v15 6/9] net: stmmac: qcom-ethqos: update phy_mode to the resolved interface in mac_finish() Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
2026-09-23 15:14 ` [PATCH net-next v15 7/9] net: stmmac: qcom-ethqos: reuse the address of ethqos_emac_driver_data Bartosz Golaszewski
2026-09-23 15:14 ` [PATCH net-next v15 8/9] net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko [this message]
2026-09-23 15:14 ` [PATCH net-next v15 9/9] net: stmmac: qcom-ethqos: add support for sa8255p Bartosz Golaszewski
2026-09-27 16:29 ` netdev-bot+sashiko
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=179052655862.2160803.476962840384562724@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=andersson@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bartosz.golaszewski@linaro.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=christophe.roullier@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dfustini@tenstorrent.com \
--cc=edumazet@google.com \
--cc=festevam@gmail.com \
--cc=geert+renesas@glider.be \
--cc=imx@lists.linux.dev \
--cc=jan.petrous@oss.nxp.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=khilman@baylibre.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=magnus.damm@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mohd.anwar@oss.qualcomm.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=radu@rendec.net \
--cc=robh@kernel.org \
--cc=romain.gantois@bootlin.com \
--cc=s32@nxp.com \
--cc=shawnguo@kernel.org \
--cc=sophgo@lists.linux.dev \
--cc=vkoul@kernel.org \
--cc=wens@kernel.org \
/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®