On Sun, Oct 18, 2026 at 10:47:34AM +0000, netdev-bot+sashiko@kernel.org wrote:
Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 2 · Low: 1
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] In rgmii-id mode at 100M and 10M, ethqos_set_clk_tx_rate() now
calls clk_set_rate(link_clk, 25000000) or clk_set_rate(link_clk,…
- [Medium] net: stmmac: qcom-ethqos: rgmii_setmask() on multi-bit
RGMII_CONFIG2_RSVD_CONFIG15
- [Low] The commit is titled and described as a fix for a defect in the
current tree, but it has no Fixes: tag.
--
[Severity: Medium]
Can qcs404 and sc8280xp actually produce 25 MHz and 2.5 MHz on the link
clock?
On qcs404 the "rgmii" link clock is GCC_ETH_RGMII_CLK. Its parent's
frequency table only has these entries:
drivers/clk/qcom/gcc-qcs404.c:ftbl_emac_clk_src
5 MHz, 50 MHz, 125 MHz, 250 MHz
On sc8280xp it is GCC_EMAC0_RGMII_CLK, and the lowest entry is 50 MHz:
drivers/clk/qcom/gcc-sc8280xp.c:ftbl_gcc_emac0_rgmii_clk_src
50 MHz, 125 MHz, 250 MHz
Both branch clocks have CLK_SET_RATE_PARENT. The parent RCGs round up
rather than fail:
drivers/clk/qcom/clk-rcg2.c:clk_rcg2_determine_rate() {
...
return _freq_tbl_determine_rate(hw, rcg->freq_tbl, req, CEIL);
}
So in rgmii-id mode at 100M/10M, the request would silently become 50 MHz
or 5 MHz on qcs404, and 50 MHz on sc8280xp. clk_set_rate() would still
return 0.
As mentioned in another reply, I will update the series to use this new
flow for PHY managed RGMII delay for only SoCs that could be validated,
i.e. shikra and qcs615.
Ayaan
pw-bot: cr