* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Rob Herring (Arm) @ 2026-06-30 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sireesh Kodali, Stephen Boyd, Rob Clark, Wesley Cheng, Vinod Koul,
Seung-Woo Kim, Michael Turquette, freedreno, Linus Walleij,
Sam Protsenko, Rafael J. Wysocki, Alim Akhtar, linux-gpio,
linux-arm-msm, Taniya Das, Liam Girdwood, Imran Shaik, linux-phy,
Christian Marangi, Sebastian Reichel, Luo Jie,
Niklas Söderlund, Bjorn Andersson, Niklas Söderlund,
linux-kernel, linux-arm-kernel, dri-devel, Magnus Damm,
Conor Dooley, Brian Masney, linux-serial, linux-mmc, Sean Paul,
Kyungmin Park, Krishna Manikandan, linux-i2c, Konrad Dybcio,
Sylwester Nawrocki, Bartlomiej Zolnierkiewicz, Hans Verkuil,
Krzysztof Kozlowski, Chanwoo Choi, Sricharan Ramabadhran,
Andy Gross, Simona Vetter, Jaehoon Chung, Mauro Carvalho Chehab,
Zhang Rui, Maarten Lankhorst, Jessica Zhang, Tomasz Figa,
Shin Son, Marek Szyprowski, Robert Marko, linux-leds, Lee Jones,
Lukasz Luba, Srinivas Kandagatla, Georgi Djakov, Barnabas Czeman,
Greg Kroah-Hartman, Anusha Rao, linux-sound, Neil Armstrong,
linux-pm, Jiri Slaby, Marijn Suijten, Stephan Gerhold, linux-clk,
Mark Brown, Maxime Ripard, Pavel Machek, David Airlie,
Geert Uytterhoeven, Sunyeal Hong, Peter Griffin,
Sebastian Reichel, Andi Shyti, Dmitry Baryshkov, linux-usb,
Thomas Zimmermann, Jacek Anaszewski, Daniel Lezcano, Alina Yu,
Abhinav Kumar, Adam Skladowski, Conor Dooley,
Javier Martinez Canillas, Jonathan Marek, linux-renesas-soc,
linux-samsung-soc, Inki Dae, linux-media, Ulf Hansson,
Chanho Park, devicetree
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 23 Jun 2026 07:48:44 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
>
> Changes in v2:
> 1. Add tags (partial Reviews as Acks, as that's the meaning of Ack)
> 2. Do not replace ::= in mux.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
> .../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
> .../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
> 30 files changed, 73 insertions(+), 73 deletions(-)
>
Applied, thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Rob Herring (Arm) @ 2026-06-30 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Sean Paul, Krzysztof Kozlowski, David Airlie,
Kyungmin Park, Lukasz Luba, Vinod Koul, Adam Skladowski,
Chanho Park, Wesley Cheng, Mark Brown, Linus Walleij, Alim Akhtar,
Abhinav Kumar, linux-gpio, linux-samsung-soc, Anusha Rao,
linux-mmc, Jonathan Marek, Greg Kroah-Hartman,
Javier Martinez Canillas, Taniya Das, linux-clk, Stephen Boyd,
linux-kernel, Zhang Rui, Srinivas Kandagatla, Barnabas Czeman,
Bjorn Andersson, Sunyeal Hong, freedreno, Stephan Gerhold,
Rob Clark, Simona Vetter, Andi Shyti, Niklas Söderlund,
linux-i2c, Brian Masney, Mauro Carvalho Chehab, Maarten Lankhorst,
Konrad Dybcio, Maxime Ripard, Daniel Lezcano, Rafael J. Wysocki,
Hans Verkuil, Dmitry Baryshkov, Sebastian Reichel, Chanwoo Choi,
Robert Marko, linux-sound, linux-usb, Pavel Machek, Peter Griffin,
linux-arm-msm, Marijn Suijten, Christian Marangi, Imran Shaik,
Neil Armstrong, dri-devel, Jiri Slaby, linux-phy, Shin Son,
Jessica Zhang, Liam Girdwood, Sam Protsenko, Tomasz Figa,
Magnus Damm, linux-renesas-soc, Jacek Anaszewski,
Sricharan Ramabadhran, Georgi Djakov, Conor Dooley,
Geert Uytterhoeven, devicetree, Luo Jie, linux-serial,
Jaehoon Chung, Andy Gross, Krishna Manikandan, Thomas Zimmermann,
linux-leds, Marek Szyprowski, Conor Dooley, linux-media,
Michael Turquette, Ulf Hansson, Bartlomiej Zolnierkiewicz,
Seung-Woo Kim, Inki Dae, linux-arm-kernel, Sireesh Kodali,
Sylwester Nawrocki, linux-pm, Alina Yu
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 23 Jun 2026 07:48:43 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> I split the patches to avoid bounces from mailing list due to email size.
>
> This can go via clock tree (no dependencies)... or both could go via
> Rob's tree.
>
> Changes in v2:
> 1. Add tags (partial Reviews as Acks, as that's the meaning of Ack)
> ---
> .../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
> .../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
> .../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
> .../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
> 32 files changed, 34 insertions(+), 34 deletions(-)
>
Applied, thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Rakesh Kota @ 2026-06-30 12:42 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Kamal Wadhwa, linux-arm-msm, sashiko-reviews, Komal Bajaj, robh,
linux-phy, neil.armstrong, vkoul, olteanv, krzk+dt, conor+dt,
devicetree, Jishnu Prakash
In-Reply-To: <5idu4ljmcvcvzqsr5g73h2roxzs36l6xxc5ju6ovc5aitt3gx4@wmfqueyf2rj6>
On Sun, Jun 28, 2026 at 03:33:23PM +0300, Dmitry Baryshkov wrote:
> 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.
Currently, Agatti uses the same PMIC, so we cannot set the driver
supply name reference to NULL. Since it's an older target,
we'll need to run a regression before making any driver-level changes.
Additionally, the child-to-parent regulator ganging differs between
Shikra and Agatti:
- On Agatti, l3 regulator is ganged with vdd_l13_l14_l15_l16
- On Shikra, l3 is ganged with vdd_l2_l3
Since vdd_l2_l3 is not present as a supply name in the driver, it will
be skipped by the driver and would only serve as a representational
reference in the DT.
We have two options to consider:
Option 1: Skip adding the child/parent relationship for Shikra for now,
since the DT bindings are not enforcing it. (Ref:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml?h=v7.1)
Option 2: Go ahead and add the Shikra-specific ganging in DT now. Since
the supply name (vdd_l2_l3) does not match what the driver expects
(Agatti's mapping), it will be gracefully skipped by the driver — making
it safe to add for documentation/representation purposes without any
functional impact.
So,Please share your thoughts on above options ?
Thanks
Rakesh kota
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: phy-can-transceiver: Add suspend operation for tcan1043
From: sashiko-bot @ 2026-06-30 12:40 UTC (permalink / raw)
Cc: olteanv, vkoul, Vincent Mailhol, Oliver Hartkopp, Oleksij Rempel,
linux-can, Marc Kleine-Budde, linux-phy, neil.armstrong
In-Reply-To: <20260630-phy-can-transceiver-suspend-resume-support-v1-1-6842c2d697e4@bootlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `.resume` callback in PM operations leaves the CAN PHY permanently in Sleep mode after system resume.
- [Medium] Missing delay when transitioning through Normal mode may result in the transition being ignored by the transceiver hardware.
--
commit 2d2e1a772ce8aac2faea27b0135abc2a7ed70072
Author: Thomas Richard (TI) <thomas.richard@bootlin.com>
phy: phy-can-transceiver: Add suspend operation for tcan1043
This commit adds a suspend operation for the tcan1043 PHY, switching it
to Sleep mode during system suspend. It transitions the PHY through Normal
mode to clear the WAKERQ flag before entering Go-to-Sleep and finally
Sleep mode.
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 75dc49e75ca0e..2bca1a173fcc3 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
> @@ -76,12 +80,28 @@ static const struct phy_ops can_transceiver_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static int tcan1043_suspend(struct can_transceiver_phy *phy)
> +{
> + /* Switch to Normal mode, it clears WAKERQ */
> + gpiod_set_value_cansleep(phy->standby_gpio, 0);
> + gpiod_set_value_cansleep(phy->enable_gpio, 1);
> +
> + /* Switch to Go-to-Sleep mode */
> + gpiod_set_value_cansleep(phy->standby_gpio, 1);
[Severity: Medium]
Will this back-to-back GPIO toggle execute too quickly on platforms with fast
memory-mapped GPIOs?
Without an intermediate delay, the sub-microsecond state change might not
give the transceiver's internal state machine enough time to register the
Normal mode transition. Can this cause the transceiver to ignore the
transition, fail to clear the WAKERQ flag, and thus fail to enter Sleep
mode?
> +
> + /* Wait transition to Sleep mode */
> + fsleep(5);
> +
> + return 0;
> +}
[ ... ]
> @@ -115,6 +135,26 @@ static struct phy *can_transceiver_phy_xlate(struct device *dev,
> return priv->can_transceiver_phy[idx].generic_phy;
> }
>
> +static int can_transceiver_phy_suspend(struct device *dev)
> +{
> + struct can_transceiver_priv *priv = dev_get_drvdata(dev);
> + const struct can_transceiver_data *data = priv->data;
> + int ret, i;
> +
> + for (i = 0; i < priv->num_ch; i++) {
> + if (data->suspend) {
> + ret = data->suspend(&priv->can_transceiver_phy[i]);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(can_transceiver_phy_pm_ops,
> + can_transceiver_phy_suspend, NULL);
[Severity: High]
Does leaving the resume callback as NULL permanently leave the CAN PHY in
Sleep mode after a system resume?
Since the parent CAN MAC driver typically relies on the PHY framework for
power management and may not manually wake the PHY during its own resume
flow, could this prevent the CAN interface from becoming responsive again
until it is manually brought down and back up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-phy-can-transceiver-suspend-resume-support-v1-1-6842c2d697e4@bootlin.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: phy-can-transceiver: Add suspend operation for tcan1043
From: Thomas Richard (TI) @ 2026-06-30 12:28 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong
Cc: Thomas Petazzoni, Gregory CLEMENT, richard.genoud, Udit Kumar,
Abhash Kumar, linux-can, linux-phy, linux-kernel,
Thomas Richard (TI)
Add suspend operation for tcan1043. It switches the PHY in Sleep mode, the
lowest power mode of the device. If a bus wake-up pattern or a local
wake-up event occurs, the PHY transitions to Standby mode, set its internal
WAKERQ flag and set the INH output high. In Sleep mode INH is floating.
The WAKERQ flag prevents transition to Go-to-Sleep mode. The only way to
clear it is to switch to Normal mode. So to reach Sleep mode, we firstly
switch to Normal mode, then to Go-to-Sleep mode.
Suspend sequence (PHY is off):
Standby -> Normal -> Go-to-Sleep -> Sleep
Suspend sequence (PHY is on):
Normal -> Go-to-Sleep -> Sleep
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/phy/phy-can-transceiver.c | 56 ++++++++++++++++++++++++++++++++++-----
1 file changed, 49 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 75dc49e75ca0..2bca1a173fcc 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,6 +5,7 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
+#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
@@ -12,25 +13,28 @@
#include <linux/module.h>
#include <linux/mux/consumer.h>
+struct can_transceiver_phy {
+ struct phy *generic_phy;
+ struct gpio_desc *silent_gpio;
+ struct gpio_desc *standby_gpio;
+ struct gpio_desc *enable_gpio;
+ struct can_transceiver_priv *priv;
+};
+
struct can_transceiver_data {
u32 flags;
#define CAN_TRANSCEIVER_STB_PRESENT BIT(0)
#define CAN_TRANSCEIVER_EN_PRESENT BIT(1)
#define CAN_TRANSCEIVER_DUAL_CH BIT(2)
#define CAN_TRANSCEIVER_SILENT_PRESENT BIT(3)
+ int (*suspend)(struct can_transceiver_phy *phy);
};
-struct can_transceiver_phy {
- struct phy *generic_phy;
- struct gpio_desc *silent_gpio;
- struct gpio_desc *standby_gpio;
- struct gpio_desc *enable_gpio;
- struct can_transceiver_priv *priv;
-};
struct can_transceiver_priv {
struct mux_state *mux_state;
int num_ch;
+ const struct can_transceiver_data *data;
struct can_transceiver_phy can_transceiver_phy[] __counted_by(num_ch);
};
@@ -76,12 +80,28 @@ static const struct phy_ops can_transceiver_phy_ops = {
.owner = THIS_MODULE,
};
+static int tcan1043_suspend(struct can_transceiver_phy *phy)
+{
+ /* Switch to Normal mode, it clears WAKERQ */
+ gpiod_set_value_cansleep(phy->standby_gpio, 0);
+ gpiod_set_value_cansleep(phy->enable_gpio, 1);
+
+ /* Switch to Go-to-Sleep mode */
+ gpiod_set_value_cansleep(phy->standby_gpio, 1);
+
+ /* Wait transition to Sleep mode */
+ fsleep(5);
+
+ return 0;
+}
+
static const struct can_transceiver_data tcan1042_drvdata = {
.flags = CAN_TRANSCEIVER_STB_PRESENT,
};
static const struct can_transceiver_data tcan1043_drvdata = {
.flags = CAN_TRANSCEIVER_STB_PRESENT | CAN_TRANSCEIVER_EN_PRESENT,
+ .suspend = tcan1043_suspend,
};
static const struct can_transceiver_data tja1048_drvdata = {
@@ -115,6 +135,26 @@ static struct phy *can_transceiver_phy_xlate(struct device *dev,
return priv->can_transceiver_phy[idx].generic_phy;
}
+static int can_transceiver_phy_suspend(struct device *dev)
+{
+ struct can_transceiver_priv *priv = dev_get_drvdata(dev);
+ const struct can_transceiver_data *data = priv->data;
+ int ret, i;
+
+ for (i = 0; i < priv->num_ch; i++) {
+ if (data->suspend) {
+ ret = data->suspend(&priv->can_transceiver_phy[i]);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(can_transceiver_phy_pm_ops,
+ can_transceiver_phy_suspend, NULL);
+
static int can_transceiver_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -145,6 +185,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
return -ENOMEM;
priv->num_ch = num_ch;
+ priv->data = drvdata;
platform_set_drvdata(pdev, priv);
mux_state = devm_mux_state_get_optional(dev, NULL);
@@ -247,6 +288,7 @@ static struct platform_driver can_transceiver_phy_driver = {
.driver = {
.name = "can-transceiver-phy",
.of_match_table = can_transceiver_phy_ids,
+ .pm = pm_sleep_ptr(&can_transceiver_phy_pm_ops),
},
};
---
base-commit: a25d586f7f9e7f22e7e0350053c15924d28ed6ee
change-id: 20260618-phy-can-transceiver-suspend-resume-support-de9f32852fb8
Best regards,
--
Thomas Richard (TI) <thomas.richard@bootlin.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: sashiko-bot @ 2026-06-30 11:13 UTC (permalink / raw)
To: Xu Yang; +Cc: Frank.Li, vkoul, olteanv, linux-phy, imx, neil.armstrong
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-4-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Runtime PM enablement is leaked on probe error paths.
--
commit 487a0a8551844cc9b5c38e7f8d7cbf2ec3f1435d
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: add control register regmap
This commit adds a control register regmap for the USB 3.0 femtoPHY.
It exposes these registers through debugfs to assist with diagnostic
efforts.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 9d1dd0e7352ed..4949ec78d3044 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -695,6 +707,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> + &imx_cr_regmap_config);
> + if (IS_ERR(imx_phy->cr_regmap)) {
> + dev_warn(dev, "Fail to init debug register regmap\n");
> + imx_phy->cr_regmap = NULL;
> + }
> +
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
[Severity: Medium]
Is there a leak of the runtime PM enablement state on probe error paths here?
In imx8mq_usb_phy_probe(), pm_runtime_enable() is called, but subsequent
initialization steps (like devm_phy_create() or devm_regulator_get()) can fail
and return directly without calling pm_runtime_disable().
Could this leave the disable_depth counter at 0 on a probe failure like
-EPROBE_DEFER, resulting in an 'Unbalanced pm_runtime_enable!' warning on the
next probe attempt? Would using devm_pm_runtime_enable() ensure this state is
properly cleaned up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: sashiko-bot @ 2026-06-30 10:52 UTC (permalink / raw)
To: Xu Yang; +Cc: imx, vkoul, linux-phy, olteanv, Frank.Li, neil.armstrong
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-3-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `pm_runtime_disable()` in `imx8mq_usb_phy_probe()` error paths causes a `disable_depth` imbalance and PM state corruption.
--
commit e9418c8d510e8492ef9a52ace4cb6d672041d448
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: add runtime PM support
This commit adds runtime PM support to ensure the PHY is properly powered
and clocked during register access, preventing potential system hangs.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -708,6 +695,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> +
> phy_ops = of_device_get_match_data(dev);
> if (!phy_ops)
> return -EINVAL;
[Severity: High]
Does this code need a cleanup path to call pm_runtime_disable() on probe
failures?
If functions following pm_runtime_enable() fail (such as
of_device_get_match_data(), devm_phy_create(), or devm_regulator_get()),
the driver returns the error directly without cleaning up the PM state.
This can leave the disable_depth counter out of sync. If the device probe
defers (for example, if devm_regulator_get() returns -EPROBE_DEFER) and
runs again, the subsequent pm_runtime_enable() could drop the counter
below zero. This might trigger an unbalanced pm_runtime_enable warning
and leave the device permanently stuck in RPM_ACTIVE.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 1/5] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
From: sashiko-bot @ 2026-06-30 10:31 UTC (permalink / raw)
To: Xu Yang; +Cc: linux-phy, Frank.Li, vkoul, imx, neil.armstrong, olteanv
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-1-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition causing NULL pointer dereference during device probe.
- [High] Use-After-Free of devm-allocated driver data during device unbind.
--
commit d64f34cfc15d26f577e5ff3a17572cf971e65696
Author: Felix Gu <ustc.gu@gmail.com>
phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
If probe fails after imx95_usb_phy_get_tca() succeeds, the typec
switch leaks because the only cleanup path was in .remove, which
never runs on probe failure. Use devm_add_action_or_reset() so the
switch is cleaned up on both probe failure and driver removal.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -266,17 +267,11 @@ static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
> tca->orientation = TYPEC_ORIENTATION_NORMAL;
> tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
[Severity: High]
This is a pre-existing issue, but does this code introduce a race
condition during probe?
When tca_blk_get_typec_switch() registers the switch, it is immediately
visible to consumers. However, imx_phy->tca has not been assigned yet.
It is only assigned after returning from imx95_usb_phy_get_tca() in
imx8mq_usb_phy_probe().
If a consumer concurrently finds the switch and calls typec_switch_set(),
tca_blk_typec_switch_set() will access imx_phy->tca->orientation,
dereferencing a NULL pointer.
>
> - return tca;
> -}
> -
> -static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
> -{
> - struct tca_blk *tca = imx_phy->tca;
> -
> - if (!tca)
> - return;
> + ret = devm_add_action_or_reset(&pdev->dev, tca_blk_put_typec_switch, tca->sw);
[Severity: High]
This is a pre-existing issue, but could this devm cleanup lead to a
use-after-free during driver unbind?
The imx_phy and tca structures are allocated via devm_kzalloc(). During
unbind, this devres action will execute tca_blk_put_typec_switch(), which
calls typec_switch_unregister().
While typec_switch_unregister() unlinks the device, if a consumer still
holds a reference to the switch, the object itself will outlive the driver
unbind. Since devres immediately frees imx_phy and tca after the action
returns, any subsequent call to tca_blk_typec_switch_set() by the active
consumer will access freed memory.
> + if (ret)
> + return ERR_PTR(ret);
>
> - tca_blk_put_typec_switch(tca->sw);
> + return tca;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
On i.MX8MP, the USB PHY has a dedicated power domain that was previously
never powered off at runtime. With the introduction of runtime PM support,
the power domain will be powered off if the device is runtime suspended,
which breaks USB wakeup functionality.
To preserve wakeup functionality, mark the PHY power domain as runtime
always-on for i.MX8MP platform. To limit the behavior to i.MX8MP, add a
new imx95_usb_phy_ops for i.MX95 and introduce usb_phy_is_imx8mp() helper
to identify i.MX8MP PHY instance.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 4949ec78d304..c9741b532663 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -9,6 +9,7 @@
#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
#include <linux/regmap.h>
@@ -660,13 +661,20 @@ static const struct phy_ops imx8mp_usb_phy_ops = {
.owner = THIS_MODULE,
};
+static const struct phy_ops imx95_usb_phy_ops = {
+ .init = imx8mp_usb_phy_init,
+ .power_on = imx8mq_phy_power_on,
+ .power_off = imx8mq_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
static const struct of_device_id imx8mq_usb_phy_of_match[] = {
{.compatible = "fsl,imx8mq-usb-phy",
.data = &imx8mq_usb_phy_ops,},
{.compatible = "fsl,imx8mp-usb-phy",
.data = &imx8mp_usb_phy_ops,},
{.compatible = "fsl,imx95-usb-phy",
- .data = &imx8mp_usb_phy_ops,},
+ .data = &imx95_usb_phy_ops,},
{ }
};
MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
@@ -679,6 +687,11 @@ static const struct regmap_config imx_cr_regmap_config = {
.max_register = 0x7,
};
+static bool usb_phy_is_imx8mp(const void *data)
+{
+ return data == &imx8mp_usb_phy_ops;
+}
+
static int imx8mq_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -721,6 +734,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (!phy_ops)
return -EINVAL;
+ if (usb_phy_is_imx8mp(phy_ops))
+ dev_pm_genpd_rpm_always_on(dev, true);
+
imx_phy->phy = devm_phy_create(dev, NULL, phy_ops);
if (IS_ERR(imx_phy->phy))
return PTR_ERR(imx_phy->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 v5 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
The CR port is a simple 16-bit data/address parallel port that is
accessed through 32-bit MMIO registers for on-chip access to the
control registers inside the USB 3.0 femtoPHY. Add control register
regmap and export these registers by debugfs to help PHY's diagnostic.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- add Rb tag
Changes in v4:
- improve commit message as Haibo's suggestion
Changes in v3:
- drop Frank's tag because it includes other changes
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 9d1dd0e7352e..4949ec78d304 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0+
-/* Copyright (c) 2017 NXP. */
+/* Copyright 2017-2026 NXP. */
#include <linux/bitfield.h>
#include <linux/clk.h>
@@ -11,6 +11,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
#include <linux/usb/typec_mux.h>
#define PHY_CTRL0 0x0
@@ -56,6 +57,8 @@
#define PHY_CTRL6_ALT_CLK_EN BIT(1)
#define PHY_CTRL6_ALT_CLK_SEL BIT(0)
+#define PHY_CRCTL 0x30
+
#define PHY_TUNE_DEFAULT 0xffffffff
#define TCA_CLK_RST 0x00
@@ -119,6 +122,7 @@ struct imx8mq_usb_phy {
void __iomem *base;
struct regulator *vbus;
struct tca_blk *tca;
+ struct regmap *cr_regmap;
u32 pcs_tx_swing_full;
u32 pcs_tx_deemph_3p5db;
u32 tx_vref_tune;
@@ -667,6 +671,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
};
MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
+static const struct regmap_config imx_cr_regmap_config = {
+ .name = "cr",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x7,
+};
+
static int imx8mq_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -695,6 +707,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (IS_ERR(imx_phy->base))
return PTR_ERR(imx_phy->base);
+ imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
+ &imx_cr_regmap_config);
+ if (IS_ERR(imx_phy->cr_regmap)) {
+ dev_warn(dev, "Fail to init debug register regmap\n");
+ imx_phy->cr_regmap = NULL;
+ }
+
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
@@ -738,6 +757,9 @@ static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
{
struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+ if (imx_phy->cr_regmap)
+ regcache_cache_only(imx_phy->cr_regmap, true);
+
clk_disable_unprepare(imx_phy->alt_clk);
clk_disable_unprepare(imx_phy->clk);
@@ -759,6 +781,9 @@ static int imx8mq_usb_phy_runtime_resume(struct device *dev)
return ret;
}
+ if (imx_phy->cr_regmap)
+ regcache_cache_only(imx_phy->cr_regmap, false);
+
return 0;
}
--
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 v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
Add runtime PM to ensure the PHY is properly powered and clocked during
register access, preventing potential system hangs.
It guards register access in the following scenarios:
- PHY operations: init() and power_on/off() callbacks are guarded by
phy core
- Type-C orientation switching when PHY/Controller are suspended which
needs explicitly care
- Future PHY control port register regmap debugfs access
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- use non-devm PM runtime callback to correctly enable/disable clocks
when unbind the device
Changes in v4:
- replace guard() with PM_RUNTIME_ACQUIRE()
Changes in v3:
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 64 +++++++++++++++++++++---------
1 file changed, 45 insertions(+), 19 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 3a5788c609e1..9d1dd0e7352e 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -9,6 +9,7 @@
#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
#include <linux/usb/typec_mux.h>
@@ -136,17 +137,15 @@ static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
{
struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
struct tca_blk *tca = imx_phy->tca;
- int ret;
if (tca->orientation == orientation)
return 0;
- ret = clk_prepare_enable(imx_phy->clk);
- if (ret)
- return ret;
+ PM_RUNTIME_ACQUIRE(&imx_phy->phy->dev, pm);
+ if (PM_RUNTIME_ACQUIRE_ERR(&pm))
+ return -ENXIO;
tca_blk_orientation_set(tca, orientation);
- clk_disable_unprepare(imx_phy->clk);
return 0;
}
@@ -620,16 +619,6 @@ static int imx8mq_phy_power_on(struct phy *phy)
if (ret)
return ret;
- ret = clk_prepare_enable(imx_phy->clk);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(imx_phy->alt_clk);
- if (ret) {
- clk_disable_unprepare(imx_phy->clk);
- return ret;
- }
-
/* Disable rx term override */
value = readl(imx_phy->base + PHY_CTRL6);
value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
@@ -648,8 +637,6 @@ static int imx8mq_phy_power_off(struct phy *phy)
value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
writel(value, imx_phy->base + PHY_CTRL6);
- clk_disable_unprepare(imx_phy->alt_clk);
- clk_disable_unprepare(imx_phy->clk);
regulator_disable(imx_phy->vbus);
return 0;
@@ -693,13 +680,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, imx_phy);
- imx_phy->clk = devm_clk_get(dev, "phy");
+ imx_phy->clk = devm_clk_get_enabled(dev, "phy");
if (IS_ERR(imx_phy->clk)) {
dev_err(dev, "failed to get imx8mq usb phy clock\n");
return PTR_ERR(imx_phy->clk);
}
- imx_phy->alt_clk = devm_clk_get_optional(dev, "alt");
+ imx_phy->alt_clk = devm_clk_get_optional_enabled(dev, "alt");
if (IS_ERR(imx_phy->alt_clk))
return dev_err_probe(dev, PTR_ERR(imx_phy->alt_clk),
"Failed to get alt clk\n");
@@ -708,6 +695,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (IS_ERR(imx_phy->base))
return PTR_ERR(imx_phy->base);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
phy_ops = of_device_get_match_data(dev);
if (!phy_ops)
return -EINVAL;
@@ -737,15 +727,51 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
static void imx8mq_usb_phy_remove(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+
+ pm_runtime_get_sync(dev);
+ pm_runtime_disable(dev);
+ pm_runtime_put_noidle(dev);
+}
+
+static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
+{
+ struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(imx_phy->alt_clk);
+ clk_disable_unprepare(imx_phy->clk);
+
+ return 0;
+}
+
+static int imx8mq_usb_phy_runtime_resume(struct device *dev)
+{
+ struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(imx_phy->clk);
+ if (ret)
+ return ret;
+ ret = clk_prepare_enable(imx_phy->alt_clk);
+ if (ret) {
+ clk_disable_unprepare(imx_phy->clk);
+ return ret;
+ }
+
+ return 0;
}
+static DEFINE_RUNTIME_DEV_PM_OPS(imx8mq_usb_phy_pm_ops, imx8mq_usb_phy_runtime_suspend,
+ imx8mq_usb_phy_runtime_resume, NULL);
+
static struct platform_driver imx8mq_usb_phy_driver = {
.probe = imx8mq_usb_phy_probe,
.remove = imx8mq_usb_phy_remove,
.driver = {
.name = "imx8mq-usb-phy",
.of_match_table = imx8mq_usb_phy_of_match,
+ .pm = pm_ptr(&imx8mq_usb_phy_pm_ops),
.suppress_bind_attrs = true,
}
};
--
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 v5 2/5] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
Set PHY wakeup capable because this PHY supports remote wakeup function.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- no changes
Changes in v4:
- add Rb tag
Changes in v3:
- no changes
Changes in v2:
- no changes
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 9a33c06d6fc3..3a5788c609e1 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -728,6 +728,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
"failed to get tca\n");
imx8m_get_phy_tuning_data(imx_phy);
+ device_set_wakeup_capable(dev, true);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
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 v5 1/5] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Felix Gu, stable,
Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Felix Gu <ustc.gu@gmail.com>
If probe fails after imx95_usb_phy_get_tca() succeeds, the typec
switch leaks because the only cleanup path was in .remove, which
never runs on probe failure.
Use devm_add_action_or_reset() so the switch is cleaned up on both
probe failure and driver removal. The .remove callback and
imx95_usb_phy_put_tca() are no longer needed.
Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95")
Cc: stable@vger.kernel.org
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Xu Yang <xu.yang_2@nxp.com>
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- keep remove() callback as patch #3 needs it
Changes in v4:
- add my signed-off tag
Changes in v3:
- add R-b tag
- cc statble
- drop "sw = data" conversion
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index b05d80e849a1..9a33c06d6fc3 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -173,9 +173,9 @@ static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device
return sw;
}
-static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
+static void tca_blk_put_typec_switch(void *data)
{
- typec_switch_unregister(sw);
+ typec_switch_unregister(data);
}
static void tca_blk_orientation_set(struct tca_blk *tca,
@@ -248,6 +248,7 @@ static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
struct device *dev = &pdev->dev;
struct resource *res;
struct tca_blk *tca;
+ int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (!res)
@@ -266,17 +267,11 @@ static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
tca->orientation = TYPEC_ORIENTATION_NORMAL;
tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
- return tca;
-}
-
-static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
-{
- struct tca_blk *tca = imx_phy->tca;
-
- if (!tca)
- return;
+ ret = devm_add_action_or_reset(&pdev->dev, tca_blk_put_typec_switch, tca->sw);
+ if (ret)
+ return ERR_PTR(ret);
- tca_blk_put_typec_switch(tca->sw);
+ return tca;
}
static u32 phy_tx_vref_tune_from_property(u32 percent)
@@ -741,9 +736,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
static void imx8mq_usb_phy_remove(struct platform_device *pdev)
{
- struct imx8mq_usb_phy *imx_phy = platform_get_drvdata(pdev);
- imx95_usb_phy_put_tca(imx_phy);
}
static struct platform_driver imx8mq_usb_phy_driver = {
--
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 v5 0/5] phy: fsl-imx8mq-usb: few improvements
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Felix Gu, stable,
Xu Yang
This patchset is a continuous of v2, it mainly resolves some concerns
reported by sashiko-bot.
Patch #1 fix Type-C switch resource leak if probe() fails.
Patch #3 add runtime PM support to avoid register access issue if the
USB controller enters into runtime suspended state, in this state
accessing USB PHY register may lack some resources. This will also
avoid regulator leak if power_on() fails.
Patch #4 add debug control register regmap
Patch #5 correct i.MX8MP USB runtime wakeup issue after introduce runtime
PM support.
---
Changes in v5:
- not use devm runtime callback to avoid clk enable/disable imblance
- Link to v4: https://patch.msgid.link/20260605-imx8mp-usb-phy-improvement-v4-0-b2ddf2f3862c@nxp.com
Changes in v4:
- add Rb tag
- replace guard() with PM_RUNTIME_ACQUIRE()
- Link to v3: https://patch.msgid.link/20260603-imx8mp-usb-phy-improvement-v3-0-7afb8f89abc6@nxp.com
Link to v2:
- https://lore.kernel.org/linux-phy/20260512101046.1498096-1-xu.yang_2@nxp.com/
- https://lore.kernel.org/linux-phy/20260512101212.1498223-1-xu.yang_2@nxp.com/
---
Felix Gu (1):
phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
Xu Yang (4):
phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
phy: fsl-imx8mq-usb: add runtime PM support
phy: fsl-imx8mq-usb: add control register regmap
phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 131 +++++++++++++++++++++--------
1 file changed, 96 insertions(+), 35 deletions(-)
---
base-commit: 7de6ae9e12207ec146f2f3f1e58d1a99317e88bc
change-id: 20260602-imx8mp-usb-phy-improvement-4272d308d862
Best regards,
--
Xu Yang <xu.yang_2@nxp.com>
--
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: Heikki Krogerus @ 2026-06-30 9:54 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Xu Yang, 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: <b2633b22-da30-4778-8e23-7b5bed9ead07@rock-chips.com>
> @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
This look good to me. Please do add the patch for this.
thanks,
--
heikki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: sashiko-bot @ 2026-06-30 8:00 UTC (permalink / raw)
To: Gerald Loacker
Cc: robh, devicetree, vkoul, olteanv, conor+dt, linux-phy,
neil.armstrong
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-1-176792ab71fa@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Valid low-frequency configurations are incorrectly rejected because a `cfg_bit` value of `0x00` conflicts with the default 'not found' sentinel.
- [High] The `rk3368_grf_dphy_regs` array is missing an explicit size and only initializes index 0, meaning it is compiled as an array of size 1. `rockchip_inno_csidphy_power_on()` unconditionally indexes into this array at indices 1 and 2, causing an out-of-bounds read and an erroneous write to an undefined GRF register offset.
--
commit 4cc350ff3a3bfdcb6204ddc2357172385fbe4d2a
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
The rk1808 hsfreq table previously capped at 2499 Mbps. This commit
extends the final entry to 2500 Mbps to support this exact data rate,
which is essential for the RK3588 platform reusing this array.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index c79fb53d8ee5c..5281f8dea0ad3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
> { 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
> { 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
> {1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
> - {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
> + {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
> };
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the frequency
tables I noticed a potential problem in how the selected configuration is
evaluated later in the driver.
If a data rate maps to a configuration where the cfg_bit is 0x00, will
rockchip_inno_csidphy_configure() incorrectly reject it?
In rockchip_inno_csidphy_configure():
if (!hsfreq)
return -EINVAL;
It seems this check uses 0x00 as a not found sentinel, but valid low
frequency ranges might legitimately use 0x00 as their configuration value.
This same logic is also present in rk_dphy_configure() in
phy-rockchip-dphy-rx0.c. Does this prevent the hardware from operating at
those low frequencies?
[Severity: High]
This is also a pre-existing issue, but I noticed an out-of-bounds array
access in this driver for the RK3368 platform.
The rk3368_grf_dphy_regs array is initialized with only a single element:
static const struct dphy_reg rk3368_grf_dphy_regs[] = {
[GRF_DPHY_CSIPHY_FORCERXMODE] = PHY_REG(RK3368_GRF_SOC_CON6_OFFSET, 4, 8),
};
However, rockchip_inno_csidphy_power_on() unconditionally accesses
indices beyond this:
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
Could this read past the end of the 1-element array and cause an erroneous
write to an undefined register offset if the adjacent memory evaluates as
valid?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-feature-mipi-csi-dphy-4k60-v3-0-176792ab71fa@wolfvision.net?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Bartosz Golaszewski @ 2026-06-30 7:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, 29 Jun 2026 15:26:20 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
>
> Arnd
Thanks for doing this Arnd!
For the series:
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-30 7:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-0-176792ab71fa@wolfvision.net>
At high data rates like 4K60 (2500 Mbps), such as when using an
LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters
can cause signal integrity issues and clock-data recovery failures.
The driver currently lacks a mechanism to adjust the clock lane sampling
phase to compensate for board-specific trace variations.
Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase'
device tree property. This enables board-specific tuning of the clock
lane sampling phase in ~40 ps steps (range 0-7) to optimize link
stability. If the property is absent, the driver falls back to the
hardware default.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 25 ++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index 5281f8dea0ad3..3a15840e86cad 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -69,6 +69,10 @@
#define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
#define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
+#define CSIDPHY_LANE_CLK_3_PHASE 0x38
+#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
+#define CSIDPHY_CLK_PHASE_DEFAULT 3
+
#define RESETS_MAX 2
/*
@@ -151,6 +155,7 @@ struct rockchip_inno_csidphy {
const struct dphy_drv_data *drv_data;
struct phy_configure_opts_mipi_dphy config;
u8 hsfreq;
+ int clk_phase;
};
static inline void write_grf_reg(struct rockchip_inno_csidphy *priv,
@@ -304,6 +309,13 @@ static int rockchip_inno_csidphy_power_on(struct phy *phy)
rockchip_inno_csidphy_ths_settle(priv, priv->hsfreq,
CSIDPHY_LANE_THS_SETTLE(i));
+ if (priv->clk_phase >= 0) {
+ val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ val &= ~CSIDPHY_CLK_PHASE_MASK;
+ val |= FIELD_PREP(CSIDPHY_CLK_PHASE_MASK, priv->clk_phase);
+ writel(val, priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ }
+
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
@@ -449,6 +461,7 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct phy *phy;
+ u32 phase;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -464,6 +477,18 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
return -ENODEV;
}
+ priv->clk_phase = -1;
+ if (device_property_read_u32(dev, "rockchip,clk-lane-phase",
+ &phase) == 0) {
+ if (phase >= BIT(3)) {
+ dev_err(dev,
+ "rockchip,clk-lane-phase %u out of range [0,7]\n",
+ phase);
+ return -EINVAL;
+ }
+ priv->clk_phase = phase;
+ }
+
priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
if (IS_ERR(priv->grf)) {
--
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 v3 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-30 7:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-0-176792ab71fa@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
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 v3 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-30 7:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Changes in v3:
- dt-bindings: add default for rockchip,clk-lane-phase
- Link to v2: https://patch.msgid.link/20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net
Changes in v2:
- dt-bindings: improve rockchip,clk-lane-phase description wording
(Conor Dooley)
- Link to v1: https://patch.msgid.link/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-phy@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 10 ++++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-30 7:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-0-176792ab71fa@wolfvision.net>
Add support for the optional rockchip,clk-lane-phase device tree property
to allow board-specific tuning of the clock lane sampling phase for
improved signal integrity across supported data rates.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
.../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 03950b3cad08c..913aa688c0ae9 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,16 @@ properties:
description:
Some additional phy settings are access through GRF regs.
+ rockchip,clk-lane-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ default: 3
+ description:
+ Clock lane sampling phase selection (hardware tap index 0–7). Each step
+ corresponds to an approximately 40 ps delay as described in the hardware
+ specification.
+
required:
- compatible
- reg
--
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/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Krzysztof Kozlowski @ 2026-06-30 6:16 UTC (permalink / raw)
To: Joey Lu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Arnd Bergmann, Catalin Marinas, Jacky Huang,
Shan-Chun Hung, Hui-Ping Chen, Joey Lu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <24de6a00-ba4e-455b-baa7-479d1cc2edf3@gmail.com>
On 29/06/2026 12:40, Joey Lu wrote:
>
> On 6/25/2026 3:58 PM, Krzysztof Kozlowski wrote:
>> On Thu, Jun 25, 2026 at 10:39:56AM +0800, Joey Lu wrote:
>>> properties:
>>> compatible:
>>> enum:
>>> - nuvoton,ma35d1-usb2-phy
>>>
>>> + reg:
>>> + maxItems: 1
>>> +
>>> "#phy-cells":
>>> - const: 0
>>> + const: 1
>>> + description:
>>> + The single cell selects the PHY port. 0 selects the OTG port (USB0,
>>> + shared with DWC2 gadget controller) and 1 selects the host-only port
>>> + (USB1).
>>>
>>> - clocks:
>>> - maxItems: 1
>> This is odd, considering that parent does not have clocks. So explain me
>> this:
>> 1. USB PHY needed clocks.
>> 2. You extend USB PHY to cover second part.
>> 3. That extension for second part means that clocks are not needed.
>> Really, how? How is it possible in hardware?
> The hardware has two independent clock domains:
>
> - The PHY analog block takes the 24 MHz HXT as its reference, wired
> directly to the PHY's internal PLL, which derives the required
> operating
> frequencies internally. This reference path is entirely outside the SoC
> software clock tree; no software-gatable clock gate needs to be enabled
> for the PHY to power up and lock its PLL. The only software control the
> PHY driver exercises is toggling each PHY's Power-On Reset (POR) bit,
> which resides in the SYS register block. The driver accesses this via
> the parent regmap
>
> - `HUSBH0_GATE` / `HUSBH1_GATE` / `USBD_GATE` are AHB/APB bus interface
> clocks for the host and gadget (EHCI, OHCI, DWC2). They gate
> the register-access path between the CPU and each controller, not
> the PHY
> analog circuitry itself.
>
> The original single-port driver enabled `HUSBH0_GATE` as if it belonged
> to the
> PHY, but that gate is actually owned by EHCI0/OHCI0 and is already
> managed by
> those controller drivers through their own `clocks` DTS bindings. The PHY
> driver was redundantly enabling the same gate.
>
> When extending the driver to cover PHY1, the same pattern held: EHCI1/OHCI1
> manage `HUSBH1_GATE` themselves. There is no clock that belongs
> exclusively to
> the PHY, so `clocks` will be dropped from the PHY binding entirely.
What driver has to do with it?
You did not answer the question. How adding missing OTG to existing
device causes that hardware to lose a clock? How is it possible?
>>> + nuvoton,rcalcode:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + minItems: 1
>>> + maxItems: 2
>> You should require two values. I understand that any PHY is optional,
>> thus you skip the entry, so how would you provide value for PHY1 only?
> `nuvoton,rcalcode` will be changed to require exactly two values
> (`minItems: 2, maxItems: 2`), one for PHY0 and one for PHY1 respectively.
> The property will remain optional overall; when absent, each port
> retains its
> power-on default value loaded at hardware initialisation. When present, both
> entries must be supplied.
So are you going to implement it or not?
>>> + items:
>>> + minimum: 0
>>> + maximum: 15
>>> + description:
>>> + Resistor calibration trim codes for PHY0 and PHY1 respectively.
>>> + Each 4-bit value is written to the RCALCODE field in USBPMISCR and
>>> + adjusts the PHY's internal termination resistance. Both entries are
>>> + optional; when absent the hardware reset default is used.
>>>
>>> - nuvoton,sys:
>>> - $ref: /schemas/types.yaml#/definitions/phandle
>>> + nuvoton,oc-active-high:
>>> + type: boolean
>>> description:
>>> - phandle to syscon for checking the PHY clock status.
>>> + 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
>>> + - reg
>> That's ABI break which was not explained in the commit msg - neither
>> specifying impact nor actually providing reasons why you break ABI.
>>
>> And honestly, you have no resources here except the address, so now it
>> is clear that this should be folded into parent. See DTS101 talk slides.
> The commit message will be updated to explicitly acknowledge the ABI break:
> existing DTS files that contain a standalone `usb-phy` node without a `reg`
> property will fail dt-schema validation after this change. The impact is
> limited to the MA35D1 SoC; no upstream DTS for this SoC existed before this
> patch series, so no in-tree board files are broken. The break is intentional
But all of out of tree users are broken.
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 net v5 2/2] Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"
From: Petr Wozniak @ 2026-06-29 18:55 UTC (permalink / raw)
To: maxime.chevallier, linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
bjorn, olek2, kabel
In-Reply-To: <1bdf0dd4-4f34-406e-ae97-f2ec5b540906@bootlin.com>
Hi Maxime,
Thanks a lot for testing and reviewing, much appreciated.
No worries about the original probe approach not panning out; restoring the
working RollBall detection is what matters here. If I ever get my hands on
genuine RollBall hardware, I'll revisit the per-module timing idea.
Thanks,
Petr
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: usb: Add Tegra264 XUSB host support
From: Conor Dooley @ 2026-06-29 15:21 UTC (permalink / raw)
To: Wayne Chang
Cc: mathias.nyman, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
gregkh, thierry.reding, jonathanh, linux-usb, linux-tegra,
linux-kernel, linux-phy, devicetree
In-Reply-To: <20260629093406.1118594-3-waynec@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 6856 bytes --]
On Mon, Jun 29, 2026 at 05:34:00PM +0800, Wayne Chang wrote:
> Extend the Tegra234 XUSB host binding to cover Tegra264:
>
> - Add nvidia,tegra264-xusb compatible string
> - Document optional USB wake interrupts for Tegra264
> - Document Tegra264 PMC wake event to port mapping
> - Allow up to five IOMMU specifiers for the additional XUSB host
> stream IDs
>
> Signed-off-by: Wayne Chang <waynec@nvidia.com>
> ---
> .../bindings/usb/nvidia,tegra234-xusb.yaml | 115 ++++++++++++------
> 1 file changed, 80 insertions(+), 35 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
> index ec0993497fbb..94b1dbe2b02f 100644
> --- a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
> +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
> @@ -17,7 +17,9 @@ description: |
>
> properties:
> compatible:
> - const: nvidia,tegra234-xusb
> + enum:
> + - nvidia,tegra234-xusb
> + - nvidia,tegra264-xusb
>
> reg:
> items:
> @@ -31,37 +33,6 @@ properties:
> - const: fpci
> - const: bar2
>
> - interrupts:
> - minItems: 2
> - items:
> - - description: xHCI host interrupt
> - - description: mailbox interrupt
> - - description: USB wake event 0
> - - description: USB wake event 1
> - - description: USB wake event 2
> - - description: USB wake event 3
> - - description: USB wake event 4
> - - description: USB wake event 5
> - - description: USB wake event 6
> - description: |
> - The first two interrupts are required for the USB host controller. The
> - remaining USB wake event interrupts are optional. Each USB wake event is
> - independent; it is not necessary to use all of these events on a
> - platform. The USB host controller can function even if no wake-up events
> - are defined. The USB wake event interrupts are handled by the Tegra PMC;
> - hence, the interrupt controller for these is the PMC and the interrupt
> - IDs correspond to the PMC wake event IDs. A complete list of wake event
> - IDs is provided below, and this information is also present in the Tegra
> - TRM document.
> -
> - PMC wake-up 76 for USB3 port 0 wakeup
> - PMC wake-up 77 for USB3 port 1 wakeup
> - PMC wake-up 78 for USB3 port 2 and port 3 wakeup
> - PMC wake-up 79 for USB2 port 0 wakeup
> - PMC wake-up 80 for USB2 port 1 wakeup
> - PMC wake-up 81 for USB2 port 2 wakeup
> - PMC wake-up 82 for USB2 port 3 wakeup
> -
Property definitions should remain at the top level, with the widest
constraints and list of entries.
Conditional sections should just apply restrictions. In this case, only
one additional clock seems to be the difference, so conditional
restrictions should suffice.
> clocks:
> items:
> - description: XUSB host clock
> @@ -96,9 +67,6 @@ properties:
> - const: dma-mem # read
> - const: write
>
> - iommus:
> - maxItems: 1
Same with this, conditionally forbid it on the new platform but leave
this here.
pw-bot: changes-requested
Thanks,
Conor.
> -
> nvidia,xusb-padctl:
> $ref: /schemas/types.yaml#/definitions/phandle
> description: phandle to the XUSB pad controller that is used to configure
> @@ -137,6 +105,83 @@ properties:
> allOf:
> - $ref: usb-xhci.yaml
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra234-xusb
> + then:
> + properties:
> + interrupts:
> + minItems: 2
> + description: |
> + The first two interrupts are required for the USB host controller.
> + The remaining USB wake event interrupts are optional. Each USB wake
> + event is independent; it is not necessary to use all of these events
> + on a platform. The USB host controller can function even if no
> + wake-up events are defined. The USB wake event interrupts are
> + handled by the Tegra PMC; hence, the interrupt controller for these
> + is the PMC and the interrupt IDs correspond to the PMC wake event
> + IDs.
> +
> + PMC wake-up 76 for USB3 port 0 wakeup
> + PMC wake-up 77 for USB3 port 1 wakeup
> + PMC wake-up 78 for USB3 port 2 and port 3 wakeup
> + PMC wake-up 79 for USB2 port 0 wakeup
> + PMC wake-up 80 for USB2 port 1 wakeup
> + PMC wake-up 81 for USB2 port 2 wakeup
> + PMC wake-up 82 for USB2 port 3 wakeup
> + items:
> + - description: xHCI host interrupt
> + - description: mailbox interrupt
> + - description: USB wake event 0
> + - description: USB wake event 1
> + - description: USB wake event 2
> + - description: USB wake event 3
> + - description: USB wake event 4
> + - description: USB wake event 5
> + - description: USB wake event 6
> + iommus:
> + maxItems: 1
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra264-xusb
> + then:
> + properties:
> + interrupts:
> + minItems: 2
> + description: |
> + Same as Tegra234, with one additional optional USB wake event
> + interrupt. USB3 port 2 and port 3 each have a dedicated wake event
> + interrupt on Tegra264.
> +
> + PMC wake-up 79 for USB3 port 0 wakeup
> + PMC wake-up 80 for USB3 port 1 wakeup
> + PMC wake-up 81 for USB3 port 2 wakeup
> + PMC wake-up 82 for USB3 port 3 wakeup
> + PMC wake-up 83 for USB2 port 0 wakeup
> + PMC wake-up 84 for USB2 port 1 wakeup
> + PMC wake-up 85 for USB2 port 2 wakeup
> + PMC wake-up 86 for USB2 port 3 wakeup
> + items:
> + - description: xHCI host interrupt
> + - description: mailbox interrupt
> + - description: USB wake event 0
> + - description: USB wake event 1
> + - description: USB wake event 2
> + - description: USB wake event 3
> + - description: USB wake event 4
> + - description: USB wake event 5
> + - description: USB wake event 6
> + - description: USB wake event 7
> + iommus:
> + maxItems: 5
> +
> unevaluatedProperties: false
>
> examples:
> --
> 2.25.1
>
[-- 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
* Re: [PATCH 1/8] dt-bindings: phy: tegra-xusb: Add support for Tegra264
From: Conor Dooley @ 2026-06-29 15:19 UTC (permalink / raw)
To: Wayne Chang
Cc: mathias.nyman, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
gregkh, thierry.reding, jonathanh, linux-usb, linux-tegra,
linux-kernel, linux-phy, devicetree
In-Reply-To: <20260629093406.1118594-2-waynec@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 949 bytes --]
On Mon, Jun 29, 2026 at 05:33:59PM +0800, Wayne Chang wrote:
> Add the compatible string for the Tegra264 XUSB PHY.
>
> Signed-off-by: Wayne Chang <waynec@nvidia.com>
Why is a fallback compatible not suitable here?
Thanks,
Conor.
> ---
> .../devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
> index d8de900a4fce..f6fe3c90b5b0 100644
> --- a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
> @@ -45,6 +45,7 @@ properties:
> enum:
> - nvidia,tegra194-xusb-padctl
> - nvidia,tegra234-xusb-padctl
> + - nvidia,tegra264-xusb-padctl
>
> reg:
> items:
> --
> 2.25.1
>
[-- 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
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