From: Jakub Kicinski <kuba@kernel.org>
To: bartosz.golaszewski@oss.qualcomm.com
Cc: Jakub Kicinski <kuba@kernel.org>,
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, 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 v13 09/10] net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function
Date: Fri, 24 Jul 2026 15:46:02 -0700 [thread overview]
Message-ID: <20260724224602.1650002-1-kuba@kernel.org> (raw)
In-Reply-To: <20260713-qcom-sa8255p-emac-v13-9-119f8699ef8e@oss.qualcomm.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function
This refactor extends ethqos_emac_driver_data with a setup() callback,
implements it for the existing models, and moves operations not required
in SCMI mode into it, in preparation for firmware-controlled 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 43384960278b..3af1608fc21c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -5,6 +5,7 @@
> #include <linux/of.h>
> #include <linux/of_net.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/phy.h>
> #include <linux/phy/phy.h>
[Low]
Is there a reason linux/pm_domain.h is added here? Looking through
this commit, no pm_domain symbols (pm_genpd_*, dev_pm_domain_*,
PD_FLAG_*, etc.) appear to be referenced.
The header seems to belong with the follow-up patch that introduces
devm_pm_domain_attach_list() and struct dev_pm_domain_list usage.
Would it be preferable to move this include into the patch that
actually needs it, so each patch remains self-contained?
[ ... ]
> @@ -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;
> plat_dat->bsp_priv = ethqos;
> - plat_dat->set_clk_tx_rate = ethqos_set_clk_tx_rate;
> - plat_dat->dump_debug_regs = rgmii_dump;
> plat_dat->ptp_clk_freq_config = ethqos_ptp_clk_freq_config;
> plat_dat->core_type = DWMAC_CORE_GMAC4;
> if (data->has_emac_ge_3)
[Low]
Was the comment above plat_dat->clk_csr = STMMAC_CSR_60_100M; intended
to be dropped?
The assignment itself is preserved, but the rationale for choosing
STMMAC_CSR_60_100M (firmware-controlled AHB clock in the 50-100MHz
range yielding an MDC between 1.19 and 2.38MHz) is now gone.
The commit message describes a mechanical refactor and does not
mention removing this rationale. Should the comment be kept next to
the assignment, or moved into ethqos_hlos_setup() where the
surrounding clock setup now lives?
next prev parent reply other threads:[~2026-07-24 22:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 13:20 [PATCH net-next v13 00/10] net: stmmac: qcom-ethqos: add support for SCMI power domains Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 01/10] net: phy: aquantia: fix system interface type not updated in forced mode Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 02/10] dt-bindings: phy: document the serdes PHY on sa8255p Bartosz Golaszewski
2026-07-24 22:45 ` Jakub Kicinski
2026-07-13 13:20 ` [PATCH net-next v13 03/10] phy: qcom: add the SGMII SerDes PHY driver for SCMI systems Bartosz Golaszewski
2026-07-24 22:45 ` Jakub Kicinski
2026-07-13 13:20 ` [PATCH net-next v13 04/10] dt-bindings: net: qcom: document the ethqos device for SCMI-based systems Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 05/10] net: stmmac: qcom-ethqos: set serdes mode before powerup Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 06/10] net: stmmac: qcom-ethqos: update phy_mode to the resolved interface in mac_finish() Bartosz Golaszewski
2026-07-24 22:45 ` Jakub Kicinski
2026-07-13 13:20 ` [PATCH net-next v13 07/10] net: stmmac: qcom-ethqos: fix SGMII loopback not set on resume after speed change Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 08/10] net: stmmac: qcom-ethqos: reuse the address of ethqos_emac_driver_data Bartosz Golaszewski
2026-07-13 13:20 ` [PATCH net-next v13 09/10] net: stmmac: qcom-ethqos: factor out linux-level setup into a separate function Bartosz Golaszewski
2026-07-24 22:46 ` Jakub Kicinski [this message]
2026-07-13 13:20 ` [PATCH net-next v13 10/10] net: stmmac: qcom-ethqos: add support for sa8255p Bartosz Golaszewski
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=20260724224602.1650002-1-kuba@kernel.org \
--to=kuba@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=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