[PATCH v2 10/24] dt-bindings: phy: Add ZTE ZX279128S PCIe PHY binding

[PATCH v2 10/24] dt-bindings: phy: Add ZTE ZX279128S PCIe PHY binding

[Navid Ghahremani]

Add Device Tree binding for the PCIe SerDes PHY found inside the
topcrm block of the ZTE ZX279128S SoC.

Signed-off-by: Navid Ghahremani <ghahramani.navid@gmail.com>
---
 .../bindings/phy/zte,zx279128s-pcie-phy.yaml  | 40 +++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
new file mode 100644
index 0000000000..7bfa363294
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/zte,zx279128s-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE ZX279128S PCIe PHY
+
+maintainers:
+  - Navid Ghahremani <ghahramani.navid@gmail.com>
+
+description:
+  PCIe PHY block inside the ZTE ZX279128S Top CRM.
+
+properties:
+  compatible:
+    const: zte,zx279128s-pcie-phy
+
+  reg:
+    description: Port index (0 or 1)
+    items:
+      - enum: [0, 1]
+
+  "#phy-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    phy@0 {
+        compatible = "zte,zx279128s-pcie-phy";
+        reg = <0>;
+        #phy-cells = <0>;
+    };
-- 
2.55.0


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

Re: [PATCH v2 10/24] dt-bindings: phy: Add ZTE ZX279128S PCIe PHY binding

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: dt_binding_check reg_format failure in example due to missing parent context
- [Low] dt-bindings: phy: Invalid reg property enum constraint
--

commit 7ff99fb8ef3161ab6ed95f85e757575452c473c6
Author: Navid Ghahremani <ghahramani.navid@gmail.com>

dt-bindings: phy: Add ZTE ZX279128S PCIe PHY binding

Add Device Tree binding for the PCIe SerDes PHY found inside the
topcrm block of the ZTE ZX279128S SoC.

> diff --git a/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
> new file mode 100644
> index 0000000000000..7bfa363294c05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml

[ ... ]

> +properties:
> +  compatible:
> +    const: zte,zx279128s-pcie-phy
> +
> +  reg:
> +    description: Port index (0 or 1)
> +    items:
> +      - enum: [0, 1]

[Severity: Low]
Will this schema definition for the reg property pass validation? 

The dt-schema tool translates reg properties into arrays of arrays (matrices).
Enforcing a scalar enum against the array tuple guarantees a schema validation
failure, as a list cannot equal an integer. Could this be corrected by setting
maxItems to 1 instead of specifying items with an enum list?

> +
> +  "#phy-cells":
> +    const: 0
> +
> +required:
> +  - compatible
> +  - reg
> +  - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    phy@0 {
> +        compatible = "zte,zx279128s-pcie-phy";
> +        reg = <0>;

[Severity: Low]
Could this standalone example trigger a compilation warning during make
dt_binding_check?

Because the phy@0 node is placed at the root level without a parent container,
dtc applies the default #address-cells = <1> and #size-cells = <1>. A
size-cells value of 1 requires the reg property to consist of both an address
and a length (2 cells in total).

The 1-cell reg property shown here triggers a reg_format warning in dtc,
causing make dt_binding_check to fail as warnings are treated as errors.

Should the example be enclosed in a parent node (such as soc { ... }) that
sets #address-cells = <1> and #size-cells = <0>?

> +        #phy-cells = <0>;
> +    };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014072109.1759502-1-ghahramani.navid@gmail.com?part=10

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

Re: [PATCH v2 10/24] dt-bindings: phy: Add ZTE ZX279128S PCIe PHY binding

[Krzysztof Kozlowski]

On Wed, Oct 14, 2026 at 08:20:50AM +0100, Navid Ghahremani wrote:
> Add Device Tree binding for the PCIe SerDes PHY found inside the
> topcrm block of the ZTE ZX279128S SoC.
> 
> Signed-off-by: Navid Ghahremani <ghahramani.navid@gmail.com>
> ---
>  .../bindings/phy/zte,zx279128s-pcie-phy.yaml  | 40 +++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
> new file mode 100644
> index 0000000000..7bfa363294
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/zte,zx279128s-pcie-phy.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/zte,zx279128s-pcie-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ZTE ZX279128S PCIe PHY
> +
> +maintainers:
> +  - Navid Ghahremani <ghahramani.navid@gmail.com>
> +
> +description:
> +  PCIe PHY block inside the ZTE ZX279128S Top CRM.
> +
> +properties:
> +  compatible:
> +    const: zte,zx279128s-pcie-phy
> +
> +  reg:
> +    description: Port index (0 or 1)
> +    items:
> +      - enum: [0, 1]

No, that's pointless. What is this index meaning on the bus?

> +
> +  "#phy-cells":
> +    const: 0
> +

No other resources? Then this belongs to the parent node.

Best regards,
Krzysztof


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

[PATCH v2 11/24] phy: zte: Add ZTE ZX279128S PCIe PHY driver

[Navid Ghahremani]

Add a generic PHY driver for the PCIe SerDes PHY inside the Top CRM
block of the ZTE ZX279128S SoC. This driver encapsulates PLL power
and analog SerDes calibration for the two PCIe ports, isolating
these hardware details from the PCIe host controller driver.

Signed-off-by: Navid Ghahremani <ghahramani.navid@gmail.com>
---
 drivers/phy/Kconfig              |  12 +++
 drivers/phy/Makefile             |   1 +
 drivers/phy/phy-zx279128s-pcie.c | 156 +++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+)
 create mode 100644 drivers/phy/phy-zx279128s-pcie.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b..3518d384be 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -91,6 +91,18 @@ config PHY_ECONET_PCIE
 	  callback for PCIe GEN1 and GEN2 ports. This PHY is found on
 	  EcoNet SoCs including EN751221 and EN7528.
 
+config PHY_ZX279128S_PCIE
+	tristate "ZTE ZX279128S PCIe PHY driver"
+	depends on ARCH_ZTE || COMPILE_TEST
+	depends on OF
+	select GENERIC_PHY
+	select MFD_SYSCON
+	help
+	  Enable support for the PCIe SerDes PHY found inside the Top CRM
+	  of ZTE ZX279128S SoCs. This driver configures PLL power and analog
+	  calibration for the two PCIe ports.
+	  If you say Y or M here, you will enable PCIe PHY initialization.
+
 config PHY_GOOGLE_USB
 	tristate "Google Tensor SoC USB PHY driver"
 	select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d7aa516bcc..1323aa817f 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PHY_NXP_TJA1145)		+= phy-nxp-tja1145.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_SNPS_EUSB2)		+= phy-snps-eusb2.o
 obj-$(CONFIG_PHY_XGENE)			+= phy-xgene.o
+obj-$(CONFIG_PHY_ZX279128S_PCIE)	+= phy-zx279128s-pcie.o
 
 obj-$(CONFIG_GENERIC_PHY)		+= allwinner/	\
 					   amlogic/	\
diff --git a/drivers/phy/phy-zx279128s-pcie.c b/drivers/phy/phy-zx279128s-pcie.c
new file mode 100644
index 0000000000..33bf0eaac8
--- /dev/null
+++ b/drivers/phy/phy-zx279128s-pcie.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ZTE zx279128s PCIe PHY driver
+ *
+ * Controls the analog SerDes and PLL for the two PCIe ports inside the
+ * Top CRM block.
+ *
+ * Copyright (C) 2026 Navid Ghahremani <ghahramani.navid@gmail.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define CRM1_PHY_CTRL		0x008
+#define CRM1_MISC		0x024
+#define CRM1_MISC_BIT26		BIT(26)
+#define CRM1_PHY1_CAL0		0x1b0
+#define CRM1_PHY1_CAL1		0x1b4
+
+struct zx_pcie_phy_port {
+	u32 phy_on[3];
+	bool has_cal;
+};
+
+static const struct zx_pcie_phy_port zx_phy_ports[] = {
+	[0] = {
+		.phy_on = { BIT(15), BIT(13), BIT(14) },
+	},
+	[1] = {
+		.phy_on = { BIT(27), BIT(25), BIT(26) },
+		.has_cal = true,
+	},
+};
+
+struct zx_pcie_phy {
+	struct regmap *regmap;
+	const struct zx_pcie_phy_port *port;
+	unsigned int port_id;
+};
+
+static int zx_pcie_phy_init(struct phy *phy)
+{
+	struct zx_pcie_phy *zphy = phy_get_drvdata(phy);
+	const struct zx_pcie_phy_port *port = zphy->port;
+	int i, ret;
+
+	for (i = 0; i < ARRAY_SIZE(port->phy_on); i++) {
+		ret = regmap_write_bits(zphy->regmap, CRM1_PHY_CTRL,
+					port->phy_on[i], port->phy_on[i]);
+		if (ret)
+			return ret;
+		fsleep(50);
+
+		if (i == 0 && port->has_cal) {
+			ret = regmap_write(zphy->regmap, CRM1_PHY1_CAL1, 0x00202d5a);
+			if (ret)
+				return ret;
+			ret = regmap_write(zphy->regmap, CRM1_PHY1_CAL0, 0x0046c24a);
+			if (ret)
+				return ret;
+		}
+	}
+
+	ret = regmap_write_bits(zphy->regmap, CRM1_MISC, CRM1_MISC_BIT26, 0);
+	if (ret)
+		return ret;
+	fsleep(50);
+
+	return 0;
+}
+
+static int zx_pcie_phy_exit(struct phy *phy)
+{
+	struct zx_pcie_phy *zphy = phy_get_drvdata(phy);
+	const struct zx_pcie_phy_port *port = zphy->port;
+	int i, ret;
+
+	for (i = ARRAY_SIZE(port->phy_on) - 1; i >= 0; i--) {
+		ret = regmap_write_bits(zphy->regmap, CRM1_PHY_CTRL,
+					port->phy_on[i], 0);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const struct phy_ops zx_pcie_phy_ops = {
+	.init = zx_pcie_phy_init,
+	.exit = zx_pcie_phy_exit,
+	.owner = THIS_MODULE,
+};
+
+static int zx_pcie_phy_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct phy_provider *provider;
+	struct zx_pcie_phy *zphy;
+	struct phy *phy;
+	u32 port_id;
+	int ret;
+
+	zphy = devm_kzalloc(dev, sizeof(*zphy), GFP_KERNEL);
+	if (!zphy)
+		return -ENOMEM;
+
+	ret = of_property_read_u32(dev->of_node, "reg", &port_id);
+	if (ret)
+		return dev_err_probe(dev, ret, "missing reg property\n");
+
+	if (port_id >= ARRAY_SIZE(zx_phy_ports))
+		return dev_err_probe(dev, -EINVAL, "invalid port id %u\n", port_id);
+
+	zphy->port_id = port_id;
+	zphy->port = &zx_phy_ports[port_id];
+
+	zphy->regmap = syscon_node_to_regmap(dev->parent->of_node);
+	if (IS_ERR(zphy->regmap))
+		return dev_err_probe(dev, PTR_ERR(zphy->regmap),
+				     "failed to get parent topcrm regmap\n");
+
+	phy = devm_phy_create(dev, dev->of_node, &zx_pcie_phy_ops);
+	if (IS_ERR(phy))
+		return dev_err_probe(dev, PTR_ERR(phy), "failed to create phy\n");
+
+	phy_set_drvdata(phy, zphy);
+
+	provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(provider);
+}
+
+static const struct of_device_id zx_pcie_phy_of_match[] = {
+	{ .compatible = "zte,zx279128s-pcie-phy" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, zx_pcie_phy_of_match);
+
+static struct platform_driver zx_pcie_phy_driver = {
+	.probe = zx_pcie_phy_probe,
+	.driver = {
+		.name = "zx279128s-pcie-phy",
+		.of_match_table = zx_pcie_phy_of_match,
+		.suppress_bind_attrs = true,
+	},
+};
+builtin_platform_driver(zx_pcie_phy_driver);
+
+MODULE_AUTHOR("Navid Ghahremani <ghahramani.navid@gmail.com>");
+MODULE_DESCRIPTION("ZTE ZX279128S PCIe PHY driver");
+MODULE_LICENSE("GPL");
-- 
2.55.0


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

Re: [PATCH v2 11/24] phy: zte: Add ZTE ZX279128S PCIe PHY driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] phy: missing error path cleanup in zx_pcie_phy_init()
- [Low] phy: incomplete hardware teardown on error in zx_pcie_phy_exit()
- [Low] kconfig: PHY_ZX279128S_PCIE selects MFD_SYSCON without HAS_IOMEM
--

commit 9afe9a48cb2bc29d0bfd7f5b0a437a5d1621c1b4
Author: Navid Ghahremani <ghahramani.navid@gmail.com>

phy: zte: Add ZTE ZX279128S PCIe PHY driver

Add a generic PHY driver for the PCIe SerDes PHY inside the Top CRM
block of the ZTE ZX279128S SoC. This driver encapsulates PLL power
and analog SerDes calibration for the two PCIe ports.

> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19f3b7d12b7d4..3518d384be854 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
[ ... ]
> @@ -91,6 +91,18 @@ config PHY_ECONET_PCIE
>  	  callback for PCIe GEN1 and GEN2 ports. This PHY is found on
>  	  EcoNet SoCs including EN751221 and EN7528.
>  
> +config PHY_ZX279128S_PCIE
> +	tristate "ZTE ZX279128S PCIe PHY driver"
> +	depends on ARCH_ZTE || COMPILE_TEST
> +	depends on OF
> +	select GENERIC_PHY
> +	select MFD_SYSCON

[Severity: Low]
Does selecting MFD_SYSCON here without a HAS_IOMEM dependency cause an unmet
direct dependency warning? Because this driver supports COMPILE_TEST, it could
be built on architectures without HAS_IOMEM (like UML), where MFD_SYSCON
cannot be naturally enabled.

> +	help
> +	  Enable support for the PCIe SerDes PHY found inside the Top CRM
> +	  of ZTE ZX279128S SoCs. This driver configures PLL power and analog
[ ... ]
> diff --git a/drivers/phy/phy-zx279128s-pcie.c b/drivers/phy/phy-zx279128s-pcie.c
> new file mode 100644
> index 0000000000000..33bf0eaac8f74
> --- /dev/null
> +++ b/drivers/phy/phy-zx279128s-pcie.c
[ ... ]
> +static int zx_pcie_phy_init(struct phy *phy)
> +{
> +	struct zx_pcie_phy *zphy = phy_get_drvdata(phy);
> +	const struct zx_pcie_phy_port *port = zphy->port;
> +	int i, ret;
> +
> +	for (i = 0; i < ARRAY_SIZE(port->phy_on); i++) {
> +		ret = regmap_write_bits(zphy->regmap, CRM1_PHY_CTRL,
> +					port->phy_on[i], port->phy_on[i]);
> +		if (ret)
> +			return ret;

[Severity: Medium]
Can this leave the PHY blocks in an inconsistent state? If regmap_write_bits()
fails on a later iteration (for example, when i > 0), this loop returns
immediately and leaves the hardware resources from previous iterations powered
on.

Since the PHY framework's phy_init() does not invoke the phy_exit() callback
if initialization fails, the driver likely needs to manually unwind the power
bits before returning the error.

> +		fsleep(50);
> +
> +		if (i == 0 && port->has_cal) {
> +			ret = regmap_write(zphy->regmap, CRM1_PHY1_CAL1, 0x00202d5a);
> +			if (ret)
> +				return ret;

[Severity: Medium]
Similarly, if either of these calibration writes fail, we return without
clearing the CRM1_PHY_CTRL bits that were already successfully set. Should
there be an error path here that unwinds the state?

> +			ret = regmap_write(zphy->regmap, CRM1_PHY1_CAL0, 0x0046c24a);
> +			if (ret)
> +				return ret;
> +		}
> +	}
[ ... ]
> +static int zx_pcie_phy_exit(struct phy *phy)
> +{
> +	struct zx_pcie_phy *zphy = phy_get_drvdata(phy);
> +	const struct zx_pcie_phy_port *port = zphy->port;
> +	int i, ret;
> +
> +	for (i = ARRAY_SIZE(port->phy_on) - 1; i >= 0; i--) {
> +		ret = regmap_write_bits(zphy->regmap, CRM1_PHY_CTRL,
> +					port->phy_on[i], 0);
> +		if (ret)
> +			return ret;

[Severity: Low]
Does this early return leave the hardware partially active on teardown? If
regmap_write_bits() fails while clearing one of the bits, we abort the loop
early.

It might be safer to record the error but continue unwinding the remaining
bits to ensure the fullest possible teardown.

> +	}
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014072109.1759502-1-ghahramani.navid@gmail.com?part=11

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