* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Geert Uytterhoeven @ 2026-03-24 13:05 UTC (permalink / raw)
To: Prabhakar
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260324121608.3444943-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Tue, 24 Mar 2026 at 13:16, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> the value instead of performing multiple MMIO reads.
>
> Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> directly. This preserves the existing behaviour while improving code
> clarity and avoiding redundant register accesses.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> {
> if (ch->phy_data->vblvl_ctrl) {
> + u32 val = readl(ch->base + USB2_ADPCTRL);
> bool vbus_valid;
> bool device;
>
> - device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> - vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
> + device = !!(val & USB2_ADPCTRL_IDDIG);
> + vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
Perhaps combine variable declarations and assignments?
The "!!" is not needed when assigning to a bool.
>
> - return vbus_valid ? device : !device;
> + return device == vbus_valid;
> }
>
> if (!ch->uses_otg_pins)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Jon Hunter @ 2026-03-24 13:33 UTC (permalink / raw)
To: Diogo Ivo, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <5a5397c8-cc32-4d6b-86a4-76f924ae6d75@tecnico.ulisboa.pt>
On 24/03/2026 11:31, Diogo Ivo wrote:
>
>
> On 3/24/26 10:16, Jon Hunter wrote:
>>
>> On 27/01/2026 15:11, Diogo Ivo wrote:
>>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>>> In order to do this first revert cefc1caee9dd.
>>
>> This commit message does not seem complete.
>
> How so? It is succint but it states exactly what the commit does. It
> reverts cefc1caee9dd and changes T186 to the common implementation
> prepared in the previous patch.
It does not read clearly to me. The 2nd sentence sounds like that's all
this is doing but we are not, we are reverting and doing the move.
>> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
>> purposely moved the regulator_enable/disable into
>> tegra186_xusb_padctl_id_override() because it is tied to setting the
>> USB2_VBUS_ID. So I would prefer to keep it this way and move the
>> Tegra210 implementation in the same direction (if possible).
>
> I don't agree that this is the best solution.
>
> We really benefit from a common implementation for the two platforms, not
> only because of duplicate code but more importantly because without it
> whenever a bug is found and fixed on either platform it most likely will
> not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
> on T186 but not the same bug on T210 (which then led to this series) since
> the implementation was not shared among them. Were it the case that they
> shared the implementation the fix would have come "free" for T210.
>
> This will keep happening for as long as we have duplicate implementations,
> which becomes more relevant since there is a severe lack of testing in
> older Tegra platforms. I also thought about making the id_override()
> implementation shared between T186 and T210 but that would be take more
> changes since register definitions would need to be moved somewhere
> else too.
I am all for a common implementation. I believe that in the
tegra186_xusb_padctl_id_override() function the only thing that is
different is the offset for the USB2_VBUS_ID register, which should be
easy to handle.
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-24 13:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acHCIA1d5-s2xkvz@google.com>
On Mon, Mar 23, 2026 at 03:48:42PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 11:39:03PM +0100, Andrew Lunn wrote:
> > > If there is a deprecated property you can do:
> > >
> > > error = device_property_read_u32(dev, "prop", &val);
> > > if (error == -ENOENT)
> > > error = device_property_read_u32(dev, "deprecated-prop", &val);
> >
> > It is not as simple as that. There are a lot of optional
> > properties. Say "prop" is optional? And not present. So -ENOENT. We
> > then look for this deprecated property. That should not happen.
>
> Why? That is exactly what you want: you favor new one if it is present
> and fall back to deprecated one if it is absent. And then you decide
> whether to continue or abort.
The old property is only valid in DT, where it is deprecated, but
still valid. It should never appear in any other newer firmware
bindings.
> If you only have of_property_read_u32() then it will not stand out. If
> you advocate of using device_property_read_u32() normally but
> of_property_read_u32() for deprecated only - that is a possibility, but
> I do not know if anyone does this.
For the subsystems i've dealt with, when somebody proposes a patch
adding an ACPI binding, and they do an of_ to device_ conversion
without engaging brain, i point out the issues, they should not be
adding deprecated properties to a brand new binding, and they go away
and never come back. And so the code remains OF only. Which is fine,
nobody does networking devices using ACPI.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Lad, Prabhakar @ 2026-03-24 14:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdV_94xOmqRqDKW_e740ckmRoyW+oaHvorphNg27JNKUrw@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Tue, Mar 24, 2026 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, 24 Mar 2026 at 13:16, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> > the value instead of performing multiple MMIO reads.
> >
> > Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> > directly. This preserves the existing behaviour while improving code
> > clarity and avoiding redundant register accesses.
> >
> > Reported-by: Pavel Machek <pavel@nabladev.com>
> > Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > @@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> > static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> > {
> > if (ch->phy_data->vblvl_ctrl) {
> > + u32 val = readl(ch->base + USB2_ADPCTRL);
> > bool vbus_valid;
> > bool device;
> >
> > - device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> > - vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
> > + device = !!(val & USB2_ADPCTRL_IDDIG);
> > + vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
>
> Perhaps combine variable declarations and assignments?
> The "!!" is not needed when assigning to a bool.
>
Agreed, I will address it and send a v2.
Cheers,
Prabhakar
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Diogo Ivo @ 2026-03-24 14:36 UTC (permalink / raw)
To: Jon Hunter, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <7a6f8967-c635-4d84-bbab-9e019ff79134@nvidia.com>
On 3/24/26 13:33, Jon Hunter wrote:
>
>
> On 24/03/2026 11:31, Diogo Ivo wrote:
>>
>>
>> On 3/24/26 10:16, Jon Hunter wrote:
>>>
>>> On 27/01/2026 15:11, Diogo Ivo wrote:
>>>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>>>> In order to do this first revert cefc1caee9dd.
>>>
>>> This commit message does not seem complete.
>>
>> How so? It is succint but it states exactly what the commit does. It
>> reverts cefc1caee9dd and changes T186 to the common implementation
>> prepared in the previous patch.
>
> It does not read clearly to me. The 2nd sentence sounds like that's all
> this is doing but we are not, we are reverting and doing the move.
>>> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
>>> purposely moved the regulator_enable/disable into
>>> tegra186_xusb_padctl_id_override() because it is tied to setting the
>>> USB2_VBUS_ID. So I would prefer to keep it this way and move the
>>> Tegra210 implementation in the same direction (if possible).
>>
>> I don't agree that this is the best solution.
>>
>> We really benefit from a common implementation for the two platforms, not
>> only because of duplicate code but more importantly because without it
>> whenever a bug is found and fixed on either platform it most likely will
>> not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
>> on T186 but not the same bug on T210 (which then led to this series)
>> since
>> the implementation was not shared among them. Were it the case that they
>> shared the implementation the fix would have come "free" for T210.
>>
>> This will keep happening for as long as we have duplicate
>> implementations,
>> which becomes more relevant since there is a severe lack of testing in
>> older Tegra platforms. I also thought about making the id_override()
>> implementation shared between T186 and T210 but that would be take more
>> changes since register definitions would need to be moved somewhere
>> else too.
>
> I am all for a common implementation. I believe that in the
> tegra186_xusb_padctl_id_override() function the only thing that is
> different is the offset for the USB2_VBUS_ID register, which should be
> easy to handle.
Ok, I can make it common there as well. However I still feel like
reverting cefc1caee9dd leads to cleaner code since vbus_override() and
id_override() will look similar and only do exactly what they state in
their names and the overall logic looks cleaner.
Diogo
> Jon
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Abel Vesa @ 2026-03-24 16:26 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-4-ce0fc07f0e52@oss.qualcomm.com>
On 26-03-23 00:15:31, Qiang Yu wrote:
> The third PCIe controller on Glymur SoC supports 8-lane operation via
> bifurcation of two PHYs (each requires separate power domian, resets and
> aux clk).
>
> Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> clock ("phy_b_aux") required for 8-lane operation. Introduce new
> glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Tobias Heider @ 2026-03-24 19:14 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Bjorn Helgaas, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <dnx4ge2e2zy2unw5jtmmhktyzlnmmhrogb5skskxewi6y7ekau@vpfdphzay7td>
On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > Resending because the previous mail ended up being HTML (sorry)
> >
> > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > >
> > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > to the port nodes.
> > > > > > > > >
> > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > > - x1-microsoft-denali
> > > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > > - x1-crd
> > > > > > > > > - x1-dell-thena
> > > > > > > > >
> > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > >
> > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > >
> > > > > > >
> > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > combinations, so it fails correctly so.
> > > > > > >
> > > > > >
> > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > v7.0-rc?
> > > > > >
> > > > >
> > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > >
> > > >
> > > > In line with Bjorn's request, we shouldn't have to guess.
> > > >
> > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > applied?
> > > > > >
> > > > >
> > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > fix on top of v7.0-rc1.
> > > > >
> > > >
> > > > So 960609b22be5 was broken when I merged it?
> > > >
> > >
> > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > platforms.
> > >
> > > > The commit message says that the commit was incomplete, in that it
> > > > didn't fully convert from the old to the new style, so it sounds like
> > > > the offending commit was incomplete - but I believe the offending commit
> > > > was a workaround for the new solution not being in place and this commit
> > > > mostly reverts the changes in the offending commit.
> > > >
> > >
> > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > new for greater good, but it apparently decided to do so only for a subset of
> > > the platforms for some reason which don't know. But the problem arises due to
> > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > or dts converted and not both to the new binding, the driver will get confused
> > > and fail. And this is what exactly happended for below machines:
> > >
> > > - x1-hp-omnibook-x14
> > > - x1-microsoft-denali
> > > - x1e80100-lenovo-yoga-slim7x
> > > - x1e80100-medion-sprchrgd-14-s1
> > > - x1p42100-lenovo-thinkbook-16
> > > - x1-asus-zenbook-a14
> > > - x1-crd
> > > - x1-dell-thena
> >
> > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> >
> > I'll try to collect some test feedback for the fix.
> > I'd certainly appreciate this being included as an rc fix since
> > currently half of
> > the x1 laptop devices are broken.
> >
>
> Thanks for the report. We will try to get this patch into v7.0-rcS.
>
> It'd be appreciated if you can test this patch and give your tested-by tag.
>
> - Mani
Thank you!
Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
I have tested the CRD and got user feedback that it works on at least an
Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
Potentially more but not everyone provides feedback when things don't break.
Tested-by: Tobias Heider <tobias.heider@canonical.com>
>
> --
> மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support
From: Dmitry Baryshkov @ 2026-03-24 21:18 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-2-ce0fc07f0e52@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 12:15:29AM -0700, Qiang Yu wrote:
> The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs in
> a bifurcated configuration. Each PHY has its own power domain (phy_gdsc)
> that must be powered on before initialization per hardware requirements.
>
> Current PHY power management assumes a single power domain per PHY,
> preventing proper setup for this dual-PHY scenario. Add support for
> multiple power domains by using devm_pm_domain_attach_list() to attach
> power domains manually, while maintaining compatibility with single
> power domain PHYs.
>
> Enable runtime PM to allow power domain control when the PCIe driver
> calls phy_power_on/phy_power_off:
>
> - Single power domain: QMP PHY platform device directly attaches to
> power domain and controls it during runtime resume/suspend
> - Multiple power domains: devm_pm_domain_attach_list() creates virtual
> devices as power domain suppliers, linked to the QMP PHY platform
> device as consumer
>
> This ensures power domains are properly attached and turned on/off
> for both single and multiple power domain configurations.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Dmitry Baryshkov @ 2026-03-24 21:21 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-5-ce0fc07f0e52@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 12:15:32AM -0700, Qiang Yu wrote:
> Describe PCIe3a controller and PHY. Also add required system resources
> like regulators, clocks, interrupts and registers configuration for PCIe3a.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 314 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 313 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index bde287f645ee94116a489c55be3b7b80db3815e9..52104607a1713323fdfe2e7de710e38c1e22d06e 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -736,7 +736,7 @@ gcc: clock-controller@100000 {
> <0>, /* USB 2 Phy PCIE PIPEGMUX */
> <0>, /* USB 2 Phy PIPEGMUX */
> <0>, /* USB 2 Phy SYS PCIE PIPEGMUX */
> - <0>, /* PCIe 3a */
> + <&pcie3a_phy>, /* PCIe 3a */
> <&pcie3b_phy>, /* PCIe 3b */
> <&pcie4_phy>, /* PCIe 4 */
> <&pcie5_phy>, /* PCIe 5 */
> @@ -2360,6 +2360,318 @@ pcie_west_slv_noc: interconnect@1920000 {
> #interconnect-cells = <2>;
> };
>
> + pcie3a: pci@1c10000 {
Incorrect placement. 1c10000 > 1bf0000.
> + device_type = "pci";
> + compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
> + reg = <0x0 0x01c10000 0x0 0x3000>,
> + <0x0 0x70000000 0x0 0xf20>,
> + <0x0 0x70000f40 0x0 0xa8>,
> + <0x0 0x70001000 0x0 0x4000>,
> + <0x0 0x70100000 0x0 0x100000>,
> + <0x0 0x01c13000 0x0 0x1000>;
[...]
> + };
> +
> + pcie3a_phy: phy@f00000 {
This one too, it should be before PCIe3b PHY.
> + compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
> + reg = <0 0x00f00000 0 0x10000>;
> +
[...]
> + };
> +
> pcie4: pci@1bf0000 {
> device_type = "pci";
> compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Dmitry Baryshkov @ 2026-03-24 21:23 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-4-ce0fc07f0e52@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 12:15:31AM -0700, Qiang Yu wrote:
> The third PCIe controller on Glymur SoC supports 8-lane operation via
> bifurcation of two PHYs (each requires separate power domian, resets and
> aux clk).
>
> Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> clock ("phy_b_aux") required for 8-lane operation. Introduce new
> glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> @@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
> .phy_status = PHYSTATUS_4_20,
> };
>
> +static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
> + .lanes = 8,
> +
> + .offsets = &qmp_pcie_offsets_v8_50,
> +
> + .reset_list = glymur_pciephy_reset_l,
> + .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
> + .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
> + .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
Just for my understanding. If it was not the NOCSR case and had to
program the registers, would we have needed to program anything in the
PCIe3B space?
> + .vreg_list = qmp_phy_vreg_l,
> + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> +
> + .regs = pciephy_v8_50_regs_layout,
> +
> + .phy_status = PHYSTATUS_4_20,
> +};
> +
> static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
> {
> const struct qmp_phy_cfg *cfg = qmp->cfg;
> @@ -5483,6 +5508,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,glymur-qmp-gen5x8-pcie-phy",
> + .data = &glymur_qmp_gen5x8_pciephy_cfg,
> }, {
> .compatible = "qcom,ipq6018-qmp-pcie-phy",
> .data = &ipq6018_pciephy_cfg,
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: rockchip: naneng-combphy: Consolidate SSC configuration
From: Shawn Lin @ 2026-03-25 7:11 UTC (permalink / raw)
To: Vinod Koul
Cc: shawn.lin, linux-rockchip, linux-phy, Heiko Stuebner,
Neil Armstrong, linux-kernel
In-Reply-To: <1772696450-139583-1-git-send-email-shawn.lin@rock-chips.com>
Hi Vinod
在 2026/03/05 星期四 15:40, Shawn Lin 写道:
> The PCIe SSC configuration for the RK3588 and RK3576 SoCs required
> additional tuning which is missing. When adding these same SSC
> configurations for both of these two SoCs, as well as upcoming
> platforms, it's obvious the SSC setup code was largely duplicated
> across the platform-specific configuration functions. This becomes
> harder to maintain as more platforms are added.
>
> So extract the common SSC logic into a shared helper function,
> rk_combphy_common_cfg_ssc(). This cleans up the per-platform drivers
> and centralizes the standard configuration as possible.
>
Gentle ping...
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> ---
>
> Changes in v2:
> - rework to consolidate more configuration
> - reword the commit message
>
> drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 173 +++++++++------------
> 1 file changed, 73 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> index b60d6bf..2b0f152 100644
> --- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> @@ -121,6 +121,7 @@
> #define RK3568_PHYREG32_SSC_OFFSET_500PPM 1
>
> #define RK3568_PHYREG33 0x80
> +#define RK3568_PHYREG33_PLL_SSC_CTRL BIT(5)
> #define RK3568_PHYREG33_PLL_KVCO_MASK GENMASK(4, 2)
> #define RK3568_PHYREG33_PLL_KVCO_SHIFT 2
> #define RK3568_PHYREG33_PLL_KVCO_VALUE 2
> @@ -446,6 +447,74 @@ static int rockchip_combphy_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> +static void rk_combphy_common_cfg_ssc(struct rockchip_combphy_priv *priv, unsigned long rate)
> +{
> + struct device_node *np = priv->dev->of_node;
> + u32 val;
> +
> + if (!priv->enable_ssc)
> + return;
> +
> + /* Set SSC downward spread spectrum for PCIe and USB3 */
> + if (priv->type == PHY_TYPE_PCIE || priv->type == PHY_TYPE_USB3) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> + }
> +
> + /* Set SSC downward spread spectrum +500ppm for SATA in 100MHz */
> + if (priv->type == PHY_TYPE_SATA && rate == REF_CLOCK_100MHz) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> + RK3568_PHYREG32_SSC_DOWNWARD);
> + val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> + RK3568_PHYREG32_SSC_OFFSET_500PPM);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> + RK3568_PHYREG32);
> + }
> +
> + /* Enable SSC */
> + val = readl(priv->mmio + RK3568_PHYREG8);
> + val |= RK3568_PHYREG8_SSC_EN;
> + writel(val, priv->mmio + RK3568_PHYREG8);
> +
> + /* Some SoCs need tuning PCIe SSC instead of default configuration in 24MHz */
> + if (!of_device_is_compatible(np, "rockchip,rk3588-naneng-combphy") &&
> + !of_device_is_compatible(np, "rockchip,rk3576-naneng-combphy"))
> + return;
> +
> + /* PLL control SSC module period should be set if need tuning */
> + val = readl(priv->mmio + RK3568_PHYREG33);
> + val |= RK3568_PHYREG33_PLL_SSC_CTRL;
> + writel(val, priv->mmio + RK3568_PHYREG33);
> +
> + if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> + /* Set PLL loop divider */
> + writel(0x00, priv->mmio + RK3576_PHYREG17);
> + writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> +
> + /* Set up rx_pck invert and rx msb to disable */
> + writel(0x00, priv->mmio + RK3588_PHYREG27);
> +
> + /*
> + * Set up SU adjust signal:
> + * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> + * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> + * su_trim[23:16], CKRCV adjust
> + * su_trim[31:24], CKDRV adjust
> + */
> + writel(0x90, priv->mmio + RK3568_PHYREG11);
> + writel(0x02, priv->mmio + RK3568_PHYREG12);
> + writel(0x08, priv->mmio + RK3568_PHYREG13);
> + writel(0x57, priv->mmio + RK3568_PHYREG14);
> + writel(0x40, priv->mmio + RK3568_PHYREG15);
> +
> + writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> +
> + val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> + RK3576_PHYREG33_PLL_KVCO_VALUE);
> + writel(val, priv->mmio + RK3568_PHYREG33);
> + }
> +}
> +
> static int rk3528_combphy_cfg(struct rockchip_combphy_priv *priv)
> {
> const struct rockchip_combphy_grfcfg *cfg = priv->cfg->grfcfg;
> @@ -600,21 +669,12 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con3_for_pcie, true);
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> rockchip_combphy_updatel(priv, RK3568_PHYREG15_CTLE_EN,
> RK3568_PHYREG15_CTLE_EN, RK3568_PHYREG15);
> @@ -706,11 +766,7 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -755,11 +811,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> -
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -767,10 +818,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT,
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -880,13 +927,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
>
> @@ -909,11 +949,7 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -972,10 +1008,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -983,10 +1015,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1110,14 +1138,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> writel(0x88, priv->mmio + RK3568_PHYREG13);
> writel(0x56, priv->mmio + RK3568_PHYREG14);
> } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> - RK3568_PHYREG32_SSC_DOWNWARD);
> - val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> - RK3568_PHYREG32_SSC_OFFSET_500PPM);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* ssc ppm adjust to 3500ppm */
> rockchip_combphy_updatel(priv, RK3576_PHYREG10_SSC_PCM_MASK,
> RK3576_PHYREG10_SSC_PCM_3500PPM,
> @@ -1156,39 +1176,7 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> -
> - if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> - /* Set PLL loop divider */
> - writel(0x00, priv->mmio + RK3576_PHYREG17);
> - writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> -
> - /* Set up rx_pck invert and rx msb to disable */
> - writel(0x00, priv->mmio + RK3588_PHYREG27);
> -
> - /*
> - * Set up SU adjust signal:
> - * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> - * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> - * su_trim[23:16], CKRCV adjust
> - * su_trim[31:24], CKDRV adjust
> - */
> - writel(0x90, priv->mmio + RK3568_PHYREG11);
> - writel(0x02, priv->mmio + RK3568_PHYREG12);
> - writel(0x08, priv->mmio + RK3568_PHYREG13);
> - writel(0x57, priv->mmio + RK3568_PHYREG14);
> - writel(0x40, priv->mmio + RK3568_PHYREG15);
> -
> - writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> -
> - val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> - RK3576_PHYREG33_PLL_KVCO_VALUE);
> - writel(val, priv->mmio + RK3568_PHYREG33);
> - }
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -1255,10 +1243,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1343,13 +1327,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> /* Set up su_trim: */
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
> default:
> @@ -1371,11 +1348,7 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: rockchip: naneng-combphy: Fix TX detect RX termination errata
From: Shawn Lin @ 2026-03-25 7:23 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-rockchip, linux-phy, Heiko Stuebner, Neil Armstrong,
linux-kernel, Shawn Lin
Some PHY revisions may fail to detect the peer RX's termination
resistor (RTERM) under certain critical temperature conditions.
This causes TX detection failures on PCIe links.
Add a workaround to force the RTERM detection ready signal for
affected PHY revisions. This ensures reliable TX-to-RX termination
detection across all operating temperature ranges.
The fix applies to RK3562, RK3568, RK3576 and RK3588 SoCs which share
the same PHY IP with this hardware errata.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
index b60d6bf..76d4994 100644
--- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
@@ -106,6 +106,9 @@
#define RK3568_PHYREG18 0x44
#define RK3568_PHYREG18_PLL_LOOP 0x32
+#define RK3568_PHYREG26 0x64
+#define RK3568_PHYREG26_FORCE_RTERM_DET_RDY BIT(5)
+
#define RK3568_PHYREG30 0x74
#define RK3568_PHYREG30_GATE_TX_PCK_SEL BIT(7)
#define RK3568_PHYREG30_GATE_TX_PCK_DLY_PLL_OFF BIT(7)
@@ -193,6 +196,7 @@ struct rockchip_combphy_cfg {
unsigned int num_phys;
unsigned int phy_ids[3];
const struct rockchip_combphy_grfcfg *grfcfg;
+ bool force_rxterm_det_rdy;
int (*combphy_cfg)(struct rockchip_combphy_priv *priv);
};
@@ -264,6 +268,17 @@ static int rockchip_combphy_init(struct phy *phy)
switch (priv->type) {
case PHY_TYPE_PCIE:
+ /*
+ * Hardware Errata: TX fails to detect peer RX termination.
+ * Some PHY revisions may fail to detect remote RX's RTERM
+ * (receiver termination resistor) under certain critical
+ * temperature conditions. Set force rterm detect ready to
+ * fix it.
+ */
+ if (priv->cfg->force_rxterm_det_rdy)
+ rockchip_combphy_updatel(priv, RK3568_PHYREG26_FORCE_RTERM_DET_RDY,
+ RK3568_PHYREG26_FORCE_RTERM_DET_RDY, RK3568_PHYREG26);
+ fallthrough;
case PHY_TYPE_USB3:
case PHY_TYPE_SATA:
case PHY_TYPE_SGMII:
@@ -745,6 +760,7 @@ static const struct rockchip_combphy_cfg rk3562_combphy_cfgs = {
},
.grfcfg = &rk3562_combphy_grfcfgs,
.combphy_cfg = rk3562_combphy_cfg,
+ .force_rxterm_det_rdy = true,
};
static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
@@ -962,6 +978,7 @@ static const struct rockchip_combphy_cfg rk3568_combphy_cfgs = {
},
.grfcfg = &rk3568_combphy_grfcfgs,
.combphy_cfg = rk3568_combphy_cfg,
+ .force_rxterm_det_rdy = true,
};
static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
@@ -1231,6 +1248,7 @@ static const struct rockchip_combphy_cfg rk3576_combphy_cfgs = {
},
.grfcfg = &rk3576_combphy_grfcfgs,
.combphy_cfg = rk3576_combphy_cfg,
+ .force_rxterm_det_rdy = true,
};
static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
@@ -1418,6 +1436,7 @@ static const struct rockchip_combphy_cfg rk3588_combphy_cfgs = {
},
.grfcfg = &rk3588_combphy_grfcfgs,
.combphy_cfg = rk3588_combphy_cfg,
+ .force_rxterm_det_rdy = true,
};
static const struct of_device_id rockchip_combphy_of_match[] = {
--
2.7.4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Prabhakar @ 2026-03-25 11:20 UTC (permalink / raw)
To: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
Magnus Damm, Pavel Machek
Cc: linux-renesas-soc, linux-phy, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Read USB2_ADPCTRL once in rcar_gen3_check_id() instead of issuing
multiple MMIO reads, and derive both IDDIG and VBUSVALID from the same
value.
Drop the redundant !! operator, as assigning a masked u32 value to a
bool already performs the required normalization. Simplify the logic by
comparing the ID and VBUS status directly, which is equivalent to the
previous conditional but easier to follow.
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/acJVCOdlchLiSe5n@duo.ucw.cz/
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- Rebased on top of latest next-20260324
- Combined variable declarations and assignments and dropped
redundant !! operator
- Updated commit message
- Corrected the link for closes tag
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 79e820e2fe55..9a45d840efeb 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -314,13 +314,11 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
{
if (ch->phy_data->vblvl_ctrl) {
- bool vbus_valid;
- bool device;
+ u32 val = readl(ch->base + USB2_ADPCTRL);
+ bool vbus_valid = val & USB2_ADPCTRL_VBUSVALID;
+ bool device = val & USB2_ADPCTRL_IDDIG;
- device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
- vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
-
- return vbus_valid ? device : !device;
+ return device == vbus_valid;
}
if (!ch->uses_otg_pins)
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-25 11:43 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <ezrcjjwtg5n76w4m65l27szu5mywx66ti3xuprkfcp3x6quvbf@2rew4zrnnbt2>
On Tue, Mar 24, 2026 at 11:00:10AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 20, 2026 at 12:32:24AM +0200, Vladimir Oltean wrote:
> > As explained in the similar ufs-exynos.c change, PHY consumer drivers
> > should not look at the phy->power_count, because in the general case
> > there might also be other consumers who have called phy_power_on() too,
> > so the fact that the power_count is non-zero does not mean that we did.
> >
> > Moreover, struct phy will become opaque soon, so the qcom UFS driver
> > will not be able to apply this pattern. Keep parallel track of the PHY
> > power state, instead of looking at a field which will become unavailable
> > (phy->power_count).
> >
> > About treating the phy_power_off() return code: from an API perspective,
> > this should have probably returned void, otherwise consumers would be
> > stuck in a state they can't escape. The provider, phy-qcom-qmp-ufs.c,
> > does return 0 in its power_off() implementation. I consider it safe to
> > discard potential errors from phy_power_off() instead of complicating
> > the phy_powered_on logic.
> >
>
> You could even simplify the code by getting rid of the 'phy_powered_on' check
> altogether. There is no real need to track the PHY power state in this driver.
> It is safe to call phy_power_off() without any checks.
>
> - Mani
Ok.. as the author of commit 7bac65687510 ("scsi: ufs: qcom: Power off
the PHY if it was already powered on in ufs_qcom_power_up_sequence()"),
I assume you have hardware to test. Would you mind writing a patch that
I could pick up to replace this one with?
I suppose that the power_count test is somehow no longer necessary after
commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls"), but frankly I don't see it - the ufshcd state machine is a bit
too complicated for me to just statically analyze.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Manivannan Sadhasivam @ 2026-03-25 11:51 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260325114309.3k7xkfrffpxp5xq4@skbuf>
On Wed, Mar 25, 2026 at 01:43:09PM +0200, Vladimir Oltean wrote:
> On Tue, Mar 24, 2026 at 11:00:10AM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Mar 20, 2026 at 12:32:24AM +0200, Vladimir Oltean wrote:
> > > As explained in the similar ufs-exynos.c change, PHY consumer drivers
> > > should not look at the phy->power_count, because in the general case
> > > there might also be other consumers who have called phy_power_on() too,
> > > so the fact that the power_count is non-zero does not mean that we did.
> > >
> > > Moreover, struct phy will become opaque soon, so the qcom UFS driver
> > > will not be able to apply this pattern. Keep parallel track of the PHY
> > > power state, instead of looking at a field which will become unavailable
> > > (phy->power_count).
> > >
> > > About treating the phy_power_off() return code: from an API perspective,
> > > this should have probably returned void, otherwise consumers would be
> > > stuck in a state they can't escape. The provider, phy-qcom-qmp-ufs.c,
> > > does return 0 in its power_off() implementation. I consider it safe to
> > > discard potential errors from phy_power_off() instead of complicating
> > > the phy_powered_on logic.
> > >
> >
> > You could even simplify the code by getting rid of the 'phy_powered_on' check
> > altogether. There is no real need to track the PHY power state in this driver.
> > It is safe to call phy_power_off() without any checks.
> >
> > - Mani
>
> Ok.. as the author of commit 7bac65687510 ("scsi: ufs: qcom: Power off
> the PHY if it was already powered on in ufs_qcom_power_up_sequence()"),
> I assume you have hardware to test. Would you mind writing a patch that
> I could pick up to replace this one with?
>
Sure, will do.
> I suppose that the power_count test is somehow no longer necessary after
> commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
> calls"), but frankly I don't see it - the ufshcd state machine is a bit
> too complicated for me to just statically analyze.
I believe I added the power_count check for phy_exit(). But since that got
moved, the check becomes no longer necessary.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-25 11:57 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <vu3cxpynr5mu2fzkrtmjcwijc5jz323wlnbc3r7lp2wxqmhydx@z5xhgf4myw2d>
On Wed, Mar 25, 2026 at 05:21:14PM +0530, Manivannan Sadhasivam wrote:
> I believe I added the power_count check for phy_exit(). But since that got
> moved, the check becomes no longer necessary.
FYI, the power_count keeps track of the balance of phy_power_on() and
phy_power_off() calls, whereas it is the init_count keeps track of
phy_init() and phy_exit() calls. They are only related to the extent
that you must respect the phy_init() -> phy_power_on() -> phy_power_off()
-> phy_exit() sequence. But in any case, both should be considered
PHY-internal fields. The "Order of API calls" section from
Documentation/driver-api/phy/phy.rst mentions the order that I just
described above, and consumers should just ensure they follow that.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Geert Uytterhoeven @ 2026-03-25 12:30 UTC (permalink / raw)
To: Prabhakar
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260325112039.464992-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, 25 Mar 2026 at 12:20, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read USB2_ADPCTRL once in rcar_gen3_check_id() instead of issuing
> multiple MMIO reads, and derive both IDDIG and VBUSVALID from the same
> value.
>
> Drop the redundant !! operator, as assigning a masked u32 value to a
> bool already performs the required normalization. Simplify the logic by
> comparing the ID and VBUS status directly, which is equivalent to the
> previous conditional but easier to follow.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJVCOdlchLiSe5n@duo.ucw.cz/
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Rebased on top of latest next-20260324
> - Combined variable declarations and assignments and dropped
> redundant !! operator
> - Updated commit message
> - Corrected the link for closes tag
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: spacemit: Remove incorrect clk_disable() in spacemit_usb2phy_init()
From: Felix Gu @ 2026-03-25 16:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Yixun Lan, Ze Huang
Cc: linux-phy, linux-riscv, spacemit, linux-kernel, Felix Gu
When clk_enable() fails, the clock was never enabled. Calling
clk_disable() in this error path is incorrect.
Remove the spurious clk_disable() call from the error handling
in spacemit_usb2phy_init().
Fixes: fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/spacemit/phy-k1-usb2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 9215d0b223b2..e8c1e26428a9 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -97,7 +97,6 @@ static int spacemit_usb2phy_init(struct phy *phy)
ret = clk_enable(sphy->clk);
if (ret) {
dev_err(&phy->dev, "failed to enable clock\n");
- clk_disable(sphy->clk);
return ret;
}
---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20260326-k1-usb3-f6a52f413616
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
* [PATCH 0/4] Extend phy_configure_opts_mipi_dphy to support position and polarity
From: Bryan O'Donoghue @ 2026-03-25 21:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Marco Felsch, Maxime Ripard
Cc: linux-phy, linux-kernel, Bryan O'Donoghue
struct phy_configure_opts_mipi_dphy currently passes @lanes as a linear
count of data-lanes starting from lane zero to a consuming DPHY driver.
This proves insufficient when we want to specify lane location and lane
polarity.
To address this gap extend the structure to pass four new fields.
- lane_positions
An array indicating the physical position of each data-lane
- lane_polarities
An array indicating the polarity of each data-lane
- clock_lane_position
A singleton indicating the physical location of the clock-lane
- clock_lane_polarity
A singleton indicating the polarity of the clock lane
These properties correspond to data-lanes, clock-lanes and lane-polarities
as defined in video-interfaces.yaml and already parsed by
v4l2_fwnode_endpoint_parse.
A controller can use these fields to pass down the relevant data to the PHY
driver over and above the assumption of simple linear consecutive
data-lanes as has been possible to this point.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
Bryan O'Donoghue (4):
phy: dphy: Add lane_positions to DPHY config struct
phy: dphy: Add lane_polarities to DPHY config struct
phy: dphy: Add clock_lane_position to DPHY config struct
phy: dphy: Add clock_lane_polarity to DPHY config struct
include/linux/phy/phy-mipi-dphy.h | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
---
base-commit: c824345288d11e269ce41b36c105715bc2286050
change-id: 20260325-dphy-params-extension-5fcd9ba8af61
Best regards,
--
Bryan O'Donoghue <bryan.odonoghue@linaro.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 2/4] phy: dphy: Add lane_polarities to DPHY config struct
From: Bryan O'Donoghue @ 2026-03-25 21:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Marco Felsch, Maxime Ripard
Cc: linux-phy, linux-kernel, Bryan O'Donoghue
In-Reply-To: <20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org>
Pass an array of data-lane polarities from controller to PHY. A true value
means the lane polarity is inverted.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
include/linux/phy/phy-mipi-dphy.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h
index c7eb11c41d7ec..3e0333b5a1a71 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -284,6 +284,14 @@ struct phy_configure_opts_mipi_dphy {
* Indexed by logical lane number.
*/
unsigned char lane_positions[PHY_MIPI_DPHY_MAX_DATA_LANES];
+
+ /**
+ * @lane_polarities:
+ *
+ * Array representing data-lane polarities. True means inverted.
+ * Indexed by logical lane number.
+ */
+ bool lane_polarities[PHY_MIPI_DPHY_MAX_DATA_LANES];
};
int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/4] phy: dphy: Add lane_positions to DPHY config struct
From: Bryan O'Donoghue @ 2026-03-25 21:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Marco Felsch, Maxime Ripard
Cc: linux-phy, linux-kernel, Bryan O'Donoghue
In-Reply-To: <20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org>
Add lane_positions to the DPHY configuration struct. This data-field
represents the physical positions of the data-lanes indexed by lane number.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
include/linux/phy/phy-mipi-dphy.h | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h
index 1ac128d78dfeb..c7eb11c41d7ec 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,6 +6,8 @@
#ifndef __PHY_MIPI_DPHY_H_
#define __PHY_MIPI_DPHY_H_
+#define PHY_MIPI_DPHY_MAX_DATA_LANES 4
+
/**
* struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
*
@@ -269,10 +271,19 @@ struct phy_configure_opts_mipi_dphy {
/**
* @lanes:
*
- * Number of active, consecutive, data lanes, starting from
- * lane 0, used for the transmissions.
+ * Number of active data lanes used for the transmission.
+ * When @lane_positions is not populated, lanes are consecutive
+ * starting from lane 0.
*/
unsigned char lanes;
+
+ /**
+ * @lane_positions:
+ *
+ * Array representing the physical positions of the data-lanes.
+ * Indexed by logical lane number.
+ */
+ unsigned char lane_positions[PHY_MIPI_DPHY_MAX_DATA_LANES];
};
int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 3/4] phy: dphy: Add clock_lane_position to DPHY config struct
From: Bryan O'Donoghue @ 2026-03-25 21:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Marco Felsch, Maxime Ripard
Cc: linux-phy, linux-kernel, Bryan O'Donoghue
In-Reply-To: <20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org>
We need to identify which lane is the clock-lane as many different PHYs
allow for a range of lanes, potentially any of the lanes to be the clock
input lane on a PHY.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
include/linux/phy/phy-mipi-dphy.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h
index 3e0333b5a1a71..76d41580e225a 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -292,6 +292,13 @@ struct phy_configure_opts_mipi_dphy {
* Indexed by logical lane number.
*/
bool lane_polarities[PHY_MIPI_DPHY_MAX_DATA_LANES];
+
+ /**
+ * @clock_lane_position:
+ *
+ * Physical lane number used as the clock lane.
+ */
+ unsigned char clock_lane_position;
};
int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 4/4] phy: dphy: Add clock_lane_polarity to DPHY config struct
From: Bryan O'Donoghue @ 2026-03-25 21:48 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Marco Felsch, Maxime Ripard
Cc: linux-phy, linux-kernel, Bryan O'Donoghue
In-Reply-To: <20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org>
Specify the polarity of the clock lane in DPHY mode. When true this bool
means the polarity is inverted.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
include/linux/phy/phy-mipi-dphy.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h
index 76d41580e225a..f7b4ad29e6f83 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -299,6 +299,13 @@ struct phy_configure_opts_mipi_dphy {
* Physical lane number used as the clock lane.
*/
unsigned char clock_lane_position;
+
+ /**
+ * @clock_lane_polarity:
+ *
+ * Clock lane polarity. True means inverted.
+ */
+ bool clock_lane_polarity;
};
int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v4 0/2] phy: spacemit: Add USB2 PHY support for K3 SoC
From: Yixun Lan @ 2026-03-26 0:14 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Krzysztof Kozlowski, Yao Zi
In-Reply-To: <20260305-11-k3-usb2-phy-v4-0-15554fb933bc@kernel.org>
Hi Vinod Koul,
On 01:00 Thu 05 Mar , Yixun Lan wrote:
> The series trys to add USB2 PHY support for SpacemiT K3 SoC, while
> patch [1/2] implement a disconnect function which is needed during
> next connection.
>
> No DTS part has been inclueded in this series, instead I plan to
> submit them later while adding USB host support.
>
> I've collected all patches and pushed a complete review branch here[1],
> for people who interested to test easily, which include DTS and necessary
> changes, other patches may still need to improve, but sufficient for
> verifying the functionality.
>
> Link: https://github.com/spacemit-com/linux/tree/WIP/k3/usb2 [1]
>
Just want to ping this, Can you queue it for v7.1? Thanks
--
Yixun Lan (dlan)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 0/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-26 1:04 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel,
Bryan O'Donoghue
v5:
- Adds support to apply passed parameters for clock/data position/polarity - Neil
- Drops GEN1/GEN2 differentiation this can be reconstituted if GEN1 ever
gets supported in this driver - Dmitry
- Drops camnoc_axi, cpas_ahb - Konrad
- Renames csiphy->core csiphy_timer->timer - Konrad
- Renames rail from 0p8 to 0p9 schematics say VDD_A_CSI_n_0P9 - Konrad
- TITAN_TOP_GDSC dropped - Konrad
- Passes PHY_QCOM_CSI2_MODE_{DPHY|CPHY|SPLIT_DPHY} with the controller
selecting the mode. Only DPHY mode is supported but the method to pass
CPHY or split-mode DPHY configuration is there.
Since split-mode is a Qualcomm specific mode the PHY modes are defined in
our binding instead of adding a new type to include/linux/phy/phy.h - bod
- Depends-on: https://lore.kernel.org/r/20260325-dphy-params-extension-v1-0-c6df5599284a@linaro.org
- Link to v4: https://lore.kernel.org/r/20260315-x1e-csi2-phy-v4-0-90c09203888d@linaro.org
v4:
- MMCX, MCX and MX/MXA power-domains added - Dmitry, Vijay, Konrad
- power-domain-names added as required - bod
- opp-tables amended to capture RPMHPD deps - Dmitry, Vijay
- Switched to dev_pm_opp_set_rate, dev_pm_domain_attach_by_name etc
dropped inherited CAMSS code - Dmitry
- Amended parameters structure to specify power-domain name list - bod
- Removed dead defines - Dmitry
- Noted in CSIPHY commit log intention to rework patterns of
PHY lane configs into loops/defines/bit-fields later - Dmitry, bod
- Lowercase hex throughout - Dmitry
- The yaml and code in this driver doesn't care if the node is a
sibling or a sub-node of CAMSS confirmed to work both ways - Dmitry, bod
- Link to v3: https://lore.kernel.org/r/20260226-x1e-csi2-phy-v3-0-11e608759410@linaro.org
v3:
- Resending this to make clear this submission is additive to x1e/Hamoa
The existing bindings and code will continue to work
Bindings are added only, nothing is subtracted from existing ABI.
- Link to v2: https://lore.kernel.org/r/20260225-x1e-csi2-phy-v2-0-7756edb67ea9@linaro.org
v2:
In this updated version
- Added operating-point support
The csiphy clock sets the OPP prior to setting the rate
for csiphy and csiphy_timer - Konrad
- Combo mode
Combo mode in CAMSS yaml has been added. Right now
no code has been changed in the PHY driver to support it as
I don't have hardware to test. In principle though it can
be supported. - Vladimir
- CSIPHY init sequences
I left these as their "magic number formats". With my diminished
status as a non-qcom VPN person - I can no longer see what the bits
map to. Moreover this is the situation any non-VPN community member
will be in when submitting CSIPHY sequences derived from downstream.
I think it is perfectly reasonable to take public CSIPHY init sequences
as magic numbers. If someone with bit-level access wants to enumerate
the bits that's fine but, it shouldn't gate in the interim. - Konrad/bod
- Sensor endpoints
I've stuck to the format used by every other CSIPHY in upstream.
Sensor endpoints hit the CAMSS/CSID endpoint not a endpoint in the PHY.
Given the proposed changes to CAMSS though to support "combo mode" I
think this should achieve the same outcome - multiple sensors on the one
PHY without introducing endpoints into the PHY that no other CSIPHY in
upstream currently has.
- Bitmask of enabled lanes
Work needs to be done in the v4l2 layer to really support this.
I propose making a separate series dedicated to non-linear bit
interpretation after merging this so as to contain the scope of the
series to something more bite (byte haha) sized. - Konrad/bod
- Link to v1: https://lore.kernel.org/r/20250710-x1e-csi2-phy-v1-0-74acbb5b162b@linaro.org
v1:
This short series adds a CSI2 MIPI PHY driver, initially supporting D-PHY
mode. The core logic and init sequences come directly from CAMSS and are
working on at least five separate x1e devices.
The rationale to instantiate CSI2 PHYs as standalone devices instead of as
sub-nodes of CAMSS is as follows.
1. Precedence
CAMSS has a dedicated I2C bus called CCI Camera Control Interface.
We model this controller as its own separate device in devicetree.
This makes sense and CCI/I2C is a well defined bus type already modelled
in Linux.
MIPI CSI2 PHY devices similarly fit into a well defined separate
bus/device structure.
Contrast to another CAMSS component such as VFE, CSID or TPG these
components only interact with other CAMSS inputs/outputs unlike CSIPHY
which interacts with non-SoC components.
2. Hardware pinouts and rails
The CSI2 PHY has its own data/clock lanes out from the SoC and indeed
has its own incoming power-rails.
3. Other devicetree schemas
There are several examples throughout the kernel of CSI PHYs modeled as
standalone devices which one assumes follows the same reasoning as given
above.
I've been working on this on-and-off since the end of April:
Link: https://lore.kernel.org/linux-media/c5cf0155-f839-4db9-b865-d39b56bb1e0a@linaro.org
There is another proposal to have the PHYs be subdevices of CAMSS but, I
believe we should go with a "full fat" PHY to match best practices in
drivers/phy/qualcomm/*.
Using the standard PHY API and the parameter passing that goes with it
allows us to move away from custom interfaces in CAMSS and to conform more
clearly to established PHY paradigms such as the QMP combo PHY.
Looking at existing compat strings I settled on
"qcom,x1e80100-mipi-csi2-combo-phy" deliberately omitting reference to the
fact the PHY is built on a four nano-meter process node, which seems to
match recent submissions to QMP PHY.
My first pass at this driver included support for the old two phase
devices:
Link: https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/a504c28d109296c93470340cfe7281231f573bcb#b6e59ed7db94c9da22e492bb03fcda6a4300983c
I realised that the device tree schema changes required to support a
comprehensive conversion of all CAMSS to this driver would be an
almost certainly be unacceptable ABI break or at the very least an enormous
amount of work and verification so I instead aimed to support just one new
SoC in the submission.
I've retained the callback indirections give us scope to add in another type of
future PHY including potentially adding in the 2PH later on.
This driver is tested and working on x1e/Hamoa and has been tested as not
breaking sc8280xp/Makena and sm8250/Kona.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
Bryan O'Donoghue (2):
dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
.../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 130 ++++++++
MAINTAINERS | 11 +
drivers/phy/qualcomm/Kconfig | 13 +
drivers/phy/qualcomm/Makefile | 5 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 361 +++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 298 +++++++++++++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 95 ++++++
include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +
8 files changed, 928 insertions(+)
---
base-commit: c824345288d11e269ce41b36c105715bc2286050
change-id: 20250710-x1e-csi2-phy-f6434b651d3a
Best regards,
--
Bryan O'Donoghue <bryan.odonoghue@linaro.org>
--
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