Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1 4/4] phy: phy-can-transceiver: Drop unused include
From: Andy Shevchenko @ 2026-02-19 20:26 UTC (permalink / raw)
  To: linux-can, linux-phy, linux-kernel
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	Andy Shevchenko
In-Reply-To: <20260219202910.2304440-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.

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 ebce48ef217f..ba40bad4ccb1 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 v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Andy Shevchenko @ 2026-02-19 20:26 UTC (permalink / raw)
  To: linux-can, linux-phy, linux-kernel
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	Andy Shevchenko
In-Reply-To: <20260219202910.2304440-1-andriy.shevchenko@linux.intel.com>

It seems the driver is half-moved to use device property APIs.
Finish that by converting everything to use that.

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 330356706ad7..f2259af4af8a 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>
@@ -130,7 +130,7 @@ MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
 static inline struct mux_state *
 devm_mux_state_get_optional(struct device *dev, const char *mux_name)
 {
-	if (!of_property_present(dev->of_node, "mux-states"))
+	if (!device_property_present(dev, "mux-states"))
 		return NULL;
 
 	return devm_mux_state_get(dev, mux_name);
@@ -162,7 +162,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;
@@ -171,8 +170,7 @@ 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);
-	drvdata = match->data;
+	drvdata = device_get_match_data(dev);
 	if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
 		num_ch = 2;
 
@@ -197,7 +195,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 v1 3/4] phy: phy-can-transceiver: Don't check for specific errors when parsing properties
From: Andy Shevchenko @ 2026-02-19 20:26 UTC (permalink / raw)
  To: linux-can, linux-phy, linux-kernel
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	Andy Shevchenko
In-Reply-To: <20260219202910.2304440-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 | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index dd08faf46837..ebce48ef217f 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -138,8 +138,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->flags & CAN_TRANSCEIVER_DUAL_CH)
@@ -158,8 +159,15 @@ 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)
+	propname = "max-bitrate";
+	if (device_property_present(dev, propname)) {
+		err = device_property_read_u32(dev, "max-bitrate", &max_bitrate);
+		if (err)
+			return dev_err_probe(dev, err, "failed to parse %s\n", propname);
+	} else {
+		max_bitrate = 0;
+	}
+	if (!max_bitrate)
 		dev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit\n");
 
 	for (i = 0; i < num_ch; 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 v1 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring
From: Andy Shevchenko @ 2026-02-19 20:26 UTC (permalink / raw)
  To: linux-can, linux-phy, linux-kernel
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	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.

Andy Shevchenko (4):
  phy: phy-can-transceiver: Convert to use device property API
  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: Drop unused include

 drivers/phy/phy-can-transceiver.c | 86 ++++++++++++++++---------------
 1 file changed, 45 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 v1 2/4] phy: phy-can-transceiver: Move OF ID table closer to their user
From: Andy Shevchenko @ 2026-02-19 20:26 UTC (permalink / raw)
  To: linux-can, linux-phy, linux-kernel
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	Andy Shevchenko
In-Reply-To: <20260219202910.2304440-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 | 59 +++++++++++++++----------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index f2259af4af8a..dd08faf46837 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);
-
 /* Temporary wrapper until the multiplexer subsystem supports optional muxes */
 static inline struct mux_state *
 devm_mux_state_get_optional(struct device *dev, const char *mux_name)
@@ -239,6 +210,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 = {
@@ -246,7 +246,6 @@ static struct platform_driver can_transceiver_phy_driver = {
 		.of_match_table = can_transceiver_phy_ids,
 	},
 };
-
 module_platform_driver(can_transceiver_phy_driver);
 
 MODULE_AUTHOR("Faiz Abbas <faiz_abbas@ti.com>");
-- 
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] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Dmitry Torokhov @ 2026-02-19 23:57 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Neil Armstrong, Rafael J. Wysocki, Geert Uytterhoeven,
	Johan Hovold, Claudiu Beznea, Dr. David Alan Gilbert,
	Peter Griffin, Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu,
	linux-phy, linux-kernel

The implementation put_device()s located device and then uses
container_of() on the pointer. The device may disappear by that time,
resulting in UAF.

Fix the problem by keeping the reference to the framer device,
avoiding getting an extra reference to it in framer_get(), and making
sure to drop the reference in error path when we fail to get the module.

Fixes: e6625db66212 ("phy: core: Simplify API of_phy_simple_xlate() implementation")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/phy/phy-core.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 4ad396214d0c..cf62eb9ddca9 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -682,10 +682,10 @@ struct phy *of_phy_get(struct device_node *np, const char *con_id)
 	if (IS_ERR(phy))
 		return phy;
 
-	if (!try_module_get(phy->ops->owner))
+	if (!try_module_get(phy->ops->owner)) {
+		put_device(&phy->dev);
 		return ERR_PTR(-EPROBE_DEFER);
-
-	get_device(&phy->dev);
+	}
 
 	return phy;
 }
@@ -765,7 +765,6 @@ struct phy *of_phy_simple_xlate(struct device *dev,
 	if (!target_dev)
 		return ERR_PTR(-ENODEV);
 
-	put_device(target_dev);
 	return to_phy(target_dev);
 }
 EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
-- 
2.53.0.345.g96ddfc5eaa-goog


-- 
Dmitry

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

^ permalink raw reply related
* Re: [PATCH] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Dmitry Torokhov @ 2026-02-20  0:11 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Neil Armstrong, Rafael J. Wysocki, Geert Uytterhoeven,
	Johan Hovold, Claudiu Beznea, Dr. David Alan Gilbert,
	Peter Griffin, Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu,
	linux-phy, linux-kernel
In-Reply-To: <aZejMSJ9qqRWb2pX@google.com>

On Thu, Feb 19, 2026 at 03:57:11PM -0800, Dmitry Torokhov wrote:
> The implementation put_device()s located device and then uses
> container_of() on the pointer. The device may disappear by that time,
> resulting in UAF.
> 
> Fix the problem by keeping the reference to the framer device,
> avoiding getting an extra reference to it in framer_get(), and making
> sure to drop the reference in error path when we fail to get the module.

Hmm, I was too rash. There are bunch of other xlate functions that need
to be updated to take the reference.

> 
> Fixes: e6625db66212 ("phy: core: Simplify API of_phy_simple_xlate() implementation")
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/phy/phy-core.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 4ad396214d0c..cf62eb9ddca9 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -682,10 +682,10 @@ struct phy *of_phy_get(struct device_node *np, const char *con_id)
>  	if (IS_ERR(phy))
>  		return phy;
>  
> -	if (!try_module_get(phy->ops->owner))
> +	if (!try_module_get(phy->ops->owner)) {
> +		put_device(&phy->dev);
>  		return ERR_PTR(-EPROBE_DEFER);
> -
> -	get_device(&phy->dev);
> +	}
>  
>  	return phy;
>  }
> @@ -765,7 +765,6 @@ struct phy *of_phy_simple_xlate(struct device *dev,
>  	if (!target_dev)
>  		return ERR_PTR(-ENODEV);
>  
> -	put_device(target_dev);
>  	return to_phy(target_dev);
>  }
>  EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
> -- 
> 2.53.0.345.g96ddfc5eaa-goog
> 
> 

-- 
Dmitry

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

^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Krzysztof Kozlowski @ 2026-02-20  7:50 UTC (permalink / raw)
  To: Abel Vesa
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Nitin Rawat, Konrad Dybcio, linux-arm-msm,
	linux-phy, devicetree, linux-kernel
In-Reply-To: <20260219-eliza-bindings-phy-ufs-v1-1-1635e7b53049@oss.qualcomm.com>

On Thu, Feb 19, 2026 at 06:17:11PM +0200, Abel Vesa wrote:
> Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
> compatible with the PHY implemented in SM8650, so use the SM8650
> compatible as fallback.
> 
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> index a1731b08c9d1..7120741ea092 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> @@ -16,6 +16,10 @@ description:
>  properties:
>    compatible:
>      oneOf:
> +      - items:
> +          - enum:
> +              - qcom,eliza-qmp-ufs-phy
> +          - const: qcom,sm8650-qmp-ufs-phy

sm8650 > sm6115

Don't break the order.

Best regards,
Krzysztof


-- 
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,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Abel Vesa @ 2026-02-20  8:25 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: Nitin Rawat, Konrad Dybcio, linux-arm-msm, linux-phy, devicetree,
	linux-kernel, Abel Vesa

Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
compatible with the PHY implemented in SM8650, so use the SM8650
compatible as fallback.

While at it, move the QCS8300 one so that the it is sorted correctly by
fallback compatible.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Changes in v2:
- Fixed the order by moving it below X1E80100 so that the fallback
  compatibles would be sorted, like Krzysztof suggested.
- While at it, moved the QCS8300 in first, so the sorting of all fallback
  compatibles will be complete all the way.
- Picked up Konrad's R-b tag.
- Link to v1: https://patch.msgid.link/20260219-eliza-bindings-phy-ufs-v1-1-1635e7b53049@oss.qualcomm.com
---
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml        | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index a1731b08c9d1..9616c736b6d4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -16,6 +16,10 @@ description:
 properties:
   compatible:
     oneOf:
+      - items:
+          - enum:
+              - qcom,qcs8300-qmp-ufs-phy
+          - const: qcom,sa8775p-qmp-ufs-phy
       - items:
           - enum:
               - qcom,qcs615-qmp-ufs-phy
@@ -26,8 +30,8 @@ properties:
           - const: qcom,sm8550-qmp-ufs-phy
       - items:
           - enum:
-              - qcom,qcs8300-qmp-ufs-phy
-          - const: qcom,sa8775p-qmp-ufs-phy
+              - qcom,eliza-qmp-ufs-phy
+          - const: qcom,sm8650-qmp-ufs-phy
       - items:
           - enum:
               - qcom,kaanapali-qmp-ufs-phy

---
base-commit: 50f68cc7be0a2cbf54d8f6aaf17df32fb01acc3f
change-id: 20260219-eliza-bindings-phy-ufs-3d95c2377aeb

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: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4
From: Neil Armstrong @ 2026-02-20  8:30 UTC (permalink / raw)
  To: Abel Vesa, Vinod Koul, Konrad Dybcio
  Cc: Manivannan Sadhasivam, linux-arm-msm, linux-phy, linux-kernel,
	stable, Nitin Rawat
In-Reply-To: <20260219-phy-qcom-qmp-ufs-fix-sm8650-pcs-g4-table-v1-1-f136505b57f6@oss.qualcomm.com>

On 2/19/26 12:11, Abel Vesa wrote:
> According to internal documentation, on SM8650, when the PHY is configured
> in Gear 4, the QPHY_V6_PCS_UFS_PLL_CNTL register needs to have the same
> value as for Gear 5.
> 
> At the moment, there is no board that comes with a UFS 3.x device, so
> this issue doesn't show up, but with the new Eliza SoC, which uses the
> same init sequence as SM8650, on the MTP board, the link startup fails
> with the current Gear 4 PCS table.
> 
> So fix that by moving the entry into the PCS generic table instead,
> while keeping the value from Gear 5 configuration.
> 
> Cc: stable@vger.kernel.org # v6.10
> Fixes: b9251e64a96f ("phy: qcom: qmp-ufs: update SM8650 tables for Gear 4 & 5")
> Suggested-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>   drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index df138a5442eb..771bc7c2ab50 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -990,6 +990,7 @@ static const struct qmp_phy_init_tbl sm8650_ufsphy_pcs[] = {
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PCS_CTRL1, 0xc1),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x33),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0f),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_SIGDET_CTRL2, 0x68),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_POST_EMP_LVL_S4, 0x0e),
> @@ -999,13 +1000,11 @@ static const struct qmp_phy_init_tbl sm8650_ufsphy_pcs[] = {
>   };
>   
>   static const struct qmp_phy_init_tbl sm8650_ufsphy_g4_pcs[] = {
> -	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x13),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x04),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x04),
>   };
>   
>   static const struct qmp_phy_init_tbl sm8650_ufsphy_g5_pcs[] = {
> -	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x33),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x05),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x05),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY, 0x4d),
> 
> ---
> base-commit: 50f68cc7be0a2cbf54d8f6aaf17df32fb01acc3f
> change-id: 20260219-phy-qcom-qmp-ufs-fix-sm8650-pcs-g4-table-9d1adf1508fb
> 
> Best regards,
> --
> Abel Vesa <abel.vesa@oss.qualcomm.com>
> 

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK

Thanks,
Neil

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

^ permalink raw reply
* Re: [PATCH] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Dmitry Torokhov @ 2026-02-21  1:01 UTC (permalink / raw)
  To: Vinod Koul, Kishon Vijay Abraham I
  Cc: Neil Armstrong, Rafael J. Wysocki, Geert Uytterhoeven,
	Johan Hovold, Claudiu Beznea, Dr. David Alan Gilbert,
	Peter Griffin, Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu,
	linux-phy, linux-kernel
In-Reply-To: <aZemjhBNFyOfKeNL@google.com>

On Thu, Feb 19, 2026 at 04:11:37PM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 19, 2026 at 03:57:11PM -0800, Dmitry Torokhov wrote:
> > The implementation put_device()s located device and then uses
> > container_of() on the pointer. The device may disappear by that time,
> > resulting in UAF.
> > 
> > Fix the problem by keeping the reference to the framer device,
> > avoiding getting an extra reference to it in framer_get(), and making
> > sure to drop the reference in error path when we fail to get the module.
> 
> Hmm, I was too rash. There are bunch of other xlate functions that need
> to be updated to take the reference.

So I am convinced that xlate functions need to bump up the reference to
phy devices they return. The question is how to deal with the ones that
do not. I can either convert them in the same patch (the changes are
quite mechanical) or we can do the whole song and dance, introduce a
flag, set it up in converted xlate functions, have the core respect it,
and then remove it from xlates and from the core when it is all done.

Please let me know.

Thanks.

-- 
Dmitry

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

^ permalink raw reply
* Re: [PATCH v2] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Krzysztof Kozlowski @ 2026-02-21 10:24 UTC (permalink / raw)
  To: Abel Vesa
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Nitin Rawat, Konrad Dybcio, linux-arm-msm,
	linux-phy, devicetree, linux-kernel
In-Reply-To: <20260220-eliza-bindings-phy-ufs-v2-1-4910bdcc585a@oss.qualcomm.com>

On Fri, Feb 20, 2026 at 10:25:50AM +0200, Abel Vesa wrote:
> Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
> compatible with the PHY implemented in SM8650, so use the SM8650
> compatible as fallback.
> 
> While at it, move the QCS8300 one so that the it is sorted correctly by
> fallback compatible.
> 
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---

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

Best regards,
Krzysztof


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

^ permalink raw reply
* PROBLEM: Raxda Rock 5 ITX shared SATA broken by "phy: rockchip: naneng-combphy: fix phy reset"
From: Arthur Fabre @ 2026-02-21 13:28 UTC (permalink / raw)
  To: Heiko Stuebner, Chukun Pan
  Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
	FUKAUMI Naoki

Hello,

I have a Raxda Rock 5 ITX, with a device-tree overlay to enable
the shared SATA port:

// ROCK 5 ITX M.2 E-Key Sata
/dts-v1/;
/plugin/;

/ {
	fragment@0 {
		target = <&pcie2x1l0>;

		__overlay__ {
			status = "disabled";
		};
	};

	fragment@1 {
		target = <&sata1>;

		__overlay__ {
			status = "okay";
		};
	};
};

This worked fine, with the kernel normally logging:

[    0.754425] ata1: SATA max UDMA/133 abar m8192@0xf1282000 port 0xf1282100 irq 70 lpm-pol 0
[    1.692424] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

However this stopped working after a kernel update:

[    2.687755] ata1: SATA max UDMA/133 mmio [mem 0xfe220000-0xfe220fff] port 0x100 irq 79 lpm-pol 0
[    4.893204] ata1: SATA link down (SStatus 1 SControl 300)
[    7.111503] ata1: SATA link down (SStatus 1 SControl 300)
[    7.111993] ata1: limiting SATA link speed to 1.5 Gbps

I've reliably bisected it to commit:
fbcbffbac994 "phy: rockchip: naneng-combphy: fix phy reset".

Unfortunately coming up with a patch is out of my depth.
Happy to test any suggestions.

If it matters I'm using the EDK2 UEFI firmware v1.1:
https://github.com/edk2-porting/edk2-rk3588

Thank you,

Arthur

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

^ permalink raw reply
* Re: [PATCH v2 1/4] phy: rockchip: inno-usb2: Add usb2 phy support for RK3368
From: Heiko Stübner @ 2026-02-21 14:59 UTC (permalink / raw)
  To: robh, WeiHao Li
  Cc: krzk+dt, conor+dt, linux-phy, devicetree, linux-arm-kernel,
	linux-rockchip, linux-kernel, WeiHao Li
In-Reply-To: <20250909132958.26423-2-cn.liweihao@gmail.com>

Hi,

Am Dienstag, 9. September 2025, 15:29:55 Mitteleuropäische Normalzeit schrieb WeiHao Li:
> RK3368 has one USB2.0 PHY with two ports. This adds device specific data
> for it. Device specific data get form rockchip downstream source [1].
> 
> [1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/phy/rockchip/phy-rockchip-inno-usb2.c#L2805
> 
> Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

just realized, this patch is missing the phy maintainer/reviewer as
recipient, the phy-list is likely not enough.

Please use scripts/get_maintainer.pl for the whole series, to get necessary
people. Because this phy-patch needs to go through the phy tree.

Thanks
Heiko



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

^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Thomas Niederprüm @ 2026-02-21 15:05 UTC (permalink / raw)
  To: Cristian Ciocaltea, Vinod Koul, Neil Armstrong, Heiko Stuebner,
	linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
	regressions
In-Reply-To: <a662745a-1b2a-47b3-a66d-7c1c5c8af525@collabora.com>

Hi Cristian,

Am Mittwoch, dem 18.02.2026 um 22:56 +0200 schrieb Cristian Ciocaltea:
> Hi Thomas,
> 
> On 2/18/26 10:43 PM, 1und1 wrote:
> > Hi Cristian,
> > 
> > 
> > Am Mittwoch, dem 18.02.2026 um 22:15 +0200 schrieb Cristian Ciocaltea:
> > > On 2/18/26 3:22 AM, Cristian Ciocaltea wrote:
> > > > On 2/18/26 2:52 AM, Cristian Ciocaltea wrote:
> > > > > Hi Thomas,
> > > > [...]
> > > > 
> > > > > 
> > > > > Sorry, I somehow missed the following warning message, though it has
> > > > > been
> > > > > already present in all the logs you've sent to me so far:
> > > > > 
> > > > >   rockchip-hdptx-phy fed60000.phy: PLL locked by unknown consumer!
> > > > > 
> > > > > That indicates the PHY has been preconfigured by an external component
> > > > > (e.g. the
> > > > > bootloader), which is actually a scenario that I didn't verify.
> > > > > 
> > > > > However, this just another way to expose a limitation of the current
> > > > > approach
> > > > > for managing the TMDS character rate: done via the Common Clock
> > > > > Framework
> > > > > API
> > > > > instead of the HDMI PHY configuration API.
> > > > > 
> > > > > As a matter of fact, it was actually an item on my TODOs list for
> > > > > quite a
> > > > > while,
> > > > > but blocked until recently due to several dependencies waiting to be
> > > > > merged
> > > > > upstream.
> > > > > 
> > > > > Hence I took the opportunity to finalize this task - please give the
> > > > > following
> > > > > commits in my rk3588-hdmi-debug branch [2] a try:
> > > > 
> > > > I've just realized I introduced a regression while doing some cleanup
> > > > work,
> > > > hence
> > > > please ignore this until further notice.
> > > 
> > > I think I got this working properly now, at least it passes all the tests
> > > I
> > > could run.  The updated commits in [2] are:
> > > 
> > >   fa7cd1e75aaa ("phy: rockchip: samsung-hdptx: Fix rate recalculation for
> > > high
> > > bpc")
> > >   8048db5544da ("phy: rockchip: samsung-hdptx: Exclusively use PHY config
> > > API
> > > for PLL changes")
> > >   0085a382dfd0 ("[DEBUG] drm/rockchip: Add HDMI verbose logging")
> > > 
> > 
> > applying these commits solves my problems. I tested 1920x1080@60,
> > 1920x1080@50
> > and 1920x1080@30. All work now. Thanks for the quick fix! 
> 
> Thanks for the quick test!
> 
> I can add you to cc: when I submit the series, so that you may provide your
> Tested-by tag if you'd like to.

sure, I would be happy to.

> 
> > And the positive side> effect seems to be that you can now take one of your
> > old todos from your list.
> 
> Indeed. :-)
> 
> Regards,
> Cristian

Best regards,

Thomas

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

^ permalink raw reply
* [PATCH] phy: move spacemit pcie driver to its subfolder
From: Vinod Koul @ 2026-02-23  6:42 UTC (permalink / raw)
  To: linux-phy
  Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul, Alex Elder, Ze Huang,
	spacemit

Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
created spacemit subfolder with usb driver while commit 57e920b92724
("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
folder. Move latter into spacemit subfolder and rename file to
phy-k1-pcie.c

Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
 drivers/phy/Kconfig                                  | 12 ------------
 drivers/phy/Makefile                                 |  1 -
 drivers/phy/spacemit/Kconfig                         | 12 ++++++++++++
 drivers/phy/spacemit/Makefile                        |  1 +
 .../phy-k1-pcie.c}                                   |  0
 5 files changed, 13 insertions(+), 13 deletions(-)
 rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 02467dfd4fb0..c0574e44f0a3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
 	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
 	  Speed and High Speed.
 
-config PHY_SPACEMIT_K1_PCIE
-	tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
-	depends on ARCH_SPACEMIT || COMPILE_TEST
-	depends on COMMON_CLK
-	depends on HAS_IOMEM
-	depends on OF
-	select GENERIC_PHY
-	default ARCH_SPACEMIT
-	help
-	  Enable support for the PCIe and USB 3 combo PHY and two
-	  PCIe-only PHYs used in the SpacemiT K1 SoC.
-
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/apple/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a648c2e02a83..2773d596e543 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2)		+= phy-snps-eusb2.o
 obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
 obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
 obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
-obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE)	+= phy-spacemit-k1-pcie.o
 obj-$(CONFIG_GENERIC_PHY)		+= allwinner/	\
 					   amlogic/	\
 					   apple/	\
diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
index 0136aee2e8a2..50b0005acf66 100644
--- a/drivers/phy/spacemit/Kconfig
+++ b/drivers/phy/spacemit/Kconfig
@@ -2,6 +2,18 @@
 #
 # Phy drivers for SpacemiT platforms
 #
+config PHY_SPACEMIT_K1_PCIE
+	tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
+	depends on ARCH_SPACEMIT || COMPILE_TEST
+	depends on COMMON_CLK
+	depends on HAS_IOMEM
+	depends on OF
+	select GENERIC_PHY
+	default ARCH_SPACEMIT
+	help
+	  Enable support for the PCIe and USB 3 combo PHY and two
+	  PCIe-only PHYs used in the SpacemiT K1 SoC.
+
 config PHY_SPACEMIT_K1_USB2
 	tristate "SpacemiT K1 USB 2.0 PHY support"
 	depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
index fec0b425a948..a821a21d6142 100644
--- a/drivers/phy/spacemit/Makefile
+++ b/drivers/phy/spacemit/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE)		+= phy-k1-pcie.o
 obj-$(CONFIG_PHY_SPACEMIT_K1_USB2)		+= phy-k1-usb2.o
diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
similarity index 100%
rename from drivers/phy/phy-spacemit-k1-pcie.c
rename to drivers/phy/spacemit/phy-k1-pcie.c
-- 
2.43.0


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

^ permalink raw reply related
* [PATCH] phy: Sort the subsystem Makefile
From: Vinod Koul @ 2026-02-23  6:57 UTC (permalink / raw)
  To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul

Makefile is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that

Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
 drivers/phy/Makefile | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2773d596e543..90cad2b72cfa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,15 +7,16 @@ obj-$(CONFIG_PHY_COMMON_PROPS)		+= phy-common-props.o
 obj-$(CONFIG_PHY_COMMON_PROPS_TEST)	+= phy-common-props-test.o
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY)	+= phy-core-mipi-dphy.o
+obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
 obj-$(CONFIG_PHY_CAN_TRANSCEIVER)	+= phy-can-transceiver.o
 obj-$(CONFIG_PHY_GOOGLE_USB)		+= phy-google-usb.o
+obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)	+= phy-lpc18xx-usb-otg.o
-obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
+obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_SNPS_EUSB2)		+= phy-snps-eusb2.o
-obj-$(CONFIG_USB_LGM_PHY)		+= phy-lgm-usb.o
-obj-$(CONFIG_PHY_AIROHA_PCIE)		+= phy-airoha-pcie.o
-obj-$(CONFIG_PHY_NXP_PTN3222)		+= phy-nxp-ptn3222.o
+obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
+
 obj-$(CONFIG_GENERIC_PHY)		+= allwinner/	\
 					   amlogic/	\
 					   apple/	\
-- 
2.43.0


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

^ permalink raw reply related
* [PATCH] phy: Sort the subsystem Kconfig
From: Vinod Koul @ 2026-02-23  6:58 UTC (permalink / raw)
  To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul

Kconfig is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that

Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
 drivers/phy/Kconfig | 88 ++++++++++++++++++++++-----------------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c0574e44f0a3..a00266c8256b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,26 @@ config GENERIC_PHY_MIPI_DPHY
 	  Provides a number of helpers a core functions for MIPI D-PHY
 	  drivers to us.
 
+config PHY_AIROHA_PCIE
+	tristate "Airoha PCIe-PHY Driver"
+	depends on ARCH_AIROHA || COMPILE_TEST
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Say Y here to add support for Airoha PCIe PHY driver.
+	  This driver create the basic PHY instance and provides initialize
+	  callback for PCIe GEN3 port.
+
+config PHY_CAN_TRANSCEIVER
+	tristate "CAN transceiver PHY"
+	select GENERIC_PHY
+	select MULTIPLEXER
+	help
+	  This option enables support for CAN transceivers as a PHY. This
+	  driver provides function for putting the transceivers in various
+	  functional modes using gpios and sets the attribute max link
+	  rate, for CAN drivers.
+
 config PHY_GOOGLE_USB
 	tristate "Google Tensor SoC USB PHY driver"
 	select GENERIC_PHY
@@ -58,6 +78,18 @@ config PHY_GOOGLE_USB
 	  both of which are integrated with the DWC3 USB DRD controller.
 	  This driver currently supports USB high-speed.
 
+config USB_LGM_PHY
+	tristate "INTEL Lightning Mountain USB PHY Driver"
+	depends on USB_SUPPORT
+	depends on X86 || COMPILE_TEST
+	select USB_PHY
+	select REGULATOR
+	select REGULATOR_FIXED_VOLTAGE
+	help
+	  Enable this to support Intel DWC3 PHY USB phy. This driver provides
+	  interface to interact with USB GEN-II and USB 3.x PHY that is part
+	  of the Intel network SOC.
+
 config PHY_LPC18XX_USB_OTG
 	tristate "NXP LPC18xx/43xx SoC USB OTG PHY driver"
 	depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
@@ -69,6 +101,17 @@ config PHY_LPC18XX_USB_OTG
 	  This driver is need for USB0 support on LPC18xx/43xx and takes
 	  care of enabling and clock setup.
 
+config PHY_NXP_PTN3222
+	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
+	depends on I2C
+	depends on OF
+	select GENERIC_PHY
+	help
+	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
+	  This redriver performs translation between eUSB2 and USB2 signalling
+	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
+	  Speed and High Speed.
+
 config PHY_PISTACHIO_USB
 	tristate "IMG Pistachio USB2.0 PHY driver"
 	depends on MIPS || COMPILE_TEST
@@ -91,49 +134,6 @@ config PHY_XGENE
 	help
 	  This option enables support for APM X-Gene SoC multi-purpose PHY.
 
-config USB_LGM_PHY
-	tristate "INTEL Lightning Mountain USB PHY Driver"
-	depends on USB_SUPPORT
-	depends on X86 || COMPILE_TEST
-	select USB_PHY
-	select REGULATOR
-	select REGULATOR_FIXED_VOLTAGE
-	help
-	  Enable this to support Intel DWC3 PHY USB phy. This driver provides
-	  interface to interact with USB GEN-II and USB 3.x PHY that is part
-	  of the Intel network SOC.
-
-config PHY_CAN_TRANSCEIVER
-	tristate "CAN transceiver PHY"
-	select GENERIC_PHY
-	select MULTIPLEXER
-	help
-	  This option enables support for CAN transceivers as a PHY. This
-	  driver provides function for putting the transceivers in various
-	  functional modes using gpios and sets the attribute max link
-	  rate, for CAN drivers.
-
-config PHY_AIROHA_PCIE
-	tristate "Airoha PCIe-PHY Driver"
-	depends on ARCH_AIROHA || COMPILE_TEST
-	depends on OF
-	select GENERIC_PHY
-	help
-	  Say Y here to add support for Airoha PCIe PHY driver.
-	  This driver create the basic PHY instance and provides initialize
-	  callback for PCIe GEN3 port.
-
-config PHY_NXP_PTN3222
-	tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
-	depends on I2C
-	depends on OF
-	select GENERIC_PHY
-	help
-	  Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
-	  This redriver performs translation between eUSB2 and USB2 signalling
-	  schemes. It supports all three USB 2.0 data rates: Low Speed, Full
-	  Speed and High Speed.
-
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/apple/Kconfig"
@@ -142,6 +142,7 @@ source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/freescale/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/ingenic/Kconfig"
+source "drivers/phy/intel/Kconfig"
 source "drivers/phy/lantiq/Kconfig"
 source "drivers/phy/marvell/Kconfig"
 source "drivers/phy/mediatek/Kconfig"
@@ -163,7 +164,6 @@ source "drivers/phy/starfive/Kconfig"
 source "drivers/phy/sunplus/Kconfig"
 source "drivers/phy/tegra/Kconfig"
 source "drivers/phy/ti/Kconfig"
-source "drivers/phy/intel/Kconfig"
 source "drivers/phy/xilinx/Kconfig"
 
 endmenu
-- 
2.43.0


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

^ permalink raw reply related
* [PATCH] phy: phy-mtk-tphy: Update names and format of kernel-doc comments
From: Vinod Koul @ 2026-02-23  7:10 UTC (permalink / raw)
  To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul, chunfeng.yun

mtk_phy_pdata documentation does not use correct tag for struct, while at
it fix one of member wrongly documented.

Warning: drivers/phy/mediatek/phy-mtk-tphy.c:289 cannot understand function prototype: 'struct mtk_phy_pdata'
Warning: drivers/phy/mediatek/phy-mtk-tphy.c:296 struct member 'slew_ref_clock_mhz' not described in 'mtk_phy_pdata'

Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
index f6504e0ecd1a..acf506529507 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -276,14 +276,14 @@ enum mtk_phy_version {
 };
 
 /**
- * mtk_phy_pdata - SoC specific platform data
+ * struct mtk_phy_pdata - SoC specific platform data
  * @avoid_rx_sen_degradation: Avoid TX Sensitivity level degradation (MT6795/8173 only)
  * @sw_pll_48m_to_26m:        Workaround for V3 IP (MT8195) - switch the 48MHz PLL from
  *                            fractional mode to integer to output 26MHz for U2PHY
  * @sw_efuse_supported:       Switches off eFuse auto-load from PHY and applies values
  *                            read from different nvmem (usually different eFuse array)
  *                            that is pointed at in the device tree node for this PHY
- * @slew_ref_clk_mhz:         Default reference clock (in MHz) for slew rate calibration
+ * @slew_ref_clock_mhz:         Default reference clock (in MHz) for slew rate calibration
  * @slew_rate_coefficient:    Coefficient for slew rate calibration
  * @version:                  PHY IP Version
  */
-- 
2.43.0


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

^ permalink raw reply related
* [PATCH v3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Abel Vesa @ 2026-02-23  8:19 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: Nitin Rawat, Konrad Dybcio, linux-arm-msm, linux-phy, devicetree,
	linux-kernel, Krzysztof Kozlowski, Abel Vesa

Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
compatible with the PHY implemented in SM8650, so use the SM8650
compatible as fallback.

While at it, move the QCS8300 one so that it is sorted correctly by
fallback compatible.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Changes in v3:
- Fix commit message by dropping extra "the" word from last sentence.
- Picked up Krzysztof's R-b tag.
- Link to v2: https://patch.msgid.link/20260220-eliza-bindings-phy-ufs-v2-1-4910bdcc585a@oss.qualcomm.com

Changes in v2:
- Fixed the order by moving it below X1E80100 so that the fallback
  compatibles would be sorted, like Krzysztof suggested.
- While at it, moved the QCS8300 in first, so the sorting of all fallback
  compatibles will be complete all the way.
- Picked up Konrad's R-b tag.
- Link to v1: https://patch.msgid.link/20260219-eliza-bindings-phy-ufs-v1-1-1635e7b53049@oss.qualcomm.com
---
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml        | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index a1731b08c9d1..9616c736b6d4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -16,6 +16,10 @@ description:
 properties:
   compatible:
     oneOf:
+      - items:
+          - enum:
+              - qcom,qcs8300-qmp-ufs-phy
+          - const: qcom,sa8775p-qmp-ufs-phy
       - items:
           - enum:
               - qcom,qcs615-qmp-ufs-phy
@@ -26,8 +30,8 @@ properties:
           - const: qcom,sm8550-qmp-ufs-phy
       - items:
           - enum:
-              - qcom,qcs8300-qmp-ufs-phy
-          - const: qcom,sa8775p-qmp-ufs-phy
+              - qcom,eliza-qmp-ufs-phy
+          - const: qcom,sm8650-qmp-ufs-phy
       - items:
           - enum:
               - qcom,kaanapali-qmp-ufs-phy

---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260219-eliza-bindings-phy-ufs-3d95c2377aeb

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 RFC net-next+ 4/9] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
From: Mohd Ayaan Anwar @ 2026-02-23  9:44 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
	linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
	Vinod Koul
In-Reply-To: <E1vt3US-0000000A5eE-1RHM@rmk-PC.armlinux.org.uk>

Hi Russell,
On Thu, Feb 19, 2026 at 12:50:44PM +0000, Russell King (Oracle) wrote:
> @@ -675,20 +676,16 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
>  				    phy_interface_t interface)
>  {
>  	struct qcom_ethqos *ethqos = priv;
> -	int speed, ret = 0;
> +	int ret = 0;
>  
>  	qcom_ethqos_set_sgmii_loopback(ethqos, false);
>  
> -	speed = SPEED_UNKNOWN;
> -	if (interface == PHY_INTERFACE_MODE_SGMII)
> -		speed = SPEED_1000;
> -	else if (interface == PHY_INTERFACE_MODE_2500BASEX)
> -		speed = SPEED_2500;
> -
> -	if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
> -		ret = phy_set_speed(ethqos->serdes_phy, speed);
> +	if (interface == PHY_INTERFACE_MODE_SGMII ||
> +	    interface == PHY_INTERFACE_MODE_2500BASEX) {
> +		ret = phy_set_mode(ethqos->serdes_phy, PHY_MODE_ETHERNET,
> +				   interface);

Shouldn't this be phy_set_mode_ext()?

	Ayaan

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

^ permalink raw reply
* Re: [PATCH RFC net-next+previous 0/9] net: stmmac: qcom-ethqos: further updates
From: Mohd Ayaan Anwar @ 2026-02-23  9:49 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
	linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
	Vinod Koul
In-Reply-To: <aZcGxDBwfMXHbo_O@shell.armlinux.org.uk>

On Thu, Feb 19, 2026 at 12:49:08PM +0000, Russell King (Oracle) wrote:
> This is part 2 of the qcom-ethqos series, building on the previous
> series which can be found at
> https://lore.kernel.org/r/aY0aJppQWUC52OUq@shell.armlinux.org.uk
> 
> This part of the series focuses on the generic PHY driver, but these
> changes have dependencies on the ethernet driver, hence why
> it will need to go via net-next. Furthermore, subsequent changes
> depend on these patches.
> 
> The underlying ideas here are:
> 
> - get rid of the driver using phy_set_speed() with SPEED_1000 and
>   SPEED_2500 which makes no sense for an ethernet SerDes due to the
>   PCS 8B10B data encoding, which inflates the data rate at the SerDes
>   compared to the MAC.
> - allow phy_power_on() / phy_set_mode*() to be called in any order.
> 
> I've included the set_clk_tx_rate() patch as that was tested, which
> would make applying this series awkward to apply without it.
> 
> Mohd, please could you test this series - I'm hoping it will pass with
> flying colours as there should be no change to the order in which we
> program the hardware. Thanks.
> 
>  .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 52 +++++++-----------
>  drivers/phy/qualcomm/phy-qcom-sgmii-eth.c          | 62 +++++++++++++++++-----
>  2 files changed, 68 insertions(+), 46 deletions(-)
> 

After changing phy_set_mode() to phy_set_mode_ext() in
dwmac-qcom-ethqos.c, no issues found on:

  - QCS9100 Ride R3 (AQR115C PHY, 2500BASE-X) - 2.5G/1G/100M
  - IQ9 EVK (QCA8081 PHY, 2500BASE-X) - 2.5G

Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

	Ayaan


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

^ permalink raw reply
* Re: [PATCH RFC net-next+ 2/9] net: stmmac: qcom-ethqos: move ethqos_set_serdes_speed()
From: Mohd Ayaan Anwar @ 2026-02-23  9:52 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
	linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
	Vinod Koul
In-Reply-To: <E1vt3UI-0000000A5e2-0Im5@rmk-PC.armlinux.org.uk>

On Thu, Feb 19, 2026 at 12:50:34PM +0000, Russell King (Oracle) wrote:
> Combine ethqos_set_serdes_speed() with ethqos_mac_finish_serdes() to
> simplify the code.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 22 +++++++++----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 

Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

	Ayaan

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

^ permalink raw reply
* Re: [PATCH RFC net-next+ 9/9] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
From: Mohd Ayaan Anwar @ 2026-02-23  9:54 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
	linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
	Vinod Koul
In-Reply-To: <E1vt3Us-0000000A5ei-04Bg@rmk-PC.armlinux.org.uk>

On Thu, Feb 19, 2026 at 12:51:10PM +0000, Russell King (Oracle) wrote:
> The call to phy_set_mode_ext() after phy_power_on() was a work-around
> for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on
> phy_power_on() but did not configure the PHY. Now that the SerDes driver
> fully configures the SerDes at phy_power_on(), there is no need to call
> phy_set_mode_ext() immediately afterwards.
> 
> This also means we no longer need to record the previous operating mode
> of the driver - this is up to the SerDes driver. In any case, the only
> thing that we care about is the SerDes provides the necessary clocks to
> the stmmac core to allow it to reset at this point. The actual mode is
> irrelevant at this point as the correct mode will be configured in
> ethqos_mac_finish_serdes() just before the network device is brought
> online.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
>  .../stmicro/stmmac/dwmac-qcom-ethqos.c         | 18 ++----------------
>  1 file changed, 2 insertions(+), 16 deletions(-)
> 

Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

	Ayaan

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

^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Josua Mayer @ 2026-02-23 12:43 UTC (permalink / raw)
  To: Andreas Kemnade, Vladimir Oltean
  Cc: Geert Uytterhoeven, Marc Kleine-Budde, Vincent Mailhol,
	Vinod Koul, Neil Armstrong, Peter Rosin, Aaro Koskinen,
	Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
	Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
	Magnus Damm, Wolfram Sang, Yazan Shhady, Jon Nettleton,
	Mikhail Anikin, linux-can@vger.kernel.org,
	linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org
In-Reply-To: <20260216162406.0121dd91@kemnade.info>

Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> On Mon, 16 Feb 2026 11:29:14 +0200
> Vladimir Oltean <olteanv@gmail.com> wrote:
>
>> Hi Josua,
>>
>> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
>>>>> In the future, when you have a series with cross-tree dependencies,
>>>>> please try to think of it as individual mini-series for each tree's
>>>>> 'next' branch, and specify clearly that you need stable tags (to be
>>>>> pulled into other trees).  
>>> I don't really understand how I could split my series up to avoid this 
>>> issue.
>>>
>>> Due to the fact that one (and now two) drivers implemented local
>>> mux helpers, to undo that an atomic change must be made tree-wide.
>>>
>>> Meanwhile it must be avoided that while the mux core helpers are being
>>> tested / reviewed, that any tree adds another driver-local mux helper
>>> like appears to have happened here.
>>>
>>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
>>>
>>> The second challenge for this series was that mux framework is being
>>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
>>> This is e.g. responsible for being unable to test =m build with arm64
>>> defconfig - and lead to it only being detected through kernel robot
>>> x86_64 allmodconfig.  
>> To avoid this, a combination of developer due diligence + maintainer due
>> diligence is probably required.
>>
>> From linux-phy perspective, there will be some automated build testing
>> (which did not exist at the time of your submission). This would have
>> caught the 'hidden' devm_mux_state_get_optional() call present only in
>> linux-phy/next, when testing patch 2/7.
Excellent!
>>
>> But, to work, the build automation needs to be able to apply the entire
>> patch set on linux-phy/next. So expect some pushback if it doesn't
>> (hence the recommendation to send a mini-series to linux-phy first, and
>> request a stable tag).
It would help immensely if there was a way to get the patches renaming
driver-local conflicting helper-functions very early, before anything else.

Would this sort of patch be acceptable in linux-next now, so it can make
it into v7.0-rc1?

If not then that mini-patchset would be the first one I shall submit after
v7.0-rc1 is released.

Then I can treat the actual implementation of the devm_mux_* helpers
as a second standalone patch-set.

And finally patching all drivers with local helpers to use the new global ones
can be patch-set number 3.

Any opinions on this?

> I do not think that is at all the duty of the patch submitter. I think as
> long as every dependencies and side effects are documented, it is IMHO up to the
> maintainers to decide how it can be merged best. They know best whether there
> is any danger of conflicts in their working tree because that is an area 
> where people are working on. Especially this patchset is around for months.
>
>  In MFD where it is
> more common practice to have cross-subsystem patchsets, once acks from
> everyone are there, MFD Maintainer creates an immutable branch with a tag.
> The maintainers of the affected subsystems pull it in. 
This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
>
> Regards,
> Andreas
>
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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