* [RESEND PATCH 0/3] phy: zynqmp: fix SERDES scrambler register handling and enable for USB
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Radhey Shyam Pandey
This series fixes three related issues in the ZynqMP SERDES PHY
scrambler/encoder bypass path:
1. The L0_TM_DISABLE_SCRAMBLE_ENCODER mask incorrectly included bit 2
of L0_TX_DIG_61, which is a reserved read-only field. Correct the
mask to (BIT(3) | GENMASK(1, 0)).
2. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which
performs a full register write, clobbering unrelated bits. Switch
to xpsgtr_clr_set_phy() with clr=mask, set=mask to preserve other
register fields.
3. USB Gen1 requires PHY-side scrambling and 8b/10b encoding as
mandated by the USB 3.x specification. The driver was incorrectly
bypassing these for USB, the same as SATA and SGMII where encoding
is handled in the controller.
Issues reported by sashiko[1] are pre-existing issues and will
taken as separate followup series.
[1]:
https://lore.kernel.org/all/20260512213513.852EEC2BCB0@smtp.kernel.org
https://lore.kernel.org/all/20260512223142.1AFC4C2BCB0@smtp.kernel.org
Nava kishore Manne (3):
phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
phy: zynqmp: use read-modify-write for SERDES scrambler bypass
phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
drivers/phy/xilinx/phy-zynqmp.c | 37 ++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [RESEND PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Nava kishore Manne,
stable, Radhey Shyam Pandey
In-Reply-To: <20260627155229.2791113-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
USB Gen1 requires scrambling and 8b/10b encoding to be performed in the
physical layer. Do not bypass PHY-side scrambler or encoder/decoder for
USB operation, as mandated by the USB 3.x specification.
Scrambler and 8b/10b bypass remain restricted to SATA and SGMII
modes, where encoding is handled in the controller.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 39 ++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index 6c56c4df8523..087fe402e4e2 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -502,15 +502,30 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
}
}
-/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
-static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
+/**
+ * xpsgtr_bypass_scrambler_8b10b - Configure scrambler/encoder behavior
+ * @gtr_phy: pointer to lane context
+ * @bypass: true to enable scrambler/encoder bypass (SATA/SGMII),
+ * false to disable scrambler/encoder bypass (USB3)
+ *
+ * Uses RMW to preserve reserved and unrelated register fields.
+ */
+static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy,
+ bool bypass)
{
- xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
- L0_TM_DIS_DESCRAMBLE_DECODER,
- L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
- L0_TM_DISABLE_SCRAMBLE_ENCODER,
- L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ if (bypass) {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ } else {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER, 0);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER, 0);
+ }
}
/* DP-specific initialization. */
@@ -531,7 +546,7 @@ static void xpsgtr_phy_init_sata(struct xpsgtr_phy *gtr_phy)
{
struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
writel(gtr_phy->lane, gtr_dev->siou + SATA_CONTROL_OFFSET);
}
@@ -547,7 +562,7 @@ static void xpsgtr_phy_init_sgmii(struct xpsgtr_phy *gtr_phy)
xpsgtr_clr_set(gtr_dev, TX_PROT_BUS_WIDTH, mask, val);
xpsgtr_clr_set(gtr_dev, RX_PROT_BUS_WIDTH, mask, val);
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
}
/* Configure TX de-emphasis and margining for DP. */
@@ -707,6 +722,10 @@ static int xpsgtr_phy_init(struct phy *phy)
case ICM_PROTOCOL_SGMII:
xpsgtr_phy_init_sgmii(gtr_phy);
break;
+
+ case ICM_PROTOCOL_USB:
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, false);
+ break;
}
out:
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [RESEND PATCH 2/3] phy: zynqmp: use read-modify-write for SERDES scrambler bypass
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Nava kishore Manne,
stable, Radhey Shyam Pandey
In-Reply-To: <20260627155229.2791113-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which performs
a full register write, silently clearing any bits beyond the intended
bypass control fields.
Switch to xpsgtr_clr_set_phy() with clr=mask, set=mask to set only
the bypass bits while preserving the remaining bits in each register.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index c037d7c13d48..6c56c4df8523 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -505,8 +505,12 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
{
- xpsgtr_write_phy(gtr_phy, L0_TM_DIG_6, L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_write_phy(gtr_phy, L0_TX_DIG_61, L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
}
/* DP-specific initialization. */
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [RESEND PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
From: sashiko-bot @ 2026-06-27 16:02 UTC (permalink / raw)
To: Radhey Shyam Pandey; +Cc: linux-phy, vkoul, neil.armstrong, olteanv
In-Reply-To: <20260627155229.2791113-4-radhey.shyam.pandey@amd.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] PCIe and DisplayPort (DP) protocols lack explicit initialization of the scrambler/encoder bypass state, leaving them vulnerable to state pollution.
- [High] Silently ignores clock enable failure, masking the error and causing unbalanced clock disables later.
- [High] Bus width registers modified by SGMII are not reset by other protocols, risking state inheritance bugs.
--
commit e6d5f06ce31b70c624ec3e6a69c5b7e7ef55746a
Author: Nava kishore Manne <nava.kishore.manne@amd.com>
Subject: phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
This commit ensures that the scrambler and 8b/10b encoder/decoder are not
bypassed for USB operation, as mandated by the USB 3.x specification. The
bypass functionality is restricted to SATA and SGMII modes where encoding is
handled in the controller.
Cc: stable@vger.kernel.org
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index 6c56c4df8523c..087fe402e4e20 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
[ ... ]
> @@ -547,7 +562,7 @@ static void xpsgtr_phy_init_sgmii(struct xpsgtr_phy *gtr_phy)
> xpsgtr_clr_set(gtr_dev, TX_PROT_BUS_WIDTH, mask, val);
> xpsgtr_clr_set(gtr_dev, RX_PROT_BUS_WIDTH, mask, val);
[Severity: High]
This isn't a bug introduced by this patch, but SGMII alters the global bus
width registers here without other protocols guaranteeing they are restored to
default states.
If a lane previously used for SGMII is reassigned to another protocol (e.g.,
via warm reboot or bootloader handoff), will the 10-bit bus width setting
persist in the hardware and silently break other protocols (like USB or PCIe)
that expect their default bus widths?
>
> - xpsgtr_bypass_scrambler_8b10b(gtr_phy);
> + xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
> }
[ ... ]
> @@ -707,6 +722,10 @@ static int xpsgtr_phy_init(struct phy *phy)
> case ICM_PROTOCOL_SGMII:
> xpsgtr_phy_init_sgmii(gtr_phy);
> break;
> +
> + case ICM_PROTOCOL_USB:
> + xpsgtr_bypass_scrambler_8b10b(gtr_phy, false);
> + break;
[Severity: High]
This isn't a bug introduced by this patch, but the switch statement in
xpsgtr_phy_init() misses explicit bypass configuration for DP and PCIe.
If a lane is dynamically reassigned or left bypassed by previous boot stages,
will DP and PCIe silently fail as they inherit a stale bypass = true state?
> }
>
> out:
[Severity: High]
This isn't a bug introduced by this patch, but looking at xpsgtr_phy_init(),
could the clock error path cause issues here?
drivers/phy/xilinx/phy-zynqmp.c:xpsgtr_phy_init() {
int ret = 0;
...
if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
goto out;
...
out:
mutex_unlock(>r_dev->gtr_mutex);
return ret;
}
If clk_prepare_enable() fails, we branch to 'out', but 'ret' remains 0. Will
this silently ignore the clock enable failure, mask the error, and cause
unbalanced clock disables later when xpsgtr_phy_exit() calls
clk_disable_unprepare() on a clock that was never successfully enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627155229.2791113-1-radhey.shyam.pandey@amd.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RESEND PATCH 2/3] phy: zynqmp: use read-modify-write for SERDES scrambler bypass
From: sashiko-bot @ 2026-06-27 16:02 UTC (permalink / raw)
To: Radhey Shyam Pandey; +Cc: neil.armstrong, vkoul, olteanv, linux-phy
In-Reply-To: <20260627155229.2791113-3-radhey.shyam.pandey@amd.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The error code from clk_prepare_enable() is not propagated, causing a false success return.
- [High] Missing clk_disable_unprepare() on error paths causes a clock resource leak.
--
commit 5cbba5539e34550743b9636376f1a41a65d04bb8
Author: Nava kishore Manne <nava.kishore.manne@amd.com>
phy: zynqmp: use read-modify-write for SERDES scrambler bypass
This commit switches xpsgtr_bypass_scrambler_8b10b() to use
xpsgtr_clr_set_phy() instead of xpsgtr_write_phy(). This modifies only the
bypass bits while preserving the rest of the register fields.
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index c037d7c13d485..6c56c4df8523c 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -505,8 +505,12 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
> /* Bypass (de)scrambler and 8b/10b decoder and encoder. */
> static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
> {
[ ... ]
> static int xpsgtr_phy_init(struct phy *phy)
> {
> struct xpsgtr_phy *gtr_phy = phy_get_drvdata(phy);
> struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
> int ret = 0;
>
> mutex_lock(>r_dev->gtr_mutex);
>
> /* Configure and enable the clock when peripheral phy_init call */
> if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
> goto out;
[Severity: High]
This is a pre-existing issue, but does this error path fail to set the
return code?
When clk_prepare_enable() fails, it jumps to 'out' while 'ret'
is still 0, leading to a false success return. This can cause the PHY
framework to assume the PHY is initialized.
>
> /* Skip initialization if not required. */
> if (!xpsgtr_phy_init_required(gtr_phy))
> goto out;
>
> if (gtr_dev->tx_term_fix) {
> ret = xpsgtr_phy_tx_term_fix(gtr_phy);
> if (ret < 0)
> goto out;
[Severity: High]
This is a pre-existing issue, but does this error path jump to 'out' without
disabling the previously enabled clock?
Because 'ret' is negative here, the PHY framework considers the
initialization failed and won't call xpsgtr_phy_exit(). This results in
a permanent clock resource leak.
>
> gtr_dev->tx_term_fix = false;
> }
>
> /* Enable coarse code saturation limiting logic. */
> xpsgtr_write_phy(gtr_phy, L0_TM_PLL_DIG_37, L0_TM_COARSE_CODE_LIMIT);
>
> /*
> * Configure the PLL, the lane protocol, and perform protocol-specific
> * initialization.
> */
> ret = xpsgtr_configure_pll(gtr_phy);
> if (ret)
> goto out;
[Severity: High]
This is a pre-existing issue, but does this error path also leak the clock?
Like the tx_term_fix failure above, this jumps to 'out' without calling
clk_disable_unprepare() on the clock enabled at the start of the function.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627155229.2791113-1-radhey.shyam.pandey@amd.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RESEND PATCH 1/3] phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
From: sashiko-bot @ 2026-06-27 16:02 UTC (permalink / raw)
To: Radhey Shyam Pandey; +Cc: vkoul, neil.armstrong, linux-phy, olteanv
In-Reply-To: <20260627155229.2791113-2-radhey.shyam.pandey@amd.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The return value of clk_prepare_enable() is not captured, leading to a masked error and potential hardware faults.
- [Medium] Missing clk_disable_unprepare() on error paths causes a clock reference count leak.
--
commit b562ec219de1a77ec468ae7c48ab00117de6c7d1
Author: Nava kishore Manne <nava.kishore.manne@amd.com>
phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
This patch fixes the L0_TM_DISABLE_SCRAMBLE_ENCODER mask in the ZynqMP
PHY driver. The previous mask incorrectly included a reserved read-only
field, which has now been excluded.
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index fe6b4925d1662..c037d7c13d485 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -53,7 +53,7 @@
> #define L0_TM_DIG_6 0x106c
> #define L0_TM_DIS_DESCRAMBLE_DECODER 0x0f
> #define L0_TX_DIG_61 0x00f4
> -#define L0_TM_DISABLE_SCRAMBLE_ENCODER 0x0f
> +#define L0_TM_DISABLE_SCRAMBLE_ENCODER (BIT(3) | GENMASK(1, 0))
>
> /* PLL Test Mode register parameters */
> #define L0_TM_PLL_DIG_37 0x2094
[Severity: High]
This is a pre-existing issue, but does xpsgtr_phy_init() improperly mask
errors if the clock fails to enable?
drivers/phy/xilinx/phy-zynqmp.c:xpsgtr_phy_init() {
...
/* Configure and enable the clock when peripheral phy_init call */
if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
goto out;
...
out:
mutex_unlock(>r_dev->gtr_mutex);
return ret;
}
Since ret is initialized to 0 and the error from clk_prepare_enable() isn't
assigned to it, this function will return 0 on failure.
This could cause the PHY framework to mistakenly believe the PHY is
initialized, potentially leading to unclocked register accesses and system
hangs.
[Severity: Medium]
This is also a pre-existing issue, but could this result in a clock
reference count leak on error paths?
drivers/phy/xilinx/phy-zynqmp.c:xpsgtr_phy_init() {
...
if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
goto out;
/* Skip initialization if not required. */
if (!xpsgtr_phy_init_required(gtr_phy))
goto out;
if (gtr_dev->tx_term_fix) {
ret = xpsgtr_phy_tx_term_fix(gtr_phy);
if (ret < 0)
goto out;
...
If a subsequent step like xpsgtr_phy_tx_term_fix() or xpsgtr_configure_pll()
fails, the function jumps to out and returns an error without calling
clk_disable_unprepare().
Because the initialization failed, phy_exit() will not be called by the
framework, leaving the clock prepared and enabled indefinitely.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627155229.2791113-1-radhey.shyam.pandey@amd.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Radhey Shyam Pandey as ZynqMP PHY maintainer
From: Radhey Shyam Pandey @ 2026-06-27 16:22 UTC (permalink / raw)
To: laurent.pinchart, tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Radhey Shyam Pandey
I am maintaining phy-zynqmp driver in xilinx tree and would like to
maintain it in the mainline kernel as well. Hence adding myself as a
maintainer.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1705eb823dd0..90dd86437c5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29645,6 +29645,7 @@ F: drivers/edac/zynqmp_edac.c
XILINX ZYNQMP PSGTR PHY DRIVER
M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+M: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
L: linux-kernel@vger.kernel.org
S: Supported
T: git https://github.com/Xilinx/linux-xlnx.git
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net v5 0/2] net: phy: sfp: fix mii_bus leak and revert RollBall bridge probe
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
v4 tried to fix the RollBall regression from 8fe125892f40 by deferring the
bridge probe to PHY discovery time. Maxime Chevallier and Aleksander
Bajkowski both tested that on genuine RollBall hardware and confirmed it
does not restore PHY detection (the module still is not ready when the
probe runs), and the Sashiko static review flagged the same path.
So this version drops the deferred-probe patch and instead reverts
8fe125892f40, restoring the pre-regression behaviour for genuine RollBall
modules. A proper fix for slow-initializing modules needs per-module init
timing (a longer module_t_wait / a per-module quirk) and genuine RollBall
hardware to validate; that is better owned as a follow-up by someone with
such a module.
Patch 1 is the independent mii_bus leak fix, unchanged, now carrying
Reviewed-by from Maxime and Larysa.
Patch 2 reverts 8fe125892f40.
v4: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Petr Wozniak (2):
net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in
mdio-i2c"
drivers/net/mdio/mdio-i2c.c | 59 +++++--------------------------------
drivers/net/phy/sfp.c | 15 +++-------
2 files changed, 11 insertions(+), 63 deletions(-)
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH net v5 1/2] net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak,
Larysa Zaremba
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().
Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release")
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
---
drivers/net/phy/sfp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db9..c4d274ab651e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -963,6 +963,7 @@ static int sfp_i2c_mdiobus_create(struct sfp *sfp)
static void sfp_i2c_mdiobus_destroy(struct sfp *sfp)
{
mdiobus_unregister(sfp->i2c_mii);
+ mdiobus_free(sfp->i2c_mii);
sfp->i2c_mii = NULL;
}
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net v5 2/2] Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
This reverts commit 8fe125892f40 ("net: phy: sfp: probe for RollBall
I2C-to-MDIO bridge in mdio-i2c").
That commit added a RollBall bridge probe at MDIO bus creation time, in
i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on
modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT,
before genuine RollBall modules have finished their firmware/bridge
initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The
probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection
is then skipped for genuine RollBall modules that worked before the commit.
This was confirmed on hardware by Maxime Chevallier and Aleksander
Bajkowski: their RollBall modules no longer detect a PHY, and work again
on v7.0 (before the bridge probing was introduced). The Sashiko static
review flagged the same path.
Deferring the probe to PHY discovery time does not fix it either: at that
point a slow module may still be initializing, so the probe still returns
-ENODEV. A proper fix needs per-module init timing (a longer module_t_wait
or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms
after insertion), which requires genuine RollBall hardware to develop and
validate. Revert to restore the previous, working behaviour in the meantime.
The RTL8261BE retry-loop latency that the reverted commit addressed is
handled in our downstream tree, so reverting upstream is safe on our side.
Fixes: 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c")
Reported-by: Aleksander Bajkowski <olek2@wp.pl>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
drivers/net/mdio/mdio-i2c.c | 59 +++++--------------------------------
drivers/net/phy/sfp.c | 14 ++-------
2 files changed, 10 insertions(+), 63 deletions(-)
diff --git a/drivers/net/mdio/mdio-i2c.c b/drivers/net/mdio/mdio-i2c.c
index b88f63234b4e..ed20352a589a 100644
--- a/drivers/net/mdio/mdio-i2c.c
+++ b/drivers/net/mdio/mdio-i2c.c
@@ -419,50 +419,6 @@ static int i2c_mii_write_rollball(struct mii_bus *bus, int phy_id, int devad,
return 0;
}
-static int i2c_mii_probe_rollball(struct i2c_adapter *i2c)
-{
- u8 data_buf[] = { ROLLBALL_DATA_ADDR, 0x01, 0x00, 0x00 };
- u8 cmd_buf[] = { ROLLBALL_CMD_ADDR, ROLLBALL_CMD_READ };
- u8 cmd_addr = ROLLBALL_CMD_ADDR;
- struct i2c_msg msgs[2];
- u8 result;
- int ret;
- int i;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = sizeof(data_buf);
- msgs[0].buf = data_buf;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = 0;
- msgs[1].len = sizeof(cmd_buf);
- msgs[1].buf = cmd_buf;
-
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = 1;
- msgs[0].buf = &cmd_addr;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = I2C_M_RD;
- msgs[1].len = 1;
- msgs[1].buf = &result;
-
- for (i = 0; i < 10; i++) {
- msleep(20);
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
- if (result == ROLLBALL_CMD_DONE)
- return 0;
- }
-
- return -ENODEV;
-}
-
static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
{
struct i2c_msg msg;
@@ -482,11 +438,11 @@ static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
ret = i2c_transfer(i2c, &msg, 1);
if (ret < 0)
- return -ENODEV;
- if (ret != 1)
+ return ret;
+ else if (ret != 1)
return -EIO;
-
- return i2c_mii_probe_rollball(i2c);
+ else
+ return 0;
}
static bool mdio_i2c_check_functionality(struct i2c_adapter *i2c,
@@ -531,10 +487,9 @@ struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
case MDIO_I2C_ROLLBALL:
ret = i2c_mii_init_rollball(i2c);
if (ret < 0) {
- if (ret != -ENODEV)
- dev_err(parent,
- "Cannot initialize RollBall MDIO I2C protocol: %d\n",
- ret);
+ dev_err(parent,
+ "Cannot initialize RollBall MDIO I2C protocol: %d\n",
+ ret);
mdiobus_free(mii);
return ERR_PTR(ret);
}
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index c4d274ab651e..f520206734da 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -597,7 +597,6 @@ static const struct sfp_quirk sfp_quirks[] = {
// OEM SFP-GE-T is a 1000Base-T module with broken TX_FAULT indicator
SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
- SFP_QUIRK_F("OEM", "SFP-10G-T-I", sfp_fixup_rollball),
SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
SFP_QUIRK_S("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
SFP_QUIRK_S("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),
@@ -2174,17 +2173,10 @@ static void sfp_sm_fault(struct sfp *sfp, unsigned int next_state, bool warn)
static int sfp_sm_add_mdio_bus(struct sfp *sfp)
{
- int ret;
-
- if (sfp->mdio_protocol == MDIO_I2C_NONE)
- return 0;
+ if (sfp->mdio_protocol != MDIO_I2C_NONE)
+ return sfp_i2c_mdiobus_create(sfp);
- ret = sfp_i2c_mdiobus_create(sfp);
- if (ret == -ENODEV) {
- sfp->mdio_protocol = MDIO_I2C_NONE;
- return 0;
- }
- return ret;
+ return 0;
}
/* Probe a SFP for a PHY device if the module supports copper - the PHY
--
2.51.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Dmitry Baryshkov @ 2026-06-28 12:33 UTC (permalink / raw)
To: Kamal Wadhwa
Cc: Rakesh Kota, linux-arm-msm, sashiko-reviews, Komal Bajaj, robh,
linux-phy, neil.armstrong, vkoul, olteanv, krzk+dt, conor+dt,
devicetree
In-Reply-To: <bvankzuazswuigrm7hvyjqigzfaru5o43wi3zvyphgme2pgqwz@pyspqky3u6cn>
On Thu, Jun 25, 2026 at 09:11:19PM +0530, Kamal Wadhwa wrote:
> On Wed, Jun 17, 2026 at 03:48:14PM +0300, Dmitry Baryshkov wrote:
> > On Mon, 18 May 2026 at 14:49, Kamal Wadhwa
> > <kamal.wadhwa@oss.qualcomm.com> wrote:
> > >
> > > On Sun, May 17, 2026 at 08:18:15PM +0300, Dmitry Baryshkov wrote:
> > > > On Thu, May 14, 2026 at 04:09:18PM +0530, Kamal Wadhwa wrote:
> > > > > On Wed, May 13, 2026 at 06:14:20PM +0300, Dmitry Baryshkov wrote:
> > > > > > On 13/05/2026 17:29, Rakesh Kota wrote:
> > > > > > > On Wed, May 13, 2026 at 03:01:47PM +0300, Dmitry Baryshkov wrote:
> > > > > > > > On Wed, May 13, 2026 at 04:28:35AM +0000, sashiko-bot@kernel.org wrote:
> > > > > > > > > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > > > > > > > > - [High] The PMIC regulator definitions omit their required input supply dependencies (e.g., `vdd_s2-supply`, `vdd_l3-supply`), breaking the power hierarchy.
> > > > > > > > > - [Medium] The device tree inaccurately hardcodes the `compatible` string to a different PMIC model (`qcom,rpm-pm2250-regulators`) instead of explicitly identifying the actual hardware (PM4125).
> > > > > > > > > --
> > > > > > > > > > +
> > > > > > > > > > + pm4125_s2: s2 {
> > > > > > > > > > + regulator-min-microvolt = <1000000>;
> > > > > > > > > > + regulator-max-microvolt = <1200000>;
> > > > > > > > > > + };
> > > > > > > > >
> > > > > > > > > Do these regulators need to explicitly define their input supply dependencies
> > > > > > > > > such as vdd_s2-supply?
> > > > > > > > >
> > > > > > > > > Without these properties, the regulator framework might be unaware that the
> > > > > > > > > PMIC regulators draw power from upstream supplies.
> > > > > > > > >
> > > > > > > > > If the kernel dynamically manages the upstream supply and its reference count
> > > > > > > > > drops to zero, could it be disabled, causing an unexpected power loss for
> > > > > > > > > downstream components?
> > > > > > > >
> > > > > > > > And this is a correct comment. Please provide missing supplies.
> > > > > > > >
> > > > > > > As per the Qualcomm system design, the parent-child supply relationship
> > > > > > > is managed by the RPM firmware, not the Linux regulator framework. The
> > > > > > > RPM ensures the parent supply is never disabled until all subsystem
> > > > > > > votes are cleared.
> > > > > >
> > > > > > How is this different from other, previous platforms?
> > > > >
> > > > > This is not different. In the previous platforms too this is taken care from the
> > > > > RPM/RPMH firmware side, the only case where we may need explicit vote to parent
> > > > > is for non-rpmh/rpm regulator rails (like i2c based regulator pm8008), which
> > > > > may have a RPM/RPMH regulator as a parent.
> > > > >
> > > > > Even on those previous targets the parent rail of all RPM/RPMH regulators are
> > > > > internally voted by RPM/RPMH FW at proper voltage with required headroom
> > > > > calculated based on the active child rails. This was done for all the
> > > > > subsystems (including APPS) regulators.
> > > > >
> > > > > So no explicit handling from the APPS is required for parent supply.
> > > >
> > > > You are explaining the driver behaviour. But the question is about the
> > > > hardware description. If there is no difference, please add necessary
> > > > supplies back.
> > >
> > > I understand your concern about descibing the parent-child relation in the
> > > devicetree, and given that we have been almost always followed this for all
> > > the previous targets, it will expected of us to add them.
> >
> > Yes.
> >
> > >
> > > However, we want to avoid the unnecessary access to the parent from APPS.
> >
> > Why? What is the reason? Do we want to do the same for all the
> > platforms? Only for Shikra? Something else?
> >
> > > At the moment, I do not see a way to avoid that, if we add the parent
> > > regulators.
> >
> > That depend on the answer to the previous question. In the end, we can
> > make the driver ignore the parents by removing them from the regulator
> > desc.
>
> Ok, this seems like a good suggestion, so you mean its ok if we define the
> regulator desc's supply column with NULL? And only keep that in the DT?
>
> you mean like this?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/qcom-rpmh-regulator.c?h=v7.1#n1453
>
> (please let me know if i got that right. thanks)
Yes. Don't forget to explain in the commit message, why you are doing
so.
--
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] MAINTAINERS: Add Radhey Shyam Pandey as ZynqMP PHY maintainer
From: Laurent Pinchart @ 2026-06-28 21:12 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: tomi.valkeinen, vkoul, michal.simek, linux-kernel, linux-phy,
linux-arm-kernel
In-Reply-To: <20260627162233.2803425-1-radhey.shyam.pandey@amd.com>
On Sat, Jun 27, 2026 at 09:52:33PM +0530, Radhey Shyam Pandey wrote:
> I am maintaining phy-zynqmp driver in xilinx tree and would like to
> maintain it in the mainline kernel as well. Hence adding myself as a
> maintainer.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thank you for volunteering.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1705eb823dd0..90dd86437c5c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -29645,6 +29645,7 @@ F: drivers/edac/zynqmp_edac.c
>
> XILINX ZYNQMP PSGTR PHY DRIVER
> M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> +M: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> L: linux-kernel@vger.kernel.org
> S: Supported
> T: git https://github.com/Xilinx/linux-xlnx.git
>
> base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
Regards,
Laurent Pinchart
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Chaoyi Chen @ 2026-06-29 1:29 UTC (permalink / raw)
To: Xu Yang, Heikki Krogerus
Cc: Chaoyi Chen, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel
In-Reply-To: <erx73m2ueuvbzjteadjli6aki5by4pr3hyertkkqqoqwhaa4v3@5cstmshcercx>
Hello Xu Yang,
On 6/26/2026 7:15 PM, Xu Yang wrote:
> On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> The HPD function of Type-C DP is implemented through
>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>
>> To describe the relationship between the DP controller and the Type-C
>> port device, we usually using drm_bridge to build a bridge chain.
>>
>> Now several USB-C controller drivers have already implemented the DP
>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>> HPD bridge on USB-C connector port device.
>>
>> But this requires the USB-C controller driver to manually register the
>> HPD bridge. If the driver does not implement this feature, the bridge
>> will not be create.
>>
>> So this patch implements a generic DP HPD bridge based on
>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>> Type-C port device containing the DP svid is registered, it will
>> create an HPD bridge for it without the need for the USB-C controller
>> driver to implement it.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> ---
>>
>> (no changes since v14)
>>
>> Changes in v13:
>> - Only register drm dp hpd bridge for typec port altmode device.
>>
>> (no changes since v12)
>>
>> Changes in v11:
>> - Switch to using typec bus notifiers.
>>
>> (no changes since v10)
>>
>> Changes in v9:
>> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
>> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
>> - Add more commit comment about problem background.
>>
>> Changes in v8:
>> - Merge generic DP HPD bridge into one module.
>> ---
>>
>> drivers/gpu/drm/bridge/Kconfig | 10 ++++
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
>> 3 files changed, 60 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index a250afd8d662..559487aa09a9 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>> Simple bridge that terminates the bridge chain and provides HPD
>> support.
>>
>> +if DRM_AUX_HPD_BRIDGE
>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>> + tristate
>> + depends on TYPEC || !TYPEC
>> + default TYPEC
>> + help
>> + Simple bridge that terminates the bridge chain and provides HPD
>> + support. It build bridge on each USB-C connector device node.
>> +endif
>> +
>
> Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
> manually.
>
> $ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
> ./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
> ./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>
That's a fair point. But based on the previous discussion, Heikki
point out that configurations in the TYPEC subsystem should not
select configurations from DRM.
--
Best,
Chaoyi
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
From: Qiang Yu @ 2026-06-29 5:05 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <ab21f1c7-f861-4961-9287-84cae280d8c1@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 01:19:49PM +0200, Konrad Dybcio wrote:
> On 5/19/26 7:47 AM, Qiang Yu wrote:
> > Glymur PCIe3 uses a single shared Gen5x8 QMP PHY block. Model PCIe3a and
> > PCIe3b as consumers of that shared PHY provider instead of separate PHY
> > nodes.
> >
> > Update the DTS wiring to:
> > - point GCC PCIe3A/3B pipe parents to the shared PHY clock outputs
> > - add PCIe3a controller node and route PCIe3a/PCIe3b port phys to
> > &pcie3_phy using two-cell PHY arguments
> > - configure the shared PHY node with link-mode and dual pipe outputs
> >
> > Use QMP_PCIE_GLYMUR_MODE_* dt-binding macros for mode selection.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + pcie3a: pci@1c10000 {
> > + device_type = "pci";
> > + compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
> > + reg = <0x0 0x01c10000 0x0 0x3000>,
> > + <0x0 0x70000000 0x0 0xf20>,
> > + <0x0 0x70000f40 0x0 0xa8>,
> > + <0x0 0x70001000 0x0 0x4000>,
> > + <0x0 0x70100000 0x0 0x100000>,
> > + <0x0 0x01c13000 0x0 0x1000>;
> > + reg-names = "parf",
> > + "dbi",
> > + "elbi",
> > + "atu",
> > + "config",
> > + "mhi";
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
> > + <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
> > + <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>,
> > + <0x43000000 0x70 0x00000000 0x70 0x00000000 0x10 0x00000000>;
> > +
> > + bus-range = <0 0xff>;
> > +
> > + dma-coherent;
> > +
> > + linux,pci-domain = <3>;
> > + num-lanes = <8>;
>
> Is it fine to keep num-lanes 8 here even for configurations with
> bifurcated PHY?
>
> I would assume so, given essentially this is a x8 host, whose 4
> lanes may simply be effectively NC
>
Actually, on existing platforms, the PCIe3a and PCIe3b controllers are
never enabled at the same time. When PCIe3a is exposed, it is always in an
x8 slot. But if we have a x4+x4 platform in future, we can simply override
num-lanes to 4 in the board.dts.
- Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 1/9] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add glymur-qmp-gen5x8-pcie-phy compatible
From: Qiang Yu @ 2026-06-29 5:14 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <5dffdbe0-cbb9-429e-ba15-0afdf6f20fba@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 04:03:39PM +0200, Konrad Dybcio wrote:
> On 5/19/26 7:47 AM, Qiang Yu wrote:
> > The Glymur SoC uses a single PCIe Gen5 PHY hardware block for the
> > PCIe3a/PCIe3b controllers. This block supports two link modes:
> >
> > 1. x4+x4: two 4-lane PHY instances are exposed
> > 2. x8: one 8-lane PHY instance is exposed
> >
> > Add qcom,glymur-qmp-gen5x8-pcie-phy as a multi-mode PHY compatible and
> > document the new link-mode property, which selects the active link mode
> > via a TCSR syscon register.
> >
> > Document the required clocks, resets, and power-domains for both PHY
> > instances active in x8 mode. Use #phy-cells = <1> for this compatible,
> > where the cell value is the PHY index within the active link mode.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > @@ -68,20 +69,29 @@ properties:
> > - const: ref
> > - enum: [rchng, refgen]
> > - const: pipe
> > - - const: pipediv2
> > + - enum: [pipediv2, phy_b_aux]
>
> I'm surprised to learn 3A doesnm'doesn't have a PIPE_DIV2 clk.. it does have
> a non-div2 one though.
>
> Seems like it's specifically not the case on Hamoa and Makena, so perhaps
> it's better for maintainability if the Glymur list was separate
>
Do you mean splitting Glymur out into a separate YAML file for the PCIe3
PHY? I'll add a new file if that's preferred and Krzysztof is on board.
- Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 2/9] dt-bindings: phy: qcom-qmp: Add PHY selector and Glymur link-mode macros
From: Qiang Yu @ 2026-06-29 5:18 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <bb3dd1d0-af41-4ecf-b23a-3800aa5414ce@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 04:07:27PM +0200, Konrad Dybcio wrote:
> On 5/19/26 7:47 AM, Qiang Yu wrote:
> > Add two sets of constants to phy-qcom-qmp.h to support upcoming multiple
> > link mode QMP PHY:
> >
> > - QMP_PHY_SELECTOR_0 / QMP_PHY_SELECTOR_1: generic logical PHY index
> > values for QMP providers that expose multiple PHY instances under a
> > single DT node (i.e. #phy-cells = <1>).
> >
> > - QMP_PCIE_GLYMUR_MODE_X8 / QMP_PCIE_GLYMUR_MODE_X4X4: link-mode
> > values for the Glymur Gen5x8 PCIe PHY "qcom,link-mode" syscon property,
> > selecting between the x8 single-PHY and x4+x4 dual-PHY topologies.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > include/dt-bindings/phy/phy-qcom-qmp.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/dt-bindings/phy/phy-qcom-qmp.h b/include/dt-bindings/phy/phy-qcom-qmp.h
> > index 6b43ea9e0051..befa76f8392f 100644
> > --- a/include/dt-bindings/phy/phy-qcom-qmp.h
> > +++ b/include/dt-bindings/phy/phy-qcom-qmp.h
> > @@ -21,4 +21,12 @@
> > #define QMP_PCIE_PIPE_CLK 0
> > #define QMP_PCIE_PHY_AUX_CLK 1
> >
> > +/* Generic QMP logical PHY selectors */
> > +#define QMP_PHY_SELECTOR_0 0
> > +#define QMP_PHY_SELECTOR_1 1
>
> Is this for the second phy cell? FWIW I think it's fine to use raw
> numbers as they're just indices (i.e. "nth bifurcated phy") anyway
I can't use lane numbers. In x4+x4 case, I need to tell phy the first 4
lanes or second 4 lanes are required.
- Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers
From: Qiang Yu @ 2026-06-29 5:56 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Baryshkov, Manivannan Sadhasivam, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <1bbccb16-b91e-4116-a4cd-213a46978fa1@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 04:05:43PM +0200, Konrad Dybcio wrote:
> On 5/29/26 9:02 AM, Qiang Yu wrote:
> > On Thu, May 28, 2026 at 04:48:24PM +0300, Dmitry Baryshkov wrote:
> >> On Fri, May 22, 2026 at 04:27:35PM +0530, Manivannan Sadhasivam wrote:
> >>> On Wed, May 20, 2026 at 07:25:01PM +0300, Dmitry Baryshkov wrote:
> >>>> On Mon, May 18, 2026 at 10:47:16PM -0700, Qiang Yu wrote:
> >>>>> Some QMP PCIe PHY hardware blocks can be split into multiple sub-PHYs
> >>>>> under a single DT node, each requiring its own pipe clock registration and
> >>>>> DT resource mapping. The current helpers are tightly coupled to a single
> >>>>> qmp_pcie instance, which prevents reuse across sub-PHY instances.
> >>>>>
> >>>>> Refactor __phy_pipe_clk_register() as a generic helper and reduce
> >>>>> phy_pipe_clk_register() to a thin wrapper around it. Similarly, extract
> >>>>> qmp_pcie_parse_dt_common() from qmp_pcie_parse_dt() to hold the register-
> >>>>> mapping and pipe-clock setup that will be shared between sub-PHY instances,
> >>>>> with pipe clock names parameterised per instance.
> >>>>>
> >>>>> This is a preparatory step before adding multi-PHY support. No functional
> >>>>> change for existing platforms.
> >>>>>
> >>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>>>> ---
> >>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 76 ++++++++++++++++++--------------
> >>>>> 1 file changed, 44 insertions(+), 32 deletions(-)
> >>>>
> >>>> I'd suggest splitting the Glymur PHY to a separate driver. Otherwise we
> >>>> end up having too many single-platform, single-device specifics which
> >>>> don't apply to other platforms.
> >>>>
> >>>
> >>> I don't think that's really needed. This shared PHY concept is going to be
> >>> applicable to upcoming SoCs as well. And moreover, the split won't be clean
> >>> either. We still need to reuse a lot of common logic in the 'phy-qcom-qmp-pcie'
> >>> driver and may only end up keeping very minimal code in
> >>> 'phy-qcom-qmp-pcie-glymur'.
> >>
> >> Then splitting makes even more sense. Let's not clutter the existing
> >> driver with too many conditions and options.
> >>
> >>>
> >>> If you are concerned about the file size of 'phy-qcom-qmp-pcie', then we should
> >>> move the SoC specific 'cfg' structs into a separate file as that's what
> >>> occupying majority of the space.
> >>
> >> No, it's really the 'shared' part.
> >>
> >
> > To confirm, are you okay with some code duplication between the new
> > Glymur-specific driver and phy-qcom-qmp-pcie driver.
>
> That's a necessity, to some degree. See e.g. qmp-combo and qmp-usbc
>
I've already prototyped a separate Glymur driver, and it turned out better
than expected — there's actually not much duplication. The parts that do
overlap aren't fully identical either; they tend to diverge once the
Glymur-specific handling is factored in.
Currently, I meet an issue when tesing the patch, and will post it after
fixing the issue.
- Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH V1 0/2] arm64: dts: qcom: Shikra SD Card support
From: Monish Chunara @ 2026-06-29 7:13 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson, Kernel Team, linux-arm-msm, devicetree, linux-kernel,
linux-phy, linux-mmc, Nitin Rawat, Pradeep Pragallapati,
Komal Bajaj, Konrad Dybcio
In-Reply-To: <boo7p6mgop7rarfu3rfsrfah6eq7zp6y3sf6mdq3hsejtacwxx@yl543m4lj47d>
On Tue, Jun 16, 2026 at 03:54:56AM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 04, 2026 at 05:50:43PM +0530, Monish Chunara wrote:
> > This series adds SD card support for the Shikra platform.
> >
> > The first patch adds the SDHC2 controller node and the necessary pinctrl
> > configurations to the base Shikra SoC dtsi. The second patch enables
> > this support on the Shikra EVK (CQS, CQM, and IQS variants) by defining
> > the regulator supplies and the card detection GPIO.
> >
> > Testing:
> > - Validated on Shikra EVK variants.
> >
> > This series depends on:
> > - https://lore.kernel.org/all/20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com/
> > - https://lore.kernel.org/all/20260521-shikra-rproc-v3-0-2fca0bbe1ad7@oss.qualcomm.com/
> > - https://lore.kernel.org/linux-devicetree/20260513-tsens_binding-v1-1-1780c6a6caf2@oss.qualcomm.com/
>
> If the SD card depends on remote proc, tsens or cpufreq, then something
> is wrong. Maybe, the way the serieas are organized and sent.
There is no technical dependency on tsens for SD card. The mentioned dependency
series was to ensure the changes get picked up without conflicts.
In the next patch series, only the actual dependenices will be mentioned in the
cover letter.
Regards,
Monish
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Xu Yang @ 2026-06-29 8:26 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Heikki Krogerus, Chaoyi Chen, Greg Kroah-Hartman,
Dmitry Baryshkov, Peter Chen, Luca Ceresoli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel
In-Reply-To: <56c6abb8-c127-449f-9368-12f94620c2bc@rock-chips.com>
On Mon, Jun 29, 2026 at 09:29:08AM +0800, Chaoyi Chen wrote:
> Hello Xu Yang,
>
> On 6/26/2026 7:15 PM, Xu Yang wrote:
> > On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
> >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >>
> >> The HPD function of Type-C DP is implemented through
> >> drm_connector_oob_hotplug_event(). For embedded DP, it is required
> >> that the DRM connector fwnode corresponds to the Type-C port fwnode.
> >>
> >> To describe the relationship between the DP controller and the Type-C
> >> port device, we usually using drm_bridge to build a bridge chain.
> >>
> >> Now several USB-C controller drivers have already implemented the DP
> >> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
> >> HPD bridge on USB-C connector port device.
> >>
> >> But this requires the USB-C controller driver to manually register the
> >> HPD bridge. If the driver does not implement this feature, the bridge
> >> will not be create.
> >>
> >> So this patch implements a generic DP HPD bridge based on
> >> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
> >> Type-C port device containing the DP svid is registered, it will
> >> create an HPD bridge for it without the need for the USB-C controller
> >> driver to implement it.
> >>
> >> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> >> ---
> >>
> >> (no changes since v14)
> >>
> >> Changes in v13:
> >> - Only register drm dp hpd bridge for typec port altmode device.
> >>
> >> (no changes since v12)
> >>
> >> Changes in v11:
> >> - Switch to using typec bus notifiers.
> >>
> >> (no changes since v10)
> >>
> >> Changes in v9:
> >> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
> >> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
> >> - Add more commit comment about problem background.
> >>
> >> Changes in v8:
> >> - Merge generic DP HPD bridge into one module.
> >> ---
> >>
> >> drivers/gpu/drm/bridge/Kconfig | 10 ++++
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
> >> 3 files changed, 60 insertions(+)
> >> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
> >>
> >> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> >> index a250afd8d662..559487aa09a9 100644
> >> --- a/drivers/gpu/drm/bridge/Kconfig
> >> +++ b/drivers/gpu/drm/bridge/Kconfig
> >> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
> >> Simple bridge that terminates the bridge chain and provides HPD
> >> support.
> >>
> >> +if DRM_AUX_HPD_BRIDGE
> >> +config DRM_AUX_HPD_TYPEC_BRIDGE
> >> + tristate
> >> + depends on TYPEC || !TYPEC
> >> + default TYPEC
> >> + help
> >> + Simple bridge that terminates the bridge chain and provides HPD
> >> + support. It build bridge on each USB-C connector device node.
> >> +endif
> >> +
> >
> > Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
> > manually.
> >
> > $ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
> > ./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
> > ./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> > ./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> > ./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> > ./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> >
>
> That's a fair point. But based on the previous discussion, Heikki
> point out that configurations in the TYPEC subsystem should not
> select configurations from DRM.
I have just reviewed your previous patchsets but I did't find such opinion from
Heikki. Otherwise, why are tcpm.c/ucsi.c already allowed to add the above select
condition in their configs?
I think Heikki means that the DRM_AUX_HPD_BRIDGE shouldn't been selected at the
top level of Type-C subsystem. Because not all Type-C devices support the DP function.
As a generic Type-C DP HPD bridge, displayport.c will likely need to use it in
the future. Therefore, allowing displayport.c to select DRM_AUX_HPD_BRIDGE makes sense.
According to my testing, it's impossible to build this driver in unless TYPEC_FUSB302
or a relevant CONFIG is built in to select DRM_AUX_HPD_BRIDGE, or the defconfig is modified.
Thanks,
Xu Yang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Chaoyi Chen @ 2026-06-29 9:09 UTC (permalink / raw)
To: Xu Yang, Heikki Krogerus
Cc: Chaoyi Chen, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel
In-Reply-To: <k53t2soc3nxhwugncatksektig6agxfgdkogkdwbhrhu2fn2g7@auvsfrv76wxy>
Hello Xu Yang, Heikki
On 6/29/2026 4:26 PM, Xu Yang wrote:
> On Mon, Jun 29, 2026 at 09:29:08AM +0800, Chaoyi Chen wrote:
>> Hello Xu Yang,
>>
>> On 6/26/2026 7:15 PM, Xu Yang wrote:
>>> On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
>>>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>>
>>>> The HPD function of Type-C DP is implemented through
>>>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>>>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>>>
>>>> To describe the relationship between the DP controller and the Type-C
>>>> port device, we usually using drm_bridge to build a bridge chain.
>>>>
>>>> Now several USB-C controller drivers have already implemented the DP
>>>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>>>> HPD bridge on USB-C connector port device.
>>>>
>>>> But this requires the USB-C controller driver to manually register the
>>>> HPD bridge. If the driver does not implement this feature, the bridge
>>>> will not be create.
>>>>
>>>> So this patch implements a generic DP HPD bridge based on
>>>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>>>> Type-C port device containing the DP svid is registered, it will
>>>> create an HPD bridge for it without the need for the USB-C controller
>>>> driver to implement it.
>>>>
>>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>>> ---
>>>>
>>>> (no changes since v14)
>>>>
>>>> Changes in v13:
>>>> - Only register drm dp hpd bridge for typec port altmode device.
>>>>
>>>> (no changes since v12)
>>>>
>>>> Changes in v11:
>>>> - Switch to using typec bus notifiers.
>>>>
>>>> (no changes since v10)
>>>>
>>>> Changes in v9:
>>>> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
>>>> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
>>>> - Add more commit comment about problem background.
>>>>
>>>> Changes in v8:
>>>> - Merge generic DP HPD bridge into one module.
>>>> ---
>>>>
>>>> drivers/gpu/drm/bridge/Kconfig | 10 ++++
>>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>>> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
>>>> 3 files changed, 60 insertions(+)
>>>> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>>> index a250afd8d662..559487aa09a9 100644
>>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>>>> Simple bridge that terminates the bridge chain and provides HPD
>>>> support.
>>>>
>>>> +if DRM_AUX_HPD_BRIDGE
>>>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>>>> + tristate
>>>> + depends on TYPEC || !TYPEC
>>>> + default TYPEC
>>>> + help
>>>> + Simple bridge that terminates the bridge chain and provides HPD
>>>> + support. It build bridge on each USB-C connector device node.
>>>> +endif
>>>> +
>>>
>>> Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
>>> manually.
>>>
>>> $ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
>>> ./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
>>> ./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>>> ./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>>> ./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>>> ./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>>>
>>
>> That's a fair point. But based on the previous discussion, Heikki
>> point out that configurations in the TYPEC subsystem should not
>> select configurations from DRM.
>
> I have just reviewed your previous patchsets but I did't find such opinion from
> Heikki. Otherwise, why are tcpm.c/ucsi.c already allowed to add the above select
> condition in their configs?
>
> I think Heikki means that the DRM_AUX_HPD_BRIDGE shouldn't been selected at the
> top level of Type-C subsystem. Because not all Type-C devices support the DP function.
>
> As a generic Type-C DP HPD bridge, displayport.c will likely need to use it in
> the future. Therefore, allowing displayport.c to select DRM_AUX_HPD_BRIDGE makes sense.
>
> According to my testing, it's impossible to build this driver in unless TYPEC_FUSB302
> or a relevant CONFIG is built in to select DRM_AUX_HPD_BRIDGE, or the defconfig is modified.
>
Yep. For me, I select DRM_AUX_HPD_BRIDGE in DRM.
@Heikki, what do you think of the following change?
Should we add a new patch for this? Thanks.
diff --git a/drivers/usb/typec/altmodes/Kconfig b/drivers/usb/typec/altmodes/Kconfig
index 7867fa7c405d..f89cdf3c949b 100644
--- a/drivers/usb/typec/altmodes/Kconfig
+++ b/drivers/usb/typec/altmodes/Kconfig
@@ -5,6 +5,7 @@ menu "USB Type-C Alternate Mode drivers"
config TYPEC_DP_ALTMODE
tristate "DisplayPort Alternate Mode driver"
depends on DRM
+ select DRM_AUX_HPD_BRIDGE
help
DisplayPort USB Type-C Alternate Mode allows DisplayPort
displays and adapters to be attached to the USB Type-C
--
Best,
Chaoyi
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH RFC v4 9/9] arm64: dts: qcom: glymur: Wire PCIe3a/3b to shared Gen5x8 PHY
From: Konrad Dybcio @ 2026-06-29 9:20 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <akH9LKxqhciznM2x@hu-qianyu-lv.qualcomm.com>
On 6/29/26 7:05 AM, Qiang Yu wrote:
> On Wed, Jun 17, 2026 at 01:19:49PM +0200, Konrad Dybcio wrote:
>> On 5/19/26 7:47 AM, Qiang Yu wrote:
>>> Glymur PCIe3 uses a single shared Gen5x8 QMP PHY block. Model PCIe3a and
>>> PCIe3b as consumers of that shared PHY provider instead of separate PHY
>>> nodes.
>>>
>>> Update the DTS wiring to:
>>> - point GCC PCIe3A/3B pipe parents to the shared PHY clock outputs
>>> - add PCIe3a controller node and route PCIe3a/PCIe3b port phys to
>>> &pcie3_phy using two-cell PHY arguments
>>> - configure the shared PHY node with link-mode and dual pipe outputs
>>>
>>> Use QMP_PCIE_GLYMUR_MODE_* dt-binding macros for mode selection.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + pcie3a: pci@1c10000 {
>>> + device_type = "pci";
>>> + compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
>>> + reg = <0x0 0x01c10000 0x0 0x3000>,
>>> + <0x0 0x70000000 0x0 0xf20>,
>>> + <0x0 0x70000f40 0x0 0xa8>,
>>> + <0x0 0x70001000 0x0 0x4000>,
>>> + <0x0 0x70100000 0x0 0x100000>,
>>> + <0x0 0x01c13000 0x0 0x1000>;
>>> + reg-names = "parf",
>>> + "dbi",
>>> + "elbi",
>>> + "atu",
>>> + "config",
>>> + "mhi";
>>> + #address-cells = <3>;
>>> + #size-cells = <2>;
>>> + ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
>>> + <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
>>> + <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>,
>>> + <0x43000000 0x70 0x00000000 0x70 0x00000000 0x10 0x00000000>;
>>> +
>>> + bus-range = <0 0xff>;
>>> +
>>> + dma-coherent;
>>> +
>>> + linux,pci-domain = <3>;
>>> + num-lanes = <8>;
>>
>> Is it fine to keep num-lanes 8 here even for configurations with
>> bifurcated PHY?
>>
>> I would assume so, given essentially this is a x8 host, whose 4
>> lanes may simply be effectively NC
>>
> Actually, on existing platforms, the PCIe3a and PCIe3b controllers are
> never enabled at the same time. When PCIe3a is exposed, it is always in an
> x8 slot. But if we have a x4+x4 platform in future, we can simply override
> num-lanes to 4 in the board.dts.
My question is whether that will be necessary - if yes, sure, we
can do it, but if not, we can conclude on this early and not have
to fight over it in a couple months
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 1/9] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add glymur-qmp-gen5x8-pcie-phy compatible
From: Konrad Dybcio @ 2026-06-29 9:20 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <akH/N/ZwnSD5BkIj@hu-qianyu-lv.qualcomm.com>
On 6/29/26 7:14 AM, Qiang Yu wrote:
> On Tue, Jun 16, 2026 at 04:03:39PM +0200, Konrad Dybcio wrote:
>> On 5/19/26 7:47 AM, Qiang Yu wrote:
>>> The Glymur SoC uses a single PCIe Gen5 PHY hardware block for the
>>> PCIe3a/PCIe3b controllers. This block supports two link modes:
>>>
>>> 1. x4+x4: two 4-lane PHY instances are exposed
>>> 2. x8: one 8-lane PHY instance is exposed
>>>
>>> Add qcom,glymur-qmp-gen5x8-pcie-phy as a multi-mode PHY compatible and
>>> document the new link-mode property, which selects the active link mode
>>> via a TCSR syscon register.
>>>
>>> Document the required clocks, resets, and power-domains for both PHY
>>> instances active in x8 mode. Use #phy-cells = <1> for this compatible,
>>> where the cell value is the PHY index within the active link mode.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> @@ -68,20 +69,29 @@ properties:
>>> - const: ref
>>> - enum: [rchng, refgen]
>>> - const: pipe
>>> - - const: pipediv2
>>> + - enum: [pipediv2, phy_b_aux]
>>
>> I'm surprised to learn 3A doesnm'doesn't have a PIPE_DIV2 clk.. it does have
>> a non-div2 one though.
>>
>> Seems like it's specifically not the case on Hamoa and Makena, so perhaps
>> it's better for maintainability if the Glymur list was separate
>>
> Do you mean splitting Glymur out into a separate YAML file for the PCIe3
> PHY? I'll add a new file if that's preferred and Krzysztof is on board.
I believe that may be the better approach since Glymur seems to be an
outlier with the clocks I mentioned above. Krzysztof?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 2/9] dt-bindings: phy: qcom-qmp: Add PHY selector and Glymur link-mode macros
From: Konrad Dybcio @ 2026-06-29 9:21 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <akIAPK7daXxPH5JO@hu-qianyu-lv.qualcomm.com>
On 6/29/26 7:18 AM, Qiang Yu wrote:
> On Tue, Jun 16, 2026 at 04:07:27PM +0200, Konrad Dybcio wrote:
>> On 5/19/26 7:47 AM, Qiang Yu wrote:
>>> Add two sets of constants to phy-qcom-qmp.h to support upcoming multiple
>>> link mode QMP PHY:
>>>
>>> - QMP_PHY_SELECTOR_0 / QMP_PHY_SELECTOR_1: generic logical PHY index
>>> values for QMP providers that expose multiple PHY instances under a
>>> single DT node (i.e. #phy-cells = <1>).
>>>
>>> - QMP_PCIE_GLYMUR_MODE_X8 / QMP_PCIE_GLYMUR_MODE_X4X4: link-mode
>>> values for the Glymur Gen5x8 PCIe PHY "qcom,link-mode" syscon property,
>>> selecting between the x8 single-PHY and x4+x4 dual-PHY topologies.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>> ---
>>> include/dt-bindings/phy/phy-qcom-qmp.h | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/include/dt-bindings/phy/phy-qcom-qmp.h b/include/dt-bindings/phy/phy-qcom-qmp.h
>>> index 6b43ea9e0051..befa76f8392f 100644
>>> --- a/include/dt-bindings/phy/phy-qcom-qmp.h
>>> +++ b/include/dt-bindings/phy/phy-qcom-qmp.h
>>> @@ -21,4 +21,12 @@
>>> #define QMP_PCIE_PIPE_CLK 0
>>> #define QMP_PCIE_PHY_AUX_CLK 1
>>>
>>> +/* Generic QMP logical PHY selectors */
>>> +#define QMP_PHY_SELECTOR_0 0
>>> +#define QMP_PHY_SELECTOR_1 1
>>
>> Is this for the second phy cell? FWIW I think it's fine to use raw
>> numbers as they're just indices (i.e. "nth bifurcated phy") anyway
>
> I can't use lane numbers. In x4+x4 case, I need to tell phy the first 4
> lanes or second 4 lanes are required.
I didn't mean lane indices, but instead the same numbers you defined,
without the name. It's a minor difference though, and ultimately both
work for me.
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers
From: Konrad Dybcio @ 2026-06-29 9:21 UTC (permalink / raw)
To: Qiang Yu
Cc: Dmitry Baryshkov, Manivannan Sadhasivam, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <akII/X8OWO5XN9Gw@hu-qianyu-lv.qualcomm.com>
On 6/29/26 7:56 AM, Qiang Yu wrote:
> On Tue, Jun 16, 2026 at 04:05:43PM +0200, Konrad Dybcio wrote:
>> On 5/29/26 9:02 AM, Qiang Yu wrote:
>>> On Thu, May 28, 2026 at 04:48:24PM +0300, Dmitry Baryshkov wrote:
>>>> On Fri, May 22, 2026 at 04:27:35PM +0530, Manivannan Sadhasivam wrote:
>>>>> On Wed, May 20, 2026 at 07:25:01PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Mon, May 18, 2026 at 10:47:16PM -0700, Qiang Yu wrote:
>>>>>>> Some QMP PCIe PHY hardware blocks can be split into multiple sub-PHYs
>>>>>>> under a single DT node, each requiring its own pipe clock registration and
>>>>>>> DT resource mapping. The current helpers are tightly coupled to a single
>>>>>>> qmp_pcie instance, which prevents reuse across sub-PHY instances.
>>>>>>>
>>>>>>> Refactor __phy_pipe_clk_register() as a generic helper and reduce
>>>>>>> phy_pipe_clk_register() to a thin wrapper around it. Similarly, extract
>>>>>>> qmp_pcie_parse_dt_common() from qmp_pcie_parse_dt() to hold the register-
>>>>>>> mapping and pipe-clock setup that will be shared between sub-PHY instances,
>>>>>>> with pipe clock names parameterised per instance.
>>>>>>>
>>>>>>> This is a preparatory step before adding multi-PHY support. No functional
>>>>>>> change for existing platforms.
>>>>>>>
>>>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 76 ++++++++++++++++++--------------
>>>>>>> 1 file changed, 44 insertions(+), 32 deletions(-)
>>>>>>
>>>>>> I'd suggest splitting the Glymur PHY to a separate driver. Otherwise we
>>>>>> end up having too many single-platform, single-device specifics which
>>>>>> don't apply to other platforms.
>>>>>>
>>>>>
>>>>> I don't think that's really needed. This shared PHY concept is going to be
>>>>> applicable to upcoming SoCs as well. And moreover, the split won't be clean
>>>>> either. We still need to reuse a lot of common logic in the 'phy-qcom-qmp-pcie'
>>>>> driver and may only end up keeping very minimal code in
>>>>> 'phy-qcom-qmp-pcie-glymur'.
>>>>
>>>> Then splitting makes even more sense. Let's not clutter the existing
>>>> driver with too many conditions and options.
>>>>
>>>>>
>>>>> If you are concerned about the file size of 'phy-qcom-qmp-pcie', then we should
>>>>> move the SoC specific 'cfg' structs into a separate file as that's what
>>>>> occupying majority of the space.
>>>>
>>>> No, it's really the 'shared' part.
>>>>
>>>
>>> To confirm, are you okay with some code duplication between the new
>>> Glymur-specific driver and phy-qcom-qmp-pcie driver.
>>
>> That's a necessity, to some degree. See e.g. qmp-combo and qmp-usbc
>>
> I've already prototyped a separate Glymur driver, and it turned out better
> than expected — there's actually not much duplication. The parts that do
> overlap aren't fully identical either; they tend to diverge once the
> Glymur-specific handling is factored in.
>
> Currently, I meet an issue when tesing the patch, and will post it after
> fixing the issue.
Good, thank you!
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 0/8] Enable USB host functions on Jetson AGX Thor
From: Wayne Chang @ 2026-06-29 9:33 UTC (permalink / raw)
To: mathias.nyman, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
gregkh, thierry.reding, jonathanh
Cc: waynec, linux-usb, linux-tegra, linux-kernel, linux-phy,
devicetree
Enable support for USB host functions on the Tegra264 Jetson AGX Thor
platform
Sing-Han Chen (1):
phy: tegra: xusb: Use devm_clk_get_optional to fetch USB2 tracking
clock
Wayne Chang (7):
dt-bindings: phy: tegra-xusb: Add support for Tegra264
dt-bindings: usb: Add Tegra264 XUSB host support
arm64: tegra: Enable XUSB host function on Jetson AGX Thor
phy: tegra: xusb: Increase timeout for USB2_TRK_COMPLETED polling
phy: tegra: xusb: Add Tegra264 support
usb: host: xhci-tegra: Skip MBOX MSG_ENABLED on Tegra264
usb: host: xhci-tegra: Add Tegra264 XHCI support
.../phy/nvidia,tegra194-xusb-padctl.yaml | 1 +
.../bindings/usb/nvidia,tegra234-xusb.yaml | 115 +++++++++----
.../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 50 ++++++
.../dts/nvidia/tegra264-p4071-0000+p3834.dtsi | 95 +++++++++++
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 154 ++++++++++++++++++
drivers/phy/tegra/Makefile | 1 +
drivers/phy/tegra/xusb-tegra186.c | 30 +++-
drivers/phy/tegra/xusb.c | 6 +
drivers/phy/tegra/xusb.h | 3 +
drivers/usb/host/xhci-tegra.c | 37 +++++
10 files changed, 454 insertions(+), 38 deletions(-)
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.25.1
--
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