* Re: [PATCH] phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config
From: Dmitry Baryshkov @ 2026-02-27 19:50 UTC (permalink / raw)
To: xiangxu.yin
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, fange.zhang, yongxing.mou, li.liu, tingwei.zhang,
Konrad Dybcio, Dan Carpenter
In-Reply-To: <20260227-master-v1-1-8d91b9407fdb@oss.qualcomm.com>
On Fri, Feb 27, 2026 at 08:15:01PM +0800, Xiangxu Yin via B4 Relay wrote:
> From: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com>
>
> swing_tbl and pre_emphasis_tbl are 4x4 arrays (valid indices 0-3), but
> the boundary check uses "> 4" instead of ">= 4", allowing index 4 to
> cause an out-of-bounds access.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Fixes: 81791c45c8e0 ("phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config and DP mode support")
> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: m31-eusb2: Make USB repeater optional
From: Dmitry Baryshkov @ 2026-02-27 19:40 UTC (permalink / raw)
To: Abel Vesa
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, Wesley Cheng
In-Reply-To: <20260227-phy-qcom-m31-eusb2-make-repeater-optional-v1-1-07a086bbaba4@oss.qualcomm.com>
On Fri, Feb 27, 2026 at 07:47:14PM +0200, Abel Vesa wrote:
> From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
>
> A repeater is not required for the PHY to function. On systems with
> multiple PHY instances connected to a multi-port controller, some PHYs
> may be unconnected. All PHYs must still probe successfully even without
> attached repeaters, otherwise the controller probe fails.
>
> So make it optional.
>
> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
> [abel.vesa@oss.qualcomm.com: commit re-worded to reflect actual reason]
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> This has been sent initially by Wesley here:
> https://lore.kernel.org/all/20250920032108.242643-10-wesley.cheng@oss.qualcomm.com/
>
> This is still needed, but for a different reason, so re-worded the
> commit message to reflect why.
> ---
> drivers/phy/qualcomm/phy-qcom-m31-eusb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
With the changes suggested by Bjorn:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: m31-eusb2: Make USB repeater optional
From: Bjorn Andersson @ 2026-02-27 18:40 UTC (permalink / raw)
To: Abel Vesa
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, Wesley Cheng
In-Reply-To: <20260227-phy-qcom-m31-eusb2-make-repeater-optional-v1-1-07a086bbaba4@oss.qualcomm.com>
On Fri, Feb 27, 2026 at 07:47:14PM +0200, Abel Vesa wrote:
> From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
>
s/qualcomm/qcom/ insubject, to match other changes to this file.
> A repeater is not required for the PHY to function. On systems with
> multiple PHY instances connected to a multi-port controller, some PHYs
> may be unconnected. All PHYs must still probe successfully even without
> attached repeaters, otherwise the controller probe fails.
>
> So make it optional.
I like this rewrite.
>
> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
> [abel.vesa@oss.qualcomm.com: commit re-worded to reflect actual reason]
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
With $subject adjusted:
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> ---
> This has been sent initially by Wesley here:
> https://lore.kernel.org/all/20250920032108.242643-10-wesley.cheng@oss.qualcomm.com/
>
> This is still needed, but for a different reason, so re-worded the
> commit message to reflect why.
Doesn't that make this patch v2?
Regards,
Bjorn
> ---
> drivers/phy/qualcomm/phy-qcom-m31-eusb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> index 95cd3175926d..70a81ab2482f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> @@ -285,7 +285,7 @@ static int m31eusb2_phy_probe(struct platform_device *pdev)
>
> phy_set_drvdata(phy->phy, phy);
>
> - phy->repeater = devm_of_phy_get_by_index(dev, dev->of_node, 0);
> + phy->repeater = devm_phy_optional_get(dev, NULL);
> if (IS_ERR(phy->repeater))
> return dev_err_probe(dev, PTR_ERR(phy->repeater),
> "failed to get repeater\n");
>
> ---
> base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> change-id: 20260227-phy-qcom-m31-eusb2-make-repeater-optional-621c8c1c0354
>
> Best regards,
> --
> Abel Vesa <abel.vesa@oss.qualcomm.com>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom: qmp-combo: Move pipe_clk on/off to common
From: Konrad Dybcio @ 2026-02-27 18:07 UTC (permalink / raw)
To: Val Packett, Vinod Koul, Kishon Vijay Abraham I, Bjorn Andersson,
Wesley Cheng
Cc: Dmitry Baryshkov, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel
In-Reply-To: <20250927093915.45124-2-val@packett.cool>
On 9/27/25 11:17 AM, Val Packett wrote:
> Keep the USB pipe clock working when the phy is in DP-only mode, because
> the dwc controller still needs it for USB 2.0 over the same Type-C port.
>
> Tested with the BenQ RD280UA monitor which has a downstream-facing port
> for data passthrough that's manually switchable between USB 2 and 3,
> corresponding to 4-lane and 2-lane DP respectively.
>
> Note: the suspend/resume callbacks were already gating the enable/disable
> of this clock only on init_count and not usb_init_count!
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> o/
>
> Just got my hands on a perfect test device for DP alt mode: a monitor with an
> on-demand toggle between 2 and 4 lanes. (Started digging because I thought
> I needed 4 lanes to use its full resolution and refresh rate, even though
> it turned out to be the dpu adjusted mode clock check rejecting the modes,
> patches for which are already posted.)
>
> In [1] Konrad mentioned that "the hardware disagrees" with keeping the USB
> PLL always on. I'm not sure what exactly was meant by disagreement there,
> and I didn't find any specific code that touches that PLL in the driver,
> so I decided to just try it anyway.
>
> Before the changes, 4-lane mode would actually kill the USB 2.0 functionality
> on the port, no recovery until reboot.
>
> With this patch, I can switch the monitor between 4-lane and 2-lane modes
> (with an unplug-replug cycle..) and the USB 2.0 devices attached through
> the monitor keep working! (I verified the number of lanes used via dp_debug).
>
> I'm sure it might not be that simple but from my limited and uninformed
> understanding without any internal knowledge, the "sneaky workaround"
> might actually be the intended way to do things?
+Bjorn, Wesley I wrote a wall of text for you, hopefully it makes sense
I now think I have some more knowledge about the setup.
The PIPE clock is an *output* of the PHY that feeds back into GCC, which
provides a XO-PHY mux, which then has a gate/branch downstream of it.
(that's 100% sure)
That branch (e.g. GCC_USB3_PRIM_PHY_PIPE_CLK) then feeds into the
destination core (PCIe, DWC3..) (that's *almost* 100% sure.. it's
surprisingly difficult to fully confirm)
Both msm-5.10 (and older) and upstream decided to keep that clock within
the PHY device though, and that makes.. some.. sense, because you're
not really supposed to turn it off (at least on recent chips), so much so
as switch its source from PHY to XO. That of course needs to happen when
the PHY is going to be disabled, as otherwise the PIPE clock is absent..
I can't really find information about when that branch is supposed to
be *disabled*, but one can probably assume with reasonable confidence
that if the PHY is offline (which generally only happens if the controller
is offline), that may be disabled as well.
The only remaining question remains then, where does the PIPE clock
come from? It's most likely not derived from the DP PLL.
The PHY has some slow onboard always-on clocks (for USB4 wakeup and
USB3 autonomous mode), but those are waay too slow to be driving PIPE
(which runs at 125 MHz @ SS, 312.5 MHz @ SS+).. so only the USB PLL
remains.
But then, in DP-only mode, SW_USB3PHY_RESET is asserted. The
documentation uses some imprecise wording with regards to what that
entails, but there's not many options left other than it may be
leaving the PLL in tact, while halting other parts of the USB3 logic.
Conversely, usb3phy_(nocsr_)reset is explicitly promised to reset the
USB_PLL.
I think the PLL also happens to be disabled when entering either of
the aforementioned sleep modes, since the table tells me the required
RPMH level is 'retention', which surely isn't enough to feed a big PLL.
The solution of teaching DWC3 how to switch clock sources is a little
involved, since we (to my understanding) have to/should omit programming
the parts that are conditional upon superspeed capabilities, and doing
that at runtime would probably realistically require making it type-C
aware (I don't think we want to go that route plus micro-b/MHL edge cases
*sigh*), or we could count on the suspend/resume work making it magically
click into place (since the dwc3 core does quite some re-programming upon
any sort of sus/res today anyway, it seems). If the latter happens, we may
end up reverting this patch as it may then turn out no longer necessary.
Today, i think this commit resolves this immediate issue and I think it's
the fix we should take (bumping my request of reordering the clock disables
and resubmitting..).
On an interesting note, if we take for granted my hypothesis about the
soft-reset not impacting the USB_PLL, this seems like an oversight in
programming guides, because USB4 transition sequences explicitly mention
the names which refer to resets coming from GCC, while DP/USB mix-and-
matching explicitly suggests using the soft-resets, but that might have
gone unnoticed, since dp-only hasn't been much of a prime use case for
in the past, as most of these chips were targetting mobile.
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: qualcomm: m31-eusb2: Make USB repeater optional
From: Abel Vesa @ 2026-02-27 17:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel, Wesley Cheng, Abel Vesa
From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
A repeater is not required for the PHY to function. On systems with
multiple PHY instances connected to a multi-port controller, some PHYs
may be unconnected. All PHYs must still probe successfully even without
attached repeaters, otherwise the controller probe fails.
So make it optional.
Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
[abel.vesa@oss.qualcomm.com: commit re-worded to reflect actual reason]
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
This has been sent initially by Wesley here:
https://lore.kernel.org/all/20250920032108.242643-10-wesley.cheng@oss.qualcomm.com/
This is still needed, but for a different reason, so re-worded the
commit message to reflect why.
---
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
index 95cd3175926d..70a81ab2482f 100644
--- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
@@ -285,7 +285,7 @@ static int m31eusb2_phy_probe(struct platform_device *pdev)
phy_set_drvdata(phy->phy, phy);
- phy->repeater = devm_of_phy_get_by_index(dev, dev->of_node, 0);
+ phy->repeater = devm_phy_optional_get(dev, NULL);
if (IS_ERR(phy->repeater))
return dev_err_probe(dev, PTR_ERR(phy->repeater),
"failed to get repeater\n");
---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260227-phy-qcom-m31-eusb2-make-repeater-optional-621c8c1c0354
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH] phy: mediatek: allow building T-PHY driver for MT7621 MIPS SoC
From: Vladimir Oltean @ 2026-02-27 17:26 UTC (permalink / raw)
To: Shiji Yang, AngeloGioacchino Del Regno
Cc: linux-phy, Chunfeng Yun, Vinod Koul, Neil Armstrong,
Matthias Brugger, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <3c2dcbf4-7702-42ef-9e61-5f4091e9a85e@collabora.com>
On Mon, Feb 23, 2026 at 02:47:09PM +0100, AngeloGioacchino Del Regno wrote:
> Il 19/02/26 13:53, Shiji Yang ha scritto:
> > MT7621 also has compatible T-PHY which attached to the XHCI interface.
> >
> > Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
>
> MT7621 seems to be a bit special among the mips/ralink platforms, so I agree.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
I wanted to see for myself, but I didn't find it.
arch/mips/boot/dts/ralink/mt7621.dtsi:
usb: usb@1e1c0000 {
compatible = "mediatek,mt8173-xhci", "mediatek,mtk-xhci";
reg = <0x1e1c0000 0x1000
0x1e1d0700 0x0100>;
reg-names = "mac", "ippc";
#address-cells = <1>;
#size-cells = <0>;
clocks = <&sysc MT7621_CLK_XTAL>;
clock-names = "sys_ck";
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 22 IRQ_TYPE_LEVEL_HIGH>;
};
Shiji, did you also submit a device tree patch somewhere? Not that
you're required to, for this patch to be accepted. I'm just curious.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 2/2] phy: Add driver for EyeQ5 Ethernet PHY wrapper
From: Vladimir Oltean @ 2026-02-27 17:14 UTC (permalink / raw)
To: Théo Lebrun
Cc: Vinod Koul, Neil Armstrong, linux-phy, linux-kernel, linux-mips,
Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260225-macb-phy-v7-2-e5211a61db56@bootlin.com>
On Wed, Feb 25, 2026 at 05:54:41PM +0100, Théo Lebrun wrote:
> +static int eq5_phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> +
> + if (eq5_phy_validate(phy, mode, submode, NULL))
> + return -EOPNOTSUPP;
Propagate the phy_validate() return code, don't generate your own.
-EINVAL should be preferable to -EOPNOTSUPP, so that callers can
distinguish between "phy_set_mode() not implemented" and "phy_set_mode()
failed".
(yeah, phy_set_mode() was made optional a while ago, IMO incorrectly,
but that's another story)
> +
> + if (submode == inst->phy_interface)
> + return 0;
I think this simple comparison fails to serve its intended purpose
(avoid PHY reset when not changing modes) for RGMII modes, of which
there exist 4 variants.
Maybe:
if ((phy_interface_mode_is_rgmii(submode) &&
phy_interface_mode_is_rgmii(inst->phy_interface)) ||
submode == inst->phy_interface)
return 0;
Does the EyeQ5 platform support internal RGMII delays? If yes, which
layer enables them? The Generic PHY?
> +
> + inst->phy_interface = submode;
> +
> + if (phy->power_count) {
> + eq5_phy_init(phy);
> + return eq5_phy_power_on(phy);
> + }
> +
> + return 0;
> +}
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config
From: Konrad Dybcio @ 2026-02-27 16:50 UTC (permalink / raw)
To: xiangxu.yin, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel, fange.zhang, yongxing.mou,
li.liu, tingwei.zhang, Konrad Dybcio, Dan Carpenter
In-Reply-To: <20260227-master-v1-1-8d91b9407fdb@oss.qualcomm.com>
On 2/27/26 1:15 PM, Xiangxu Yin via B4 Relay wrote:
> From: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com>
>
> swing_tbl and pre_emphasis_tbl are 4x4 arrays (valid indices 0-3), but
> the boundary check uses "> 4" instead of ">= 4", allowing index 4 to
> cause an out-of-bounds access.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Fixes: 81791c45c8e0 ("phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config and DP mode support")
> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 0/8] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Vladimir Oltean @ 2026-02-27 15:48 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet, Andrew Lunn,
Paolo Abeni <pabeni@redhat.com>, David S. Miller,
Andrew Lunn
Cc: Russell King (Oracle), Alexandre Torgue, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Vinod Koul
In-Reply-To: <aaDSJAc-x2-klvHJ@shell.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:07:16PM +0000, Russell King (Oracle) wrote:
> This is part 2 of the qcom-ethqos series, part 1 has now been merged.
>
> This part of the series focuses on the generic PHY driver, but these
> changes have dependencies on the ethernet driver, hence why
> it will need to go via net-next. Furthermore, subsequent changes
> depend on these patches.
>
> The underlying ideas here are:
>
> - get rid of the driver using phy_set_speed() with SPEED_1000 and
> SPEED_2500 which makes no sense for an ethernet SerDes due to the
> PCS 8B10B data encoding, which inflates the data rate at the SerDes
> compared to the MAC. This is replaced with phy_set_mode_ext().
> - allow phy_power_on() / phy_set_mode*() to be called in any order.
>
> Mohd has tested this series, but it would be great to get acks/reviews
> from the generic PHY maintainers.
>
> .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 31 +++--------
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 62 +++++++++++++++++-----
> 2 files changed, 57 insertions(+), 36 deletions(-)
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>
Reiterating Vinod's request to netdev maintainers from here, just
because it's easy to get lost in the multiple patch versions:
https://lore.kernel.org/netdev/aaGgWUpM2A5y11Wh@vaman/
Can we please get a tag to pull into linux-phy when this gets merged
in net-next? I'm also working on a patch set for phy-next which will
conflict with this series.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 6/8] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()
From: Vladimir Oltean @ 2026-02-27 15:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vvkUN-0000000AuPR-2qKj@rmk-PC.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:09:47PM +0000, Russell King (Oracle) wrote:
> Now that qcom_dwmac_sgmii_phy_interface() only serves to validate the
> passed interface mode, combine it with qcom_dwmac_sgmii_phy_validate(),
> and use qcom_dwmac_sgmii_phy_validate() to validate the mode in
> qcom_dwmac_sgmii_phy_set_mode().
>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 5/8] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings
From: Vladimir Oltean @ 2026-02-27 15:40 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vvkUI-0000000AuPK-2IBa@rmk-PC.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:09:42PM +0000, Russell King (Oracle) wrote:
> As established in the previous commit, using SPEED_1000 and SPEED_2500
> does not make sense for a SerDes due to the PCS encoding that is used
> over the SerDes link, which inflates the data rate at the SerDes. Thus,
> the use of these constants in a SerDes driver is incorrect.
>
> Since qcom-sgmii-eth no longer implements phy_set_speed(), but instead
> uses the PHY interface mode passed via the .set_mode() method, convert
> the driver to use the PHY interface mode internally to decide whether
> to configure the SerDes for 1.25Gbps or 3.125Gbps mode.
>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 4/8] phy: qcom-sgmii-eth: remove .set_speed() implementation
From: Vladimir Oltean @ 2026-02-27 15:39 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vvkUD-0000000AuPE-1l06@rmk-PC.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:09:37PM +0000, Russell King (Oracle) wrote:
> Now that the qcom-ethqos driver has migrated to use phy_set_mode_ext()
> rather than phy_set_speed() to configure the SerDes, the support for
> phy_set_speed() is now obsolete. Remove support for this method.
>
> Using the MAC speed for the SerDes is never correct due to the PCS
> encoding. For SGMII and 2500BASE-X, the PCS uses 8B10B encoding, and
> so:
>
> MAC rate * PCS output bits / PCS input bits = SerDes rate
> 1000M * 10 / 8 = 1250M
> 2500M * 10 / 8 = 3125M
>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 7/8] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()
From: Vladimir Oltean @ 2026-02-27 15:37 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vvkUS-0000000AuPh-3Il7@rmk-PC.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:09:52PM +0000, Russell King (Oracle) wrote:
> Allow any order of the .power_on() and .set_mode*() methods as per the
> recent discussion. This means phy_power_on() with this SerDes will now
> restore the previous setup without requiring a subsequent
> phy_set_mode*() call.
>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RESEND2 net-next 8/8] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
From: Vladimir Oltean @ 2026-02-27 15:31 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vvkUX-0000000AuPo-3mEw@rmk-PC.armlinux.org.uk>
On Thu, Feb 26, 2026 at 11:09:57PM +0000, Russell King (Oracle) wrote:
> The call to phy_set_mode_ext() after phy_power_on() was a work-around
> for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on
> phy_power_on() but did not configure the PHY. Now that the SerDes driver
> fully configures the SerDes at phy_power_on(), there is no need to call
> phy_set_mode_ext() immediately afterwards.
>
> This also means we no longer need to record the previous operating mode
> of the driver - this is up to the SerDes driver. In any case, the only
> thing that we care about is the SerDes provides the necessary clocks to
> the stmmac core to allow it to reset at this point. The actual mode is
> irrelevant at this point as the correct mode will be configured in
> ethqos_mac_finish_serdes() just before the network device is brought
> online.
>
> Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Russell King (Oracle) @ 2026-02-27 15:30 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Andrew Lunn, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni
In-Reply-To: <20260227152707.k5lobznug3xxxc7h@skbuf>
On Fri, Feb 27, 2026 at 05:27:07PM +0200, Vladimir Oltean wrote:
> Hi Vinod,
>
> On Fri, Feb 27, 2026 at 07:17:05PM +0530, Vinod Koul wrote:
> > On 25-02-26, 09:02, Russell King (Oracle) wrote:
> > > Note: only 8 patches in this series, not 9 as the subject line says,
> > > as the set_clk_tx_rate() patch became part of the first series.
> > >
> > > On Wed, Feb 25, 2026 at 09:00:41AM +0000, Russell King (Oracle) wrote:
> > > > This is part 2 of the qcom-ethqos series, part 1 has now been merged.
> > > >
> > > > This part of the series focuses on the generic PHY driver, but these
> > > > changes have dependencies on the ethernet driver, hence why
> > > > it will need to go via net-next. Furthermore, subsequent changes
> > > > depend on these patches.
> >
> > This lgtm, can we get signed tag so that we can pull this into phy tree
> > as well
>
> I think this series is obsolete. It has been superseded in the netdev
> patchwork by:
>
> [PATCH RESEND2 net-next 0/8] net: stmmac: qcom-ethqos: further serdes reorganisation
> ├─>[PATCH RESEND2 net-next 1/8] net: stmmac: qcom-ethqos: move ethqos_set_serdes_speed()
> ├─>[PATCH RESEND2 net-next 2/8] phy: qcom-sgmii-eth: add .set_mode() and .validate() methods
> ├─>[PATCH RESEND2 net-next 3/8] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
> ├─>[PATCH RESEND2 net-next 4/8] phy: qcom-sgmii-eth: remove .set_speed() implementation
> ├─>[PATCH RESEND2 net-next 5/8] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings
> ├─>[PATCH RESEND2 net-next 6/8] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()
> ├─>[PATCH RESEND2 net-next 7/8] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()
> └─>[PATCH RESEND2 net-next 8/8] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
>
> (with which it is only partially overlapping)
>
> I guess you should give your Acks there as well.
No need. Looking at PW, it seems patch 7 has AI review issues, so will
need to be re-sent - although I can't fathom what the AI found in patch
7. I've already added Vinod's acks (since they were just resends to fix
botched sending, no actual changes in the patches themselves.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Abel Vesa
Cc: Nitin Rawat, Konrad Dybcio, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260223-eliza-bindings-phy-ufs-v3-1-2b0c0f00bcb6@oss.qualcomm.com>
On Mon, 23 Feb 2026 10:19:38 +0200, Abel Vesa wrote:
> Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
> compatible with the PHY implemented in SM8650, so use the SM8650
> compatible as fallback.
>
> While at it, move the QCS8300 one so that it is sorted correctly by
> fallback compatible.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
commit: caf08514bbee0736c31d8d4f406e3415cdf726bb
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom: m31-eusb2: clear PLL_EN during init
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: Konrad Dybcio, Neil Armstrong, Wesley Cheng, Johan Hovold,
Dmitry Baryshkov, Elson Serrao
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260217201130.2804550-1-elson.serrao@oss.qualcomm.com>
On Tue, 17 Feb 2026 12:11:30 -0800, Elson Serrao wrote:
> The driver currently sets bit 0 of USB_PHY_CFG1 (PLL_EN) during PHY
> initialization. According to the M31 EUSB2 PHY hardware documentation,
> this bit is intended only for test/debug scenarios and does not control
> mission mode operation. Keeping PLL_EN asserted causes the PHY to draw
> additional current during USB bus suspend. Clearing this bit results in
> lower suspend power consumption without affecting normal operation.
>
> [...]
Applied, thanks!
[1/1] phy: qcom: m31-eusb2: clear PLL_EN during init
commit: 520a98bdf7ae0130e22d8adced3d69a2e211b41f
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 0/2] Add driver support for Eswin EIC7700 SoC SATA PHY
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: neil.armstrong, robh, krzk+dt, conor+dt, p.zabel, linux-phy,
devicetree, linux-kernel, Yulin Lu
Cc: ningyu, linmin, fenglin
In-Reply-To: <20260205082009.1780-1-luyulin@eswincomputing.com>
On Thu, 05 Feb 2026 16:20:09 +0800, Yulin Lu wrote:
> Updates:
> v9 -> v8:
> - eswin,eic7700-sata-phy.yaml
> - Modify the format of the "default" field in the
> "eswin,tx-amplitude-tuning" and "eswin,tx-preemph-tuning"
> properties.
> - phy-eic7700-sata.c
> - Correct the incorrectly formatted symbol "-" in the comments.
> - Link to v8: https://lore.kernel.org/lkml/20260123024823.1612-1-luyulin@eswincomputing.com/
>
> [...]
Applied, thanks!
[1/2] dt-bindings: phy: eswin: Document the EIC7700 SoC SATA PHY
commit: 820265f7b666d588bcb7df06f3332265c59e8cea
[2/2] phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver
commit: 67ee9ccaa34a11c317411bb8e7d305d93d0b4111
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next v2] phy: apple: apple: Use local variable for ioremap return value
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: Sven Peter, Neal Gompa, Neil Armstrong, Philipp Zabel,
Janne Grunau
Cc: asahi, linux-phy, linux-kernel, linux-arm-kernel, Dan Carpenter,
Vladimir Oltean
In-Reply-To: <20260215-phy-apple-resource-err-ptr-v2-1-e43c22453682@jannau.net>
On Sun, 15 Feb 2026 09:02:51 +0100, Janne Grunau wrote:
> The indirection through the resources array is unnecessarily complicated
> and resuling in using IS_ERR() and PTR_ERR() on a valid address. A local
> variable for the devm_ioremap_resource() return value is both easier to
> read and matches expectations when reading code.
>
>
Applied, thanks!
[1/1] phy: apple: apple: Use local variable for ioremap return value
commit: 290a35756aaef85bbe0527eaf451f533a61b5f6c
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: apple: atc: Make atcphy_dwc3_reset_ops variable static
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Neil Armstrong,
Philipp Zabel, asahi, linux-arm-kernel, linux-phy, linux-kernel,
linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <20260216110413.159994-4-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 16 Feb 2026 12:04:14 +0100, Krzysztof Kozlowski wrote:
> File-scope 'atcphy_dwc3_reset_ops' is not used outside of this unit, so
> make it static to silence sparse warning:
>
> atc.c:2026:32: warning: symbol 'atcphy_dwc3_reset_ops' was not declared. Should it be static?
>
>
Applied, thanks!
[1/3] phy: apple: atc: Make atcphy_dwc3_reset_ops variable static
commit: b3fddddf3fb49c7472e73680d6ea5d771f9514e8
[2/3] phy: marvell: mmp3-hsic: Avoid re-casting __iomem
commit: c77eee5b44b8d32d471cf17fa193b395e321ef37
[3/3] phy: qcom: qmp-usbc: Simplify check for non-NULL pointer
commit: b6b7d1ae0653dcaa356be31c0de221311e922ccd
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/6] Add support for mt8167 display blocks
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: linux-mediatek, Luca Leonardo Scorcia
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Neil Armstrong,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
On Mon, 23 Feb 2026 16:22:44 +0000, Luca Leonardo Scorcia wrote:
> This series adds support for the display blocks on MediaTek mt8167.
> Tested on Xiaomi Mi Smart Clock x04g.
>
> The first patch just does some reordering of dts nodes with no other
> changes as this makes later patches cleaner and easier to follow.
>
> v3:
> - Added mt8167-dsi compatible to driver instead of changing the binding;
> - Resolved patch formatting issues.
>
> [...]
Applied, thanks!
[3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
commit: 7df891f2c39442c120fb4f9bfdd7c80e6de84015
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v5 0/4] Add USB support for Canaan K230
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: gregkh, conor, Jiayu Du
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex, linux-phy,
linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
On Wed, 21 Jan 2026 22:55:21 +0800, Jiayu Du wrote:
> Add support for the USB PHY and DWC2 IP which is used by Canaan K230,
> and made relevant changes to the DTS.
>
> This series is based on the initial 100ask K230 DshanPi series [1] which
> is based on the clock and pinctrl series. Check the details in the link.
>
> Link: https://lore.kernel.org/all/20260115060801.16819-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
>
> [...]
Applied, thanks!
[1/4] dt-bindings: phy: Add Canaan K230 USB PHY
commit: 50357e7d7992ba8f02c87ff7a5c4db17918635da
[3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
commit: 8787fa1da603e9e51efff11841e97b5d374aef34
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: phy-mtk-tphy: Update names and format of kernel-doc comments
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: linux-phy, Vinod Koul; +Cc: Neil Armstrong, Vladimir Oltean, chunfeng.yun
In-Reply-To: <20260223071032.408425-1-vkoul@kernel.org>
On Mon, 23 Feb 2026 12:40:32 +0530, Vinod Koul wrote:
> mtk_phy_pdata documentation does not use correct tag for struct, while at
> it fix one of member wrongly documented.
>
> Warning: drivers/phy/mediatek/phy-mtk-tphy.c:289 cannot understand function prototype: 'struct mtk_phy_pdata'
> Warning: drivers/phy/mediatek/phy-mtk-tphy.c:296 struct member 'slew_ref_clock_mhz' not described in 'mtk_phy_pdata'
>
>
> [...]
Applied, thanks!
[1/1] phy: phy-mtk-tphy: Update names and format of kernel-doc comments
commit: 8d869bc943cfe5db08f5aff355b1d8d3abeda865
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: Sort the subsystem Kconfig
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: linux-phy, Vinod Koul; +Cc: Neil Armstrong, Vladimir Oltean
In-Reply-To: <20260223065819.395612-1-vkoul@kernel.org>
On Mon, 23 Feb 2026 12:28:19 +0530, Vinod Koul wrote:
> Kconfig is supposed to be sorted alphabetically, sadly it has bitrotted
> so fix that
>
>
Applied, thanks!
[1/1] phy: Sort the subsystem Kconfig
commit: dee40773abe543723adab47319bc25dc70de10a2
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: Sort the subsystem Makefile
From: Vinod Koul @ 2026-02-27 15:29 UTC (permalink / raw)
To: linux-phy, Vinod Koul; +Cc: Neil Armstrong, Vladimir Oltean
In-Reply-To: <20260223065743.395539-1-vkoul@kernel.org>
On Mon, 23 Feb 2026 12:27:43 +0530, Vinod Koul wrote:
> Makefile is supposed to be sorted alphabetically, sadly it has bitrotted
> so fix that
>
>
Applied, thanks!
[1/1] phy: Sort the subsystem Makefile
commit: d8f0ef2aebaa90c0155e266c1fdd6fa2aef44bb1
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox