* [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Varadarajan Narayanan @ 2026-05-14 3:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
In-Reply-To: <20260514-pci-phy-v1-0-482429192746@oss.qualcomm.com>
Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index f60804687412..1ac31439c20a 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
oneOf:
- enum:
+ - qcom,ipq5210-qmp-gen3x1-pcie-phy
- qcom,ipq6018-qmp-pcie-phy
- qcom,ipq8074-qmp-gen3-pcie-phy
- qcom,ipq8074-qmp-pcie-phy
@@ -24,10 +25,12 @@ properties:
- qcom,ipq9574-qmp-gen3x2-pcie-phy
- items:
- enum:
+ - qcom,ipq5210-qmp-gen3x1-pcie-phy
- qcom,ipq5424-qmp-gen3x1-pcie-phy
- const: qcom,ipq9574-qmp-gen3x1-pcie-phy
- items:
- enum:
+ - qcom,ipq5210-qmp-gen3x2-pcie-phy
- qcom,ipq5424-qmp-gen3x2-pcie-phy
- const: qcom,ipq9574-qmp-gen3x2-pcie-phy
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/2] Enable the QMP PCIe PHY present in Qualcomm ipq5210 SoC
From: Varadarajan Narayanan @ 2026-05-14 3:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan
Document the bindings and update the driver to support
the PCIe phy present in Qualcomm ipq5210 SoC.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Varadarajan Narayanan (2):
dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
.../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 3 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 152 +++++++++++++++++++++
2 files changed, 155 insertions(+)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260514-pci-phy-38ec9b1c5a90
Best regards,
--
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-05-14 2:34 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng
When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.
Fix this by adding an error handling path to disable the clock
when these functions fail.
Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v2:
-Add pm_runtime_disable() in error path (reported by Sashiko AI).
---
drivers/phy/ti/phy-ti-pipe3.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index b5543b5c674c..5f4a81f6d2b9 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -837,15 +837,28 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
generic_phy = devm_phy_create(dev, NULL, &ops);
- if (IS_ERR(generic_phy))
- return PTR_ERR(generic_phy);
+ if (IS_ERR(generic_phy)) {
+ ret = PTR_ERR(generic_phy);
+ goto err_clk_disable;
+ }
phy_set_drvdata(generic_phy, phy);
ti_pipe3_power_off(generic_phy);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- return PTR_ERR_OR_ZERO(phy_provider);
+ if (IS_ERR(phy_provider)) {
+ ret = PTR_ERR(phy_provider);
+ goto err_clk_disable;
+ }
+
+ return 0;
+
+err_clk_disable:
+ pm_runtime_disable(dev);
+ if (phy->sata_refclk_enabled)
+ clk_disable_unprepare(phy->refclk);
+ return ret;
}
static void ti_pipe3_remove(struct platform_device *pdev)
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH] phy: ti: pipe3: Fix clock resource leak on probe errors
From: sashiko-bot @ 2026-05-14 2:10 UTC (permalink / raw)
To: Hongling Zeng; +Cc: linux-phy, vkoul, neil.armstrong, olteanv
In-Reply-To: <20260513063902.113956-1-zenghongling@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing pm_runtime_disable() in the probe error path leaves PM runtime state unbalanced.
--
commit fd04e6bd036402bf170a7ff7978b95f1478bfd7b
Author: Hongling Zeng <zenghongling@kylinos.cn>
phy: ti: pipe3: Fix clock resource leak on probe errors
This commit addresses a clock resource leak in the probe error path of the
TI PIPE3 PHY driver. It adds an err_clk_disable label to ensure the reference
clock is disabled if PHY creation or provider registration fails.
> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> index b5543b5c674c8..29a4cbe737812 100644
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c
> @@ -837,15 +837,27 @@ static int ti_pipe3_probe(struct platform_device *pdev)
[ ... ]
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> - return PTR_ERR_OR_ZERO(phy_provider);
> + if (IS_ERR(phy_provider)) {
> + ret = PTR_ERR(phy_provider);
> + goto err_clk_disable;
> + }
> +
> + return 0;
> +
> +err_clk_disable:
> + if (phy->sata_refclk_enabled)
> + clk_disable_unprepare(phy->refclk);
> + return ret;
Does this new error path leave the power management runtime state unbalanced?
Earlier in ti_pipe3_probe(), pm_runtime_enable(dev) is called. Without a
corresponding pm_runtime_disable() call in this error path, it looks like
the device's power management runtime state is left unbalanced, which can
trigger a warning on subsequent probe retries.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260513063902.113956-1-zenghongling@kylinos.cn?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 2/6] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
From: Peter Chen (CIX) @ 2026-05-14 1:42 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
Greg Kroah-Hartman, netdev, devicetree, linux-kernel, linux-phy,
linux-tegra, linux-usb
In-Reply-To: <CAPVz0n2yGALm1Z0j0j6_MaqAOZGL+a8EgCWYQpW0QN1YVf96EQ@mail.gmail.com>
On 26-05-13 20:30:10, Svyatoslav Ryhel wrote:
> вт, 12 трав. 2026 р. о 10:51 Peter Chen (CIX) <peter.chen@kernel.org> пише:
> >
> > On 26-05-12 09:13:40, Svyatoslav Ryhel wrote:
> > > вт, 12 трав. 2026 р. о 04:16 Peter Chen (CIX) <peter.chen@kernel.org> пише:
> > > >
> > > > On 26-05-11 16:56:57, Svyatoslav Ryhel wrote:
> > > > > If the USB controller and PHY are externally controlled, then the
> > > > > registration of the controller and the PHY initialization should be
> > > > > skipped, since these configurations must be done by the device that
> > > > > controls the bus to work correctly.
> > > > >
> > > >
> > > > I find you only control USB controller device add at PHY driver, most of USB drivers
> > > > has PHY control, for chipidea, it has PHY control at core.c, would please try to
> > > > adapt for it?
> > > >
> > >
> > > Usually yes, but this is not the case for Tegra unfortunately. As you
> > > can see Tegra specific section of Chipidea driver specifically
> > > describes why it has to set PHY manually.
> > >
> > > /*
> > > * USB controller registers shouldn't be touched before PHY is
> > > * initialized, otherwise CPU will hang because clocks are gated.
> > > * PHY driver controls gating of internal USB clocks on Tegra.
> > > */
> > >
> > > So in order to provide correct work of USB when set by an external
> > > device, both PHY and controller init/add must be skipped.
> >
> > You could call generic PHY APIs at ci_hdrc_tegra.c, after PHY init or power on,
> > call controller initialization.
> >
>
> I was tinkering with Chipidea driver for Tegra a bit. If you meant to
> use flag only to control usb controller device init and leave PHY to
> be handled by controller, then yes, that is possible and that is
> better approach.
>
Yes, you may summarize the initialization sequence, and see if put PHY
control at Tegra glue layer or at Chipidea core.
--
Best regards,
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 5/6] phy: phy-can-transceiver: Decouple assignment and definition in probe
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
The code like
int foo = X;
...
if (bar)
foo = Y;
is prone to subtle mistakes and hence harder to maintain as the foo value
may be changed inadvertently while code in '...' grown in lines. On top
it's harder to navigate to understand the possible values of foo when branch
is not taken (requires to look somewhere else in the code, far from the piece
at hand).
Besides that in case of taken branch the foo will be rewritten, which is
not a problem per se, just an unneeded operation.
Decouple assignment and definition to use if-else to address the inconveniences
described above.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 3cebaa54f7db..30330499585b 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -128,8 +128,8 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
struct gpio_desc *standby_gpio;
struct gpio_desc *enable_gpio;
struct mux_state *mux_state;
- int err, i, num_ch = 1;
const char *propname;
+ int err, i, num_ch;
u32 max_bitrate;
drvdata = device_get_match_data(dev);
@@ -138,6 +138,8 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
num_ch = 2;
+ else
+ num_ch = 1;
priv = devm_kzalloc(dev, struct_size(priv, can_transceiver_phy, num_ch), GFP_KERNEL);
if (!priv)
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 6/6] phy: phy-can-transceiver: Drop unused include
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
This file does not use the symbols from the legacy
<linux/gpio.h> header, so let's drop it.
Reviewed-by: Josua Mayer <josua@solid-run.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 30330499585b..75dc49e75ca0 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,12 +5,11 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
+#include <linux/gpio/consumer.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/property.h>
#include <linux/module.h>
-#include <linux/gpio.h>
-#include <linux/gpio/consumer.h>
#include <linux/mux/consumer.h>
struct can_transceiver_data {
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 4/6] phy: phy-can-transceiver: Don't check for specific errors when parsing properties
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
Instead of checking for the specific error codes (that can be considered
a layering violation to some extent) check for the property existence first
and then either parse it, or apply a default value.
With that, return an error when parsing of the existing property fails.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 5c9698f77c7d..3cebaa54f7db 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -128,8 +128,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
struct gpio_desc *standby_gpio;
struct gpio_desc *enable_gpio;
struct mux_state *mux_state;
- u32 max_bitrate = 0;
int err, i, num_ch = 1;
+ const char *propname;
+ u32 max_bitrate;
drvdata = device_get_match_data(dev);
if (!drvdata)
@@ -151,9 +152,17 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
priv->mux_state = mux_state;
- err = device_property_read_u32(dev, "max-bitrate", &max_bitrate);
- if ((err != -EINVAL) && !max_bitrate)
- dev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit\n");
+ propname = "max-bitrate";
+ if (device_property_present(dev, propname)) {
+ err = device_property_read_u32(dev, propname, &max_bitrate);
+ if (err)
+ return dev_err_probe(dev, err, "failed to parse %s\n", propname);
+
+ if (max_bitrate == 0)
+ dev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit\n");
+ } else {
+ max_bitrate = 0;
+ }
for (i = 0; i < num_ch; i++) {
can_transceiver_phy = &priv->can_transceiver_phy[i];
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 2/6] phy: phy-can-transceiver: use device_get_match_data()
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
Use the generic firmware node interface for retrieving
device match data instead of the OF-specific one.
While at it, drop unneeded argument to devm_phy_create() which
extracts device node from the given device by default.
Reviewed-by: Josua Mayer <josua@solid-run.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 1808f903c057..37b706d841ff 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,9 +5,9 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
-#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/module.h>
#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
@@ -152,7 +152,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
struct can_transceiver_phy *can_transceiver_phy;
struct can_transceiver_priv *priv;
const struct can_transceiver_data *drvdata;
- const struct of_device_id *match;
struct phy *phy;
struct gpio_desc *silent_gpio;
struct gpio_desc *standby_gpio;
@@ -161,11 +160,10 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
u32 max_bitrate = 0;
int err, i, num_ch = 1;
- match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
- if (!match || !match->data)
+ drvdata = device_get_match_data(dev);
+ if (!drvdata)
return -ENODEV;
- drvdata = match->data;
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
num_ch = 2;
@@ -190,7 +188,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
can_transceiver_phy = &priv->can_transceiver_phy[i];
can_transceiver_phy->priv = priv;
- phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
+ phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
if (IS_ERR(phy)) {
dev_err(dev, "failed to create can transceiver phy\n");
return PTR_ERR(phy);
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 0/6] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
The driver does two things that need to be addressed:
- includes subject to remove gpio.h
- checks for error code from device property APIs when it can be done in
a robust way
This series addresses the above and adds a couple of additional refactoring.
On top of that it fixes potential NULL pointer dereference when driver_override
is in use.
Changelog v5:
- fixed typo due to rebasing of patch 2 (Sashiko)
- added patch 5 to slightly improve maintainability
v4: 20260512130552.272476-1-andriy.shevchenko@linux.intel.com
Changelog v4:
- prepended the series with match and driver data check (Sashiko, Vinod)
- made the max_bitrate==0 warning only when property is present (Sashiko, Vinod)
- rebased the rest accordingly
v3: 20260504070054.29508-1-andriy.shevchenko@linux.intel.com
Changelog v3:
- fixed commit message in patch 1 (Josua)
- dropped stray change (Vinod)
- collected tags (Josua)
v2: 20260317203001.2108568-1-andriy.shevchenko@linux.intel.com
Changelog v2:
- rebased on top of the latest changes in the driver
- Cc'ed to Ulf and Josua due to above
- elaborated dropping of_node parameter (Vladimir)
v1: 20260219202910.2304440-1-andriy.shevchenko@linux.intel.com
*** BLURB HERE ***
Andy Shevchenko (6):
phy: phy-can-transceiver: Check driver match and driver data against
NULL
phy: phy-can-transceiver: use device_get_match_data()
phy: phy-can-transceiver: Move OF ID table closer to their user
phy: phy-can-transceiver: Don't check for specific errors when parsing
properties
phy: phy-can-transceiver: Decouple assignment and definition in probe
phy: phy-can-transceiver: Drop unused include
drivers/phy/phy-can-transceiver.c | 93 +++++++++++++++++--------------
1 file changed, 52 insertions(+), 41 deletions(-)
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 3/6] phy: phy-can-transceiver: Move OF ID table closer to their user
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 58 +++++++++++++++----------------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 37b706d841ff..5c9698f77c7d 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -97,35 +97,6 @@ static const struct can_transceiver_data tja1057_drvdata = {
.flags = CAN_TRANSCEIVER_SILENT_PRESENT,
};
-static const struct of_device_id can_transceiver_phy_ids[] = {
- {
- .compatible = "ti,tcan1042",
- .data = &tcan1042_drvdata
- },
- {
- .compatible = "ti,tcan1043",
- .data = &tcan1043_drvdata
- },
- {
- .compatible = "nxp,tja1048",
- .data = &tja1048_drvdata
- },
- {
- .compatible = "nxp,tja1051",
- .data = &tja1051_drvdata
- },
- {
- .compatible = "nxp,tja1057",
- .data = &tja1057_drvdata
- },
- {
- .compatible = "nxp,tjr1443",
- .data = &tcan1043_drvdata
- },
- { }
-};
-MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
-
static struct phy *can_transceiver_phy_xlate(struct device *dev,
const struct of_phandle_args *args)
{
@@ -232,6 +203,35 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(phy_provider);
}
+static const struct of_device_id can_transceiver_phy_ids[] = {
+ {
+ .compatible = "ti,tcan1042",
+ .data = &tcan1042_drvdata
+ },
+ {
+ .compatible = "ti,tcan1043",
+ .data = &tcan1043_drvdata
+ },
+ {
+ .compatible = "nxp,tja1048",
+ .data = &tja1048_drvdata
+ },
+ {
+ .compatible = "nxp,tja1051",
+ .data = &tja1051_drvdata
+ },
+ {
+ .compatible = "nxp,tja1057",
+ .data = &tja1057_drvdata
+ },
+ {
+ .compatible = "nxp,tjr1443",
+ .data = &tcan1043_drvdata
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
+
static struct platform_driver can_transceiver_phy_driver = {
.probe = can_transceiver_phy_probe,
.driver = {
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 1/6] phy: phy-can-transceiver: Check driver match and driver data against NULL
From: Andy Shevchenko @ 2026-05-13 22:01 UTC (permalink / raw)
To: Peng Fan, linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260513220336.369628-1-andriy.shevchenko@linux.intel.com>
Every platform driver can be forced to match a device that doesn't
match its list of device IDs because of device_match_driver_override()
so platform drivers that rely on the existence of a device's driver
data need to verify its presence.
Accordingly, add requisite match and driver data checks against NULL
to the driver where they are missing.
Fixes: a4a86d273ff1 ("phy: phy-can-transceiver: Add support for generic CAN transceiver driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 2b52e47f247a..1808f903c057 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -162,6 +162,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
int err, i, num_ch = 1;
match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
+ if (!match || !match->data)
+ return -ENODEV;
+
drvdata = match->data;
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
num_ch = 2;
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v4 2/5] phy: phy-can-transceiver: use device_get_match_data()
From: Andy Shevchenko @ 2026-05-13 21:51 UTC (permalink / raw)
To: sashiko-reviews; +Cc: vkoul, linux-phy, olteanv, neil.armstrong
In-Reply-To: <20260513212611.EDC78C19425@smtp.kernel.org>
On Wed, May 13, 2026 at 09:26:11PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The error check for `device_get_match_data(dev)` is inverted, causing the driver probe to fail on success and triggering a NULL pointer dereference on failure.
Right, the typo due to rebase. Will fix in v5.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 5/5] phy: phy-can-transceiver: Drop unused include
From: sashiko-bot @ 2026-05-13 21:44 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: vkoul, olteanv, neil.armstrong, linux-phy
In-Reply-To: <20260512130552.272476-6-andriy.shevchenko@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The probe function incorrectly aborts when match data is found and dereferences a NULL pointer when match data is absent.
--
commit 8e35724d73ac65aed30d62ac9342ff1ac6be9401
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
phy: phy-can-transceiver: Drop unused include
This commit removes the unused <linux/gpio.h> legacy header from the PHY CAN
transceiver driver, as its symbols are not used in the file. It also adjusts
the header order slightly.
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 973cc7ce651fb..534a4fc482aa8 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -5,12 +5,11 @@
> * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
> *
> */
> +#include <linux/gpio/consumer.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/property.h>
> #include <linux/module.h>
> -#include <linux/gpio.h>
> -#include <linux/gpio/consumer.h>
> #include <linux/mux/consumer.h>
>
> struct can_transceiver_data {
While reviewing this patch, I noticed an issue introduced earlier in the
series by commit "phy: phy-can-transceiver: use device_get_match_data()":
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
> @@ -161,11 +160,10 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> u32 max_bitrate = 0;
> int err, i, num_ch = 1;
>
> - match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> - if (!match || !match->data)
> + drvdata = device_get_match_data(dev);
> + if (drvdata)
> return -ENODEV;
>
> - drvdata = match->data;
> if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
> num_ch = 2;
Does this incorrectly abort the probe when match data is successfully found?
It looks like the condition is inverted, returning -ENODEV upon success.
Additionally, if match data is absent, drvdata will be NULL and execution
continues to the next line where it is dereferenced. Can this cause a NULL
pointer dereference?
Should the check be corrected to if (!drvdata)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512130552.272476-1-andriy.shevchenko@linux.intel.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 4/5] phy: phy-can-transceiver: Don't check for specific errors when parsing properties
From: sashiko-bot @ 2026-05-13 21:38 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: vkoul, olteanv, linux-phy, neil.armstrong
In-Reply-To: <20260512130552.272476-5-andriy.shevchenko@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The driver unconditionally fails or crashes due to incorrect checking of `drvdata`.
--
commit 64758b3de7d3ae700ae3ccdaef989d7410af4921
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
phy: phy-can-transceiver: Don't check for specific errors when parsing properties
This commit modifies the max-bitrate property parsing to check for the
property existence first before attempting to read it. It applies a default
value if the property is missing, rather than relying on specific error
codes.
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 23655956ace80..973cc7ce651fb 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -128,8 +128,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> struct gpio_desc *standby_gpio;
> struct gpio_desc *enable_gpio;
> struct mux_state *mux_state;
> - u32 max_bitrate = 0;
> int err, i, num_ch = 1;
> + const char *propname;
> + u32 max_bitrate;
>
> drvdata = device_get_match_data(dev);
> if (drvdata)
I noticed a potential issue in the context of this diff. Is the check for
drvdata inverted here? This logic appears to have been introduced by a
previous patch in the series.
If device_get_match_data() successfully finds match data, the probe function
aborts and returns -ENODEV. If no match data is found, drvdata is NULL and
the function proceeds, which leads to a dereference on the next check:
drvdata = device_get_match_data(dev);
if (drvdata)
return -ENODEV;
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
num_ch = 2;
Could this cause the driver to fail on valid probes, or dereference a NULL
pointer when match data is missing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512130552.272476-1-andriy.shevchenko@linux.intel.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 3/5] phy: phy-can-transceiver: Move OF ID table closer to their user
From: sashiko-bot @ 2026-05-13 21:31 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: neil.armstrong, vkoul, olteanv, linux-phy
In-Reply-To: <20260512130552.272476-4-andriy.shevchenko@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The check `if (drvdata)` incorrectly returns `-ENODEV` when match data is found, and leads to a NULL pointer dereference when match data is missing.
--
commit e6497a416a7e21916ac93bad3296c090e87a31d4
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
phy: phy-can-transceiver: Move OF ID table closer to their user
This commit moves the can_transceiver_phy_ids table closer to its
user at the end of the file.
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 5cfd097352048..23655956ace80 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
This regression wasn't introduced by this patch, but by a previous
commit in the series ("phy: phy-can-transceiver: use
device_get_match_data()").
Looking at can_transceiver_phy_probe(), does this code correctly handle the
match data?
drivers/phy/phy-can-transceiver.c:can_transceiver_phy_probe() {
...
drvdata = device_get_match_data(dev);
if (drvdata)
return -ENODEV;
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
...
}
It appears that if match data is successfully found, the probe will return
-ENODEV.
Conversely, if no match data is found, the condition evaluates to false,
and execution proceeds to dereference the NULL drvdata pointer.
Should the condition be changed to check for !drvdata instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512130552.272476-1-andriy.shevchenko@linux.intel.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/5] phy: phy-can-transceiver: use device_get_match_data()
From: sashiko-bot @ 2026-05-13 21:26 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: vkoul, linux-phy, olteanv, neil.armstrong
In-Reply-To: <20260512130552.272476-3-andriy.shevchenko@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The error check for `device_get_match_data(dev)` is inverted, causing the driver probe to fail on success and triggering a NULL pointer dereference on failure.
--
commit f9915d9d74989682b2b7e20d67129e0dd4abdab9
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
phy: phy-can-transceiver: use device_get_match_data()
This commit transitions the driver to use the generic firmware node interface
for retrieving device match data instead of the OF-specific one. It also drops
the unneeded device node argument from devm_phy_create().
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 1808f903c0570..5cfd097352048 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
> @@ -152,7 +152,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> struct can_transceiver_phy *can_transceiver_phy;
> struct can_transceiver_priv *priv;
> const struct can_transceiver_data *drvdata;
> - const struct of_device_id *match;
> struct phy *phy;
> struct gpio_desc *silent_gpio;
> struct gpio_desc *standby_gpio;
> @@ -161,11 +160,10 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> u32 max_bitrate = 0;
> int err, i, num_ch = 1;
>
> - match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> - if (!match || !match->data)
> + drvdata = device_get_match_data(dev);
> + if (drvdata)
> return -ENODEV;
Does this invert the error check?
When device_get_match_data() successfully returns valid match data, it looks
like this condition will evaluate to true and erroneously abort the probe with
-ENODEV.
>
> - drvdata = match->data;
> if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
> num_ch = 2;
Conversely, if device_get_match_data() fails and returns NULL, won't the
probe continue and cause a NULL pointer dereference when evaluating
drvdata->flags here?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512130552.272476-1-andriy.shevchenko@linux.intel.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: fsl-imx8mq-usb: add control register regmap
From: sashiko-bot @ 2026-05-13 20:36 UTC (permalink / raw)
To: Xu Yang; +Cc: linux-phy, vkoul, Frank.Li, neil.armstrong, imx, olteanv
In-Reply-To: <20260512101212.1498223-1-xu.yang_2@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Exporting the CR port regmap via debugfs without clock synchronization allows unclocked MMIO accesses, leading to a synchronous external abort (kernel panic).
- [Medium] Using a direct MMIO regmap for an indirect data/address parallel port does not correctly expose the internal PHY registers, defeating the diagnostic purpose of the patch.
--
commit ac06b61c8f793ff4f5693b009fbad15e95d82242
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: add control register regmap
The CR port is a simple 16-bit data/address parallel port that is
provided for on-chip access to the control registers inside the
USB 3.0 femtoPHY. Add control register regmap and export these
registers by debugfs to help PHY's diagnostic.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index b05d80e849a14..958d114b0c835 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -685,6 +689,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
>
> +static const struct regmap_config imx_cr_regmap_config = {
> + .name = "cr",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x7,
> +};
> +
> static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> {
> struct phy_provider *phy_provider;
> @@ -713,6 +725,11 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> + &imx_cr_regmap_config);
Will accessing the debugfs file when the PHY is suspended or not yet powered
on cause a kernel panic?
The driver dynamically manages its clocks (imx_phy->clk and imx_phy->alt_clk)
in imx8mq_phy_power_on() and imx8mq_phy_power_off() rather than using
pm_runtime.
Since devm_regmap_init_mmio() does not attach a clock to the regmap,
the regmap core won't enable clocks during debugfs register accesses. On
i.MX platforms, MMIO reads on an unclocked hardware block trigger a
synchronous external abort.
Could we delegate clock management to the regmap (e.g., by using
devm_regmap_init_mmio_clk()) or implement pm_runtime hooks?
Additionally, the commit message mentions the CR port is a 16-bit
data/address parallel port used to access internal PHY registers. Does
this direct MMIO regmap actually expose the internal PHY registers?
Since devm_regmap_init_mmio() creates a direct memory-mapped regmap over
the CR port's base MMIO registers, reading the debugfs file will simply
dump the CR port's Address and Data MMIO registers. It won't execute the
required address/data handshake protocol to read the internal PHY state,
which defeats the diagnostic purpose of the patch.
Would it be better to implement a custom regmap_bus to handle the atomic
address/data indirect read sequence?
Also, is max_register = 0x7 correct here? It seems misleading for a 32-bit
regmap with a stride of 4 if there are only a couple of MMIO registers.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512101212.1498223-1-xu.yang_2@nxp.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: sashiko-bot @ 2026-05-13 20:28 UTC (permalink / raw)
To: Xu Yang; +Cc: olteanv, vkoul, Frank.Li, imx, neil.armstrong, linux-phy
In-Reply-To: <20260512101046.1498096-1-xu.yang_2@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Missing error handling in the probe function leads to a Type-C switch leak and a critical Use-After-Free.
- [High] Using device_set_wakeup_capable() fails to enable wakeup by default, causing the PHY power domain to still be powered down during suspend.
- [High] Failing to enable the clocks in imx8mq_phy_power_on() leaves the vbus regulator permanently enabled.
--
commit c0b045ff9746b6affbecc02df5970fc02bc6a3ed
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
The patch intends to keep the PHY power domain active during suspend
by setting the PHY to be wakeup capable.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index b05d80e849a14..b2e1e3749fc19 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -733,6 +733,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> "failed to get tca\n");
>
> imx8m_get_phy_tuning_data(imx_phy);
> + device_set_wakeup_capable(dev, true);
Will this successfully enable wakeup by default?
The PM domain framework (genpd) checks genpd_is_active_wakeup(genpd) and
device_awake_path(dev) (which depends on device_may_wakeup(dev)) to determine
if the domain should remain powered on.
device_may_wakeup(dev) evaluates to dev->power.can_wakeup &&
dev->power.should_wakeup. While device_set_wakeup_capable(dev, true) sets
can_wakeup = true, it leaves should_wakeup = false. As a result,
device_may_wakeup() returns false by default, and genpd will still power off
the PHY domain.
Should this use device_init_wakeup(dev, true) to enable it by default,
or should the USB subsystem dynamically propagate the controller's wakeup state
to the PHY instead?
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
This isn't a bug introduced by this patch, but does this code leave a Type-C
switch registered if devm_of_phy_provider_register() fails?
If devm_of_phy_provider_register() returns an error, the probe function exits
without unregistering the Type-C switch (e.g., via imx95_usb_phy_put_tca()).
The imx_phy structure allocated with devm_kzalloc() would then be freed by the
driver core, but the switch remains active.
If the Type-C subsystem triggers the switch's set callback
(tca_blk_typec_switch_set()), it will access the freed imx_phy,
potentially resulting in a use-after-free.
>
> return PTR_ERR_OR_ZERO(phy_provider);
> }
This isn't a bug introduced by this patch, but does imx8mq_phy_power_on() leak
a regulator reference on error paths?
Looking at imx8mq_phy_power_on():
drivers/phy/freescale/phy-fsl-imx8mq-usb.c:imx8mq_phy_power_on() {
...
ret = regulator_enable(imx_phy->vbus);
if (ret)
return ret;
ret = clk_prepare_enable(imx_phy->clk);
if (ret)
return ret;
...
}
If clk_prepare_enable(imx_phy->clk) or clk_prepare_enable(imx_phy->alt_clk)
fails, the function returns directly without calling
regulator_disable(imx_phy->vbus).
Since the function returns an error, the PHY framework will not call
imx8mq_phy_power_off(). Could this leave the vbus regulator permanently
enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512101046.1498096-1-xu.yang_2@nxp.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
From: Krzysztof Kozlowski @ 2026-05-13 18:56 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,
Dmitry Baryshkov, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <d52c5039-9431-44ed-9f3b-bb00d03ae176@oss.qualcomm.com>
On 07/05/2026 13:37, Krishna Kurapati wrote:
>
>
> On 5/5/2026 7:30 PM, Krzysztof Kozlowski wrote:
>> On 05/05/2026 15:57, Krishna Kurapati wrote:
>>>
>>>
>>> On 5/5/2026 6:59 PM, Krzysztof Kozlowski wrote:
>>>> On 05/05/2026 15:27, Krishna Kurapati wrote:
>>>>>
>>>>>
>>>>> On 5/5/2026 4:22 PM, Krzysztof Kozlowski wrote:
>>>>>> On 05/05/2026 12:49, Krzysztof Kozlowski wrote:
>>>>>>> On Mon, May 04, 2026 at 10:36:57PM +0530, Krishna Kurapati wrote:
>>>>>>>> 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(+)
>>>>>>>
>>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>>
>>>>>> ... and then I looked at the driver. So un-reviewed. Devices are clearly
>>>>>> compatible. If not, explain what is not compatible.
>>>>>>
>>>>> Talos uses GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>
>>>>> In Shikra, we are using GCC_USB3_PRIM_PHY_COM_AUX_CLK. We don't have
>>>>> GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>
>>>>> Hence, I didn't use a fallback compatible.
>>>>
>>>> This still explains nothing. How different clock makes interface for SW
>>>> incompatible exactly?
>>>>
>>> So I went by the naming. AUX vs COM_AUX.
>>
>> The naming does not matter. If the clock is called
>> "no_one_expects_spanish_inquisition", does that make software
>> incompatible? Why would the name itself matter?
>>
>>>
>>> Can I use a fallback compatible and in DT vote for "COM_AUX" clock with
>>> clock-names mentioning "aux" ?
>>
>> I don't know, I asked what is different in software interface.
>>
>
> Hi Krzysztof,
>
> I checked with the hw team here and found out two things.
>
> 1. Shikra is a spinoff of Agatti and its sw interface (clocks used and
> regulators used) is the same as agatti.
>
> 2. I thought we could use qcm2290 as a fallback since the phy register
> init sequence is the same for Talos/Shikra/Agatti. The difference
> between Talos and agatti when checked in the driver was the init load
> settings. I checked with the hw team and they suggested using the init
> load settings which talos was using.
>
> Hence both these compatibles (qcm2290 and qcs615) cannot be used as
> fallback for Shikra.
Then I do not understand why you are using qcs615_usb3phy_cfg for
Shikra. You say that the initialization is different, but you use
exactly the same initialization. So in a meaning of compatibility
between hardware for Devicetree they are compatible.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH phy-next 2/2] phy: ti: add PHY driver for TI DS125DF111 Dual-Channel Retimer
From: Ioana Ciornei @ 2026-05-13 18:51 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
Cc: devicetree, linux-kernel
In-Reply-To: <20260513185103.1371809-1-ioana.ciornei@nxp.com>
Add a generic PHY driver for the TI DS125DF111 Multi-Protocol
Dual-Channel Retimer. The driver currently supports only 10G and 1G link
speeds but it can easily extended to also cover other usecases.
Since the available datasheet (https://www.ti.com/lit/gpn/DS125DF111)
does not name the registers, the name for the macros were determined by
their usage pattern.
A PHY device is created for each of the two channels present on the
retimer. This allows for independent configuration of the two channels.
This capability is especially important on retimers which have more than
2 channels that can be, depending on the board design, connected in
multiple different ways to the SerDes lanes.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/phy/ti/Kconfig | 10 ++
drivers/phy/ti/Makefile | 1 +
drivers/phy/ti/phy-ds125df111.c | 245 ++++++++++++++++++++++++++++++++
3 files changed, 256 insertions(+)
create mode 100644 drivers/phy/ti/phy-ds125df111.c
diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig
index b40f28019131..475e80fcd52d 100644
--- a/drivers/phy/ti/Kconfig
+++ b/drivers/phy/ti/Kconfig
@@ -111,3 +111,13 @@ config PHY_TI_GMII_SEL
help
This driver supports configuring of the TI CPSW Port mode depending on
the Ethernet PHY connected to the CPSW Port.
+
+config PHY_TI_DS125DF111
+ tristate "DS125DF111 2-Channel Retimer Driver"
+ depends on OF && I2C
+ select GENERIC_PHY
+ help
+ Enable this to add support for configuration and runtime management
+ of the TI DS125DF111 Multi-Protocol 2-Channel Retimer.
+ The retimer is modeled as a Generic PHY and supports both 10G and 1G
+ link speeds.
diff --git a/drivers/phy/ti/Makefile b/drivers/phy/ti/Makefile
index dcba2571c9bd..e68445ddd848 100644
--- a/drivers/phy/ti/Makefile
+++ b/drivers/phy/ti/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_PHY_AM654_SERDES) += phy-am654-serdes.o
obj-$(CONFIG_PHY_TI_GMII_SEL) += phy-gmii-sel.o
obj-$(CONFIG_PHY_J721E_WIZ) += phy-j721e-wiz.o
+obj-$(CONFIG_PHY_TI_DS125DF111) += phy-ds125df111.o
diff --git a/drivers/phy/ti/phy-ds125df111.c b/drivers/phy/ti/phy-ds125df111.c
new file mode 100644
index 000000000000..8ac10c603bf7
--- /dev/null
+++ b/drivers/phy/ti/phy-ds125df111.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2026 NXP */
+
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/phy/phy.h>
+
+#define DS125DF111_NUM_CH 2
+#define DS125DF111_NUM_VCO_GROUP_REG 5
+
+#define DS125DF111_CH_SELECT 0xff
+#define DS125DF111_CH_SELECT_TARGET_MASK GENMASK(3, 0)
+#define DS125DF111_CH_SELECT_EN BIT(2)
+
+#define DS125DF111_CH_CTRL 0x00
+#define DS125DF111_CH_CTRL_RESET BIT(2) /* self clearing */
+
+#define DS125DF111_VCO_GROUP_BASE 0x60
+
+#define DS125DF111_RATIOS 0x2F
+#define DS125DF111_RATIOS_RATE_MASK GENMASK(7, 6)
+#define DS125DF111_RATIOS_SUBRATE_MASK GENMASK(5, 4)
+
+struct ds125df111_ch {
+ struct phy *phy;
+ struct ds125df111_priv *priv;
+ int idx;
+};
+
+struct ds125df111_priv {
+ struct ds125df111_ch ch[DS125DF111_NUM_CH];
+ struct i2c_client *client;
+ struct mutex mutex; /* protects access to shared registers */
+};
+
+enum ds125df111_mode {
+ FREQ_1G,
+ FREQ_10G,
+};
+
+static const struct ds125df111_config {
+ u8 vco_group[DS125DF111_NUM_VCO_GROUP_REG];
+ u8 rate;
+ u8 subrate;
+} ds125df111_cfg[] = {
+ [FREQ_1G] = {
+ /* VCO group #0 = 10GHz, VCO group #1 = 10GHz */
+ .vco_group = {0x00, 0xB2, 0x00, 0xB2, 0xCC},
+ /* By using the following combination of rate and subrate we
+ * select divide ratios of 1, 2, 4, 8 on both groups
+ */
+ .rate = 0x1,
+ .subrate = 0x2,
+ },
+
+ [FREQ_10G] = {
+ /* VCO group #0 = 10.3125GHz, VCO group #1 = 10.3125GHz */
+ .vco_group = {0x90, 0xB3, 0x90, 0xB3, 0xCD},
+ /* By using the following combination of rate and subrate we
+ * select divide ratios of 1 on both groups
+ */
+ .rate = 0x1,
+ .subrate = 0x3,
+ },
+};
+
+static int ds125df111_configure(struct phy *phy,
+ const struct ds125df111_config *cfg)
+{
+ struct ds125df111_ch *ch = phy_get_drvdata(phy);
+ struct ds125df111_priv *priv = ch->priv;
+ struct i2c_client *i2c = priv->client;
+ struct device *dev = &phy->dev;
+ u8 val;
+ int err, i;
+
+ mutex_lock(&priv->mutex);
+
+ /* Make sure that any subsequent read/write operation will be directed
+ * only to the registers of the selected channel
+ */
+ err = i2c_smbus_read_byte_data(i2c, DS125DF111_CH_SELECT);
+ if (err < 0) {
+ dev_err(dev, "Unable to select channel\n");
+ goto out;
+ }
+ val = (u8)err;
+ val &= ~DS125DF111_CH_SELECT_TARGET_MASK;
+ val |= DS125DF111_CH_SELECT_EN | ch->idx;
+ err = i2c_smbus_write_byte_data(i2c, DS125DF111_CH_SELECT, val);
+ if (err < 0) {
+ dev_err(dev, "Unable to select channel\n");
+ goto out;
+ }
+
+ /* Reset Channel Registers */
+ err = i2c_smbus_read_byte_data(i2c, DS125DF111_CH_CTRL);
+ if (err < 0) {
+ dev_err(dev, "Error resetting channel configuration\n");
+ goto out;
+ }
+ val = (u8)err;
+ val |= DS125DF111_CH_CTRL_RESET;
+ err = i2c_smbus_write_byte_data(i2c, DS125DF111_CH_CTRL, val);
+ if (err < 0) {
+ dev_err(dev, "Error resetting channel configuration\n");
+ goto out;
+ }
+
+ /* Program the VCO group frequencies */
+ for (i = 0; i < DS125DF111_NUM_VCO_GROUP_REG; i++) {
+ err = i2c_smbus_write_byte_data(i2c,
+ DS125DF111_VCO_GROUP_BASE + i,
+ cfg->vco_group[i]);
+ if (err < 0) {
+ dev_err(dev, "Error programming VCO group frequencies\n");
+ goto out;
+ }
+ }
+
+ /* Set the Divide Ratios for the VCO Groups*/
+ err = i2c_smbus_read_byte_data(i2c, DS125DF111_RATIOS);
+ if (err < 0) {
+ dev_err(dev, "Error programming the divide ratios\n");
+ goto out;
+ }
+ val = (u8)err;
+ val &= ~(DS125DF111_RATIOS_RATE_MASK | DS125DF111_RATIOS_SUBRATE_MASK);
+ val |= FIELD_PREP(DS125DF111_RATIOS_RATE_MASK, cfg->rate) |
+ FIELD_PREP(DS125DF111_RATIOS_SUBRATE_MASK, cfg->subrate);
+ err = i2c_smbus_write_byte_data(i2c, DS125DF111_RATIOS, val);
+ if (err < 0) {
+ dev_err(dev, "Error programming the divide ratios\n");
+ goto out;
+ }
+
+ mutex_unlock(&priv->mutex);
+
+ return 0;
+
+out:
+ mutex_unlock(&priv->mutex);
+
+ return err;
+}
+
+static int ds125df111_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+ const struct ds125df111_config *cfg;
+
+ if (mode != PHY_MODE_ETHERNET)
+ return -EOPNOTSUPP;
+
+ switch (submode) {
+ case PHY_INTERFACE_MODE_10GBASER:
+ cfg = &ds125df111_cfg[FREQ_10G];
+ break;
+ case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_SGMII:
+ cfg = &ds125df111_cfg[FREQ_1G];
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return ds125df111_configure(phy, cfg);
+}
+
+static const struct phy_ops ds125df111_ops = {
+ .set_mode = ds125df111_set_mode,
+ .owner = THIS_MODULE,
+};
+
+static struct phy *ds125df111_xlate(struct device *dev,
+ const struct of_phandle_args *args)
+{
+ struct ds125df111_priv *priv = dev_get_drvdata(dev);
+ u32 idx = args->args[0];
+
+ if (idx >= DS125DF111_NUM_CH) {
+ dev_err(dev, "Maximum number of channels is %d\n",
+ DS125DF111_NUM_CH);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return priv->ch[idx].phy;
+}
+
+static int ds125df111_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct phy_provider *provider;
+ struct ds125df111_priv *priv;
+ int i, err;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->client = client;
+ err = devm_mutex_init(dev, &priv->mutex);
+ if (err)
+ return err;
+
+ i2c_set_clientdata(client, priv);
+
+ for (i = 0; i < DS125DF111_NUM_CH; i++) {
+ struct ds125df111_ch *ch = &priv->ch[i];
+ struct phy *phy;
+
+ phy = devm_phy_create(dev, NULL, &ds125df111_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ ch->idx = i;
+ ch->priv = priv;
+ ch->phy = phy;
+
+ phy_set_drvdata(phy, ch);
+ }
+
+ provider = devm_of_phy_provider_register(dev, ds125df111_xlate);
+
+ return PTR_ERR_OR_ZERO(provider);
+}
+
+static const struct of_device_id ds125df111_dt_ids[] = {
+ { .compatible = "ti,ds125df111", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ds125df111_dt_ids);
+
+static struct i2c_driver ds125df111_driver = {
+ .driver = {
+ .name = "ds125df111",
+ .of_match_table = ds125df111_dt_ids,
+ },
+ .probe = ds125df111_probe,
+};
+module_i2c_driver(ds125df111_driver);
+
+MODULE_AUTHOR("Ioana Ciornei <ioana.ciornei@nxp.com>");
+MODULE_DESCRIPTION("TI DS125DF111 Retimer driver");
+MODULE_LICENSE("GPL");
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH phy-next 1/2] dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
From: Ioana Ciornei @ 2026-05-13 18:51 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
Cc: devicetree, linux-kernel
In-Reply-To: <20260513185103.1371809-1-ioana.ciornei@nxp.com>
Add device tree binding for the TI DS125DF111 Retimer PHY.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
.../bindings/phy/ti,ds125df111.yaml | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml b/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
new file mode 100644
index 000000000000..47e9ba2a8990
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,ds125df111.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DS125DF111 Retimer PHY
+
+description:
+ This binding describes the TI DS125DF111 multi-protocol Retimer PHY.
+
+maintainers:
+ - Ioana Ciornei <ioana.ciornei@nxp.com>
+
+properties:
+ compatible:
+ const: ti,ds125df111
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+ description: |
+ The phandle's argument in the PHY specifier selects one of the two
+ channels of the retimer
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ti_retimer: retimer@18 {
+ compatible = "ti,ds125df111";
+ reg = <0x18>;
+ #phy-cells = <1>;
+ };
+ };
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH phy-next 0/2] phy: ti: add driver for TI DS125DF111 Dual-Channel Retimer
From: Ioana Ciornei @ 2026-05-13 18:51 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
Cc: devicetree, linux-kernel
This patch set adds a generic PHY driver and the corresponding DT
binding for the TI DS125DF111 Dual-Channel retimer. The datasheet on
which this driver was based on can be found at -
https://www.ti.com/lit/gpn/DS125DF111.
A separate generic PHY is registered for each of the two channels of the
retimer, so consumers can drive each channel independently. This allows
for independent control of the channels, which is especially important
since each channel can be routed to different SerDes lanes and it is not
guaranteed that the same retimer will do both directions of SerDes lane.
This was tested on a LS1088ARDB board with the Lynx10G SerDes PHY driver
yet to be submitted.
Ioana Ciornei (2):
dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
phy: ti: add PHY driver for TI DS125DF111 Dual-Channel Retimer
.../bindings/phy/ti,ds125df111.yaml | 46 ++++
drivers/phy/ti/Kconfig | 10 +
drivers/phy/ti/Makefile | 1 +
drivers/phy/ti/phy-ds125df111.c | 245 ++++++++++++++++++
4 files changed, 302 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
create mode 100644 drivers/phy/ti/phy-ds125df111.c
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v9 5/5] phy: qualcomm: add MSM8974 HDMI PHY support
From: Dmitry Baryshkov @ 2026-05-13 18:14 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260513-fd-hdmi-phy-v9-0-ca98c72f1f9f@oss.qualcomm.com>
Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 282 +++++++++++++++++++++++++++++
1 file changed, 282 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
index 720757f8f393..7d398060b3a3 100644
--- a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
@@ -6,10 +6,13 @@
* Author: Rob Clark <robdclark@gmail.com>
*/
+#include <linux/bitfield.h>
#include <linux/delay.h>
#include <linux/iopoll.h>
+#include <linux/math64.h>
#include "phy-qcom-hdmi-preqmp.h"
+#include "phy-qcom-uniphy.h"
#define REG_HDMI_8x74_ANA_CFG0 0x00000000
#define REG_HDMI_8x74_ANA_CFG1 0x00000004
@@ -31,8 +34,282 @@
#define REG_HDMI_8x74_BIST_PATN3 0x00000048
#define REG_HDMI_8x74_STATUS 0x0000005c
+#define HDMI_8974_VCO_MAX_FREQ 1800000000UL
+#define HDMI_8974_VCO_MIN_FREQ 600000000UL
+
+#define HDMI_8974_COMMON_DIV 5
+
+static inline void write16(u16 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel(val >> 8, reg + 4);
+}
+
+static inline void write24(u32 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel((val >> 8) & 0xff, reg + 4);
+ writel(val >> 16, reg + 8);
+}
+
+static inline u32 read24(void __iomem *reg)
+{
+ u32 val = readl(reg);
+
+ val |= readl(reg + 4) << 8;
+ val |= readl(reg + 8) << 16;
+
+ return val;
+}
+
+static void qcom_uniphy_setup(void __iomem *base, unsigned int ref_freq,
+ bool sdm_mode,
+ bool ref_freq_mult_2,
+ bool dither,
+ unsigned int refclk_div,
+ unsigned int vco_freq)
+{
+ unsigned int int_ref_freq = ref_freq * (ref_freq_mult_2 ? 2 : 1);
+ unsigned int div_in_freq = vco_freq / refclk_div;
+ unsigned int dc_offset = div_in_freq / int_ref_freq - 1;
+ unsigned int sdm_freq_seed;
+ unsigned int val;
+ u64 tmp = div_in_freq % int_ref_freq;
+
+ tmp *= 0x10000;
+ sdm_freq_seed = div_u64(tmp, int_ref_freq);
+
+ val = FIELD_PREP(UNIPHY_PLL_REFCLK_DBLR, ref_freq_mult_2) |
+ FIELD_PREP(UNIPHY_PLL_REFCLK_DIV, refclk_div - 1);
+ writel(val, base + UNIPHY_PLL_REFCLK_CFG);
+
+ if (sdm_mode) {
+ writel(0, base + UNIPHY_PLL_SDM_CFG0);
+ writel(FIELD_PREP(UNIPHY_PLL_SDM_DITHER_EN, dither) | dc_offset,
+ base + UNIPHY_PLL_SDM_CFG1);
+ write24(sdm_freq_seed, base + UNIPHY_PLL_SDM_CFG2);
+ } else {
+ writel(UNIPHY_PLL_SDM_BYP | dc_offset, base + UNIPHY_PLL_SDM_CFG0);
+ writel(0, base + UNIPHY_PLL_SDM_CFG1);
+ write24(0, base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ write16(mult_frac(ref_freq, 5, 1000000), base + UNIPHY_PLL_CAL_CFG8);
+ write16(vco_freq / 16, base + UNIPHY_PLL_CAL_CFG10);
+}
+
+static unsigned long qcom_uniphy_recalc(void __iomem *base, unsigned long parent_rate)
+{
+ unsigned long rate;
+ u32 refclk_cfg;
+ u32 dc_offset;
+ u64 fraq_n;
+ u32 val;
+
+ refclk_cfg = readl(base + UNIPHY_PLL_REFCLK_CFG);
+ if (refclk_cfg & UNIPHY_PLL_REFCLK_DBLR)
+ parent_rate *= 2;
+
+ val = readl(base + UNIPHY_PLL_SDM_CFG0);
+ if (FIELD_GET(UNIPHY_PLL_SDM_BYP, val)) {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_BYP_DIV, val);
+ fraq_n = 0;
+ } else {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_DC_OFFSET,
+ readl(base + UNIPHY_PLL_SDM_CFG1));
+ fraq_n = read24(base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ rate = (dc_offset + 1) * parent_rate;
+ rate += div_u64(fraq_n * parent_rate, 0x10000);
+
+ rate *= FIELD_GET(UNIPHY_PLL_REFCLK_DIV, refclk_cfg) + 1;
+
+ return rate;
+}
+
+static const unsigned int qcom_hdmi_8974_divs[] = {1, 2, 4, 6};
+
+static unsigned long qcom_hdmi_8974_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct qcom_hdmi_preqmp_phy *hdmi_phy = hw_clk_to_phy(hw);
+ u32 div_idx = readl(hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+ unsigned long rate = qcom_uniphy_recalc(hdmi_phy->pll_reg, parent_rate);
+
+ return rate / HDMI_8974_COMMON_DIV / qcom_hdmi_8974_divs[div_idx & 0x3];
+}
+
+static int qcom_hdmi_8974_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ unsigned long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ unsigned long max_freq = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
+
+ req->rate = clamp(req->rate, min_freq / 6, max_freq);
+
+ return 0;
+}
+
+static const struct clk_ops qcom_hdmi_8974_pll_ops = {
+ .recalc_rate = qcom_hdmi_8974_pll_recalc_rate,
+ .determine_rate = qcom_hdmi_8974_pll_determine_rate,
+};
+
+static int qcom_hdmi_msm8974_phy_find_div(unsigned long long pixclk)
+{
+ unsigned long long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ int i;
+
+ if (pixclk > HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(qcom_hdmi_8974_divs); i++) {
+ if (pixclk >= min_freq / qcom_hdmi_8974_divs[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_set_rate(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ unsigned long long pixclk = hdmi_phy->hdmi_opts.tmds_char_rate;
+ unsigned long vco_rate;
+ unsigned int div;
+ int div_idx = 0;
+
+ div_idx = qcom_hdmi_msm8974_phy_find_div(pixclk);
+ if (WARN_ON(div_idx < 0))
+ return div_idx;
+
+ div = qcom_hdmi_8974_divs[div_idx];
+ vco_rate = pixclk * HDMI_8974_COMMON_DIV * div;
+
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ writel(0x19, hdmi_phy->pll_reg + UNIPHY_PLL_VCOLPF_CFG);
+ writel(0x0e, hdmi_phy->pll_reg + UNIPHY_PLL_LPFR_CFG);
+ writel(0x20, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC1_CFG);
+ writel(0x0d, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC2_CFG);
+
+ qcom_uniphy_setup(hdmi_phy->pll_reg, 19200000, true, true, true, 1, vco_rate);
+
+ writel(0x10, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG0);
+ writel(0x1a, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG1);
+ writel(0x05, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG2);
+
+ writel(div_idx, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV2_CFG);
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV3_CFG);
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_CAL_CFG2);
+
+ writel(0x1f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(50);
+
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL1);
+ writel(0x10, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0xdb, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
+ writel(0x43, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
+ if (pixclk == 297000000) {
+ writel(0x06, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x03, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else if (pixclk == 268500000) {
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else {
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ }
+
+ writel(0x04, hdmi_phy->pll_reg + UNIPHY_PLL_VREG_CFG);
+
+ writel(0xd0, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG0);
+ writel(0x1a, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG1);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG0);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG1);
+
+ if (pixclk == 268500000)
+ writel(0x11, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+ else
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG3);
+ udelay(200);
+
+ return 0;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_enable(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ int ret;
+ unsigned long status;
+
+ /* Global enable */
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ /* Power up power gen */
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+
+ /* Power up PLL LDO */
+ writel(0x03, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* Poll for PLL ready status */
+ ret = readl_poll_timeout(hdmi_phy->pll_reg + UNIPHY_PLL_STATUS,
+ status, status & UNIPHY_PLL_LOCK,
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PLL not ready\n");
+ goto err;
+ }
+
+ udelay(350);
+
+ /* Poll for PHY ready status */
+ ret = readl_poll_timeout(hdmi_phy->phy_reg + REG_HDMI_8x74_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PHY not ready\n");
+ goto err;
+ }
+
+ return 0;
+
+err:
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ return ret;
+}
+
static int qcom_hdmi_msm8974_phy_power_on(struct qcom_hdmi_preqmp_phy *hdmi_phy)
{
+ int ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_set_rate(hdmi_phy);
+ if (ret)
+ return ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_enable(hdmi_phy);
+ if (ret)
+ return ret;
+
writel(0x1b, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
writel(0xf2, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_CFG0);
@@ -49,6 +326,10 @@ static int qcom_hdmi_msm8974_phy_power_off(struct qcom_hdmi_preqmp_phy *hdmi_phy
{
writel(0x7f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
return 0;
}
@@ -67,5 +348,6 @@ const struct qcom_hdmi_preqmp_cfg msm8974_hdmi_phy_cfg = {
.power_on = qcom_hdmi_msm8974_phy_power_on,
.power_off = qcom_hdmi_msm8974_phy_power_off,
+ .pll_ops = &qcom_hdmi_8974_pll_ops,
.pll_parent = &msm8974_hdmi_pll_parent,
};
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v9 4/5] phy: qcom-uniphy: add more registers from display PHYs
From: Dmitry Baryshkov @ 2026-05-13 18:14 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260513-fd-hdmi-phy-v9-0-ca98c72f1f9f@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 43 ++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
index 5f18f9593cda..e02bcc5e8150 100644
--- a/drivers/phy/qualcomm/phy-qcom-uniphy.h
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -8,10 +8,30 @@
/* PHY registers */
#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_REFCLK_DBLR BIT(0)
+#define UNIPHY_PLL_REFCLK_DIV GENMASK(3, 2)
+
+#define UNIPHY_PLL_POSTDIV1_CFG 0x004
+#define UNIPHY_PLL_CHGPUMP_CFG 0x008
+#define UNIPHY_PLL_VCOLPF_CFG 0x00c
+#define UNIPHY_PLL_VREG_CFG 0x010
#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_DMUX_CFG 0x018
+#define UNIPHY_PLL_AMUX_CFG 0x01c
#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_POSTDIV2_CFG 0x024
+#define UNIPHY_PLL_POSTDIV3_CFG 0x028
+#define UNIPHY_PLL_LPFR_CFG 0x02c
+#define UNIPHY_PLL_LPFC1_CFG 0x030
+#define UNIPHY_PLL_LPFC2_CFG 0x034
#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_BYP BIT(6)
+#define UNIPHY_PLL_SDM_BYP_DIV GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_DITHER_EN BIT(6)
+#define UNIPHY_PLL_SDM_DC_OFFSET GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG2 0x040
#define UNIPHY_PLL_SDM_CFG3 0x044
#define UNIPHY_PLL_SDM_CFG4 0x048
@@ -22,12 +42,35 @@
#define UNIPHY_PLL_LKDET_CFG0 0x05c
#define UNIPHY_PLL_LKDET_CFG1 0x060
#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_TEST_CFG 0x068
#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG1 0x070
+#define UNIPHY_PLL_CAL_CFG2 0x074
+#define UNIPHY_PLL_CAL_CFG3 0x078
+#define UNIPHY_PLL_CAL_CFG4 0x07c
+#define UNIPHY_PLL_CAL_CFG5 0x080
+#define UNIPHY_PLL_CAL_CFG6 0x084
+#define UNIPHY_PLL_CAL_CFG7 0x088
#define UNIPHY_PLL_CAL_CFG8 0x08c
#define UNIPHY_PLL_CAL_CFG9 0x090
#define UNIPHY_PLL_CAL_CFG10 0x094
#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_EFUSE_CFG 0x09c
+#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0
+#define UNIPHY_PLL_CTRL_42 0x0a4
+#define UNIPHY_PLL_CTRL_43 0x0a8
+#define UNIPHY_PLL_CTRL_44 0x0ac
+#define UNIPHY_PLL_CTRL_45 0x0b0
+#define UNIPHY_PLL_CTRL_46 0x0b4
+#define UNIPHY_PLL_CTRL_47 0x0b8
+#define UNIPHY_PLL_CTRL_48 0x0bc
#define UNIPHY_PLL_STATUS 0x0c0
#define UNIPHY_PLL_LOCK BIT(0)
+#define UNIPHY_PLL_DEBUG_BUS0 0x0c4
+#define UNIPHY_PLL_DEBUG_BUS1 0x0c8
+#define UNIPHY_PLL_DEBUG_BUS2 0x0cc
+#define UNIPHY_PLL_DEBUG_BUS3 0x0d0
+#define UNIPHY_PLL_CTRL_54 0x0d4
+
#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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