Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v4 phy-next 01/16] phy: lynx-28g: avoid returning NULL in of_xlate() function
From: sashiko-bot @ 2026-06-08 22:26 UTC (permalink / raw)
  To: Vladimir Oltean; +Cc: vkoul, linux-phy, olteanv, neil.armstrong
In-Reply-To: <20260608221710.1572971-2-vladimir.oltean@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A concurrent unbind of the PHY provider can cause a Use-After-Free when accessing the `phy` pointer in `of_phy_get()`.
--

commit 33b5ab7917964ed203a6c538e1528b54f76fa1e5
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

phy: lynx-28g: avoid returning NULL in of_xlate() function

Sashiko points out that _of_phy_get() does not support a NULL returned
output from phy_provider->of_xlate(), just a valid pointer or a
pointer-encoded error.

> diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> @@ -1435,7 +1435,7 @@ static struct phy *lynx_28g_xlate(struct device *dev,
>  		    idx < priv->info->first_lane))
>  		return ERR_PTR(-EINVAL);
>  
> -	return priv->lane[idx].phy;
> +	return priv->lane[idx].phy ?: ERR_PTR(-ENODEV);
>  }

[Severity: High]
This is a pre-existing issue, but looking at how the xlate callbacks are
consumed in the PHY core, could there be a use-after-free race condition
during device unbind?

In drivers/phy/phy-core.c:of_phy_get(), the provider's xlate callback is 
invoked via _of_phy_get():

	phy = _of_phy_get(np, index);
	if (IS_ERR(phy))
		return phy;

	if (!try_module_get(phy->ops->owner))
		return ERR_PTR(-EPROBE_DEFER);

	get_device(&phy->dev);

Since _of_phy_get() drops the phy_provider_mutex before returning the raw,
unreferenced phy pointer, what prevents a concurrent unbind of the PHY
provider from freeing the phy memory before the pointer is dereferenced via
phy->ops->owner? 

If the provider is unregistered (e.g., via sysfs) and phy_destroy() drops
the PHY device's reference count to zero precisely after _of_phy_get()
returns, would this result in accessing freed memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608221710.1572971-1-vladimir.oltean@nxp.com?part=1

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 phy-next 14/16] dt-bindings: phy: lynx-10g: initial document
From: sashiko-bot @ 2026-06-08 22:27 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: neil.armstrong, vkoul, olteanv, linux-phy, devicetree, robh,
	conor+dt
In-Reply-To: <20260608221710.1572971-15-vladimir.oltean@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Schema validation error due to conditionally required `big-endian` property not declared at the top-level
--

commit 2c5c4d6b6c1efda8718b0e291015499912a81e6e
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

dt-bindings: phy: lynx-10g: initial document

This commit adds the YAML device tree binding schema for the 10G Lynx
SerDes, supporting various QorIQ and Layerscape SoCs. It defines a common
register map with SoC-specific configurations handled via conditional blocks.

> diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml
> new file mode 100644
> index 0000000000000..eaef585338258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml

[ ... ]

> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - fsl,ls1046a-serdes1
> +              - fsl,ls1046a-serdes2
> +    then:
> +      properties:
> +        big-endian: true
> +      required:
> +        - big-endian

[Severity: Low]
Will this cause a schema validation error when dtbs_check is run?

Because big-endian is omitted from the top-level properties block, it
appears the additionalProperties constraint below will reject it even
when the compatible string matches.

Could big-endian: type: boolean be added to the top-level properties
dictionary, or should additionalProperties: false be changed to
unevaluatedProperties: false?

> +
> +additionalProperties: false
> +
> +examples:

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608221710.1572971-1-vladimir.oltean@nxp.com?part=14

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 phy-next 15/16] phy: lynx-10g: new driver
From: sashiko-bot @ 2026-06-08 22:33 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: vkoul, neil.armstrong, conor+dt, robh, olteanv, linux-phy,
	devicetree
In-Reply-To: <20260608221710.1572971-16-vladimir.oltean@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver incorrectly uses 0 as a sentinel value in `lane->default_pccr[mode]`, treating a valid backed-up PCCR configuration of 0 as uninitialized data and unintentionally falling back to a hardcoded PCS muxing configuration.
--

commit 0fcab57e2d19361e4720b40d6690e12c5a5bfd0b
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

phy: lynx-10g: new driver

Introduce a driver for the networking lanes of the 10G Lynx SerDes
block, present on the majority of Layerscape and QorIQ (Freescale/NXP)
SoCs. It provides the generic PHY framework to allow network MACs to
reconfigure the SerDes for different link modes based on connected modules.

> diff --git a/drivers/phy/freescale/phy-fsl-lynx-10g.c b/drivers/phy/freescale/phy-fsl-lynx-10g.c
> new file mode 100644
> index 0000000000000..7dd5d94b51cf2
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-lynx-10g.c
> @@ -0,0 +1,1278 @@
[ ... ]
> +static void lynx_10g_backup_pccr_val(struct lynx_lane *lane)
> +{
> +	u32 val;
> +	int err;
> +
> +	if (lane->mode == LANE_MODE_UNKNOWN)
> +		return;
> +
> +	err = lynx_pccr_read(lane, lane->mode, &val);
> +	if (err) {
> +		dev_warn(&lane->phy->dev,
> +			 "The driver doesn't know how to access the PCCR for lane mode %s\n",
> +			 lynx_lane_mode_str(lane->mode));
> +		lane->mode = LANE_MODE_UNKNOWN;
> +		return;
> +	}
> +
> +	lane->default_pccr[lane->mode] = val;
> +
> +	switch (lane->mode) {
> +	case LANE_MODE_1000BASEX_SGMII:
> +	case LANE_MODE_2500BASEX:
> +		lane->default_pccr[LANE_MODE_1000BASEX_SGMII] = val & ~PCCR8_SGMIIa_KX;
> +		lane->default_pccr[LANE_MODE_2500BASEX] = val & ~PCCR8_SGMIIa_KX;
> +		break;
> +	default:
> +		break;
> +	}
> +}

[Severity: High]
Since the PCCR8_SGMIIa_KX bit is explicitly cleared here, could this result in
a backed-up value of exactly 0 if no other configuration bits were originally
set?

[ ... ]
> +static int lynx_10g_lane_enable_pcvt(struct lynx_lane *lane,
> +				     enum lynx_lane_mode mode)
> +{
> +	struct lynx_priv *priv = lane->priv;
> +	u32 val;
> +	int err;
> +
> +	spin_lock(&priv->pcc_lock);
> +
> +	switch (mode) {
> +	case LANE_MODE_1000BASEX_SGMII:
> +	case LANE_MODE_2500BASEX:
> +		err = lynx_pcvt_rmw(lane, mode, CR(1), SGMIIaCR1_SGPCS_EN,
> +				    SGMIIaCR1_SGPCS_EN);
> +		if (err)
> +			goto out;
> +
> +		lynx_pcvt_rmw(lane, mode, CR(0), SGMIIaCR0_RST_SGM_OFF,
> +			      SGMIIaCR0_RST_SGM | SGMIIaCR0_PD_SGM);
> +		break;
> +	case LANE_MODE_QSGMII:
> +		err = lynx_pcvt_rmw(lane, mode, CR(0), QSGMIIaCR0_RST_QSGM_OFF,
> +				    QSGMIIaCR0_RST_QSGM | QSGMIIaCR0_PD_QSGM);
> +		if (err)
> +			goto out;
> +		break;
> +	default:
> +		err = 0;
> +	}
> +
> +	if (lane->default_pccr[mode]) {
> +		err = lynx_pccr_write(lane, mode, lane->default_pccr[mode]);
> +		goto out;
> +	}

[Severity: High]
If the valid backed-up PCCR configuration is 0, will this condition evaluate
to false and skip the restoration?

It seems a configuration value of 0 is a valid state for the PCCR register,
but this check relies on 0 as a sentinel value for uninitialized data. Could
this inadvertently cause the driver to apply the hardcoded default values
below, breaking the initial muxing configured by the RCW?

> +
> +	val = 0;
> +
> +	switch (mode) {
> +	case LANE_MODE_1000BASEX_SGMII:
> +	case LANE_MODE_2500BASEX:
> +		val |= PCCR8_SGMIIa_CFG;
> +		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608221710.1572971-1-vladimir.oltean@nxp.com?part=15

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v2 net-next] net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
From: Jakub Kicinski @ 2026-06-09  2:28 UTC (permalink / raw)
  To: Petr Wozniak
  Cc: netdev, andrew, hkallweit1, linux, davem, edumazet, pabeni,
	linux-phy, linux-kernel, maxime.chevallier, bjorn, olek2
In-Reply-To: <20260605053056.1977-1-petr.wozniak@gmail.com>

On Fri,  5 Jun 2026 07:30:56 +0200 Petr Wozniak wrote:
> commit 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO
> bridge in mdio-i2c") introduced a regression: the RollBall I2C-to-MDIO
> bridge is not yet ready to respond to CMD_READ/CMD_DONE cycles when
> sfp_sm_add_mdio_bus() runs in SFP_S_INIT.  The 200 ms probe times out,
> i2c_mii_probe_rollball() returns -ENODEV, and sfp_sm_add_mdio_bus()
> sets mdio_protocol = MDIO_I2C_NONE.  By the time sfp_sm_probe_for_phy()
> runs (up to ~17 s later on affected hardware), the bridge is fully
> initialized — but PHY probing is skipped because the protocol has
> already been changed to NONE.
> 
> This affects both modules inserted before boot and hotplugged modules on
> hardware where bridge initialization exceeds the 200 ms probe window
> (confirmed: FLYPRO SFP-10GT-CS-30M with Aquantia AQR113C, hotplugged).
> 
> Move the probe from i2c_mii_init_rollball() — called at bus-creation
> time — to sfp_sm_probe_for_phy() in sfp.c, where it runs after the SFP
> state machine's module initialization delays.  Export the probe function
> as mdio_i2c_probe_rollball() so sfp.c can call it.
> 
> For RTL8261BE-based modules: the probe correctly returns -ENODEV at PHY
> discovery time, causing sfp_sm_probe_for_phy() to destroy the MDIO bus
> and set MDIO_I2C_NONE — eliminating the 5+ minute PHY probe retry loop.
> 
> For genuine RollBall modules (e.g. FLYPRO SFP-10GT-CS-30M with Aquantia
> AQR113C): the probe now runs after initialization is complete and
> correctly returns 0 — PHY detection proceeds normally.

$ git pw series apply 1106341
Failed to apply patch:
Applying: net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
error: corrupt patch at .git/rebase-apply/patch:44
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
-- 
pw-bot: cr


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 01/12] dt-bindings: clock: thead: add TH1520 MISC subsys clock controller
From: Drew Fustini @ 2026-06-09  3:26 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Icenowy Zheng, Han Gao, Yao Zi
In-Reply-To: <20260507081710.4090814-2-zhengxingda@iscas.ac.cn>

On Thu, May 07, 2026 at 04:16:59PM +0800, Icenowy Zheng wrote:
> TH1520 has a subsystem clock controller called MISC_SUBSYS in its
> manual, mainly controlling clocks for USB and MMC/SD in non-TEE
> environment.
> 
> Add device tree binding for it.
> 
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
>  .../devicetree/bindings/clock/thead,th1520-clk-ap.yaml |  5 +++--
>  include/dt-bindings/clock/thead,th1520-clk-ap.h        | 10 ++++++++++
>  2 files changed, 13 insertions(+), 2 deletions(-)

Thanks for working on USB and sorry for the delay in reviewing this series.

Reviewed-by: Drew Fustini <fustini@kernel.org>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 00/12] Add TH1520 USB support
From: Drew Fustini @ 2026-06-09  4:17 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Icenowy Zheng, Han Gao, Yao Zi
In-Reply-To: <20260507081710.4090814-1-zhengxingda@iscas.ac.cn>

On Thu, May 07, 2026 at 04:16:58PM +0800, Icenowy Zheng wrote:
> This patchset adds support for T-Head TH1520's USB functionality, and
> enabled it on the Lichee Pi 4A board.
> 
> The first 3 patches add support for the MISC subsystem clock
> contrtoller, which contains some USB clocks.
> 
> The next 2 patches add support for the USB PHY of T-Head TH1520, which
> is a wrapped Synopsys USB3.0 FemtoPHY with a little integration quirk;
> the controller itself is a properly configured DWC3 controller with sane
> default register values set.
> 
> Then one patch adds the USB PHY and controller nodes to the TH1520 DTSI
> file.
> 
> The remaining half of this patchset dedicates to enablement of USB on
> TH1520, because of the onboard hub of that board -- its USB2 signals are
> behind a switch that needs to be toggled on, and Vbus supplies for both
> the hub itself and downstream ports are managed via I2C-expanded GPIOs
> (because the SoC does not have enough GPIO pins).

Hi, thanks for working on USB. I tried to apply it to next-20260601 and
several of the dts patches no longer apply cleanly. Could you rebase?

In the meantime, I'll apply to 7.1-rc7 for testing.

Thanks,
Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 00/12] Add TH1520 USB support
From: Icenowy Zheng @ 2026-06-09  5:10 UTC (permalink / raw)
  To: Drew Fustini
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <aieT4WmWK9416M9E@thelio>

在 2026-06-08一的 21:17 -0700,Drew Fustini写道:
> On Thu, May 07, 2026 at 04:16:58PM +0800, Icenowy Zheng wrote:
> > This patchset adds support for T-Head TH1520's USB functionality,
> > and
> > enabled it on the Lichee Pi 4A board.
> > 
> > The first 3 patches add support for the MISC subsystem clock
> > contrtoller, which contains some USB clocks.
> > 
> > The next 2 patches add support for the USB PHY of T-Head TH1520,
> > which
> > is a wrapped Synopsys USB3.0 FemtoPHY with a little integration
> > quirk;
> > the controller itself is a properly configured DWC3 controller with
> > sane
> > default register values set.
> > 
> > Then one patch adds the USB PHY and controller nodes to the TH1520
> > DTSI
> > file.
> > 
> > The remaining half of this patchset dedicates to enablement of USB
> > on
> > TH1520, because of the onboard hub of that board -- its USB2
> > signals are
> > behind a switch that needs to be toggled on, and Vbus supplies for
> > both
> > the hub itself and downstream ports are managed via I2C-expanded
> > GPIOs
> > (because the SoC does not have enough GPIO pins).
> 
> Hi, thanks for working on USB. I tried to apply it to next-20260601
> and
> several of the dts patches no longer apply cleanly. Could you rebase?

I think the reason is that one of the GPIO expansion chip is added to
the DT for enabling Wi-Fi.

I am not sure whether the next revision of this patchset will contain
all things, maybe I will split out at least the USB PHY part.

Thanks,
Icenowy

> 
> In the meantime, I'll apply to 7.1-rc7 for testing.
> 
> Thanks,
> Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 03/12] riscv: dts: thead: add device tree node for MISC clock controller
From: Drew Fustini @ 2026-06-09  5:14 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Icenowy Zheng, Han Gao, Yao Zi
In-Reply-To: <20260507081710.4090814-4-zhengxingda@iscas.ac.cn>

On Thu, May 07, 2026 at 04:17:01PM +0800, Icenowy Zheng wrote:
> The MISC_SUBSYS clock controller on TH1520 SoC is a clock controller
> mainly controlling USB-related clocks (which isn't utilized yet) and
> MMC/SD controllers' AHB bus clocks.
> 
> Add the device tree node for it along with the missing bus clock
> references for MMC/SD controllers.

Is there a functional reason to modify the mmc nodes in this series?

Thanks,
Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 03/12] riscv: dts: thead: add device tree node for MISC clock controller
From: Icenowy Zheng @ 2026-06-09  5:35 UTC (permalink / raw)
  To: Drew Fustini
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <aiehUzl-qZeZDjXP@thelio>

在 2026-06-08一的 22:14 -0700,Drew Fustini写道:
> On Thu, May 07, 2026 at 04:17:01PM +0800, Icenowy Zheng wrote:
> > The MISC_SUBSYS clock controller on TH1520 SoC is a clock
> > controller
> > mainly controlling USB-related clocks (which isn't utilized yet)
> > and
> > MMC/SD controllers' AHB bus clocks.
> > 
> > Add the device tree node for it along with the missing bus clock
> > references for MMC/SD controllers.
> 
> Is there a functional reason to modify the mmc nodes in this series?

When the clock isn't referenced, Linux will disable it unless
`clk_ignore_unused` parameter is passed.

Thanks,
Icenowy

> 
> Thanks,
> Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 02/12] clk: thead: th1520-ap: add support for MISC subsys clocks
From: Drew Fustini @ 2026-06-09  6:00 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Icenowy Zheng, Han Gao, Yao Zi
In-Reply-To: <20260507081710.4090814-3-zhengxingda@iscas.ac.cn>

On Thu, May 07, 2026 at 04:17:00PM +0800, Icenowy Zheng wrote:
> The TH1520 SoC contains a MISC_SUBSYS clock controller, which allows
> controlling of USB related clocks and MMC/SD controller AHB bus clocks.
> 
> Add support for this clock controller, in order to enable USB support.
> 
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
>  drivers/clk/thead/clk-th1520-ap.c | 64 +++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/drivers/clk/thead/clk-th1520-ap.c b/drivers/clk/thead/clk-th1520-ap.c
> index 3a6847f1c950f..24f785f0b329a 100644
> --- a/drivers/clk/thead/clk-th1520-ap.c
> +++ b/drivers/clk/thead/clk-th1520-ap.c
[...]
> @@ -1609,6 +1663,12 @@ static int th1520_clk_probe(struct platform_device *pdev)
>  			return ret;
>  	}
>  
> +	if (plat_data == &th1520_ap_platdata) {
> +		ret = devm_clk_hw_register(dev, &usb_suspend_div_clk.hw);
> +		if (ret)
> +			return ret;
> +	}

Should usb_suspend_div_clk.hw instead be registered under
'if (plat_data == &th1520_ap_platdata)'?

Thanks,
Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 02/12] clk: thead: th1520-ap: add support for MISC subsys clocks
From: Icenowy Zheng @ 2026-06-09  6:01 UTC (permalink / raw)
  To: Drew Fustini
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <aier9XppLeCkJydw@thelio>

在 2026-06-08一的 23:00 -0700,Drew Fustini写道:
> On Thu, May 07, 2026 at 04:17:00PM +0800, Icenowy Zheng wrote:
> > The TH1520 SoC contains a MISC_SUBSYS clock controller, which
> > allows
> > controlling of USB related clocks and MMC/SD controller AHB bus
> > clocks.
> > 
> > Add support for this clock controller, in order to enable USB
> > support.
> > 
> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > ---
> >  drivers/clk/thead/clk-th1520-ap.c | 64
> > +++++++++++++++++++++++++++++++
> >  1 file changed, 64 insertions(+)
> > 
> > diff --git a/drivers/clk/thead/clk-th1520-ap.c
> > b/drivers/clk/thead/clk-th1520-ap.c
> > index 3a6847f1c950f..24f785f0b329a 100644
> > --- a/drivers/clk/thead/clk-th1520-ap.c
> > +++ b/drivers/clk/thead/clk-th1520-ap.c
> [...]
> > @@ -1609,6 +1663,12 @@ static int th1520_clk_probe(struct
> > platform_device *pdev)
> >  			return ret;
> >  	}
> >  
> > +	if (plat_data == &th1520_ap_platdata) {
> > +		ret = devm_clk_hw_register(dev,
> > &usb_suspend_div_clk.hw);
> > +		if (ret)
> > +			return ret;
> > +	}
> 
> Should usb_suspend_div_clk.hw instead be registered under
> 'if (plat_data == &th1520_ap_platdata)'?

Do you mean misc_platdata?

Yes, this is an copy-n-paste error that deserves a fix.

Thanks,
Icenowy

> 
> Thanks,
> Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 00/12] Add TH1520 USB support
From: Drew Fustini @ 2026-06-09  6:14 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <a8dc863b1692b4d327b4b9700dd56a4754120561.camel@icenowy.me>

On Tue, Jun 09, 2026 at 01:10:41PM +0800, Icenowy Zheng wrote:
> 在 2026-06-08一的 21:17 -0700,Drew Fustini写道:
> > On Thu, May 07, 2026 at 04:16:58PM +0800, Icenowy Zheng wrote:
> > > This patchset adds support for T-Head TH1520's USB functionality,
> > > and
> > > enabled it on the Lichee Pi 4A board.
> > > 
> > > The first 3 patches add support for the MISC subsystem clock
> > > contrtoller, which contains some USB clocks.
> > > 
> > > The next 2 patches add support for the USB PHY of T-Head TH1520,
> > > which
> > > is a wrapped Synopsys USB3.0 FemtoPHY with a little integration
> > > quirk;
> > > the controller itself is a properly configured DWC3 controller with
> > > sane
> > > default register values set.
> > > 
> > > Then one patch adds the USB PHY and controller nodes to the TH1520
> > > DTSI
> > > file.
> > > 
> > > The remaining half of this patchset dedicates to enablement of USB
> > > on
> > > TH1520, because of the onboard hub of that board -- its USB2
> > > signals are
> > > behind a switch that needs to be toggled on, and Vbus supplies for
> > > both
> > > the hub itself and downstream ports are managed via I2C-expanded
> > > GPIOs
> > > (because the SoC does not have enough GPIO pins).
> > 
> > Hi, thanks for working on USB. I tried to apply it to next-20260601
> > and
> > several of the dts patches no longer apply cleanly. Could you rebase?
> 
> I think the reason is that one of the GPIO expansion chip is added to
> the DT for enabling Wi-Fi.

Yeah, I tried to resolve the conflicts but I'm not sure what the correct
resolution is.

a20241c08385 ("riscv: dts: thead: Enable WiFi on Lichee Pi 4A") adds
'clock-frquency = <400000>' to &i2c1 while this series instead sets
'clock-frequency = <100000>'. That commit also sets i2c1_pins
'bias-pull-up = <2100>' while this series sets bias-disable.

> I am not sure whether the next revision of this patchset will contain
> all things, maybe I will split out at least the USB PHY part.

I think splitting out would work, too.

Thanks,
Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 02/12] clk: thead: th1520-ap: add support for MISC subsys clocks
From: Drew Fustini @ 2026-06-09  6:15 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <93b867c1b7f5526cc25cb04f838432cd752f5981.camel@icenowy.me>

On Tue, Jun 09, 2026 at 02:01:43PM +0800, Icenowy Zheng wrote:
> 在 2026-06-08一的 23:00 -0700,Drew Fustini写道:
> > On Thu, May 07, 2026 at 04:17:00PM +0800, Icenowy Zheng wrote:
> > > The TH1520 SoC contains a MISC_SUBSYS clock controller, which
> > > allows
> > > controlling of USB related clocks and MMC/SD controller AHB bus
> > > clocks.
> > > 
> > > Add support for this clock controller, in order to enable USB
> > > support.
> > > 
> > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > ---
> > >  drivers/clk/thead/clk-th1520-ap.c | 64
> > > +++++++++++++++++++++++++++++++
> > >  1 file changed, 64 insertions(+)
> > > 
> > > diff --git a/drivers/clk/thead/clk-th1520-ap.c
> > > b/drivers/clk/thead/clk-th1520-ap.c
> > > index 3a6847f1c950f..24f785f0b329a 100644
> > > --- a/drivers/clk/thead/clk-th1520-ap.c
> > > +++ b/drivers/clk/thead/clk-th1520-ap.c
> > [...]
> > > @@ -1609,6 +1663,12 @@ static int th1520_clk_probe(struct
> > > platform_device *pdev)
> > >  			return ret;
> > >  	}
> > >  
> > > +	if (plat_data == &th1520_ap_platdata) {
> > > +		ret = devm_clk_hw_register(dev,
> > > &usb_suspend_div_clk.hw);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > 
> > Should usb_suspend_div_clk.hw instead be registered under
> > 'if (plat_data == &th1520_ap_platdata)'?
> 
> Do you mean misc_platdata?
> 
> Yes, this is an copy-n-paste error that deserves a fix.

Hah, yes, I also had a typo :)

Thanks,
Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 03/12] riscv: dts: thead: add device tree node for MISC clock controller
From: Drew Fustini @ 2026-06-09  6:16 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
	linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
	linux-usb, Han Gao, Yao Zi
In-Reply-To: <67790d90737c13127100510020262d6921810e34.camel@icenowy.me>

On Tue, Jun 09, 2026 at 01:35:11PM +0800, Icenowy Zheng wrote:
> 在 2026-06-08一的 22:14 -0700,Drew Fustini写道:
> > On Thu, May 07, 2026 at 04:17:01PM +0800, Icenowy Zheng wrote:
> > > The MISC_SUBSYS clock controller on TH1520 SoC is a clock
> > > controller
> > > mainly controlling USB-related clocks (which isn't utilized yet)
> > > and
> > > MMC/SD controllers' AHB bus clocks.
> > > 
> > > Add the device tree node for it along with the missing bus clock
> > > references for MMC/SD controllers.
> > 
> > Is there a functional reason to modify the mmc nodes in this series?
> 
> When the clock isn't referenced, Linux will disable it unless
> `clk_ignore_unused` parameter is passed.

Ah ok, thanks for explaining.

Drew

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 2/3] dt-bindings: PCI: qcom,pcie-sm8550: Add Eliza compatible
From: Krzysztof Kozlowski @ 2026-06-09  8:58 UTC (permalink / raw)
  To: Krishna Chaitanya Chundru
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
	linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <20260608-eliza-v3-2-9bdeb7434b28@oss.qualcomm.com>

On Mon, Jun 08, 2026 at 02:18:14PM +0530, Krishna Chaitanya Chundru wrote:
> PCIe controller present in Eliza SoC is backwards compatible with the
> controller present in SM8550 SoC. Hence, add the compatible with SM8550
> fallback.
> 
> Eliza requires 6 reg entries, 8 clocks and 9 interrupts, so add the
> corresponding allOf constraints.
> 
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/pci/qcom,pcie-sm8550.yaml  | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
> index 3a94a9c1bb15..fb706b1397a3 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
> @@ -20,6 +20,7 @@ properties:
>        - const: qcom,pcie-sm8550
>        - items:
>            - enum:
> +              - qcom,eliza-pcie
>                - qcom,kaanapali-pcie
>                - qcom,sar2130p-pcie
>                - qcom,pcie-sm8650
> @@ -91,6 +92,55 @@ required:
>  
>  allOf:
>    - $ref: qcom,pcie-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,eliza-pcie
> +    then:
> +      properties:
> +        reg:
> +          minItems: 6
> +        reg-names:
> +          minItems: 6
> +

This could be just one if:. Much less code, but I don't mind this
approach.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: phy: nuvoton: Add MA35D1 USB2 OTG PHY binding
From: Joey Lu @ 2026-06-09  9:15 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
	linux-arm-kernel, linux-kernel
In-Reply-To: <20260608-demonic-horned-honeybee-4f6bb7@quoll>


On 6/8/2026 6:45 PM, Krzysztof Kozlowski wrote:
> On Thu, Jun 04, 2026 at 06:12:19PM +0800, Joey Lu wrote:
>
> A nit, subject: drop second/last, redundant "binding". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Understood. The trailing "binding" will be dropped from the patch 
subject line in the next submission.
>> +properties:
>> +  compatible:
>> +    const: nuvoton,ma35d1-usb2-phy-otg
>> +
> Where is reg? MMIO is expressed with reg, not via custom phandle.
Understood. The PHY node will be restructured as a child of the syscon 
node, with a `reg = <0x60 0x14>` property covering the writable PHY 
control registers (USBPMISCR, MISCFCR0) within the parent's address 
space. The `nuvoton,sys` custom phandle will be removed; the driver will 
obtain the parent's regmap via 
`syscon_node_to_regmap(dev->parent->of_node)`, which looks up the global 
syscon list by `of_node`. PHY instance selection will be expressed via 
`#phy-cells = <1>`, with 0 for the OTG port (USB0) and 1 for the 
host-only port (USB1).
>
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  nuvoton,sys:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    items:
>> +      - items:
>> +          - description: phandle to the system management syscon.
>> +          - description: PHY instance index.
>> +            enum:
>> +              - 0   # USB0, OTG port (shared with DWC2 gadget controller)
>> +              - 1   # USB1, host-only port
>> +    description:
>> +      A phandle to the syscon node covering the SYS register block, with
>> +      one argument selecting the PHY instance. Index 0 selects the OTG
>> +      port PHY (USB0) and index 1 selects the host-only PHY (USB1).
>> +
>> +  "#phy-cells":
>> +    const: 0
>> +
>> +  nuvoton,rcalcode:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    minimum: 0
>> +    maximum: 15
>> +    description:
>> +      Resistor calibration trim code written to the RCALCODE field in
>> +      USBPMISCR. The 4-bit value adjusts the PHY's internal termination
>> +      resistance. When absent the hardware reset default is used.
>> +
>> +  nuvoton,oc-active-high:
>> +    type: boolean
>> +    description:
>> +      When present, the over-current detect input from the VBUS power
>> +      switch is treated as active-high. The default (property absent) is
>> +      active-low. This setting is shared by both USB host ports.
>> +
>> +required:
>> +  - compatible
>> +  - clocks
>> +  - nuvoton,sys
>> +  - "#phy-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> +
>> +    usb_hphy0: usb-host-phy {
> usb-phy
>
> And drop unused label.

Understood. The node name will be changed to `usb-phy` and the unused 
label `usb_hphy0:` will be removed.

Thanks for the review!

>> +        compatible = "nuvoton,ma35d1-usb2-phy-otg";
>> +        clocks = <&clk HUSBH0_GATE>;
>> +        nuvoton,sys = <&sys 0>;
>> +        #phy-cells = <0>;
>> +    };
>> -- 
>> 2.43.0
>>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH v2 0/2] Enable the QMP PCIe PHY present in Qualcomm ipq5210 SoC
From: Varadarajan Narayanan @ 2026-06-09  9:22 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
	Varadarajan Narayanan

Document the bindings and update the driver to support
the PCIe phy present in Qualcomm ipq5210 SoC.

v2: Had incorrectly made both the phys as fallback. The single
    lane phy is standalone and double lane uses ipq9574 as
    fallback.

v1: https://lore.kernel.org/linux-arm-msm/20260514-pci-phy-v1-0-482429192746@oss.qualcomm.com/

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Varadarajan Narayanan (2):
      dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
      phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys

 .../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml    |   2 +
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c           | 145 +++++++++++++++++++++
 2 files changed, 147 insertions(+)
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-pcie-phy-99fcf91a02fd
prerequisite-change-id: 20260514-icc-ipq5210-0ab03f3a3e83:v1
prerequisite-patch-id: 0b6145b6635b18fe79fbbff5815041b43778c5ed
prerequisite-patch-id: 924c6ff7baf4283ac7991ee94c803a00fc5cece4
prerequisite-patch-id: c2fe1800fe769dccd37f94c19860a07f979e3c4c

Best regards,
-- 
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH v2 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Varadarajan Narayanan @ 2026-06-09  9:22 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
	Varadarajan Narayanan
In-Reply-To: <20260609-pcie-phy-v2-0-83bc80e79fa6@oss.qualcomm.com>

Document the PCIe phys on the ipq5210 platform. The 2 lane phy uses the
ipq9574 as fallback. The single lane phy is documented separately.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index f60804687412..fc155ad5fa6d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     oneOf:
       - enum:
+          - qcom,ipq5210-qmp-gen3x1-pcie-phy
           - qcom,ipq6018-qmp-pcie-phy
           - qcom,ipq8074-qmp-gen3-pcie-phy
           - qcom,ipq8074-qmp-pcie-phy
@@ -28,6 +29,7 @@ properties:
           - const: qcom,ipq9574-qmp-gen3x1-pcie-phy
       - items:
           - enum:
+              - qcom,ipq5210-qmp-gen3x2-pcie-phy
               - qcom,ipq5424-qmp-gen3x2-pcie-phy
           - const: qcom,ipq9574-qmp-gen3x2-pcie-phy
 

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* [PATCH v2 2/2] phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
From: Varadarajan Narayanan @ 2026-06-09  9:22 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
	Varadarajan Narayanan
In-Reply-To: <20260609-pcie-phy-v2-0-83bc80e79fa6@oss.qualcomm.com>

Add support for a PCIe phys found on Qualcomm ipq5210 platform.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 145 +++++++++++++++++++++++++++++++
 1 file changed, 145 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 75afbd15aaf4..4d01123e8dbf 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -514,6 +514,105 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_gen3_pcs_misc_tbl[] = {
 	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
 };
 
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_serdes_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TIMER, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_BUF_ENABLE, 0x07),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_IVCO, 0x0f),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE0, 0xff),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE0, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE1, 0xff),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE1, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TRIM, 0x0f),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE0, 0x23),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE1, 0x23),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE0, 0x10),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE1, 0x10),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE0, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE1, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_RESETSM_CNTRL, 0x20),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP_EN, 0x42),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE0, 0x19),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE1, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE0, 0xfe),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE0, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE1, 0xfe),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE1, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE0, 0x24),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE0, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE1, 0xb4),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE1, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CMN_CONFIG, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV_MODE1, 0x08),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYS_CLK_CTRL, 0x07),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x10),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_tx_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_TX, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_V4_TX_RCV_DETECT_LVL_2, 0x12),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_rx_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0c),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x70),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x61),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1e),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x73),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_ENABLES, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_LOW, 0xf0),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH2, 0x2f),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH3, 0xd3),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH4, 0x40),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_LOW, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH2, 0xc8),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH3, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH4, 0xb1),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_LOW, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH2, 0xc8),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH3, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH4, 0xb1),
+	QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_EN_TIMER, 0x04),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_pcs_tbl[] = {
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_FLL_CNTRL1, 0x01),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x0d),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_G12S1_TXDEEMPH_M3P5DB, 0x10),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_RX_SIGDET_LVL, 0xaa),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_P2U3_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_RX_DCC_CAL_CONFIG, 0x01),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_EQ_CONFIG5, 0x01),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_pcs_misc_tbl[] = {
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2, 0x04),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_EQ_CONFIG1, 0x11),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_PRE, 0x00),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_POST, 0x58),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG1, 0x02),
+	QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG4, 0xff),
+};
+
 static const struct qmp_phy_init_tbl ipq9574_gen3x1_pcie_serdes_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
 	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
@@ -3613,6 +3712,49 @@ static const struct qmp_phy_cfg ipq6018_pciephy_cfg = {
 	.phy_status		= PHYSTATUS,
 };
 
+static const struct qmp_phy_cfg ipq5210_gen3x1_pciephy_cfg = {
+	.lanes			= 1,
+
+	.offsets		= &qmp_pcie_offsets_v4x1,
+
+	.tbls =  {
+		.serdes		= ipq9574_gen3x1_pcie_serdes_tbl,
+		.serdes_num	= ARRAY_SIZE(ipq9574_gen3x1_pcie_serdes_tbl),
+		.tx		= ipq8074_pcie_gen3_tx_tbl,
+		.tx_num		= ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl),
+		.rx		= ipq9574_pcie_rx_tbl,
+		.rx_num		= ARRAY_SIZE(ipq9574_pcie_rx_tbl),
+		.pcs		= ipq9574_gen3x1_pcie_pcs_tbl,
+		.pcs_num	= ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_tbl),
+		.pcs_misc	= ipq9574_gen3x1_pcie_pcs_misc_tbl,
+		.pcs_misc_num	= ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_misc_tbl),
+	},
+
+	.tbls_ep = &(const struct qmp_phy_cfg_tbls) {
+		.serdes		= ipq5210_gen3x1_pcie_ep_serdes_tbl,
+		.serdes_num	= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_serdes_tbl),
+		.tx		= ipq6018_pcie_tx_tbl,
+		.tx_num		= ARRAY_SIZE(ipq6018_pcie_tx_tbl),
+		.rx		= ipq5210_gen3x1_pcie_ep_rx_tbl,
+		.rx_num		= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_rx_tbl),
+		.pcs		= ipq6018_pcie_pcs_tbl,
+		.pcs_num	= ARRAY_SIZE(ipq6018_pcie_pcs_tbl),
+		.pcs_misc	= ipq5210_gen3x1_pcie_ep_pcs_misc_tbl,
+		.pcs_misc_num	= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_pcs_misc_tbl),
+	},
+
+	.reset_list		= ipq8074_pciephy_reset_l,
+	.num_resets		= ARRAY_SIZE(ipq8074_pciephy_reset_l),
+	.vreg_list		= NULL,
+	.num_vregs		= 0,
+	.regs			= pciephy_v4_regs_layout,
+
+	.pwrdn_ctrl		= SW_PWRDN | REFCLK_DRV_DSBL,
+	.phy_status		= PHYSTATUS,
+
+	.pipe_clock_rate	= 250000000,
+};
+
 static const struct qmp_phy_cfg ipq9574_gen3x1_pciephy_cfg = {
 	.lanes			= 1,
 
@@ -5404,6 +5546,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
 	}, {
 		.compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
 		.data = &glymur_qmp_gen5x4_pciephy_cfg,
+	}, {
+		.compatible = "qcom,ipq5210-qmp-gen3x1-pcie-phy",
+		.data = &ipq5210_gen3x1_pciephy_cfg,
 	}, {
 		.compatible = "qcom,ipq6018-qmp-pcie-phy",
 		.data = &ipq6018_pciephy_cfg,

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* Re: [PATCH v2 2/2] phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
From: sashiko-bot @ 2026-06-09  9:34 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: vkoul, devicetree, conor+dt, neil.armstrong, linux-phy, olteanv,
	robh
In-Reply-To: <20260609-pcie-phy-v2-2-83bc80e79fa6@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly defined PHY initialization tables `ipq5210_gen3x1_pcie_ep_tx_tbl` and `ipq5210_gen3x1_pcie_ep_pcs_tbl` are never used, as the endpoint configuration mistakenly references tables from the ipq6018 SoC.
--

commit bf5e268631f81219e100892c439cbf010f5cd5f1
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys

This patch adds support for a PCIe phys found on the Qualcomm ipq5210
platform.

> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
[ ... ]
> @@ -3613,6 +3712,49 @@ static const struct qmp_phy_cfg ipq6018_pciephy_cfg = {
[ ... ]
> +static const struct qmp_phy_cfg ipq5210_gen3x1_pciephy_cfg = {
[ ... ]
> +	.tbls_ep = &(const struct qmp_phy_cfg_tbls) {
> +		.serdes		= ipq5210_gen3x1_pcie_ep_serdes_tbl,
> +		.serdes_num	= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_serdes_tbl),
> +		.tx		= ipq6018_pcie_tx_tbl,
> +		.tx_num		= ARRAY_SIZE(ipq6018_pcie_tx_tbl),
> +		.rx		= ipq5210_gen3x1_pcie_ep_rx_tbl,
> +		.rx_num		= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_rx_tbl),
> +		.pcs		= ipq6018_pcie_pcs_tbl,
> +		.pcs_num	= ARRAY_SIZE(ipq6018_pcie_pcs_tbl),

[Severity: High]
Are the newly added ipq5210_gen3x1_pcie_ep_tx_tbl and 
ipq5210_gen3x1_pcie_ep_pcs_tbl arrays intended to be used here?

This configuration assigns the tx and pcs fields to the ipq6018 arrays, which
appears to leave the new ipq5210 tx and pcs tables entirely unused. Could this
result in incorrect PHY hardware programming for the endpoint?

> +		.pcs_misc	= ipq5210_gen3x1_pcie_ep_pcs_misc_tbl,
> +		.pcs_misc_num	= ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_pcs_misc_tbl),
> +	},
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-pcie-phy-v2-0-83bc80e79fa6@oss.qualcomm.com?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Kathiravan Thirumoorthy @ 2026-06-09 10:16 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <56zkq7bwrt5smmmum6jckzrekkkqrych2gntx3obnrmamwumtv@espahwe6pc3v>


On 6/8/2026 12:26 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 02, 2026 at 02:40:18PM +0530, Kathiravan Thirumoorthy wrote:
>> The IPQ9650 platform has three Gen3 2-lane PCIe controllers and two Gen3
>> 1-lane PCIe controllers. The PHY instances also require the on-chip refgen
>> supply.
>>
>> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations, including the
>> refgen regulator supply.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>> ---
>>   drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
>>   1 file changed, 220 insertions(+)
>>
>> @@ -3378,6 +3524,10 @@ static const char * const qmp_phy_vreg_l[] = {
>>   	"vdda-phy", "vdda-pll",
>>   };
>>   
>> +static const char * const ipq9650_qmp_phy_vreg_l[] = {
>> +	"refgen",
>> +};
> Now vdda-phy / vdda-pll supplies?

Cross checked with HW team again. Along with refgen, there is a on-chip 
LDO which supplies fixed voltage to the PHYs. It is enabled upon system 
power on and no SW intervention is required.

regulator-fixed doesn't take the resource 'reg'. May be should I create 
another regulator driver which accepts 'reg', something similar to the 
qcom-refgen-regulator? Please advise.

>
>> +
>>   static const char * const sm8550_qmp_phy_vreg_l[] = {
>>   	"vdda-phy", "vdda-pll", "vdda-qref",
>>   };

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-06-09 13:56 UTC (permalink / raw)
  To: Bryan O'Donoghue, Vladimir Zapolskiy, Bryan O'Donoghue,
	Vijay Kumar Tumati, Vinod Koul, Kishon Vijay Abraham I,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
  Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <67b6f6ae-bfca-4afd-adfb-6ec1741105d8@linaro.org>

On 6/4/26 11:06 AM, Bryan O'Donoghue wrote:
> On 04/06/2026 09:46, Vladimir Zapolskiy wrote:
>> On 6/4/26 03:30, Bryan O'Donoghue wrote:
>>> On 04/06/2026 01:07, Vladimir Zapolskiy wrote:
>>>> On 6/4/26 00:18, Bryan O'Donoghue wrote:
>>>>> On 03/06/2026 21:51, Vladimir Zapolskiy wrote:
>>>>>>> Actually, one more thing, Why isn't TITAN TOP GDSC here?>>>> +
>>>>>> If CSIPHYs are true subdevices under the umbrella CAMSS device and well
>>>>>> described as subnodes, then likely none of power domains are needed

[...]

>>
>> CCI is not described as a child of CAMSS, here the situation is different.
> 
> CCI probably _should_ be a child of CAMSS given the design we are going for here.

Yes

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Felix Gu @ 2026-06-09 14:48 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Liu Ying
  Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, sashiko, Felix Gu

The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
with pm_runtime_put(). The asynchronous variant queues a work item
to handle the idle check and potential suspend, which can be cancelled
by a subsequent pm_runtime_disable() call if probe fails after the reset.

Switch to pm_runtime_put_sync() to run the idle check and suspend
synchronously.

Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
Reported-by: sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
 drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
index ece357443521..e2a1645000ae 100644
--- a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
@@ -286,7 +286,7 @@ static int mixel_lvds_phy_reset(struct device *dev)
 
 	regmap_write(priv->regmap, PHY_CTRL, CTRL_RESET_VAL);
 
-	pm_runtime_put(dev);
+	pm_runtime_put_sync(dev);
 
 	return 0;
 }

---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-lvds-phy-6328389a2cf1

Best regards,
--  
Felix Gu <ustc.gu@gmail.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: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Frank Li @ 2026-06-09 15:51 UTC (permalink / raw)
  To: Felix Gu
  Cc: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Liu Ying, linux-phy, imx,
	linux-arm-kernel, linux-kernel, sashiko
In-Reply-To: <20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com>

On Tue, Jun 09, 2026 at 10:48:50PM +0800, Felix Gu wrote:
>
> The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
> with pm_runtime_put(). The asynchronous variant queues a work item
> to handle the idle check and potential suspend, which can be cancelled
> by a subsequent pm_runtime_disable() call if probe fails after the reset.
>
> Switch to pm_runtime_put_sync() to run the idle check and suspend
> synchronously.
>
> Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support")
> Reported-by: sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> index ece357443521..e2a1645000ae 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c
> @@ -286,7 +286,7 @@ static int mixel_lvds_phy_reset(struct device *dev)
>
>         regmap_write(priv->regmap, PHY_CTRL, CTRL_RESET_VAL);
>
> -       pm_runtime_put(dev);
> +       pm_runtime_put_sync(dev);
>
>         return 0;
>  }
>
> ---
> base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
> change-id: 20260609-lvds-phy-6328389a2cf1
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v4 phy-next 14/16] dt-bindings: phy: lynx-10g: initial document
From: Conor Dooley @ 2026-06-09 16:26 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-phy, Ioana Ciornei, Vinod Koul, Neil Armstrong,
	Tanjeff Moos, linux-kernel, Rob Herring, devicetree, Conor Dooley,
	Krzysztof Kozlowski
In-Reply-To: <20260608221710.1572971-15-vladimir.oltean@nxp.com>


[-- Attachment #1.1: Type: text/plain, Size: 496 bytes --]

On Tue, Jun 09, 2026 at 01:17:08AM +0300, Vladimir Oltean wrote:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - fsl,ls1046a-serdes1
> +              - fsl,ls1046a-serdes2
> +    then:

> +      properties:
> +        big-endian: true

This should have stayed at the top-level FWIW, and here you would do
then:
  required:
    - big-endian
else:
  properties:
    big-endian: false

> +      required:
> +        - big-endian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox