[PATCH 0/2] Add support for SA8255P in the phy-qcom-snps-femto-v2 phy driver

[PATCH 0/2] Add support for SA8255P in the phy-qcom-snps-femto-v2 phy driver

[Mattijs Korpershoek]

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.

Power domain "core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "transfer" controls clocks and interconnects.

Patch 1 adds the binding for sa8255p. Similarly to what has been done
for I2C [1], this is a separate binding.

Patch 2 adds the driver change, which is based on a public vendor
patch from qualcomm [2].
I did the following changes on top of that:
* Use devm_add_action_or_reset() for dev_pm_domain_detach_list() instead
  of implementing a driver .remove()
* Changed power domain names to drop 'usb_' prefix
* Fixed various error handling paths
* Added suspend/resume support

This has been tested on next-20260728 with a Ride4 SA8775P board that
has SCMI firmware (which is compatible).

[1] https://lore.kernel.org/all/20260617-enable-i2c-on-sa8255p-v7-1-ad736dbeab57@oss.qualcomm.com/
[2] https://git.codelinaro.org/clo/le/meta-qti-auto-kernel/-/blob/LY.AU.0.1.0.r1-16800-gen4meta.0/recipes-kernel/linux/files/usb/0014-PENDING-phy-qcom-snps-femto-v2-Add-support-for-SA825.patch

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
Mattijs Korpershoek (1):
      dt-bindings: phy: Add sa8255p high-speed USB PHY

Sriram Dash (1):
      phy: qcom-snps-femto-v2: Add support for SA8255P

 .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      |  52 +++++++++
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c      | 126 +++++++++++++++++++--
 2 files changed, 169 insertions(+), 9 deletions(-)
---
base-commit: 3652b49adac266a3d27cb41cdfdb7d8790fc3633
change-id: 20260729-phy-qcom-snps-femto-v2-8255-90ffe7674001

Best regards,
--  
Mattijs Korpershoek <mkorpershoek@kernel.org>

[PATCH 0/2] Add support for SA8255P in the phy-qcom-snps-femto-v2 phy driver

[Mattijs Korpershoek]

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.

Power domain "core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "transfer" controls clocks and interconnects.

Patch 1 adds the binding for sa8255p. Similarly to what has been done
for I2C [1], this is a separate binding.

Patch 2 adds the driver change, which is based on a public vendor
patch from qualcomm [2].
I did the following changes on top of that:
* Use devm_add_action_or_reset() for dev_pm_domain_detach_list() instead
  of implementing a driver .remove()
* Changed power domain names to drop 'usb_' prefix
* Fixed various error handling paths
* Added suspend/resume support

This has been tested on next-20260728 with a Ride4 SA8775P board that
has SCMI firmware (which is compatible).

[1] https://lore.kernel.org/all/20260617-enable-i2c-on-sa8255p-v7-1-ad736dbeab57@oss.qualcomm.com/
[2] https://git.codelinaro.org/clo/le/meta-qti-auto-kernel/-/blob/LY.AU.0.1.0.r1-16800-gen4meta.0/recipes-kernel/linux/files/usb/0014-PENDING-phy-qcom-snps-femto-v2-Add-support-for-SA825.patch

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
Mattijs Korpershoek (1):
      dt-bindings: phy: Add sa8255p high-speed USB PHY

Sriram Dash (1):
      phy: qcom-snps-femto-v2: Add support for SA8255P

 .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      |  52 +++++++++
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c      | 126 +++++++++++++++++++--
 2 files changed, 169 insertions(+), 9 deletions(-)
---
base-commit: 3652b49adac266a3d27cb41cdfdb7d8790fc3633
change-id: 20260729-phy-qcom-snps-femto-v2-8255-90ffe7674001

Best regards,
--  
Mattijs Korpershoek <mkorpershoek@kernel.org>


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

[PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

SA8255p platform abstracts resources such as clocks, interconnect and
GPIO pins configuration in Firmware. SCMI power protocol is used to
request resource configurations.

Two power domains can be requested: transfer and core.
transfer controls clocks and interconnects and core controls
the GDSC, resets and TLMM (GPIOs).

Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
USB PHY V2 found in SA8255P.

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
 .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
new file mode 100644
index 000000000000..09f7ca6e7f72
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
+
+maintainers:
+  - Mattijs Korpershoek <mkorpershoek@kernel.org>
+
+properties:
+  compatible:
+    const: qcom,sa8255p-usb-hs-phy
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 0
+
+  power-domains:
+    maxItems: 2
+
+  power-domain-names:
+    items:
+      - const: transfer
+      - const: core
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+  - power-domains
+  - power-domain-names
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        phy@88e4000 {
+            compatible = "qcom,sa8255p-usb-hs-phy";
+            reg = <0x0 0x088e4000 0x0 0x120>;
+            #phy-cells = <0>;
+            power-domains = <&scmi12_pd 0>, <&scmi12_pd 1>;
+            power-domain-names = "transfer", "core";
+        };
+    };

-- 
2.55.0

[PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

SA8255p platform abstracts resources such as clocks, interconnect and
GPIO pins configuration in Firmware. SCMI power protocol is used to
request resource configurations.

Two power domains can be requested: transfer and core.
transfer controls clocks and interconnects and core controls
the GDSC, resets and TLMM (GPIOs).

Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
USB PHY V2 found in SA8255P.

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
 .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
new file mode 100644
index 000000000000..09f7ca6e7f72
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
+
+maintainers:
+  - Mattijs Korpershoek <mkorpershoek@kernel.org>
+
+properties:
+  compatible:
+    const: qcom,sa8255p-usb-hs-phy
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 0
+
+  power-domains:
+    maxItems: 2
+
+  power-domain-names:
+    items:
+      - const: transfer
+      - const: core
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+  - power-domains
+  - power-domain-names
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        phy@88e4000 {
+            compatible = "qcom,sa8255p-usb-hs-phy";
+            reg = <0x0 0x088e4000 0x0 0x120>;
+            #phy-cells = <0>;
+            power-domains = <&scmi12_pd 0>, <&scmi12_pd 1>;
+            power-domain-names = "transfer", "core";
+        };
+    };

-- 
2.55.0


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

[PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P

[Mattijs Korpershoek]

From: Sriram Dash <quic_sriramd@quicinc.com>

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.

Power domain "core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "transfer" controls clocks and interconnects.

In this variant, two disjoint sets of resources are modeled against
the power domain suppliers which can be turned on/off to achieve modeled
device states. Two modeled low power states d1 and d3 are supported.

transition: d0 <--> d3  :: both core and transfer suppliers
transition: d0 <--> d1  :: only transfer supplier

Signed-off-by: Sriram Dash <quic_sriramd@quicinc.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 126 ++++++++++++++++++++++++--
 1 file changed, 117 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index eb0b0f61d98e..4a9bd3ae0e53 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -12,6 +12,7 @@
 #include <linux/of.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
@@ -95,6 +96,7 @@ struct override_param_map {
 	u8 table_size;
 	u8 reg_offset;
 	u8 param_mask;
+	bool fw_managed;
 };
 
 struct phy_override_seq {
@@ -121,6 +123,7 @@ struct phy_override_seq {
  * @phy_initialized: if PHY has been initialized correctly
  * @mode: contains the current mode the PHY is in
  * @update_seq_cfg: tuning parameters for phy init
+ * @pd_list: list of power domains associated with the device
  */
 struct qcom_snps_hsphy {
 	struct device *dev;
@@ -136,8 +139,81 @@ struct qcom_snps_hsphy {
 	bool phy_initialized;
 	enum phy_mode mode;
 	struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS];
+
+	struct dev_pm_domain_list *pd_list;
 };
 
+static void qcom_snps_domain_detach(void *data)
+{
+	struct qcom_snps_hsphy *hsphy = data;
+
+	dev_pm_domain_detach_list(hsphy->pd_list);
+}
+
+static int qcom_snps_domain_attach(struct qcom_snps_hsphy *hsphy)
+{
+	struct dev_pm_domain_attach_data pd_data = {
+		.pd_flags       = PD_FLAG_NO_DEV_LINK,
+		.pd_names       = (const char*[]) { "transfer", "core" },
+		.num_pd_names   = 2,
+	};
+	struct device *dev = hsphy->dev;
+	int ret;
+
+	ret = dev_pm_domain_attach_list(dev, &pd_data, &hsphy->pd_list);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "domain attach failed\n");
+
+	return 0;
+}
+
+/* d3_to_d0 transition by turning on all the suppliers */
+static int qcom_snps_d3_to_d0(struct qcom_snps_hsphy *hsphy)
+{
+	int ret;
+
+	if (!hsphy->pd_list)
+		return 0;
+
+	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
+	if (ret)
+		return ret;
+
+	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[1]);
+	if (ret)
+		pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+
+	return ret;
+}
+
+/* d0_to_d3 transition by turning off all the suppliers */
+static void qcom_snps_d0_to_d3(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return;
+
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[1]);
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+}
+
+/* d1_to_d0 transition by turning on the 'transfer' supplier */
+static int qcom_snps_d1_to_d0(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return 0;
+
+	return pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
+}
+
+/* d0_to_d1 transition by turning off the 'transfer' supplier */
+static void qcom_snps_d0_to_d1(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return;
+
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+}
+
 static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy)
 {
 	struct device *dev = hsphy->dev;
@@ -196,6 +272,8 @@ static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
 					   0, USB2_AUTO_RESUME);
 	}
 
+	qcom_snps_d0_to_d1(hsphy);
+
 	return 0;
 }
 
@@ -203,7 +281,7 @@ static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
 {
 	dev_dbg(&hsphy->phy->dev, "Resume QCOM SNPS PHY, mode\n");
 
-	return 0;
+	return qcom_snps_d1_to_d0(hsphy);
 }
 
 static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device *dev)
@@ -316,6 +394,10 @@ static const struct override_param ls_fs_output_impedance_sc7280[] = {
 	{ 1310, 0 },
 };
 
+static const struct override_param_map sa8255p_snps_hs_phy = {
+	.fw_managed = true,
+};
+
 static const struct override_param_map sc7280_snps_7nm_phy[] = {
 	{
 		"qcom,hs-disconnect-bp",
@@ -390,9 +472,15 @@ static int qcom_snps_hsphy_init(struct phy *phy)
 
 	dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__);
 
+	ret = qcom_snps_d3_to_d0(hsphy);
+	if (ret < 0) {
+		dev_err(hsphy->dev, "Failed to transition to d0 state\n");
+		return ret;
+	}
+
 	ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
 	if (ret)
-		return ret;
+		goto transition_to_d3;
 
 	ret = clk_bulk_prepare_enable(hsphy->num_clks, hsphy->clks);
 	if (ret) {
@@ -472,6 +560,8 @@ static int qcom_snps_hsphy_init(struct phy *phy)
 	clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks);
 poweroff_phy:
 	regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
+transition_to_d3:
+	qcom_snps_d0_to_d3(hsphy);
 
 	return ret;
 }
@@ -485,6 +575,8 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 	regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
 	hsphy->phy_initialized = false;
 
+	qcom_snps_d0_to_d3(hsphy);
+
 	return 0;
 }
 
@@ -496,6 +588,10 @@ static const struct phy_ops qcom_snps_hsphy_gen_ops = {
 };
 
 static const struct of_device_id qcom_snps_hsphy_of_match_table[] = {
+	{
+		.compatible	= "qcom,sa8255p-usb-hs-phy",
+		.data		= &sa8255p_snps_hs_phy,
+	},
 	{ .compatible	= "qcom,sm8150-usb-hs-phy", },
 	{ .compatible	= "qcom,usb-snps-hs-5nm-phy", },
 	{
@@ -565,6 +661,7 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct qcom_snps_hsphy *hsphy;
+	const struct override_param_map *cfg;
 	struct phy_provider *phy_provider;
 	struct phy *generic_phy;
 	int ret, i;
@@ -580,14 +677,25 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 	if (IS_ERR(hsphy->base))
 		return PTR_ERR(hsphy->base);
 
-	ret = qcom_snps_hsphy_clk_init(hsphy);
-	if (ret)
-		return dev_err_probe(dev, ret, "failed to initialize clocks\n");
+	cfg = of_device_get_match_data(dev);
+	if (cfg && cfg->fw_managed) {
+		ret = qcom_snps_domain_attach(hsphy);
+		if (ret)
+			return ret;
+
+		ret = devm_add_action_or_reset(dev, qcom_snps_domain_detach, hsphy);
+		if (ret)
+			return ret;
+	} else {
+		ret = qcom_snps_hsphy_clk_init(hsphy);
+		if (ret)
+			return dev_err_probe(dev, ret, "failed to initialize clocks\n");
 
-	hsphy->phy_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
-	if (IS_ERR(hsphy->phy_reset)) {
-		dev_err(dev, "failed to get phy core reset\n");
-		return PTR_ERR(hsphy->phy_reset);
+		hsphy->phy_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+		if (IS_ERR(hsphy->phy_reset)) {
+			dev_err(dev, "failed to get phy core reset\n");
+			return PTR_ERR(hsphy->phy_reset);
+		}
 	}
 
 	num = ARRAY_SIZE(hsphy->vregs);

-- 
2.55.0

[PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P

[Mattijs Korpershoek]

From: Sriram Dash <quic_sriramd@quicinc.com>

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.

Power domain "core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "transfer" controls clocks and interconnects.

In this variant, two disjoint sets of resources are modeled against
the power domain suppliers which can be turned on/off to achieve modeled
device states. Two modeled low power states d1 and d3 are supported.

transition: d0 <--> d3  :: both core and transfer suppliers
transition: d0 <--> d1  :: only transfer supplier

Signed-off-by: Sriram Dash <quic_sriramd@quicinc.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 126 ++++++++++++++++++++++++--
 1 file changed, 117 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index eb0b0f61d98e..4a9bd3ae0e53 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -12,6 +12,7 @@
 #include <linux/of.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
@@ -95,6 +96,7 @@ struct override_param_map {
 	u8 table_size;
 	u8 reg_offset;
 	u8 param_mask;
+	bool fw_managed;
 };
 
 struct phy_override_seq {
@@ -121,6 +123,7 @@ struct phy_override_seq {
  * @phy_initialized: if PHY has been initialized correctly
  * @mode: contains the current mode the PHY is in
  * @update_seq_cfg: tuning parameters for phy init
+ * @pd_list: list of power domains associated with the device
  */
 struct qcom_snps_hsphy {
 	struct device *dev;
@@ -136,8 +139,81 @@ struct qcom_snps_hsphy {
 	bool phy_initialized;
 	enum phy_mode mode;
 	struct phy_override_seq update_seq_cfg[NUM_HSPHY_TUNING_PARAMS];
+
+	struct dev_pm_domain_list *pd_list;
 };
 
+static void qcom_snps_domain_detach(void *data)
+{
+	struct qcom_snps_hsphy *hsphy = data;
+
+	dev_pm_domain_detach_list(hsphy->pd_list);
+}
+
+static int qcom_snps_domain_attach(struct qcom_snps_hsphy *hsphy)
+{
+	struct dev_pm_domain_attach_data pd_data = {
+		.pd_flags       = PD_FLAG_NO_DEV_LINK,
+		.pd_names       = (const char*[]) { "transfer", "core" },
+		.num_pd_names   = 2,
+	};
+	struct device *dev = hsphy->dev;
+	int ret;
+
+	ret = dev_pm_domain_attach_list(dev, &pd_data, &hsphy->pd_list);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "domain attach failed\n");
+
+	return 0;
+}
+
+/* d3_to_d0 transition by turning on all the suppliers */
+static int qcom_snps_d3_to_d0(struct qcom_snps_hsphy *hsphy)
+{
+	int ret;
+
+	if (!hsphy->pd_list)
+		return 0;
+
+	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
+	if (ret)
+		return ret;
+
+	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[1]);
+	if (ret)
+		pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+
+	return ret;
+}
+
+/* d0_to_d3 transition by turning off all the suppliers */
+static void qcom_snps_d0_to_d3(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return;
+
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[1]);
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+}
+
+/* d1_to_d0 transition by turning on the 'transfer' supplier */
+static int qcom_snps_d1_to_d0(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return 0;
+
+	return pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
+}
+
+/* d0_to_d1 transition by turning off the 'transfer' supplier */
+static void qcom_snps_d0_to_d1(struct qcom_snps_hsphy *hsphy)
+{
+	if (!hsphy->pd_list)
+		return;
+
+	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
+}
+
 static int qcom_snps_hsphy_clk_init(struct qcom_snps_hsphy *hsphy)
 {
 	struct device *dev = hsphy->dev;
@@ -196,6 +272,8 @@ static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
 					   0, USB2_AUTO_RESUME);
 	}
 
+	qcom_snps_d0_to_d1(hsphy);
+
 	return 0;
 }
 
@@ -203,7 +281,7 @@ static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
 {
 	dev_dbg(&hsphy->phy->dev, "Resume QCOM SNPS PHY, mode\n");
 
-	return 0;
+	return qcom_snps_d1_to_d0(hsphy);
 }
 
 static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device *dev)
@@ -316,6 +394,10 @@ static const struct override_param ls_fs_output_impedance_sc7280[] = {
 	{ 1310, 0 },
 };
 
+static const struct override_param_map sa8255p_snps_hs_phy = {
+	.fw_managed = true,
+};
+
 static const struct override_param_map sc7280_snps_7nm_phy[] = {
 	{
 		"qcom,hs-disconnect-bp",
@@ -390,9 +472,15 @@ static int qcom_snps_hsphy_init(struct phy *phy)
 
 	dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__);
 
+	ret = qcom_snps_d3_to_d0(hsphy);
+	if (ret < 0) {
+		dev_err(hsphy->dev, "Failed to transition to d0 state\n");
+		return ret;
+	}
+
 	ret = regulator_bulk_enable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
 	if (ret)
-		return ret;
+		goto transition_to_d3;
 
 	ret = clk_bulk_prepare_enable(hsphy->num_clks, hsphy->clks);
 	if (ret) {
@@ -472,6 +560,8 @@ static int qcom_snps_hsphy_init(struct phy *phy)
 	clk_bulk_disable_unprepare(hsphy->num_clks, hsphy->clks);
 poweroff_phy:
 	regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
+transition_to_d3:
+	qcom_snps_d0_to_d3(hsphy);
 
 	return ret;
 }
@@ -485,6 +575,8 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 	regulator_bulk_disable(ARRAY_SIZE(hsphy->vregs), hsphy->vregs);
 	hsphy->phy_initialized = false;
 
+	qcom_snps_d0_to_d3(hsphy);
+
 	return 0;
 }
 
@@ -496,6 +588,10 @@ static const struct phy_ops qcom_snps_hsphy_gen_ops = {
 };
 
 static const struct of_device_id qcom_snps_hsphy_of_match_table[] = {
+	{
+		.compatible	= "qcom,sa8255p-usb-hs-phy",
+		.data		= &sa8255p_snps_hs_phy,
+	},
 	{ .compatible	= "qcom,sm8150-usb-hs-phy", },
 	{ .compatible	= "qcom,usb-snps-hs-5nm-phy", },
 	{
@@ -565,6 +661,7 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct qcom_snps_hsphy *hsphy;
+	const struct override_param_map *cfg;
 	struct phy_provider *phy_provider;
 	struct phy *generic_phy;
 	int ret, i;
@@ -580,14 +677,25 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 	if (IS_ERR(hsphy->base))
 		return PTR_ERR(hsphy->base);
 
-	ret = qcom_snps_hsphy_clk_init(hsphy);
-	if (ret)
-		return dev_err_probe(dev, ret, "failed to initialize clocks\n");
+	cfg = of_device_get_match_data(dev);
+	if (cfg && cfg->fw_managed) {
+		ret = qcom_snps_domain_attach(hsphy);
+		if (ret)
+			return ret;
+
+		ret = devm_add_action_or_reset(dev, qcom_snps_domain_detach, hsphy);
+		if (ret)
+			return ret;
+	} else {
+		ret = qcom_snps_hsphy_clk_init(hsphy);
+		if (ret)
+			return dev_err_probe(dev, ret, "failed to initialize clocks\n");
 
-	hsphy->phy_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
-	if (IS_ERR(hsphy->phy_reset)) {
-		dev_err(dev, "failed to get phy core reset\n");
-		return PTR_ERR(hsphy->phy_reset);
+		hsphy->phy_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+		if (IS_ERR(hsphy->phy_reset)) {
+			dev_err(dev, "failed to get phy core reset\n");
+			return PTR_ERR(hsphy->phy_reset);
+		}
 	}
 
 	num = ARRAY_SIZE(hsphy->vregs);

-- 
2.55.0


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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing hardware-specific PHY tuning parameters for the Synopsys Femto High-Speed USB PHY V2.
--

--- Patch [1]: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY ---
commit 04bc91a6fe06261e099ae8fda1bb90e34d0f28fc
Author: Mattijs Korpershoek <mkorpershoek@kernel.org>

dt-bindings: phy: Add sa8255p high-speed USB PHY

This commit introduces a new device tree binding for the Qualcomm SA8255p 
Synopsys Femto High-Speed USB PHY V2. It specifies that the hardware uses 
SCMI power domains to manage resources like clocks, interconnects, and 
resets, rather than defining them individually.

> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> new file mode 100644
> index 0000000000000..09f7ca6e7f727
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - "#phy-cells"
> +  - power-domains
> +  - power-domain-names
> +
> +additionalProperties: false

[Severity: Medium]
Since this IP block is still the Synopsys Femto High-Speed USB PHY V2, 
would board configurations for this platform still need to apply standard 
hardware tuning parameters (such as qcom,squelch-detector-bp)?

While clocks and resets are abstracted into SCMI power domains here, the 
memory-mapped reg space is still provided and typically used to program 
these signal characteristics. With additionalProperties set to false, 
schema validation will fail for any board device tree that attempts to 
override these valid PHY tuning properties.

Might it be necessary to include these tuning properties, perhaps by 
referencing a common schema, so that boards can safely tune squelch 
detection and pre-emphasis without triggering validation errors?

> +
> +examples:
> +  - |
> +    soc {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=1

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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing hardware-specific PHY tuning parameters for the Synopsys Femto High-Speed USB PHY V2.
--

--- Patch [1]: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY ---
commit 04bc91a6fe06261e099ae8fda1bb90e34d0f28fc
Author: Mattijs Korpershoek <mkorpershoek@kernel.org>

dt-bindings: phy: Add sa8255p high-speed USB PHY

This commit introduces a new device tree binding for the Qualcomm SA8255p 
Synopsys Femto High-Speed USB PHY V2. It specifies that the hardware uses 
SCMI power domains to manage resources like clocks, interconnects, and 
resets, rather than defining them individually.

> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> new file mode 100644
> index 0000000000000..09f7ca6e7f727
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - "#phy-cells"
> +  - power-domains
> +  - power-domain-names
> +
> +additionalProperties: false

[Severity: Medium]
Since this IP block is still the Synopsys Femto High-Speed USB PHY V2, 
would board configurations for this platform still need to apply standard 
hardware tuning parameters (such as qcom,squelch-detector-bp)?

While clocks and resets are abstracted into SCMI power domains here, the 
memory-mapped reg space is still provided and typically used to program 
these signal characteristics. With additionalProperties set to false, 
schema validation will fail for any board device tree that attempts to 
override these valid PHY tuning properties.

Might it be necessary to include these tuning properties, perhaps by 
referencing a common schema, so that boards can safely tune squelch 
detection and pre-emphasis without triggering validation errors?

> +
> +examples:
> +  - |
> +    soc {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=1

Re: [PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect power domain enablement and teardown ordering in d3 <--> d0 transitions.
- [Medium] The `sa8255p_snps_hs_phy` match data is defined as a scalar struct but iterated over as an array, risking out-of-bounds memory access.
--

--- Patch [2]: [PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P ---
commit 337a4b6fa46b42e255f6aa6b19e2b52e65e59f7d
Author: Sriram Dash <quic_sriramd@quicinc.com>

phy: qcom-snps-femto-v2: Add support for SA8255P

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
> index eb0b0f61d98e0..4a9bd3ae0e535 100644
> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

[ ... ]

> @@ -136,8 +139,81 @@ struct qcom_snps_hsphy {
> +/* d3_to_d0 transition by turning on all the suppliers */
> +static int qcom_snps_d3_to_d0(struct qcom_snps_hsphy *hsphy)
> +{
> +	int ret;
> +
> +	if (!hsphy->pd_list)
> +		return 0;
> +
> +	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
> +	if (ret)
> +		return ret;
> +
> +	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[1]);
> +	if (ret)
> +		pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
> +
> +	return ret;
> +}

[Severity: High]
Does this resume the power domains in the correct order?

The commit message states that the power domain 'core' (pd_devs[1]) controls
the GDSC, and 'transfer' (pd_devs[0]) controls clocks and interconnects.
Resuming 'transfer' before 'core' means clocks are enabled without their
powering GDSC, which could cause bus hangs on Qualcomm SoCs.

Additionally, since state d1 has 'transfer' OFF and 'core' ON, shouldn't 'core'
always be enabled first and disabled last?

> +
> +/* d0_to_d3 transition by turning off all the suppliers */
> +static void qcom_snps_d0_to_d3(struct qcom_snps_hsphy *hsphy)
> +{
> +	if (!hsphy->pd_list)
> +		return;
> +
> +	pm_runtime_put_sync(hsphy->pd_list->pd_devs[1]);
> +	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
> +}

[Severity: High]
Should the 'transfer' domain (pd_devs[0]) be put before the 'core'
domain (pd_devs[1])?

Putting 'core' before 'transfer' disables the GDSC while the clocks are
still active.

[ ... ]

> @@ -316,6 +394,10 @@ static const struct override_param ls_fs_output_impedance_sc7280[] = {
>  	{ 1310, 0 },
>  };
>  
> +static const struct override_param_map sa8255p_snps_hs_phy = {
> +	.fw_managed = true,
> +};
> +

[Severity: Medium]
Will this scalar struct cause an out-of-bounds read in
qcom_snps_hsphy_read_override_param_seq()?

The match data is defined here as a single scalar struct, but
qcom_snps_hsphy_read_override_param_seq() casts the match data to an array and
iterates over it until cfg[i].prop_name != NULL:

drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c:qcom_snps_hsphy_read_override_param_seq() {
    ...
	cfg = of_device_get_match_data(dev);
	if (!cfg)
		return;

	for (i = 0; cfg[i].prop_name != NULL; i++) {
    ...
}

Currently this terminates on the first iteration because the uninitialized
.prop_name field is implicitly NULL, but if a property is ever added to this
struct in the future, it will read past the end of the struct into adjacent
memory.

Should this be defined as an array with an empty sentinel element like the
other param maps?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=2

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

Re: [PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect power domain enablement and teardown ordering in d3 <--> d0 transitions.
- [Medium] The `sa8255p_snps_hs_phy` match data is defined as a scalar struct but iterated over as an array, risking out-of-bounds memory access.
--

--- Patch [2]: [PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P ---
commit 337a4b6fa46b42e255f6aa6b19e2b52e65e59f7d
Author: Sriram Dash <quic_sriramd@quicinc.com>

phy: qcom-snps-femto-v2: Add support for SA8255P

The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.

> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
> index eb0b0f61d98e0..4a9bd3ae0e535 100644
> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

[ ... ]

> @@ -136,8 +139,81 @@ struct qcom_snps_hsphy {
> +/* d3_to_d0 transition by turning on all the suppliers */
> +static int qcom_snps_d3_to_d0(struct qcom_snps_hsphy *hsphy)
> +{
> +	int ret;
> +
> +	if (!hsphy->pd_list)
> +		return 0;
> +
> +	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[0]);
> +	if (ret)
> +		return ret;
> +
> +	ret = pm_runtime_resume_and_get(hsphy->pd_list->pd_devs[1]);
> +	if (ret)
> +		pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
> +
> +	return ret;
> +}

[Severity: High]
Does this resume the power domains in the correct order?

The commit message states that the power domain 'core' (pd_devs[1]) controls
the GDSC, and 'transfer' (pd_devs[0]) controls clocks and interconnects.
Resuming 'transfer' before 'core' means clocks are enabled without their
powering GDSC, which could cause bus hangs on Qualcomm SoCs.

Additionally, since state d1 has 'transfer' OFF and 'core' ON, shouldn't 'core'
always be enabled first and disabled last?

> +
> +/* d0_to_d3 transition by turning off all the suppliers */
> +static void qcom_snps_d0_to_d3(struct qcom_snps_hsphy *hsphy)
> +{
> +	if (!hsphy->pd_list)
> +		return;
> +
> +	pm_runtime_put_sync(hsphy->pd_list->pd_devs[1]);
> +	pm_runtime_put_sync(hsphy->pd_list->pd_devs[0]);
> +}

[Severity: High]
Should the 'transfer' domain (pd_devs[0]) be put before the 'core'
domain (pd_devs[1])?

Putting 'core' before 'transfer' disables the GDSC while the clocks are
still active.

[ ... ]

> @@ -316,6 +394,10 @@ static const struct override_param ls_fs_output_impedance_sc7280[] = {
>  	{ 1310, 0 },
>  };
>  
> +static const struct override_param_map sa8255p_snps_hs_phy = {
> +	.fw_managed = true,
> +};
> +

[Severity: Medium]
Will this scalar struct cause an out-of-bounds read in
qcom_snps_hsphy_read_override_param_seq()?

The match data is defined here as a single scalar struct, but
qcom_snps_hsphy_read_override_param_seq() casts the match data to an array and
iterates over it until cfg[i].prop_name != NULL:

drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c:qcom_snps_hsphy_read_override_param_seq() {
    ...
	cfg = of_device_get_match_data(dev);
	if (!cfg)
		return;

	for (i = 0; cfg[i].prop_name != NULL; i++) {
    ...
}

Currently this terminates on the first iteration because the uninitialized
.prop_name field is implicitly NULL, but if a property is ever added to this
struct in the future, it will read past the end of the struct into adjacent
memory.

Should this be defined as an array with an empty sentinel element like the
other param maps?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=2

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Thu, Jul 30, 2026 at 14:06, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Missing hardware-specific PHY tuning parameters for the Synopsys Femto High-Speed USB PHY V2.
> --
>
> --- Patch [1]: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY ---
> commit 04bc91a6fe06261e099ae8fda1bb90e34d0f28fc
> Author: Mattijs Korpershoek <mkorpershoek@kernel.org>
>
> dt-bindings: phy: Add sa8255p high-speed USB PHY
>
> This commit introduces a new device tree binding for the Qualcomm SA8255p 
> Synopsys Femto High-Speed USB PHY V2. It specifies that the hardware uses 
> SCMI power domains to manage resources like clocks, interconnects, and 
> resets, rather than defining them individually.
>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> new file mode 100644
>> index 0000000000000..09f7ca6e7f727
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>
> [ ... ]
>
>> +required:
>> +  - compatible
>> +  - reg
>> +  - "#phy-cells"
>> +  - power-domains
>> +  - power-domain-names
>> +
>> +additionalProperties: false
>
> [Severity: Medium]
> Since this IP block is still the Synopsys Femto High-Speed USB PHY V2, 
> would board configurations for this platform still need to apply standard 
> hardware tuning parameters (such as qcom,squelch-detector-bp)?
>
> While clocks and resets are abstracted into SCMI power domains here, the 
> memory-mapped reg space is still provided and typically used to program 
> these signal characteristics. With additionalProperties set to false, 
> schema validation will fail for any board device tree that attempts to 
> override these valid PHY tuning properties.
>
> Might it be necessary to include these tuning properties, perhaps by 
> referencing a common schema, so that boards can safely tune squelch 
> detection and pre-emphasis without triggering validation errors?

No, from the testing I've done it's not needed to add any PHY tuning properties.

>
>> +
>> +examples:
>> +  - |
>> +    soc {
>
> [ ... ]
>
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=1

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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Thu, Jul 30, 2026 at 14:06, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Missing hardware-specific PHY tuning parameters for the Synopsys Femto High-Speed USB PHY V2.
> --
>
> --- Patch [1]: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY ---
> commit 04bc91a6fe06261e099ae8fda1bb90e34d0f28fc
> Author: Mattijs Korpershoek <mkorpershoek@kernel.org>
>
> dt-bindings: phy: Add sa8255p high-speed USB PHY
>
> This commit introduces a new device tree binding for the Qualcomm SA8255p 
> Synopsys Femto High-Speed USB PHY V2. It specifies that the hardware uses 
> SCMI power domains to manage resources like clocks, interconnects, and 
> resets, rather than defining them individually.
>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> new file mode 100644
>> index 0000000000000..09f7ca6e7f727
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>
> [ ... ]
>
>> +required:
>> +  - compatible
>> +  - reg
>> +  - "#phy-cells"
>> +  - power-domains
>> +  - power-domain-names
>> +
>> +additionalProperties: false
>
> [Severity: Medium]
> Since this IP block is still the Synopsys Femto High-Speed USB PHY V2, 
> would board configurations for this platform still need to apply standard 
> hardware tuning parameters (such as qcom,squelch-detector-bp)?
>
> While clocks and resets are abstracted into SCMI power domains here, the 
> memory-mapped reg space is still provided and typically used to program 
> these signal characteristics. With additionalProperties set to false, 
> schema validation will fail for any board device tree that attempts to 
> override these valid PHY tuning properties.
>
> Might it be necessary to include these tuning properties, perhaps by 
> referencing a common schema, so that boards can safely tune squelch 
> detection and pre-emphasis without triggering validation errors?

No, from the testing I've done it's not needed to add any PHY tuning properties.

>
>> +
>> +examples:
>> +  - |
>> +    soc {
>
> [ ... ]
>
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260730-phy-qcom-snps-femto-v2-8255-v1-0-8b8bf5105a68@kernel.org?part=1

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Krzysztof Kozlowski]

On Thu, Jul 30, 2026 at 03:58:14PM +0200, Mattijs Korpershoek wrote:
> SA8255p platform abstracts resources such as clocks, interconnect and
> GPIO pins configuration in Firmware. SCMI power protocol is used to
> request resource configurations.
> 
> Two power domains can be requested: transfer and core.
> transfer controls clocks and interconnects and core controls
> the GDSC, resets and TLMM (GPIOs).
> 
> Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
> USB PHY V2 found in SA8255P.
> 
> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
> ---
>  .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> new file mode 100644
> index 000000000000..09f7ca6e7f72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
> +
> +maintainers:
> +  - Mattijs Korpershoek <mkorpershoek@kernel.org>
> +
> +properties:
> +  compatible:
> +    const: qcom,sa8255p-usb-hs-phy
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 0
> +
> +  power-domains:
> +    maxItems: 2
> +
> +  power-domain-names:
> +    items:
> +      - const: transfer
> +      - const: core

Here and in your other binding you call these 'transfer' and 'core' but
all other bindings call them 'power' and 'perf'. Why this difference?
What are these domains responsible for?

Commit msg is pretty useless here - repeats the diff. I can read the
diff but I still do not understand why such naming.

And why core is not the first one? It clearly feels like the power
domain thus the main one.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Krzysztof Kozlowski]

On Thu, Jul 30, 2026 at 03:58:14PM +0200, Mattijs Korpershoek wrote:
> SA8255p platform abstracts resources such as clocks, interconnect and
> GPIO pins configuration in Firmware. SCMI power protocol is used to
> request resource configurations.
> 
> Two power domains can be requested: transfer and core.
> transfer controls clocks and interconnects and core controls
> the GDSC, resets and TLMM (GPIOs).
> 
> Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
> USB PHY V2 found in SA8255P.
> 
> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
> ---
>  .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> new file mode 100644
> index 000000000000..09f7ca6e7f72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
> +
> +maintainers:
> +  - Mattijs Korpershoek <mkorpershoek@kernel.org>
> +
> +properties:
> +  compatible:
> +    const: qcom,sa8255p-usb-hs-phy
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#phy-cells":
> +    const: 0
> +
> +  power-domains:
> +    maxItems: 2
> +
> +  power-domain-names:
> +    items:
> +      - const: transfer
> +      - const: core

Here and in your other binding you call these 'transfer' and 'core' but
all other bindings call them 'power' and 'perf'. Why this difference?
What are these domains responsible for?

Commit msg is pretty useless here - repeats the diff. I can read the
diff but I still do not understand why such naming.

And why core is not the first one? It clearly feels like the power
domain thus the main one.

Best regards,
Krzysztof


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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Tue, Aug 04, 2026 at 10:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On Thu, Jul 30, 2026 at 03:58:14PM +0200, Mattijs Korpershoek wrote:
>> SA8255p platform abstracts resources such as clocks, interconnect and
>> GPIO pins configuration in Firmware. SCMI power protocol is used to
>> request resource configurations.
>> 
>> Two power domains can be requested: transfer and core.
>> transfer controls clocks and interconnects and core controls
>> the GDSC, resets and TLMM (GPIOs).
>> 
>> Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
>> USB PHY V2 found in SA8255P.
>> 
>> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
>> ---
>>  .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> new file mode 100644
>> index 000000000000..09f7ca6e7f72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
>> +
>> +maintainers:
>> +  - Mattijs Korpershoek <mkorpershoek@kernel.org>
>> +
>> +properties:
>> +  compatible:
>> +    const: qcom,sa8255p-usb-hs-phy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#phy-cells":
>> +    const: 0
>> +
>> +  power-domains:
>> +    maxItems: 2
>> +
>> +  power-domain-names:
>> +    items:
>> +      - const: transfer
>> +      - const: core
>
> Here and in your other binding you call these 'transfer' and 'core' but
> all other bindings call them 'power' and 'perf'. Why this difference?

Thanks for the question. I had to do some digging because I did not know
the answer to this.

Per my understanding, the SCMI firmware (in my case, gearvm) exposes
multiple protocols identified by a protocol_id.

For example, power domains have protocol_id=0x11 and and performance
domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
https://support.arm.com/documentation/den0056/f/

Each USB phy has 2 distinct power domains.
This can be observed at runtime from linux via:

/sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
scmi-power-usb0-ss-phy-pm       off-0                           0
scmi-power-usb0-ss-phy-rpm      off-0                           0
scmi-power-usb0-hs-phy-pm       off-0                           0
scmi-power-usb0-hs-phy-rpm      off-0                           0

In the case of the other bindings - for example i2c - there is only one
power domain (0x11) and one perf domain (protocol_id 0x13):

/sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
scmi-perf-i2c0_7                on                              0
scmi-power-i2c0                 off-0                           0

I hope that explains the naming difference. Please let me know if this
is still unclear.

> What are these domains responsible for?

If we take the example of the high-speed (hs) phy, we can see that on
the firmware side, the only difference is the -pm or -rpm suffix.
When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
bindings), the SCMI firmware (gearvm) will interact with the reset line,
the clks and the regulator.
When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
bindings), the SCMI firmware will only interact with the USB clocks
(reset and regulators remain unchanged).

>
> Commit msg is pretty useless here - repeats the diff. I can read the
> diff but I still do not understand why such naming.

'core' controls reset, clocks and regulators.
'transfer' only controls clocks. Putting 'transfer' to 'off' is
interesting in case of runtime suspend/resume as it cuts the data
transfer (by disabling usb clock)

Is it more clear that way?

>
> And why core is not the first one? It clearly feels like the power
> domain thus the main one.

The order is based on how it's defined in the SCMI firmware. It's not a
problem to put 'core' first as power-domain-names property is only used
by the linux driver. Only the SCMI channel (in my case 12) and domain
indices (0,1) matter here.

>
> Best regards,
> Krzysztof

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Tue, Aug 04, 2026 at 10:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On Thu, Jul 30, 2026 at 03:58:14PM +0200, Mattijs Korpershoek wrote:
>> SA8255p platform abstracts resources such as clocks, interconnect and
>> GPIO pins configuration in Firmware. SCMI power protocol is used to
>> request resource configurations.
>> 
>> Two power domains can be requested: transfer and core.
>> transfer controls clocks and interconnects and core controls
>> the GDSC, resets and TLMM (GPIOs).
>> 
>> Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
>> USB PHY V2 found in SA8255P.
>> 
>> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
>> ---
>>  .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> new file mode 100644
>> index 000000000000..09f7ca6e7f72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
>> +
>> +maintainers:
>> +  - Mattijs Korpershoek <mkorpershoek@kernel.org>
>> +
>> +properties:
>> +  compatible:
>> +    const: qcom,sa8255p-usb-hs-phy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#phy-cells":
>> +    const: 0
>> +
>> +  power-domains:
>> +    maxItems: 2
>> +
>> +  power-domain-names:
>> +    items:
>> +      - const: transfer
>> +      - const: core
>
> Here and in your other binding you call these 'transfer' and 'core' but
> all other bindings call them 'power' and 'perf'. Why this difference?

Thanks for the question. I had to do some digging because I did not know
the answer to this.

Per my understanding, the SCMI firmware (in my case, gearvm) exposes
multiple protocols identified by a protocol_id.

For example, power domains have protocol_id=0x11 and and performance
domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
https://support.arm.com/documentation/den0056/f/

Each USB phy has 2 distinct power domains.
This can be observed at runtime from linux via:

/sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
scmi-power-usb0-ss-phy-pm       off-0                           0
scmi-power-usb0-ss-phy-rpm      off-0                           0
scmi-power-usb0-hs-phy-pm       off-0                           0
scmi-power-usb0-hs-phy-rpm      off-0                           0

In the case of the other bindings - for example i2c - there is only one
power domain (0x11) and one perf domain (protocol_id 0x13):

/sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
scmi-perf-i2c0_7                on                              0
scmi-power-i2c0                 off-0                           0

I hope that explains the naming difference. Please let me know if this
is still unclear.

> What are these domains responsible for?

If we take the example of the high-speed (hs) phy, we can see that on
the firmware side, the only difference is the -pm or -rpm suffix.
When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
bindings), the SCMI firmware (gearvm) will interact with the reset line,
the clks and the regulator.
When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
bindings), the SCMI firmware will only interact with the USB clocks
(reset and regulators remain unchanged).

>
> Commit msg is pretty useless here - repeats the diff. I can read the
> diff but I still do not understand why such naming.

'core' controls reset, clocks and regulators.
'transfer' only controls clocks. Putting 'transfer' to 'off' is
interesting in case of runtime suspend/resume as it cuts the data
transfer (by disabling usb clock)

Is it more clear that way?

>
> And why core is not the first one? It clearly feels like the power
> domain thus the main one.

The order is based on how it's defined in the SCMI firmware. It's not a
problem to put 'core' first as power-domain-names property is only used
by the linux driver. Only the SCMI channel (in my case 12) and domain
indices (0,1) matter here.

>
> Best regards,
> Krzysztof

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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Krzysztof Kozlowski]

On 10/08/2026 16:59, Mattijs Korpershoek wrote:
>>> +  power-domain-names:
>>> +    items:
>>> +      - const: transfer
>>> +      - const: core
>>
>> Here and in your other binding you call these 'transfer' and 'core' but
>> all other bindings call them 'power' and 'perf'. Why this difference?
> 
> Thanks for the question. I had to do some digging because I did not know
> the answer to this.
> 
> Per my understanding, the SCMI firmware (in my case, gearvm) exposes
> multiple protocols identified by a protocol_id.
> 
> For example, power domains have protocol_id=0x11 and and performance
> domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
> https://support.arm.com/documentation/den0056/f/
> 
> Each USB phy has 2 distinct power domains.
> This can be observed at runtime from linux via:
> 
> /sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
> scmi-power-usb0-ss-phy-pm       off-0                           0
> scmi-power-usb0-ss-phy-rpm      off-0                           0
> scmi-power-usb0-hs-phy-pm       off-0                           0
> scmi-power-usb0-hs-phy-rpm      off-0                           0

What about perf domains?


> 
> In the case of the other bindings - for example i2c - there is only one
> power domain (0x11) and one perf domain (protocol_id 0x13):
> 
> /sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
> scmi-perf-i2c0_7                on                              0
> scmi-power-i2c0                 off-0                           0
> 
> I hope that explains the naming difference. Please let me know if this
> is still unclear.
> 
>> What are these domains responsible for?
> 
> If we take the example of the high-speed (hs) phy, we can see that on
> the firmware side, the only difference is the -pm or -rpm suffix.
> When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
> bindings), the SCMI firmware (gearvm) will interact with the reset line,
> the clks and the regulator.
> When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
> bindings), the SCMI firmware will only interact with the USB clocks
> (reset and regulators remain unchanged).
> 
>>
>> Commit msg is pretty useless here - repeats the diff. I can read the
>> diff but I still do not understand why such naming.
> 
> 'core' controls reset, clocks and regulators.
> 'transfer' only controls clocks. Putting 'transfer' to 'off' is
> interesting in case of runtime suspend/resume as it cuts the data
> transfer (by disabling usb clock)

Either the binding or the commit msg should be clear that these are
power domains responsible only for power on SA platform, not for perf
(so a power power domain... ehh :/)

> 
> Is it more clear that way?
> 
>>
>> And why core is not the first one? It clearly feels like the power
>> domain thus the main one.
> 
> The order is based on how it's defined in the SCMI firmware. It's not a


Then core goes before transfer.


Best regards,
Krzysztof

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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Krzysztof Kozlowski]

On 10/08/2026 16:59, Mattijs Korpershoek wrote:
>>> +  power-domain-names:
>>> +    items:
>>> +      - const: transfer
>>> +      - const: core
>>
>> Here and in your other binding you call these 'transfer' and 'core' but
>> all other bindings call them 'power' and 'perf'. Why this difference?
> 
> Thanks for the question. I had to do some digging because I did not know
> the answer to this.
> 
> Per my understanding, the SCMI firmware (in my case, gearvm) exposes
> multiple protocols identified by a protocol_id.
> 
> For example, power domains have protocol_id=0x11 and and performance
> domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
> https://support.arm.com/documentation/den0056/f/
> 
> Each USB phy has 2 distinct power domains.
> This can be observed at runtime from linux via:
> 
> /sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
> scmi-power-usb0-ss-phy-pm       off-0                           0
> scmi-power-usb0-ss-phy-rpm      off-0                           0
> scmi-power-usb0-hs-phy-pm       off-0                           0
> scmi-power-usb0-hs-phy-rpm      off-0                           0

What about perf domains?


> 
> In the case of the other bindings - for example i2c - there is only one
> power domain (0x11) and one perf domain (protocol_id 0x13):
> 
> /sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
> scmi-perf-i2c0_7                on                              0
> scmi-power-i2c0                 off-0                           0
> 
> I hope that explains the naming difference. Please let me know if this
> is still unclear.
> 
>> What are these domains responsible for?
> 
> If we take the example of the high-speed (hs) phy, we can see that on
> the firmware side, the only difference is the -pm or -rpm suffix.
> When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
> bindings), the SCMI firmware (gearvm) will interact with the reset line,
> the clks and the regulator.
> When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
> bindings), the SCMI firmware will only interact with the USB clocks
> (reset and regulators remain unchanged).
> 
>>
>> Commit msg is pretty useless here - repeats the diff. I can read the
>> diff but I still do not understand why such naming.
> 
> 'core' controls reset, clocks and regulators.
> 'transfer' only controls clocks. Putting 'transfer' to 'off' is
> interesting in case of runtime suspend/resume as it cuts the data
> transfer (by disabling usb clock)

Either the binding or the commit msg should be clear that these are
power domains responsible only for power on SA platform, not for perf
(so a power power domain... ehh :/)

> 
> Is it more clear that way?
> 
>>
>> And why core is not the first one? It clearly feels like the power
>> domain thus the main one.
> 
> The order is based on how it's defined in the SCMI firmware. It's not a


Then core goes before transfer.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Tue, Aug 11, 2026 at 08:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 10/08/2026 16:59, Mattijs Korpershoek wrote:
>>>> +  power-domain-names:
>>>> +    items:
>>>> +      - const: transfer
>>>> +      - const: core
>>>
>>> Here and in your other binding you call these 'transfer' and 'core' but
>>> all other bindings call them 'power' and 'perf'. Why this difference?
>> 
>> Thanks for the question. I had to do some digging because I did not know
>> the answer to this.
>> 
>> Per my understanding, the SCMI firmware (in my case, gearvm) exposes
>> multiple protocols identified by a protocol_id.
>> 
>> For example, power domains have protocol_id=0x11 and and performance
>> domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
>> https://support.arm.com/documentation/den0056/f/
>> 
>> Each USB phy has 2 distinct power domains.
>> This can be observed at runtime from linux via:
>> 
>> /sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
>> scmi-power-usb0-ss-phy-pm       off-0                           0
>> scmi-power-usb0-ss-phy-rpm      off-0                           0
>> scmi-power-usb0-hs-phy-pm       off-0                           0
>> scmi-power-usb0-hs-phy-rpm      off-0                           0
>
> What about perf domains?

The perf domains for USB are also exposed by the SCMI firmware and are
also registered with genpd:

/sys/kernel/debug/pm_genpd # grep usb0 pm_genpd_summary
scmi-perf-usb0-ss-phy_86        on                              0
scmi-perf-usb0-hs-phy_85        on                              0
scmi-power-usb0-ss-phy-pm       off-0                           0
scmi-power-usb0-ss-phy-rpm      off-0                           0
scmi-power-usb0-hs-phy-pm       off-0                           0
scmi-power-usb0-hs-phy-rpm      off-0                           0
scmi-perf-usb0_0                on                              0
scmi-power-usb0-pm              off-0                           0
scmi-power-usb0-rpm             off-0                           0

They are marked as "on" here GENPD_FLAG_ALWAYS_ON is set in
scmi_perf_domain.c

If we query the SCMI firmware using raw commands, we can get some more
information about the perf domain:

# Get the OPP table for domain 0:
/sys/kernel/debug/scmi/12 # printf '\x04\x4c\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00' > /sys/kernel/debug/scmi/12/raw/message
/sys/kernel/debug/scmi/12 # xxd /sys/kernel/debug/scmi/12/raw/message
00000000: 044c 1800 0000 0000 0800 0000 0a00 0000  .L..............
00000010: 0000 0000 0000 0000 0b00 0000 0000 0000  ................
00000020: 0000 0000 0c00 0000 0000 0000 0000 0000  ................
00000030: 0d00 0000 0000 0000 0000 0000 0e00 0000  ................
00000040: 0000 0000 0000 0000 0f00 0000 0000 0000  ................
00000050: 0000 0000 1000 0000 0000 0000 0000 0000  ................
00000060: 1100 0000 0000 0000 0000 0000            ............

This gives us 8 opps, from 0x0a to 0x11, which look like opaque values.

I did not need to initialize the perf domains (in the driver) in order
to get USB working on my Ride4 (SA8775P) board.
Since the SCMI firmware exposes the perf domains, should I describe them
in the bindings, as optional?

>
>
>> 
>> In the case of the other bindings - for example i2c - there is only one
>> power domain (0x11) and one perf domain (protocol_id 0x13):
>> 
>> /sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
>> scmi-perf-i2c0_7                on                              0
>> scmi-power-i2c0                 off-0                           0
>> 
>> I hope that explains the naming difference. Please let me know if this
>> is still unclear.
>> 
>>> What are these domains responsible for?
>> 
>> If we take the example of the high-speed (hs) phy, we can see that on
>> the firmware side, the only difference is the -pm or -rpm suffix.
>> When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
>> bindings), the SCMI firmware (gearvm) will interact with the reset line,
>> the clks and the regulator.
>> When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
>> bindings), the SCMI firmware will only interact with the USB clocks
>> (reset and regulators remain unchanged).
>> 
>>>
>>> Commit msg is pretty useless here - repeats the diff. I can read the
>>> diff but I still do not understand why such naming.
>> 
>> 'core' controls reset, clocks and regulators.
>> 'transfer' only controls clocks. Putting 'transfer' to 'off' is
>> interesting in case of runtime suspend/resume as it cuts the data
>> transfer (by disabling usb clock)
>
> Either the binding or the commit msg should be clear that these are
> power domains responsible only for power on SA platform, not for perf
> (so a power power domain... ehh :/)

Yeah, the terminology is a bit confusing. In the SCMI spec, we have: *
"Power domain management protocol" for protocol_id=0x11 * "Performance
domain management protocol" for protocol_id=0x13

Since linux models both via genpd (drivers/pmdomain) we end up with a
"power power domain" and a "perf power domain".

I will rephrase the commit msg in the next version.

>
>> 
>> Is it more clear that way?
>> 
>>>
>>> And why core is not the first one? It clearly feels like the power
>>> domain thus the main one.
>> 
>> The order is based on how it's defined in the SCMI firmware. It's not a
>
>
> Then core goes before transfer.

Ok, will change in v2 and update the other series as well.

Thanks again for the reviews.

>
>
> Best regards,
> Krzysztof

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

Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek]

On Tue, Aug 11, 2026 at 08:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 10/08/2026 16:59, Mattijs Korpershoek wrote:
>>>> +  power-domain-names:
>>>> +    items:
>>>> +      - const: transfer
>>>> +      - const: core
>>>
>>> Here and in your other binding you call these 'transfer' and 'core' but
>>> all other bindings call them 'power' and 'perf'. Why this difference?
>> 
>> Thanks for the question. I had to do some digging because I did not know
>> the answer to this.
>> 
>> Per my understanding, the SCMI firmware (in my case, gearvm) exposes
>> multiple protocols identified by a protocol_id.
>> 
>> For example, power domains have protocol_id=0x11 and and performance
>> domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
>> https://support.arm.com/documentation/den0056/f/
>> 
>> Each USB phy has 2 distinct power domains.
>> This can be observed at runtime from linux via:
>> 
>> /sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
>> scmi-power-usb0-ss-phy-pm       off-0                           0
>> scmi-power-usb0-ss-phy-rpm      off-0                           0
>> scmi-power-usb0-hs-phy-pm       off-0                           0
>> scmi-power-usb0-hs-phy-rpm      off-0                           0
>
> What about perf domains?

The perf domains for USB are also exposed by the SCMI firmware and are
also registered with genpd:

/sys/kernel/debug/pm_genpd # grep usb0 pm_genpd_summary
scmi-perf-usb0-ss-phy_86        on                              0
scmi-perf-usb0-hs-phy_85        on                              0
scmi-power-usb0-ss-phy-pm       off-0                           0
scmi-power-usb0-ss-phy-rpm      off-0                           0
scmi-power-usb0-hs-phy-pm       off-0                           0
scmi-power-usb0-hs-phy-rpm      off-0                           0
scmi-perf-usb0_0                on                              0
scmi-power-usb0-pm              off-0                           0
scmi-power-usb0-rpm             off-0                           0

They are marked as "on" here GENPD_FLAG_ALWAYS_ON is set in
scmi_perf_domain.c

If we query the SCMI firmware using raw commands, we can get some more
information about the perf domain:

# Get the OPP table for domain 0:
/sys/kernel/debug/scmi/12 # printf '\x04\x4c\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00' > /sys/kernel/debug/scmi/12/raw/message
/sys/kernel/debug/scmi/12 # xxd /sys/kernel/debug/scmi/12/raw/message
00000000: 044c 1800 0000 0000 0800 0000 0a00 0000  .L..............
00000010: 0000 0000 0000 0000 0b00 0000 0000 0000  ................
00000020: 0000 0000 0c00 0000 0000 0000 0000 0000  ................
00000030: 0d00 0000 0000 0000 0000 0000 0e00 0000  ................
00000040: 0000 0000 0000 0000 0f00 0000 0000 0000  ................
00000050: 0000 0000 1000 0000 0000 0000 0000 0000  ................
00000060: 1100 0000 0000 0000 0000 0000            ............

This gives us 8 opps, from 0x0a to 0x11, which look like opaque values.

I did not need to initialize the perf domains (in the driver) in order
to get USB working on my Ride4 (SA8775P) board.
Since the SCMI firmware exposes the perf domains, should I describe them
in the bindings, as optional?

>
>
>> 
>> In the case of the other bindings - for example i2c - there is only one
>> power domain (0x11) and one perf domain (protocol_id 0x13):
>> 
>> /sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
>> scmi-perf-i2c0_7                on                              0
>> scmi-power-i2c0                 off-0                           0
>> 
>> I hope that explains the naming difference. Please let me know if this
>> is still unclear.
>> 
>>> What are these domains responsible for?
>> 
>> If we take the example of the high-speed (hs) phy, we can see that on
>> the firmware side, the only difference is the -pm or -rpm suffix.
>> When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
>> bindings), the SCMI firmware (gearvm) will interact with the reset line,
>> the clks and the regulator.
>> When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
>> bindings), the SCMI firmware will only interact with the USB clocks
>> (reset and regulators remain unchanged).
>> 
>>>
>>> Commit msg is pretty useless here - repeats the diff. I can read the
>>> diff but I still do not understand why such naming.
>> 
>> 'core' controls reset, clocks and regulators.
>> 'transfer' only controls clocks. Putting 'transfer' to 'off' is
>> interesting in case of runtime suspend/resume as it cuts the data
>> transfer (by disabling usb clock)
>
> Either the binding or the commit msg should be clear that these are
> power domains responsible only for power on SA platform, not for perf
> (so a power power domain... ehh :/)

Yeah, the terminology is a bit confusing. In the SCMI spec, we have: *
"Power domain management protocol" for protocol_id=0x11 * "Performance
domain management protocol" for protocol_id=0x13

Since linux models both via genpd (drivers/pmdomain) we end up with a
"power power domain" and a "perf power domain".

I will rephrase the commit msg in the next version.

>
>> 
>> Is it more clear that way?
>> 
>>>
>>> And why core is not the first one? It clearly feels like the power
>>> domain thus the main one.
>> 
>> The order is based on how it's defined in the SCMI firmware. It's not a
>
>
> Then core goes before transfer.

Ok, will change in v2 and update the other series as well.

Thanks again for the reviews.

>
>
> Best regards,
> Krzysztof