* [PATCH v8 phy-next 02/31] ata: add <linux/pm_runtime.h> where missing
From: Vladimir Oltean @ 2026-05-05 10:04 UTC (permalink / raw)
To: linux-phy
Cc: 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, Damien Le Moal, Niklas Cassel
In-Reply-To: <20260505100523.1922388-1-vladimir.oltean@nxp.com>
It appears that libahci.c, ahci.c as well as the ahci_brcm, ahci_ceva
and ahci_qoriq drivers are using runtime PM operations without including
<linux/pm_runtime.h>. This header is somehow being indirectly provided
by <linux/phy/phy.h>, which would like to drop it (none of the functions
it exports need it).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Damien Le Moal <dlemoal@kernel.org>
---
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Niklas Cassel <cassel@kernel.org>
v2->v8: none
v1->v2: collect tag
---
drivers/ata/ahci.c | 1 +
drivers/ata/ahci_brcm.c | 1 +
drivers/ata/ahci_ceva.c | 1 +
drivers/ata/ahci_qoriq.c | 1 +
drivers/ata/libahci.c | 1 +
5 files changed, 5 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1d73a53370cf..1396a53bd6df 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -26,6 +26,7 @@
#include <linux/device.h>
#include <linux/dmi.h>
#include <linux/gfp.h>
+#include <linux/pm_runtime.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_cmnd.h>
#include <linux/libata.h>
diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index 29be74fedcf0..48460e515722 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/string.h>
diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
index 2d6a08c23d6a..3938bf378341 100644
--- a/drivers/ata/ahci_ceva.c
+++ b/drivers/ata/ahci_ceva.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include "ahci.h"
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 0dec1a17e5b1..409152bfefb6 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -14,6 +14,7 @@
#include <linux/device.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/libata.h>
#include "ahci.h"
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index c79abdfcd7a9..e0de4703a4f2 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -30,6 +30,7 @@
#include <scsi/scsi_cmnd.h>
#include <linux/libata.h>
#include <linux/pci.h>
+#include <linux/pm_runtime.h>
#include "ahci.h"
#include "libata.h"
--
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 v8 phy-next 01/31] PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()
From: Vladimir Oltean @ 2026-05-05 10:04 UTC (permalink / raw)
To: linux-phy
Cc: 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, Bjorn Helgaas, Krzysztof Wilczyński,
Lorenzo Pieralisi, Manikandan K Pillai, Manivannan Sadhasivam,
Rob Herring
In-Reply-To: <20260505100523.1922388-1-vladimir.oltean@nxp.com>
The blamed commit functionally changed the error path of
cdns_pcie_host_probe(), now cdns_plat_pcie_probe().
When the old code path executed "goto err_get_sync", the PCIe controller
probe function propagated the pm_runtime_get_sync() error code. The new
code doesn't, and returns 0.
Similarly for the "goto err_init" previously triggered by
cdns_pcie_host_init() errors, and now triggered by
cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not
propagated and will result in probing success, which is incorrect.
Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manikandan K Pillai <mpillai@cadence.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Rob Herring <robh@kernel.org>
v7->v8: patch is new, issue was flagged by Sashiko
https://sashiko.dev/#/patchset/20260430110652.558622-1-vladimir.oltean@nxp.com
---
drivers/pci/controller/cadence/pcie-cadence-plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
index b067a3296dd3..8b12a46b5601 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
@@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
while (phy_count--)
device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
- return 0;
+ return ret;
}
static void cdns_plat_pcie_shutdown(struct platform_device *pdev)
--
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 v7 phy-next 13/27] usb: host: tegra: avoid direct dereference of phy->dev.of_node
From: Vladimir Oltean @ 2026-05-05 9:39 UTC (permalink / raw)
To: linux-phy
Cc: 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, Greg Kroah-Hartman, JC Kuo, Johan Hovold,
Jonathan Hunter, Mathias Nyman, Thierry Reding
In-Reply-To: <20260430110652.558622-14-vladimir.oltean@nxp.com>
Sashiko says:
> commit 037a329bd1e70f26b8d861fb06f3bbc539fb2c49
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
> usb: host: tegra: avoid direct dereference of phy->dev.of_node
>
> This commit updates the Tegra USB host driver to retrieve the PHY OF node
> using the "phys" phandle rather than directly accessing phy->dev.of_node.
> This addresses an upcoming change where struct phy will become an opaque
> pointer. It also simplifies a debug message to log the array index.
>
> > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> > index d2214d309e96..99b0ac9763f9 100644
> > --- a/drivers/usb/host/xhci-tegra.c
> > +++ b/drivers/usb/host/xhci-tegra.c
> > @@ -1491,6 +1491,7 @@ static int tegra_xhci_id_notify(struct notifier_block *nb,
> >
> > static int tegra_xusb_init_usb_phy(struct tegra_xusb *tegra)
> > {
> > + struct device_node *np = dev_of_node(tegra->dev);
> > unsigned int i;
> >
> > tegra->usbphy = devm_kcalloc(tegra->dev, tegra->num_usb_phys,
> > @@ -1504,23 +1505,33 @@ static int tegra_xusb_init_usb_phy(struct tegra_xusb *tegra)
> > tegra->otg_usb3_port = -EINVAL;
> >
> > for (i = 0; i < tegra->num_usb_phys; i++) {
> > - struct phy *phy = tegra_xusb_get_phy(tegra, "usb2", i);
> > + struct of_phandle_args args;
> > + struct usb_phy *usbphy;
> > + int index, err;
> > + char prop[8];
> >
> > - if (!phy)
> > + snprintf(prop, sizeof(prop), "usb2-%d", i);
> > +
> > + /*
> > + * usb-phy is optional, continue if it's not available.
> > + */
> > + index = of_property_match_string(np, "phy-names", prop);
> > + if (index < 0)
> > continue;
> >
> > - tegra->usbphy[i] = devm_usb_get_phy_by_node(tegra->dev,
> > - phy->dev.of_node,
> > - &tegra->id_nb);
> > - if (!IS_ERR(tegra->usbphy[i])) {
> > - dev_dbg(tegra->dev, "usbphy-%d registered", i);
> > - otg_set_host(tegra->usbphy[i]->otg, &tegra->hcd->self);
> > - } else {
> > - /*
> > - * usb-phy is optional, continue if its not available.
> > - */
> > - tegra->usbphy[i] = NULL;
> > - }
> > + err = of_parse_phandle_with_args(np, "phys", "#phy-cells",
> > + index, &args);
> > + if (err)
> > + continue;
>
> The call to of_parse_phandle_with_args() increments the reference count
> of the device tree node and populates it in args.np. The new code passes
> args.np to devm_usb_get_phy_by_node(), but does not appear to call
> of_node_put() to drop the reference when it is done. Does this leak the
> device node reference on both the success and error paths of the loop?
I've added an of_node_put(args.np) after devm_usb_get_phy_by_node() for v8.
> > +
> > + usbphy = devm_usb_get_phy_by_node(tegra->dev, args.np,
> > + &tegra->id_nb);
>
> Also in tegra_xusb_init_usb_phy(), the single notifier block instance
> tegra->id_nb is passed to devm_usb_get_phy_by_node() for every USB PHY
> being processed. Because the struct notifier_block API uses an embedded next
> pointer for its singly-linked list, does registering the exact same object
> to multiple independent PHY notifier chains overwrite its next pointer and
> corrupt the lists?
If this is a problem, it is a pre-existing and completely unrelated
problem which I don't have knowledge how to handle, so I will leave it
alone.
> > + if (IS_ERR(usbphy))
> > + continue;
> > +
> > + tegra->usbphy[i] = usbphy;
> > + dev_dbg(tegra->dev, "usbphy-%d registered", i);
> > + otg_set_host(tegra->usbphy[i]->otg, &tegra->hcd->self);
> > }
> >
> > return 0;
> [...]
> > drivers/usb/host/xhci-tegra.c | 42 ++++++++++++++++++++++-------------
> > 1 file changed, 26 insertions(+), 16 deletions(-)
> >
> > @@ -2168,8 +2179,7 @@ static void tegra_xhci_disable_phy_wake(struct tegra_xusb *tegra)
> > continue;
> >
> > if (tegra_xusb_padctl_remote_wake_detected(padctl, tegra->phys[i]))
> > - dev_dbg(tegra->dev, "%pOF remote wake detected\n",
> > - tegra->phys[i]->dev.of_node);
> > + dev_dbg(tegra->dev, "PHY %d remote wake detected\n", i);
> >
> > tegra_xusb_padctl_disable_phy_wake(padctl, tegra->phys[i]);
> > }
>
> In tegra_xhci_disable_phy_wake(), the loop counter i is declared as an
> unsigned int. The updated dev_dbg() message formats this variable using
> the %d specifier. This isn't a bug since the values are bounded by
> tegra->num_phys, but should it use %u to match the unsigned integer type?
I've changed to %u printing for v8.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 phy-next 14/27] usb: gadget: tegra-xudc: avoid direct dereference of phy->dev.of_node
From: Vladimir Oltean @ 2026-05-05 9:34 UTC (permalink / raw)
To: linux-phy
Cc: 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, Greg Kroah-Hartman, JC Kuo, Johan Hovold,
Jonathan Hunter, Mathias Nyman, Thierry Reding
In-Reply-To: <20260430110652.558622-15-vladimir.oltean@nxp.com>
Sashiko says:
> commit 1ca88ec2e954b3a331eb5afb8081406d9200c8f6
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
> usb: gadget: tegra-xudc: avoid direct dereference of phy->dev.of_node
>
> This commit replaces direct dereferences of the device tree node with a
> parallel lookup using the phys phandle and the padctl provider. It also
> introduces a local usbphy variable to hold the output and simplify error
> checks.
>
> > diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c
> > index e9d33be028664..cf4e6c87e44da 100644
> > --- a/drivers/usb/gadget/udc/tegra-xudc.c
> > +++ b/drivers/usb/gadget/udc/tegra-xudc.c
> [ ... ]
> > @@ -3515,7 +3516,10 @@ static int tegra_xudc_phy_get(struct tegra_xudc *xudc)
> > xudc->vbus_nb.notifier_call = tegra_xudc_vbus_notify;
> >
> > for (i = 0; i < xudc->soc->num_phys; i++) {
> > + struct of_phandle_args args;
> > char phy_name[] = "usb.-.";
> > + struct usb_phy *usbphy;
> > + int index, err;
>
> This declares a local err variable inside the loop, shadowing the outer
> err variable from the function scope.
> Later in this loop, if devm_phy_optional_get() or devm_usb_get_phy_by_node()
> fails, the code assigns the error code to this inner err and uses goto
> clean_up.
> Since the inner err is destroyed when leaving the loop block, will the
> function incorrectly return the outer err which is still 0?
This is correct, I've removed the duplicated "err" variable declaration
for v8.
> >
> > /* Get USB2 phy */
> > snprintf(phy_name, sizeof(phy_name), "usb2-%d", i);
> [ ... ]
> > @@ -3525,22 +3529,31 @@ static int tegra_xudc_phy_get(struct tegra_xudc *xudc)
> > dev_err_probe(xudc->dev, err,
> > "failed to get PHY for phy-name usb2-%d\n", i);
> > goto clean_up;
> > - } else if (xudc->utmi_phy[i]) {
> [ ... ]
> > } else if (!xudc->utmi_phy[i]) {
> > /* if utmi phy is not available, ignore USB3 phy get */
> > continue;
> > }
> >
> > + index = of_property_match_string(np, "phy-names", phy_name);
> > + if (index < 0)
> > + continue;
> > +
> > + err = of_parse_phandle_with_args(np, "phys", "#phy-cells",
> > + index, &args);
> > + if (err)
> > + continue;
>
> If either of these device tree parsing steps fail, the code uses continue
> to skip to the next iteration.
> Does this unintentionally skip the entire USB3 PHY initialization block
> that follows later in this loop for the current port?
This is correct, although theoretically of_property_match_string() and
of_parse_phandle_with_args() should not fail as long as devm_phy_optional_get()
succeeded for that very same phy_name starting from the very same OF node.
But nonetheless, if this happens due to bugs, I've instead treated the
condition as fatal and printed error messages for v8.
> > +
> > + /* Get usb-phy, if utmi phy is available */
> > + usbphy = devm_usb_get_phy_by_node(xudc->dev, args.np, NULL);
> > + of_node_put(args.np);
> [ ... ]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 phy-next 21/27] net: renesas: rswitch: include PHY provider header
From: Vladimir Oltean @ 2026-05-05 9:24 UTC (permalink / raw)
To: linux-phy
Cc: 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, Geert Uytterhoeven, Yoshihiro Shimoda,
Michael Dege, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Russell King (Oracle)
In-Reply-To: <20260430110652.558622-22-vladimir.oltean@nxp.com>
Sashiko says:
> commit 4e15b6920cd2b2dfce685835fa09c66664407579
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
> net: renesas: rswitch: include PHY provider header
>
> This commit includes the PHY provider header in the rswitch driver as a
> workaround to avoid breaking the build when struct phy becomes opaque.
> It allows the driver to continue accessing internal PHY fields while
> acknowledging that the driver's PHY API call sequence needs a complete
> redesign.
>
> > diff --git a/drivers/net/ethernet/renesas/rswitch_main.c b/drivers/net/ethernet/renesas/rswitch_main.c
> > index 6fe964816322a..132be5f15073c 100644
> > --- a/drivers/net/ethernet/renesas/rswitch_main.c
> > +++ b/drivers/net/ethernet/renesas/rswitch_main.c
> > @@ -27,6 +27,7 @@
> > #include <linux/spinlock.h>
> > #include <linux/sys_soc.h>
> >
> > +#include "../../../phy/phy-provider.h" /* FIXME */
>
> Does preserving the ability to check the provider's global reference counts
> (power_count and init_count) via this internal header leave the driver
> vulnerable to data races?
>
> Since these fields are protected by the PHY provider's internal phy->mutex,
> reading them locklessly can create a time-of-check to time-of-use
> vulnerability. The count could be altered by a concurrent operation before
> the mutex is acquired inside phy_power_off() or phy_exit().
>
> Additionally, if the PHY is shared across multiple ports (like in QSGMII
> mode), would checking the global reference count instead of tracking the
> consumer's local vote cause a port to observe a non-zero count from
> another port's vote? This could lead to an incorrect phy_power_off()
> call, prematurely decrementing the shared refcount and powering down the
> PHY while it is still in active use by other ports.
>
> While the commit message notes this is a known issue preserved as a
> workaround until a complete redesign, could retaining these unlocked
> reads cause a regression in power vote tracking in the interim?
>
> > #include "rswitch.h"
> > #include "rswitch_l2.h"
I will ignore this comment. Inaction will leave the driver in exactly
the same state as before. Not great, true, but I don't see how not
changing anything could cause a regression.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 phy-next 25/27] phy: include PHY provider header (2/2)
From: Vladimir Oltean @ 2026-05-05 9:22 UTC (permalink / raw)
To: linux-phy
Cc: 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, Dmitry Baryshkov, Shawn Lin
In-Reply-To: <20260430110652.558622-26-vladimir.oltean@nxp.com>
Sashiko says:
> commit 4194b60e90a65a3b71a94359af9d2b530bae01d8
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
> phy: include PHY provider header (2/2)
>
> This commit replaces the inclusion of the generic linux/phy/phy.h header
> with the internal PHY provider header across numerous PHY drivers. It targets
> drivers that act as PHY providers or chained provider/consumers to ensure they
> include the appropriate provider API definitions.
> [ ... ]
>
> > diff --git a/include/linux/phy/ulpi_phy.h b/include/linux/phy/ulpi_phy.h
> > index 7054b440347ce..0f9e8430d398e 100644
> > --- a/include/linux/phy/ulpi_phy.h
> > +++ b/include/linux/phy/ulpi_phy.h
> > @@ -1,5 +1,5 @@
> > /* SPDX-License-Identifier: GPL-2.0 */
> > -#include <linux/phy/phy.h>
> > +#include "../../drivers/phy/phy-provider.h"
>
> Since this header is located in include/linux/phy/, won't navigating up two
> levels resolve to the include/ directory? That would make the compiler search
> for include/drivers/phy/phy-provider.h, which does not exist, and could cause
> build failures.
The LLM review is right that the relative include path is wrong.
> Also, does including a private subsystem header from a public API header in
> include/linux/ cause issues for out-of-tree builds? This exposes private
> structures and could cause regressions for external modules that include
> <linux/phy/ulpi_phy.h> since they won't have access to the kernel's drivers/
> directory.
>
> If the provider API is needed here, would it be better to move the functions
> that depend on it out of the public header into a .c file?
I have moved the file from include/linux/phy/ulpi_phy.h to drivers/phy/ulpi_phy.h
for v8, and updated the relative include path to just "phy-provider.h".
Frankly, it is an oversight that ulpi_phy.h was still left in the public
<linux/phy/> directory.
> > /**
> > * Helper that registers PHY for a ULPI device and adds a lookup for binding it
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring
From: Josua Mayer @ 2026-05-05 9:18 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org, Marc Kleine-Budde, Vincent Mailhol,
Vinod Koul, Neil Armstrong, Ulf Hansson
In-Reply-To: <afhDm5_ydU83xFKU@ashevche-desk.local>
Am 04.05.26 um 08:58 schrieb Andy Shevchenko:
> On Mon, Apr 27, 2026 at 06:26:34PM +0300, Andy Shevchenko wrote:
>> On Mon, Apr 27, 2026 at 01:41:43PM +0000, Josua Mayer wrote:
>>> Am 27.04.26 um 15:34 schrieb Andy Shevchenko:
>>>> On Mon, Apr 27, 2026 at 11:09:48AM +0000, Josua Mayer wrote:
>>>>> Am 14.04.26 um 20:43 schrieb Andy Shevchenko:
>>>>>> On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:
> ...
>
>>>>> For unknown reason your patch-set did not arrive in my inbox.
>>>>> Perhaps it went missing for others, too?
>>>> Are you in the MAINTAINERS for this part of the kernel?
>>>> The CAN NETWORK DRIVERS and GENERIC PHY FRAMEWORK do not list your name.
>>> Correct. I touched can phy once related to mux only.
>>>> If you think of mail delivery in general, it's delivered at least to the ML
>>>> https://lore.kernel.org/all/20260317203001.2108568-1-andriy.shevchenko@linux.intel.com/
>>>>
>>>> TBH I don't know what to answer to your question as I don't know your expectations and
>>>> how it should be fulfilled taking into account my above question...
>>> Changelog v2:
>>> - Cc'ed to Ulf and Josua due to above
>>>
>>> This is why I expected it in my inbox.
>>> Usually in this situation I blame my provider.
>> Ah, blame me then. I most likely missed to add your name to the Cc list.
> Hmm... I have checked and your address is in the Cc for the whole series,
> so I withdraw that I admit earlier that problem is on my side. Please, check
> if everything fine on yours. Note, I'm about to send a v3.
Received v3, thanks!
>
>>>> But thanks for the reviewing! I will address the commit message in v3.
>>> Great!
>> And will try hard to make sure your address will be in the Cc list.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document Nord QMP UFS PHY
From: Krzysztof Kozlowski @ 2026-05-05 7:38 UTC (permalink / raw)
To: Shawn Guo
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-phy, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260504081442.825908-1-shengchao.guo@oss.qualcomm.com>
On Mon, May 04, 2026 at 04:14:42PM +0800, Shawn Guo wrote:
> Document QMP UFS PHY on Qualcomm Nord SoC.
And here you explain the hardware, IOW, that it is or is not compatible
with something and WHY.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Changes in v3:
> - Improve commit log to drop "compatible with" part
Devices are compatible with other devices, not with a string. And
previous commits could be a guidance here.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Krishna Kurapati @ 2026-05-05 4:06 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <gb46nv455vfkldkhvlo7c26amuonrlzvstirdpbzictbqgyxox@6vypar3byxhs>
On 5/5/2026 12:58 AM, Dmitry Baryshkov wrote:
> On Mon, May 04, 2026 at 10:36:59PM +0530, Krishna Kurapati wrote:
>> Add init sequence and phy configuration for the Super Speed port
>> on Shikra SoC.
>>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> index c342479a3798..400dcebf8222 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> @@ -2019,6 +2019,9 @@ static const struct of_device_id qmp_usbc_of_match_table[] = {
>> }, {
>> .compatible = "qcom,sdm660-qmp-usb3-phy",
>> .data = &sdm660_usb3phy_cfg,
>> + }, {
>> + .compatible = "qcom,shikra-qmp-usb3-phy",
>> + .data = &qcs615_usb3phy_cfg,
>
> If we are reusing Talos configuration, should Talos also be used for the
> fallback compat instead of modifying the driver?
>
The clocks are different and hence I didn't use fallback.
Regards,
Krishna,
>> }, {
>> .compatible = "qcom,sm6115-qmp-usb3-phy",
>> .data = &qcm2290_usb3phy_cfg,
>> --
>> 2.34.1
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Dmitry Baryshkov @ 2026-05-04 19:28 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260504170659.282532-5-krishna.kurapati@oss.qualcomm.com>
On Mon, May 04, 2026 at 10:36:59PM +0530, Krishna Kurapati wrote:
> Add init sequence and phy configuration for the Super Speed port
> on Shikra SoC.
>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> index c342479a3798..400dcebf8222 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> @@ -2019,6 +2019,9 @@ static const struct of_device_id qmp_usbc_of_match_table[] = {
> }, {
> .compatible = "qcom,sdm660-qmp-usb3-phy",
> .data = &sdm660_usb3phy_cfg,
> + }, {
> + .compatible = "qcom,shikra-qmp-usb3-phy",
> + .data = &qcs615_usb3phy_cfg,
If we are reusing Talos configuration, should Talos also be used for the
fallback compat instead of modifying the driver?
> }, {
> .compatible = "qcom,sm6115-qmp-usb3-phy",
> .data = &qcm2290_usb3phy_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
* [PATCH v2 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Krishna Kurapati @ 2026-05-04 17:06 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com>
Add init sequence and phy configuration for the Super Speed port
on Shikra SoC.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index c342479a3798..400dcebf8222 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -2019,6 +2019,9 @@ static const struct of_device_id qmp_usbc_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qmp-usb3-phy",
.data = &sdm660_usb3phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qmp-usb3-phy",
+ .data = &qcs615_usb3phy_cfg,
}, {
.compatible = "qcom,sm6115-qmp-usb3-phy",
.data = &qcm2290_usb3phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/4] phy: qcom-qusb2: Add support for Shikra
From: Krishna Kurapati @ 2026-05-04 17:06 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com>
Add init sequence and phy configuration for Shikra.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..ab7437e7b751 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -381,6 +381,19 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
.autoresume_en = BIT(3),
};
+static const struct qusb2_phy_cfg shikra_phy_cfg = {
+ .tbl = qcs615_init_tbl,
+ .tbl_num = ARRAY_SIZE(qcs615_init_tbl),
+ .regs = ipq6018_regs_layout,
+
+ .has_pll_test = true,
+ .se_clk_scheme_default = true,
+ .disable_ctrl = CLAMP_N_EN | FREEZIO_N | POWER_DOWN,
+ .mask_core_ready = PLL_LOCKED,
+ .autoresume_en = BIT(3),
+ .update_tune1_with_efuse = false,
+};
+
static const struct qusb2_phy_cfg sm6115_phy_cfg = {
.tbl = sm6115_init_tbl,
.tbl_num = ARRAY_SIZE(sm6115_init_tbl),
@@ -958,6 +971,9 @@ static const struct of_device_id qusb2_phy_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qusb2-phy",
.data = &sdm660_phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qusb2-phy",
+ .data = &shikra_phy_cfg,
}, {
.compatible = "qcom,sm4250-qusb2-phy",
.data = &sm6115_phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
From: Krishna Kurapati @ 2026-05-04 17:06 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com>
Declare the USB-C QMP PHY present on the Qualcomm Shikra platform.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
.../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml
index 1636285fbe53..8402fe4a96e0 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml
@@ -20,6 +20,7 @@ properties:
- qcom,qcm2290-qmp-usb3-phy
- qcom,qcs615-qmp-usb3-phy
- qcom,sdm660-qmp-usb3-phy
+ - qcom,shikra-qmp-usb3-phy
- qcom,sm6115-qmp-usb3-phy
reg:
@@ -116,6 +117,7 @@ allOf:
contains:
enum:
- qcom,qcm2290-qmp-usb3-phy
+ - qcom,shikra-qmp-usb3-phy
- qcom,sm6115-qmp-usb3-phy
then:
properties:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
From: Krishna Kurapati @ 2026-05-04 17:06 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com>
Update dt-bindings to add Shikra to QUSB2 Phy list. Shikra SoC
has two High Speed QUSB2 Phys.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 39851ba9de43..ddbddeec6fb1 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -28,6 +28,7 @@ properties:
- qcom,qcm2290-qusb2-phy
- qcom,qcs615-qusb2-phy
- qcom,sdm660-qusb2-phy
+ - qcom,shikra-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
- items:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/4] Add USB Phy driver and binding changes for Qualcomm Shikra SoC
From: Krishna Kurapati @ 2026-05-04 17:06 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
This series adds Driver and binding changes for USB Phys on Shikra. There
are two USB controllers - One of them is SS capable and other is highspeed
only capable. The ss Phy init sequence is same as that of Talos.
Changes in v2:
- Separated the usb controller binding changes
- Updated commit texts.
Krishna Kurapati (4):
dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
phy: qcom-qusb2: Add support for Shikra
phy: qcom: qmp-usbc: Add qmp configuration for Shikra
.../bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 3 +++
drivers/phy/qualcomm/phy-qcom-qusb2.c | 16 ++++++++++++++++
4 files changed, 22 insertions(+)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] dt-bindings: phy: qcom,snps-eusb2: Document the Eliza Synopsys eUSB2 PHY
From: Abel Vesa @ 2026-05-04 16:06 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Konrad Dybcio,
Abel Vesa
The Synopsys eUSB2 PHY found on the Eliza SoC is fully compatible with the
one found the SM8550.
So document it by adding the compatible to the list that has the SM8550
one as fallback.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Changes in v2:
- Rebased on next-20260430.
- Picked up Konrad's R-b tag.
- Picked up Rob's A-b tag.
- Link to v1: https://patch.msgid.link/20260327-eliza-bindings-phy-eusb2-v1-1-1f8a9ad6a033@oss.qualcomm.com
---
Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
index 854f70af0a6c..096f6b546632 100644
--- a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
@@ -17,6 +17,7 @@ properties:
oneOf:
- items:
- enum:
+ - qcom,eliza-snps-eusb2-phy
- qcom,milos-snps-eusb2-phy
- qcom,sar2130p-snps-eusb2-phy
- qcom,sdx75-snps-eusb2-phy
---
base-commit: b9303e6bff706758c167af686b5315ad00233bf8
change-id: 20260327-eliza-bindings-phy-eusb2-bc4dd201444c
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Eliza QMP PHY
From: Abel Vesa @ 2026-05-04 16:03 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski, Abel Vesa
Document the compatible for the USB QMP PHY found on the Qualcomm Eliza
SoC.
It is fully compatible with the one found on Qualcomm SM8650, so add it
with the SM8650 as fallback.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Changes in v2:
- Rebased on next-20260430.
- Picked-up Krzysztof's R-b tag.
- Link to v1: https://patch.msgid.link/20260318-eliza-bindings-qmp-phy-v1-1-96a0d529ad2d@oss.qualcomm.com
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 3d537b7f9985..4eff92343ce4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -16,6 +16,10 @@ description:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - qcom,eliza-qmp-usb3-dp-phy
+ - const: qcom,sm8650-qmp-usb3-dp-phy
- items:
- enum:
- qcom,kaanapali-qmp-usb3-dp-phy
---
base-commit: b9303e6bff706758c167af686b5315ad00233bf8
change-id: 20260318-eliza-bindings-qmp-phy-c53be4b0b131
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* RE: [PATCH] phy: renesas: phy-rzg3e-usb3: Fix runtime PM underflow during suspend
From: Ovidiu Panait @ 2026-05-04 12:11 UTC (permalink / raw)
To: geert
Cc: Vinod Koul, neil.armstrong@linaro.org, Biju Das,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdWT+hv37gxi-5fbLVc16Fk4SKsXuBis5Fg6_zm7TS6hkQ@mail.gmail.com>
Hi Geert,
>
> Hi Ovidiu,
>
> On Mon, 4 May 2026 at 13:11, Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> wrote:
> > > On 27-04-26, 19:47, Ovidiu Panait wrote:
> > > > On the Renesas RZ/V2H platform, if the xhcd driver is unbound and
> the
> > > > system is suspended afterwards, a PM underflow error will occur:
> > > >
> > > > # echo 15850000.usb > /sys/bus/platform/drivers/xhci-renesas-
> hcd/unbind
> > > > # systemctl suspend
> > > > 15870000.usb-phy: PM: dpm_run_callback(): genpd_resume_noirq
> returns -
> > > 13
> > > > 15870000.usb-phy: PM: failed to resume noirq: error -13
> > > > 15870000.usb-phy: Runtime PM usage count underflow!
> > > >
> > > > Since the PHY framework is managing the runtime PM of the PHY via
> > > > phy_power_on()/phy_power_off(), there is no need for the PHY driver
> to
> > > > manipulate the runtime PM state during suspend.
> > > >
> > > > To fix this, remove the runtime PM calls from the suspend/resume
> paths
> > > > and add a get/put pair inside rzg3e_phy_usb3_init_helper() to make
> sure
> > > > the clock is enabled during init, even when there is no consumer for
> > > > the PHY.
> > >
> > > > Also, change the suspend ops from NOIRQ_SYSTEM_SLEEP_PM_OPS to
> > > > SYSTEM_SLEEP_PM_OPS because runtime PM is disabled during the noirq
> > > phase
> > > > and pm_runtime_resume_and_get() would not actually enable the device
> > > clock.
> > >
> > > > Fixes: ee5f1a3f90a4 ("phy: renesas: Add Renesas RZ/G3E USB3.0 PHY
> > > driver")
> > > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
>
> > > > index 6b3453ea0004..055775e1a0f7 100644
> > > > --- a/drivers/phy/renesas/phy-rzg3e-usb3.c
> > > > +++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
>
> > > > @@ -215,27 +226,21 @@ static int rzg3e_phy_usb3_resume(struct device
> > > *dev)
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - ret = pm_runtime_resume_and_get(dev);
> > > > + ret = rzg3e_phy_usb3_init_helper(r);
> > > > if (ret)
> > > > goto reset_assert;
> > > >
> > > > - ret = rzg3e_phy_usb3_init_helper(r->base);
> > > > - if (ret)
> > > > - goto pm_put;
> > > > -
> > > > r->skip_reinit = true;
> > >
> > > https://sashiko.dev/#/patchset/20260427194741.161533-1-
> > > ovidiu.panait.rb%40renesas.com
> > >
> >
> > I think this is not applicable for our platforms, as the power domain
> only
> > gates the clock during runtime suspend, so the register state is not
> lost
> > across runtime suspend/resume.
> >
> > The power domain (drivers/clk/renesas/rzv2h-cpg.c) is marked as
> > GENPD_FLAG_ALWAYS_ON.
>
> Won't the SoC be powered down during s2ram?
>
Yes, the SoC will be powered down during s2ram and the USB3 PHY is
reinitialized in the resume callback:
static int rzg3e_phy_usb3_resume(struct device *dev)
{
...
ret = rzg3e_phy_usb3_init_helper(r->base);
if (ret)
goto pm_put;
My understanding is that Sashiko's comment ([1]) is about runtime PM and
whether the PM domain will be powered off after the refcount reaches 0,
destroying the PHY state. Which does not happen on our platforms, as the
CPG driver sets GENPD_FLAG_ALWAYS_ON and it only gates/ungates the clock
across runtime suspend/resume, preserving the state.
[1] https://sashiko.dev/#/patchset/20260427194741.161533-1-ovidiu.panait.rb%40renesas.com
Thanks,
Ovidiu
> 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 v7 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Vladimir Oltean @ 2026-05-04 11:48 UTC (permalink / raw)
To: linux-phy
Cc: 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, Bart Van Assche, Alim Akhtar, Martin K . Petersen,
Peter Griffin, James E.J. Bottomley, Krzysztof Kozlowski,
Chanho Park
In-Reply-To: <20260430110652.558622-10-vladimir.oltean@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
Sashiko says:
> commit 76ded6c0290bdb192c2ae1af9a2e6a47fc39c9a1
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> scsi: ufs: exynos: stop poking into struct phy guts
> This commit modifies the Exynos UFS driver to stop directly accessing the
> generic PHY's power_count. Instead, it tracks the PHY power state internally
> using a new phy_powered_on flag to properly handle link retries and
> suspend/resume operations.
>
> > diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
> > --- a/drivers/ufs/host/ufs-exynos.c
> > +++ b/drivers/ufs/host/ufs-exynos.c
> [ ... ]
> > @@ -1513,6 +1516,9 @@ static void exynos_ufs_exit(struct ufs_hba *hba)
> > {
> > struct exynos_ufs *ufs = ufshcd_get_variant(hba);
> >
> > + if (!ufs->phy_powered_on)
> > + return;
> > +
> > phy_power_off(ufs->phy);
> > phy_exit(ufs->phy);
> > }
>
> Does this introduce a regression where initialization resources are leaked
> if the driver is unbound while suspended?
> Looking at exynos_ufs_suspend(), the PHY is powered off and phy_powered_on
> is set to false, but phy_exit() is intentionally not called so the PHY
> remains initialized:
> exynos_ufs_suspend()
> if (!ufshcd_is_link_active(hba) && ufs->phy_powered_on) {
> phy_power_off(ufs->phy);
> ufs->phy_powered_on = false;
> }
> If an unbind or fatal error occurs while in this suspended state,
> exynos_ufs_exit() will see phy_powered_on as false and return immediately.
> The initialization reference and any resources allocated by phy_init()
> would never be released since phy_exit() is completely skipped.
> [ ... ]
I think I've been looking at this issue all wrong, not considering why
the UFS HCD driver calls phy_exit() -> phy_init() at runtime and what
can be done about that.
I have replaced this patch with the one attached, which I will be sending
for v8.
[-- Attachment #2: 0001-scsi-ufs-exynos-use-dedicated-API-for-updating-PHY-b.patch --]
[-- Type: text/x-diff, Size: 9438 bytes --]
From c687a8568c6c7837bb0bd539bf14343d7d0c63a1 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Mon, 4 May 2026 14:00:51 +0300
Subject: [PATCH] scsi: ufs: exynos: use dedicated API for updating PHY bus
width
I am trying to get rid of code instances where PHY consumers (like the
Exynos UFS HCD) poke inside struct phy fields, in order to further turn
struct phy into an opaque data structure.
The ufs-exynos.c driver interacts with phy-samsung-ufs.c in order to
power it on and to update the lane count. For the later purpose, it
(ab)uses phy_set_bus_width().
The phy_set_bus_width() function is a PHY provider function, not a
consumer one, and I am calling its use from ufs-exynos.c an abuse
because
(1) commit 8feed347d33b ("phy: add phy_get_bus_width()/phy_set_bus_width()
calls") clearly states so.
(2) phy_set_bus_width() only alters phy->attrs.bus_width, and does not
call into phy_ops at all. So a consumer that makes a call to
phy_set_bus_width() will not produce any hardware change in the
provider at all.
This is where the Exynos UFS HCD driver decided to be creative and
hijacked phy_init() to pick up the bus_width attribute.
This requires a very careful dance where the PHY consumer needs to
simultaneously juggle two requirements:
- the UFS PHY needs to pick up the updated lane count in its
samsung_ufs_phy_init() handler for the phy_init() call
- phy_init() calls need to be balanced with phy_exit(), otherwise
subsequent phy_init() calls don't make it into samsung_ufs_phy_init()
and just leave the PHY with an elevated init_count
- phy_power_on() can't be called without phy_init()
This is why the following bug fix commits exist:
3d73b200f989 ("scsi: ufs: ufs-exynos: Change ufs phy control sequence")
7f05fd9a3b6f ("scsi: ufs: exynos: Ensure consistent phy reference counts")
Currently the UFS HCD driver tries to keep the PHY init_count and
power_count in tight lockstep, but even this is error-prone. For
example, if exynos_ufs_suspend() runs and then exynos_ufs_exit(),
the PHY power_count will underflow.
If we address the root issue first (phy_init() abused to pick up new
lane count) by introducing a new PHY consumer method which actually does
call into the PHY provider driver, then we are able to absorb the entire
UFS HCD dance and update the lane count without altering the PHY
init_count or power_count.
Then we are much more free to call phy_init() from wherever we want, and
same goes for phy_power_on().
It is typical to call phy_init() right after phy_get(), and doing so
will naturally balance it with phy_exit().
We can also leave the phy_power_on() call to be on demand, placed inside
exynos_ufs_pre_link(). Because this call can be made multiple times and
is not balanced with anything else, we need a consumer-specific "bool
phy_powered_on" which ensures that we call phy_power_on() at most once,
and that exynos_ufs_exit() only calls phy_power_off() if phy_power_on()
was previously called. Using the phy->power_count for this purpose is
undesirable because
(a) it is going away
(b) the PHY API supports multiple consumers for the same provider, so it
cannot offer an equivalent helper because it doesn't want consumers
to interfere with each other
Inside the new samsung_ufs_phy_request_bus_width(), I've sanity checked
that the bus width is either 1 or 2 lanes. This coincides with
samsung_ufs_phy_config() which only configures LANE_0 and LANE_1.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Peter Griffin <peter.griffin@linaro.org>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Chanho Park <chanho61.park@samsung.com>
v7->v8:
- rewrote commit after Sashiko pointed out the new handling is still
not correct:
https://sashiko.dev/#/patchset/20260430110652.558622-1-vladimir.oltean@nxp.com
- removed Reviewed-by, Tested-by and Acked-by tags from Alim, Bart and
Peter
v6->v7: collect tags from Martin and Peter
v5->v6: collect tags from Alim Akhtar
v4->v5: collect tag, add "scsi: " prefix to commit title
v3->v4: none
v2->v3:
- add Cc Chanho Park, author of commit 3d73b200f989 ("scsi: ufs:
ufs-exynos: Change ufs phy control sequence")
v1->v2:
- add better ufs->phy_powered_on handling in exynos_ufs_exit(),
exynos_ufs_suspend() and exynos_ufs_resume() which ensures we won't
enter a phy->power_count underrun condition
---
drivers/phy/phy-core.c | 18 +++++++++++
drivers/phy/samsung/phy-samsung-ufs.c | 30 ++++++++++++------
drivers/ufs/host/ufs-exynos.c | 45 ++++++++++++++++++++++-----
drivers/ufs/host/ufs-exynos.h | 1 +
4 files changed, 77 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 21aaf2f76e53..6305efe210d6 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -606,6 +606,24 @@ int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
}
EXPORT_SYMBOL_GPL(phy_validate);
+int phy_request_bus_width(struct phy *phy, int bus_width)
+{
+ int ret;
+
+ if (!phy)
+ return -EINVAL;
+
+ if (!phy->ops->request_bus_width)
+ return -EOPNOTSUPP;
+
+ mutex_lock(&phy->mutex);
+ ret = phy->ops->request_bus_width(phy, bus_width);
+ mutex_unlock(&phy->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_request_bus_width);
+
/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
diff --git a/drivers/phy/samsung/phy-samsung-ufs.c b/drivers/phy/samsung/phy-samsung-ufs.c
index 00e570d699f3..5d7b842bff1a 100644
--- a/drivers/phy/samsung/phy-samsung-ufs.c
+++ b/drivers/phy/samsung/phy-samsung-ufs.c
@@ -161,16 +161,6 @@ static int samsung_ufs_phy_clks_init(struct samsung_ufs_phy *phy)
return devm_clk_bulk_get(phy->dev, num_clks, phy->clks);
}
-static int samsung_ufs_phy_request_bus_width(struct phy *phy, int bus_width)
-{
- if (bus_width != 1 && bus_width != 2)
- return -EINVAL;
-
- ss_phy->lane_cnt = phy->attrs.bus_width;
-
- return 0;
-}
-
static int samsung_ufs_phy_init(struct phy *phy)
{
struct samsung_ufs_phy *ss_phy = get_samsung_ufs_phy(phy);
@@ -213,6 +203,26 @@ static int samsung_ufs_phy_power_off(struct phy *phy)
return 0;
}
+static int samsung_ufs_phy_request_bus_width(struct phy *phy, int bus_width)
+{
+ struct samsung_ufs_phy *ss_phy = get_samsung_ufs_phy(phy);
+
+ if (bus_width != 1 && bus_width != 2)
+ return -EINVAL;
+
+ ss_phy->lane_cnt = phy->attrs.bus_width;
+
+ if (phy->init_count)
+ samsung_ufs_phy_init(phy);
+
+ if (phy->power_count) {
+ samsung_ufs_phy_power_off(phy);
+ return samsung_ufs_phy_power_on(phy);
+ }
+
+ return 0;
+}
+
static int samsung_ufs_phy_set_mode(struct phy *generic_phy,
enum phy_mode mode, int submode)
{
diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
index fb616d1599eb..b90876b268db 100644
--- a/drivers/ufs/host/ufs-exynos.c
+++ b/drivers/ufs/host/ufs-exynos.c
@@ -959,6 +959,40 @@ static void exynos_ufs_phy_exit(struct exynos_ufs *ufs)
phy_exit(ufs->phy);
}
+static int exynos_ufs_phy_power_on(struct exynos_ufs *ufs)
+{
+ int ret;
+
+ if (ufs->phy_powered_on)
+ return 0;
+
+ ret = phy_power_on(ufs->phy);
+ if (ret) {
+ dev_err(ufs->hba->dev, "Failed to power on PHY: %pe\n",
+ ERR_PTR(ret));
+ return ret;
+ }
+
+ ufs->phy_powered_on = true;
+
+ return 0;
+}
+
+static void exynos_ufs_phy_power_off(struct exynos_ufs *ufs)
+{
+ int ret;
+
+ if (!ufs->phy_powered_on)
+ return;
+
+ ret = phy_power_off(ufs->phy);
+ if (ret)
+ dev_warn(ufs->hba->dev, "Failed to power off PHY: %pe\n",
+ ERR_PTR(ret));
+
+ ufs->phy_powered_on = false;
+}
+
static int exynos_ufs_phy_update_bus_width(struct exynos_ufs *ufs)
{
struct ufs_hba *hba = ufs->hba;
@@ -979,10 +1013,7 @@ static int exynos_ufs_phy_update_bus_width(struct exynos_ufs *ufs)
if (ret)
return ret;
- if (generic_phy->power_count)
- phy_power_off(generic_phy);
-
- return phy_power_on(generic_phy);
+ return exynos_ufs_phy_power_on(ufs);
}
static void exynos_ufs_config_unipro(struct exynos_ufs *ufs)
@@ -1524,7 +1555,7 @@ static void exynos_ufs_exit(struct ufs_hba *hba)
{
struct exynos_ufs *ufs = ufshcd_get_variant(hba);
- phy_power_off(ufs->phy);
+ exynos_ufs_phy_power_off(ufs);
exynos_ufs_phy_exit(ufs);
}
@@ -1739,7 +1770,7 @@ static int exynos_ufs_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op,
ufs->drv_data->suspend(ufs);
if (!ufshcd_is_link_active(hba))
- phy_power_off(ufs->phy);
+ exynos_ufs_phy_power_off(ufs);
return 0;
}
@@ -1749,7 +1780,7 @@ static int exynos_ufs_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
struct exynos_ufs *ufs = ufshcd_get_variant(hba);
if (!ufshcd_is_link_active(hba))
- phy_power_on(ufs->phy);
+ exynos_ufs_phy_power_on(ufs);
exynos_ufs_config_smu(ufs);
exynos_ufs_fmp_resume(hba);
diff --git a/drivers/ufs/host/ufs-exynos.h b/drivers/ufs/host/ufs-exynos.h
index abe7e472759e..683b9150e2ba 100644
--- a/drivers/ufs/host/ufs-exynos.h
+++ b/drivers/ufs/host/ufs-exynos.h
@@ -227,6 +227,7 @@ struct exynos_ufs {
int avail_ln_rx;
int avail_ln_tx;
int rx_sel_idx;
+ bool phy_powered_on;
struct ufs_pa_layer_attr dev_req_params;
struct ufs_phy_time_cfg t_cfg;
ktime_t entry_hibern8_t;
--
2.34.1
[-- Attachment #3: 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 related
* Re: [PATCH] phy: renesas: phy-rzg3e-usb3: Fix runtime PM underflow during suspend
From: Geert Uytterhoeven @ 2026-05-04 11:44 UTC (permalink / raw)
To: Ovidiu Panait
Cc: Vinod Koul, neil.armstrong@linaro.org, Biju Das,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <OSOP301MB19766FF764E6626FF1CD6771D3312@OSOP301MB1976.JPNP301.PROD.OUTLOOK.COM>
Hi Ovidiu,
On Mon, 4 May 2026 at 13:11, Ovidiu Panait <ovidiu.panait.rb@renesas.com> wrote:
> > On 27-04-26, 19:47, Ovidiu Panait wrote:
> > > On the Renesas RZ/V2H platform, if the xhcd driver is unbound and the
> > > system is suspended afterwards, a PM underflow error will occur:
> > >
> > > # echo 15850000.usb > /sys/bus/platform/drivers/xhci-renesas-hcd/unbind
> > > # systemctl suspend
> > > 15870000.usb-phy: PM: dpm_run_callback(): genpd_resume_noirq returns -
> > 13
> > > 15870000.usb-phy: PM: failed to resume noirq: error -13
> > > 15870000.usb-phy: Runtime PM usage count underflow!
> > >
> > > Since the PHY framework is managing the runtime PM of the PHY via
> > > phy_power_on()/phy_power_off(), there is no need for the PHY driver to
> > > manipulate the runtime PM state during suspend.
> > >
> > > To fix this, remove the runtime PM calls from the suspend/resume paths
> > > and add a get/put pair inside rzg3e_phy_usb3_init_helper() to make sure
> > > the clock is enabled during init, even when there is no consumer for
> > > the PHY.
> >
> > > Also, change the suspend ops from NOIRQ_SYSTEM_SLEEP_PM_OPS to
> > > SYSTEM_SLEEP_PM_OPS because runtime PM is disabled during the noirq
> > phase
> > > and pm_runtime_resume_and_get() would not actually enable the device
> > clock.
> >
> > > Fixes: ee5f1a3f90a4 ("phy: renesas: Add Renesas RZ/G3E USB3.0 PHY
> > driver")
> > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > index 6b3453ea0004..055775e1a0f7 100644
> > > --- a/drivers/phy/renesas/phy-rzg3e-usb3.c
> > > +++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
> > > @@ -215,27 +226,21 @@ static int rzg3e_phy_usb3_resume(struct device
> > *dev)
> > > if (ret)
> > > return ret;
> > >
> > > - ret = pm_runtime_resume_and_get(dev);
> > > + ret = rzg3e_phy_usb3_init_helper(r);
> > > if (ret)
> > > goto reset_assert;
> > >
> > > - ret = rzg3e_phy_usb3_init_helper(r->base);
> > > - if (ret)
> > > - goto pm_put;
> > > -
> > > r->skip_reinit = true;
> >
> > https://sashiko.dev/#/patchset/20260427194741.161533-1-
> > ovidiu.panait.rb%40renesas.com
> >
>
> I think this is not applicable for our platforms, as the power domain only
> gates the clock during runtime suspend, so the register state is not lost
> across runtime suspend/resume.
>
> The power domain (drivers/clk/renesas/rzv2h-cpg.c) is marked as
> GENPD_FLAG_ALWAYS_ON.
Won't the SoC be powered down during s2ram?
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] phy: renesas: phy-rzg3e-usb3: Fix runtime PM underflow during suspend
From: Ovidiu Panait @ 2026-05-04 11:09 UTC (permalink / raw)
To: Vinod Koul
Cc: neil.armstrong@linaro.org, Biju Das,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <afd-gj-F3OYDfCwJ@vaman>
Hi Vinod,
>
> On 27-04-26, 19:47, Ovidiu Panait wrote:
> > On the Renesas RZ/V2H platform, if the xhcd driver is unbound and the
> > system is suspended afterwards, a PM underflow error will occur:
> >
> > # echo 15850000.usb > /sys/bus/platform/drivers/xhci-renesas-hcd/unbind
> > # systemctl suspend
> > 15870000.usb-phy: PM: dpm_run_callback(): genpd_resume_noirq returns -
> 13
> > 15870000.usb-phy: PM: failed to resume noirq: error -13
> > 15870000.usb-phy: Runtime PM usage count underflow!
> >
> > Since the PHY framework is managing the runtime PM of the PHY via
> > phy_power_on()/phy_power_off(), there is no need for the PHY driver to
> > manipulate the runtime PM state during suspend.
> >
> > To fix this, remove the runtime PM calls from the suspend/resume paths
> > and add a get/put pair inside rzg3e_phy_usb3_init_helper() to make sure
> > the clock is enabled during init, even when there is no consumer for
> > the PHY.
>
> Ok
>
> >
> > Also, change the suspend ops from NOIRQ_SYSTEM_SLEEP_PM_OPS to
> > SYSTEM_SLEEP_PM_OPS because runtime PM is disabled during the noirq
> phase
> > and pm_runtime_resume_and_get() would not actually enable the device
> clock.
>
> This is a fix, so split this up please
>
> >
> > Fixes: ee5f1a3f90a4 ("phy: renesas: Add Renesas RZ/G3E USB3.0 PHY
> driver")
> > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > ---
> > drivers/phy/renesas/phy-rzg3e-usb3.c | 31 ++++++++++++++++------------
> > 1 file changed, 18 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/phy/renesas/phy-rzg3e-usb3.c
> b/drivers/phy/renesas/phy-rzg3e-usb3.c
> > index 6b3453ea0004..055775e1a0f7 100644
> > --- a/drivers/phy/renesas/phy-rzg3e-usb3.c
> > +++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
> > @@ -64,6 +64,7 @@
> > #define USB3_TEST_LANECONFIG0_DEFAULT (0xd)
> >
> > struct rz_usb3 {
> > + struct device *dev;
>
> This does not belong in a fix, please split
>
Thanks for your review, I'll split this up into multiple patches.
> > void __iomem *base;
> > struct reset_control *rstc;
> > bool skip_reinit;
> > @@ -130,11 +131,21 @@ static int rzg3e_phy_usb3test_phy_init(void
> __iomem *base)
> > return 0;
> > }
> >
> > -static int rzg3e_phy_usb3_init_helper(void __iomem *base)
> > +static int rzg3e_phy_usb3_init_helper(struct rz_usb3 *r)
> > {
> > - rzg3e_phy_usb2test_phy_init(base);
> > + int ret;
> > +
> > + ret = pm_runtime_resume_and_get(r->dev);
> > + if (ret)
> > + return ret;
> > +
> > + rzg3e_phy_usb2test_phy_init(r->base);
> >
> > - return rzg3e_phy_usb3test_phy_init(base);
> > + ret = rzg3e_phy_usb3test_phy_init(r->base);
> > +
> > + pm_runtime_put_sync(r->dev);
> > +
> > + return ret;
> > }
> >
> > static int rzg3e_phy_usb3_init(struct phy *p)
> > @@ -143,7 +154,7 @@ static int rzg3e_phy_usb3_init(struct phy *p)
> > int ret = 0;
> >
> > if (!r->skip_reinit)
> > - ret = rzg3e_phy_usb3_init_helper(r->base);
> > + ret = rzg3e_phy_usb3_init_helper(r);
> >
> > return ret;
> > }
> > @@ -187,6 +198,7 @@ static int rzg3e_phy_usb3_probe(struct
> platform_device *pdev)
> >
> > platform_set_drvdata(pdev, r);
> > phy_set_drvdata(phy, r);
> > + r->dev = dev;
> >
> > provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > if (IS_ERR(provider))
> > @@ -199,7 +211,6 @@ static int rzg3e_phy_usb3_suspend(struct device
> *dev)
> > {
> > struct rz_usb3 *r = dev_get_drvdata(dev);
> >
> > - pm_runtime_put(dev);
> > reset_control_assert(r->rstc);
> > r->skip_reinit = false;
> >
> > @@ -215,27 +226,21 @@ static int rzg3e_phy_usb3_resume(struct device
> *dev)
> > if (ret)
> > return ret;
> >
> > - ret = pm_runtime_resume_and_get(dev);
> > + ret = rzg3e_phy_usb3_init_helper(r);
> > if (ret)
> > goto reset_assert;
> >
> > - ret = rzg3e_phy_usb3_init_helper(r->base);
> > - if (ret)
> > - goto pm_put;
> > -
> > r->skip_reinit = true;
>
> https://sashiko.dev/#/patchset/20260427194741.161533-1-
> ovidiu.panait.rb%40renesas.com
>
I think this is not applicable for our platforms, as the power domain only
gates the clock during runtime suspend, so the register state is not lost
across runtime suspend/resume.
The power domain (drivers/clk/renesas/rzv2h-cpg.c) is marked as
GENPD_FLAG_ALWAYS_ON.
Thanks,
Ovidiu
>
> --
> ~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: Add Spacemit K3 USB3/PCIe comb phy support
From: Inochi Amaoto @ 2026-05-04 10:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Inochi Amaoto
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Kees Cook, Gustavo A. R. Silva,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Ze Huang, Alex Elder, linux-phy, devicetree, linux-riscv,
spacemit, linux-kernel, linux-hardening, Yixun Lan, Longbin Li
In-Reply-To: <20260504-logical-nice-python-1e1f43@quoll>
On Mon, May 04, 2026 at 11:54:11AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 30, 2026 at 10:28:40AM +0800, Inochi Amaoto wrote:
> > +properties:
> > + compatible:
> > + const: spacemit,k3-comb-phy
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#phy-cells":
> > + const: 2
> > + description:
> > + The first one is phy id, the second one is phy type.
>
> You could mention here the defines representing supported phy types.
>
OK.
> > +
> > + spacemit,apb-spare:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Phandle to APB SPARE system controller interface, used for
> > + PHY calibration.
> > +
> > + spacemit,apmu:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + items:
> > + - items:
> > + - description: phandle of APMU syscon
> > + - description: configuration of the PHY lanes
> > + description: |
> > + Phandle to control PHY mux configuration. The configuration
> > + is described as follows:
> > + bit 4: 0 - PCIe A x8 mode, 1 - PCIe lane share mode
> > + bit 3: 0 - PCIe A x4 mode, 1 - PCIe A x2 and PCIe B x2 mode
> > + bit 2: 0 - PCIe C lane 0 is PCIe mode , 1 - USB mode
> > + bit 1: 0 - PCIe C lane 1 is PCIe mode , 1 - USB mode
> > + bit 0: 0 - PCIe D lane is PCIe mode , 1 - USB mode
>
> I assume this device k3-comb-phy handles phys for PCIe A, B, C and D?
>
In fact it handles phys for PCIe A-E. The mux for the phy of PCIe E
(the id is 5) is controlled by bit 4. If the comb PHY is in shared
mode, the PCIe E always got one lane.
I think it is good to add a public link for this configuration, but
Spacemit has no opened any document for this publicly....
> > +
> > + The bit[3:0] is only valid when bit 4 is 1.
> > +
> > +required:
> > + - compatible
>
> reg required.
>
It is fine for me
> > + - "#phy-cells"
> > + - spacemit,apb-spare
> > + - spacemit,apmu
> > +
> > +additionalProperties: false
>
> Best regards,
> Krzysztof
>
Regards,
Inochi
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
From: Krzysztof Kozlowski @ 2026-05-04 10:14 UTC (permalink / raw)
To: Komal Bajaj
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Vinod Koul, Neil Armstrong,
linux-arm-msm, linux-usb, devicetree, linux-kernel, linux-phy,
Krishna Kurapati
In-Reply-To: <20260430-shikra-usb-v1-2-c9c108536fdc@oss.qualcomm.com>
On Thu, Apr 30, 2026 at 05:20:27PM +0530, Komal Bajaj wrote:
> From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>
> Update dt-bindings to add Shikra to QUSB2 Phy list.
>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Incomplete DCO, incomplete description of hardware, mixing subsystems
without any need or explanation.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: usb: qcom,snps-dwc3: Add Shikra compatible
From: Krzysztof Kozlowski @ 2026-05-04 10:13 UTC (permalink / raw)
To: Komal Bajaj
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Vinod Koul, Neil Armstrong,
linux-arm-msm, linux-usb, devicetree, linux-kernel, linux-phy,
Krishna Kurapati
In-Reply-To: <20260430-shikra-usb-v1-1-c9c108536fdc@oss.qualcomm.com>
On Thu, Apr 30, 2026 at 05:20:26PM +0530, Komal Bajaj wrote:
> From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>
> Introduce the compatible definition for Shikra QCOM SNPS DWC3.
>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Please do not mix subsystems.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: Add Spacemit K3 USB3/PCIe comb phy support
From: Krzysztof Kozlowski @ 2026-05-04 9:54 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Kees Cook, Gustavo A. R. Silva,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Ze Huang, Alex Elder, linux-phy, devicetree, linux-riscv,
spacemit, linux-kernel, linux-hardening, Yixun Lan, Longbin Li
In-Reply-To: <20260430022843.1090138-2-inochiama@gmail.com>
On Thu, Apr 30, 2026 at 10:28:40AM +0800, Inochi Amaoto wrote:
> +properties:
> + compatible:
> + const: spacemit,k3-comb-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 2
> + description:
> + The first one is phy id, the second one is phy type.
You could mention here the defines representing supported phy types.
> +
> + spacemit,apb-spare:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to APB SPARE system controller interface, used for
> + PHY calibration.
> +
> + spacemit,apmu:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle of APMU syscon
> + - description: configuration of the PHY lanes
> + description: |
> + Phandle to control PHY mux configuration. The configuration
> + is described as follows:
> + bit 4: 0 - PCIe A x8 mode, 1 - PCIe lane share mode
> + bit 3: 0 - PCIe A x4 mode, 1 - PCIe A x2 and PCIe B x2 mode
> + bit 2: 0 - PCIe C lane 0 is PCIe mode , 1 - USB mode
> + bit 1: 0 - PCIe C lane 1 is PCIe mode , 1 - USB mode
> + bit 0: 0 - PCIe D lane is PCIe mode , 1 - USB mode
I assume this device k3-comb-phy handles phys for PCIe A, B, C and D?
> +
> + The bit[3:0] is only valid when bit 4 is 1.
> +
> +required:
> + - compatible
reg required.
> + - "#phy-cells"
> + - spacemit,apb-spare
> + - spacemit,apmu
> +
> +additionalProperties: false
Best regards,
Krzysztof
--
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