Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 3/5] dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
From: sashiko-bot @ 2026-05-15 11:18 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: krzk+dt, linux-phy, robh, devicetree, vkoul, neil.armstrong,
	conor+dt, olteanv
In-Reply-To: <20260515-usb2phy-v1-3-5f8338d466bf@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new compatible string `qcom,ipq5210-dwc3` is added to the top-level `compatible` list but is omitted from the `allOf` conditional blocks that enforce device-specific constraints.
--

commit f7f00d62e8a27abcab7835184425ce9a31f1b2c3
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
    
Update dt-bindings to add ipq5210 to USB DWC3 controller list.

> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> index a7f58114c02e8..f8e0819be894b 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> @@ -26,6 +26,7 @@ properties:
>        - enum:
>            - qcom,ipq4019-dwc3
>            - qcom,ipq5018-dwc3
> +          - qcom,ipq5210-dwc3

Should this new compatible string also be added to the allOf conditional blocks
that enforce constraints for related hardware?

Similar generations like ipq5018 and ipq5332 enforce clock and interrupt
limits further down in the file:

allOf:
  - if:
      properties:
        compatible:
          contains:
            enum:
              - qcom,ipq5018-dwc3
              - qcom,ipq5332-dwc3
    then:
      properties:
        interrupts:
          maxItems: 3

Does ipq5210 share these constraints, and should it be added to the appropriate
conditionals?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com?part=3

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

^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
From: sashiko-bot @ 2026-05-15 11:13 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: conor+dt, linux-phy, olteanv, krzk+dt, vkoul, devicetree,
	neil.armstrong, robh
In-Reply-To: <20260515-usb2phy-v1-2-5f8338d466bf@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new compatible string `qcom,ipq5210-qmp-usb3-phy` was added to the top-level `compatible` list but omitted from the `allOf` conditional block that enforces clock constraints for IPQ variants.
--

commit edd84912abfa4d10414e59ffbc64829f54fe7871
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY

Add dt-bindings for USB3 PHY found on Qualcomm ipq5210.

> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> index 623c2f8c7d220..bdb80371ea685 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> @@ -17,6 +17,7 @@ properties:
>    compatible:
>      enum:
>        - qcom,glymur-qmp-usb3-uni-phy
> +      - qcom,ipq5210-qmp-usb3-phy
>        - qcom,ipq5424-qmp-usb3-phy
>        - qcom,ipq6018-qmp-usb3-phy
>        - qcom,ipq8074-qmp-usb3-phy

Looking at the rest of this file, the other IPQ variants have specific
clock constraints defined:

allOf:
  - if:
      properties:
        compatible:
          contains:
            enum:
              - qcom,ipq5424-qmp-usb3-phy
              - qcom,ipq6018-qmp-usb3-phy
              - qcom,ipq8074-qmp-usb3-phy
              - qcom,ipq9574-qmp-usb3-phy
[ ... ]
    then:
      properties:
        clocks:
          maxItems: 4
        clock-names:
          items:
            - const: aux
            - const: ref
            - const: cfg_ahb
            - const: pipe

If qcom,ipq5210-qmp-usb3-phy is omitted from this enum array, it bypasses
these specific clock constraints and invalid device tree configurations might
silently pass schema validation.

Should this new compatible string also be added to the allOf conditional
block that enforces the clock constraints for the other IPQ variants?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com?part=2

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

^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
From: Krzysztof Kozlowski @ 2026-05-15 11:05 UTC (permalink / raw)
  To: Varadarajan Narayanan, Vinod Koul, Neil Armstrong, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
	Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb
In-Reply-To: <20260515-usb2phy-v1-3-5f8338d466bf@oss.qualcomm.com>

On 15/05/2026 12:47, Varadarajan Narayanan wrote:
> Update dt-bindings to add ipq5210 to USB DWC3 controller list.
> 
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
>  1 file changed, 1 insertion(+)

Same feedback as usually. What USB patch is doing here?

Also, other typical comment:
A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Considering that did not pass through internal review toolset and it has
trivial issues, which this toolset and internal review is suppose to
catch, I drop all patches from you from the DT Patchwork.

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 phy-next 2/2] phy: ti: add PHY driver for TI DS125DF111 Dual-Channel Retimer
From: Ioana Ciornei @ 2026-05-15 11:01 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
  Cc: devicetree, linux-kernel
In-Reply-To: <20260515110145.1925579-1-ioana.ciornei@nxp.com>

Add a generic PHY driver for the TI DS125DF111 Multi-Protocol
Dual-Channel Retimer. The driver currently supports only 10G and 1G link
speeds but it can easily extended to also cover other usecases.

Since the available datasheet (https://www.ti.com/lit/gpn/DS125DF111)
does not name the registers, the name for the macros were determined by
their usage pattern.

A PHY device is created for each of the two channels present on the
retimer. This allows for independent configuration of the two channels.
This capability is especially important on retimers which have more than
2 channels that can be, depending on the board design, connected in
multiple different ways to the SerDes lanes.

Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v2:
- Explicitly include all the needed headers
- Change ds125df111_xlate() so that it returns an error if args_count is
not exactly 1
- Add a MAINTAINERS entry
---
 MAINTAINERS                     |   7 +
 drivers/phy/ti/Kconfig          |  10 ++
 drivers/phy/ti/Makefile         |   1 +
 drivers/phy/ti/phy-ds125df111.c | 252 ++++++++++++++++++++++++++++++++
 4 files changed, 270 insertions(+)
 create mode 100644 drivers/phy/ti/phy-ds125df111.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f877e5aaf2c7..58f410b666e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26781,6 +26781,13 @@ T:	git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
 F:	drivers/media/platform/ti/davinci/
 F:	include/media/davinci/
 
+TI DS125DF111 RETIMER PHY DRIVER
+M:	Ioana Ciornei <ioana.ciornei@nxp.com>
+L:	linux-phy@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
+F:	drivers/phy/ti/phy-ds125df111.c
+
 TI ENHANCED CAPTURE (eCAP) DRIVER
 M:	Vignesh Raghavendra <vigneshr@ti.com>
 R:	Julien Panis <jpanis@baylibre.com>
diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig
index b40f28019131..475e80fcd52d 100644
--- a/drivers/phy/ti/Kconfig
+++ b/drivers/phy/ti/Kconfig
@@ -111,3 +111,13 @@ config PHY_TI_GMII_SEL
 	help
 	  This driver supports configuring of the TI CPSW Port mode depending on
 	  the Ethernet PHY connected to the CPSW Port.
+
+config PHY_TI_DS125DF111
+	tristate "DS125DF111 2-Channel Retimer Driver"
+	depends on OF && I2C
+	select GENERIC_PHY
+	help
+	  Enable this to add support for configuration and runtime management
+	  of the TI DS125DF111 Multi-Protocol 2-Channel Retimer.
+	  The retimer is modeled as a Generic PHY and supports both 10G and 1G
+	  link speeds.
diff --git a/drivers/phy/ti/Makefile b/drivers/phy/ti/Makefile
index dcba2571c9bd..e68445ddd848 100644
--- a/drivers/phy/ti/Makefile
+++ b/drivers/phy/ti/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_TWL4030_USB)		+= phy-twl4030-usb.o
 obj-$(CONFIG_PHY_AM654_SERDES)		+= phy-am654-serdes.o
 obj-$(CONFIG_PHY_TI_GMII_SEL)		+= phy-gmii-sel.o
 obj-$(CONFIG_PHY_J721E_WIZ)		+= phy-j721e-wiz.o
+obj-$(CONFIG_PHY_TI_DS125DF111)		+= phy-ds125df111.o
diff --git a/drivers/phy/ti/phy-ds125df111.c b/drivers/phy/ti/phy-ds125df111.c
new file mode 100644
index 000000000000..084a94e655c2
--- /dev/null
+++ b/drivers/phy/ti/phy-ds125df111.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2026 NXP */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/phy/phy.h>
+#include <linux/slab.h>
+
+#define DS125DF111_NUM_CH			2
+#define DS125DF111_NUM_VCO_GROUP_REG		5
+
+#define DS125DF111_CH_SELECT			0xff
+#define DS125DF111_CH_SELECT_TARGET_MASK	GENMASK(3, 0)
+#define DS125DF111_CH_SELECT_EN			BIT(2)
+
+#define DS125DF111_CH_CTRL			0x00
+#define DS125DF111_CH_CTRL_RESET		BIT(2) /* self clearing */
+
+#define DS125DF111_VCO_GROUP_BASE		0x60
+
+#define DS125DF111_RATIOS			0x2F
+#define DS125DF111_RATIOS_RATE_MASK		GENMASK(7, 6)
+#define DS125DF111_RATIOS_SUBRATE_MASK		GENMASK(5, 4)
+
+struct ds125df111_ch {
+	struct phy *phy;
+	struct ds125df111_priv *priv;
+	int idx;
+};
+
+struct ds125df111_priv {
+	struct ds125df111_ch ch[DS125DF111_NUM_CH];
+	struct i2c_client *client;
+	struct mutex mutex; /* protects access to shared registers */
+};
+
+enum ds125df111_mode {
+	FREQ_1G,
+	FREQ_10G,
+};
+
+static const struct ds125df111_config {
+	u8 vco_group[DS125DF111_NUM_VCO_GROUP_REG];
+	u8 rate;
+	u8 subrate;
+} ds125df111_cfg[] = {
+	[FREQ_1G] = {
+		/* VCO group #0 = 10GHz, VCO group #1 = 10GHz */
+		.vco_group = {0x00, 0xB2, 0x00, 0xB2, 0xCC},
+		/* By using the following combination of rate and subrate we
+		 * select divide ratios of 1, 2, 4, 8 on both groups
+		 */
+		.rate = 0x1,
+		.subrate = 0x2,
+	},
+
+	[FREQ_10G] = {
+		/* VCO group #0 = 10.3125GHz, VCO group #1 = 10.3125GHz */
+		.vco_group = {0x90, 0xB3, 0x90, 0xB3, 0xCD},
+		/* By using the following combination of rate and subrate we
+		 * select divide ratios of 1 on both groups
+		 */
+		.rate = 0x1,
+		.subrate = 0x3,
+	},
+};
+
+static int ds125df111_configure(struct phy *phy,
+				const struct ds125df111_config *cfg)
+{
+	struct ds125df111_ch *ch = phy_get_drvdata(phy);
+	struct ds125df111_priv *priv = ch->priv;
+	struct i2c_client *i2c = priv->client;
+	struct device *dev = &phy->dev;
+	u8 val;
+	int err, i;
+
+	mutex_lock(&priv->mutex);
+
+	/* Make sure that any subsequent read/write operation will be directed
+	 * only to the registers of the selected channel
+	 */
+	err = i2c_smbus_read_byte_data(i2c, DS125DF111_CH_SELECT);
+	if (err < 0) {
+		dev_err(dev, "Unable to select channel\n");
+		goto out;
+	}
+	val = (u8)err;
+	val &= ~DS125DF111_CH_SELECT_TARGET_MASK;
+	val |= DS125DF111_CH_SELECT_EN | ch->idx;
+	err = i2c_smbus_write_byte_data(i2c, DS125DF111_CH_SELECT, val);
+	if (err < 0) {
+		dev_err(dev, "Unable to select channel\n");
+		goto out;
+	}
+
+	/* Reset Channel Registers */
+	err = i2c_smbus_read_byte_data(i2c, DS125DF111_CH_CTRL);
+	if (err < 0) {
+		dev_err(dev, "Error resetting channel configuration\n");
+		goto out;
+	}
+	val = (u8)err;
+	val |= DS125DF111_CH_CTRL_RESET;
+	err = i2c_smbus_write_byte_data(i2c, DS125DF111_CH_CTRL, val);
+	if (err < 0) {
+		dev_err(dev, "Error resetting channel configuration\n");
+		goto out;
+	}
+
+	/* Program the VCO group frequencies */
+	for (i = 0; i < DS125DF111_NUM_VCO_GROUP_REG; i++) {
+		err = i2c_smbus_write_byte_data(i2c,
+						DS125DF111_VCO_GROUP_BASE + i,
+						cfg->vco_group[i]);
+		if (err < 0) {
+			dev_err(dev, "Error programming VCO group frequencies\n");
+			goto out;
+		}
+	}
+
+	/* Set the Divide Ratios for the VCO Groups*/
+	err = i2c_smbus_read_byte_data(i2c, DS125DF111_RATIOS);
+	if (err < 0) {
+		dev_err(dev, "Error programming the divide ratios\n");
+		goto out;
+	}
+	val = (u8)err;
+	val &= ~(DS125DF111_RATIOS_RATE_MASK | DS125DF111_RATIOS_SUBRATE_MASK);
+	val |= FIELD_PREP(DS125DF111_RATIOS_RATE_MASK, cfg->rate) |
+		FIELD_PREP(DS125DF111_RATIOS_SUBRATE_MASK, cfg->subrate);
+	err = i2c_smbus_write_byte_data(i2c, DS125DF111_RATIOS, val);
+	if (err < 0) {
+		dev_err(dev, "Error programming the divide ratios\n");
+		goto out;
+	}
+
+	mutex_unlock(&priv->mutex);
+
+	return 0;
+
+out:
+	mutex_unlock(&priv->mutex);
+
+	return err;
+}
+
+static int ds125df111_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	const struct ds125df111_config *cfg;
+
+	if (mode != PHY_MODE_ETHERNET)
+		return -EOPNOTSUPP;
+
+	switch (submode) {
+	case PHY_INTERFACE_MODE_10GBASER:
+		cfg = &ds125df111_cfg[FREQ_10G];
+		break;
+	case PHY_INTERFACE_MODE_1000BASEX:
+	case PHY_INTERFACE_MODE_SGMII:
+		cfg = &ds125df111_cfg[FREQ_1G];
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	return ds125df111_configure(phy, cfg);
+}
+
+static const struct phy_ops ds125df111_ops = {
+	.set_mode	= ds125df111_set_mode,
+	.owner		= THIS_MODULE,
+};
+
+static struct phy *ds125df111_xlate(struct device *dev,
+				    const struct of_phandle_args *args)
+{
+	struct ds125df111_priv *priv = dev_get_drvdata(dev);
+	u32 idx;
+
+	if (args->args_count != 1)
+		return ERR_PTR(-EINVAL);
+
+	idx = args->args[0];
+	if (idx >= DS125DF111_NUM_CH) {
+		dev_err(dev, "Maximum number of channels is %d\n",
+			DS125DF111_NUM_CH);
+		return ERR_PTR(-EINVAL);
+	}
+
+	return priv->ch[idx].phy;
+}
+
+static int ds125df111_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct phy_provider *provider;
+	struct ds125df111_priv *priv;
+	int i, err;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+	priv->client = client;
+	err = devm_mutex_init(dev, &priv->mutex);
+	if (err)
+		return err;
+
+	i2c_set_clientdata(client, priv);
+
+	for (i = 0; i < DS125DF111_NUM_CH; i++) {
+		struct ds125df111_ch *ch = &priv->ch[i];
+		struct phy *phy;
+
+		phy = devm_phy_create(dev, NULL, &ds125df111_ops);
+		if (IS_ERR(phy))
+			return PTR_ERR(phy);
+
+		ch->idx = i;
+		ch->priv = priv;
+		ch->phy = phy;
+
+		phy_set_drvdata(phy, ch);
+	}
+
+	provider = devm_of_phy_provider_register(dev, ds125df111_xlate);
+
+	return PTR_ERR_OR_ZERO(provider);
+}
+
+static const struct of_device_id ds125df111_dt_ids[] = {
+	{ .compatible = "ti,ds125df111", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ds125df111_dt_ids);
+
+static struct i2c_driver ds125df111_driver = {
+	.driver = {
+		.name = "ds125df111",
+		.of_match_table = ds125df111_dt_ids,
+	},
+	.probe = ds125df111_probe,
+};
+module_i2c_driver(ds125df111_driver);
+
+MODULE_AUTHOR("Ioana Ciornei <ioana.ciornei@nxp.com>");
+MODULE_DESCRIPTION("TI DS125DF111 Retimer driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1


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

^ permalink raw reply related
* [PATCH v2 phy-next 1/2] dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
From: Ioana Ciornei @ 2026-05-15 11:01 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
  Cc: devicetree, linux-kernel
In-Reply-To: <20260515110145.1925579-1-ioana.ciornei@nxp.com>

Add device tree binding for the TI DS125DF111 Retimer PHY.

Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
- Remove the label from the example
- Rename the node from 'retimer' to 'phy'
---
 .../bindings/phy/ti,ds125df111.yaml           | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml

diff --git a/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml b/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
new file mode 100644
index 000000000000..ca4605f1d664
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,ds125df111.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DS125DF111 Retimer PHY
+
+description:
+  This binding describes the TI DS125DF111 multi-protocol Retimer PHY.
+
+maintainers:
+  - Ioana Ciornei <ioana.ciornei@nxp.com>
+
+properties:
+  compatible:
+    const: ti,ds125df111
+
+  reg:
+    maxItems: 1
+
+  "#phy-cells":
+    const: 1
+    description: |
+      The phandle's argument in the PHY specifier selects one of the two
+      channels of the retimer
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      phy@18 {
+        compatible = "ti,ds125df111";
+        reg = <0x18>;
+        #phy-cells = <1>;
+      };
+    };
-- 
2.25.1


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

^ permalink raw reply related
* [PATCH v2 phy-next 0/2] phy: ti: add driver for TI DS125DF111 Dual-Channel Retimer
From: Ioana Ciornei @ 2026-05-15 11:01 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy
  Cc: devicetree, linux-kernel

This patch set adds a generic PHY driver and the corresponding DT
binding for the TI DS125DF111 Dual-Channel retimer. The datasheet on
which this driver was based on can be found at -
https://www.ti.com/lit/gpn/DS125DF111.

A separate generic PHY is registered for each of the two channels of the
retimer, so consumers can drive each channel independently. This allows
for independent control of the channels, which is especially important
since each channel can be routed to different SerDes lanes and it is not
guaranteed that the same retimer will do both directions of SerDes lane.

This was tested on a LS1088ARDB board with the Lynx10G SerDes PHY driver
yet to be submitted.

Changes in v2:
- Remove the label from the example
- Rename the node from 'retimer' to 'phy'
- Explicitly include all the needed headers
- Change ds125df111_xlate() so that it returns an error if args_count is
not exactly 1
- Add a MAINTAINERS entry
- Link to v1: https://lore.kernel.org/all/20260513185103.1371809-1-ioana.ciornei@nxp.com/

Ioana Ciornei (2):
  dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
  phy: ti: add PHY driver for TI DS125DF111 Dual-Channel Retimer

 .../bindings/phy/ti,ds125df111.yaml           |  46 ++++
 MAINTAINERS                                   |   7 +
 drivers/phy/ti/Kconfig                        |  10 +
 drivers/phy/ti/Makefile                       |   1 +
 drivers/phy/ti/phy-ds125df111.c               | 252 ++++++++++++++++++
 5 files changed, 316 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
 create mode 100644 drivers/phy/ti/phy-ds125df111.c

-- 
2.25.1


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

^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Varadarajan Narayanan @ 2026-05-15 10:50 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260515-optimistic-hedgehog-of-penetration-b34227@quoll>

On Fri, May 15, 2026 at 12:47:00PM +0200, Krzysztof Kozlowski wrote:
> On Thu, May 14, 2026 at 09:28:28AM +0530, Varadarajan Narayanan wrote:
> > Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
> > as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.
> >
> > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > ---
> >  Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> > index f60804687412..1ac31439c20a 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> > @@ -17,6 +17,7 @@ properties:
> >    compatible:
> >      oneOf:
> >        - enum:
> > +          - qcom,ipq5210-qmp-gen3x1-pcie-phy
>
> 5210-qmp-gen3x1 here
>
> >            - qcom,ipq6018-qmp-pcie-phy
> >            - qcom,ipq8074-qmp-gen3-pcie-phy
> >            - qcom,ipq8074-qmp-pcie-phy
> > @@ -24,10 +25,12 @@ properties:
> >            - qcom,ipq9574-qmp-gen3x2-pcie-phy
> >        - items:
> >            - enum:
> > +              - qcom,ipq5210-qmp-gen3x1-pcie-phy
>
> and here?
>
> >                - qcom,ipq5424-qmp-gen3x1-pcie-phy
> >            - const: qcom,ipq9574-qmp-gen3x1-pcie-phy
>
> So it is or it is not compatible with 9574?

Sorry. It is compatible with 9574. Will fix this and post a new version.

Thanks
Varada

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

^ permalink raw reply
* [PATCH 5/5] phy: qcom-qusb2: add QUSB2 support for ipq5210
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Add the phy init sequence for the Super Speed ports found
on ipq5210.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..749106175742 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -929,6 +929,9 @@ static const struct phy_ops qusb2_phy_gen_ops = {
 
 static const struct of_device_id qusb2_phy_of_match_table[] = {
 	{
+		.compatible	= "qcom,ipq5210-qusb2-phy",
+		.data		= &ipq6018_phy_cfg,
+	}, {
 		.compatible	= "qcom,ipq5424-qusb2-phy",
 		.data		= &ipq6018_phy_cfg,
 	}, {

-- 
2.34.1


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

^ permalink raw reply related
* [PATCH 3/5] dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Update dt-bindings to add ipq5210 to USB DWC3 controller list.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a7f58114c02e..f8e0819be894 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -26,6 +26,7 @@ properties:
       - enum:
           - qcom,ipq4019-dwc3
           - qcom,ipq5018-dwc3
+          - qcom,ipq5210-dwc3
           - qcom,ipq5332-dwc3
           - qcom,ipq5424-dwc3
           - qcom,ipq6018-dwc3

-- 
2.34.1


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

^ permalink raw reply related
* [PATCH 4/5] phy: qcom: qmp: Enable ipq5210 support
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Enable QMP USB3 phy support for ipq5210 SoC.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
index b0ecd5ba2464..8d3d7e39697e 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
@@ -2449,6 +2449,9 @@ static const struct of_device_id qmp_usb_of_match_table[] = {
 	{
 		.compatible = "qcom,glymur-qmp-usb3-uni-phy",
 		.data = &glymur_usb3_uniphy_cfg,
+	}, {
+		.compatible = "qcom,ipq5210-qmp-usb3-phy",
+		.data = &ipq9574_usb3phy_cfg,
 	}, {
 		.compatible = "qcom,ipq5424-qmp-usb3-phy",
 		.data = &ipq9574_usb3phy_cfg,

-- 
2.34.1


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

^ permalink raw reply related
* [PATCH 2/5] dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Add dt-bindings for USB3 PHY found on Qualcomm ipq5210

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml          | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
index 623c2f8c7d22..bdb80371ea68 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - qcom,glymur-qmp-usb3-uni-phy
+      - qcom,ipq5210-qmp-usb3-phy
       - qcom,ipq5424-qmp-usb3-phy
       - qcom,ipq6018-qmp-usb3-phy
       - qcom,ipq8074-qmp-usb3-phy

-- 
2.34.1


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

^ permalink raw reply related
* [PATCH 1/5] dt-bindings: phy: qcom,qusb2: Document ipq5210 compatible
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Document the compatible string used for the qusb2 phy in ipq5210.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 39851ba9de43..509cadd31adf 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -18,6 +18,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - qcom,ipq5210-qusb2-phy
               - qcom,ipq5424-qusb2-phy
               - qcom,ipq6018-qusb2-phy
               - qcom,ipq8074-qusb2-phy

-- 
2.34.1


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

^ permalink raw reply related
* [PATCH 0/5] Enable ipq5210 USB support
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan

The ipq5210 SoC has both USB2.0 and USB3.0 controllers. The USB3.0
can connect to either of USB2.0 or USB3.0 phy and operate in the
respective mode.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Varadarajan Narayanan (5):
      dt-bindings: phy: qcom,qusb2: Document ipq5210 compatible
      dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
      dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
      phy: qcom: qmp: Enable ipq5210 support
      phy: qcom-qusb2: add QUSB2 support for ipq5210

 Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml              | 1 +
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml        | 1 +
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml                   | 1 +
 drivers/phy/qualcomm/phy-qcom-qmp-usb.c                                | 3 +++
 drivers/phy/qualcomm/phy-qcom-qusb2.c                                  | 3 +++
 5 files changed, 9 insertions(+)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260515-usb2phy-bd850e1fb3de

Best regards,
-- 
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>


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

^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Krzysztof Kozlowski @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260514-pci-phy-v1-1-482429192746@oss.qualcomm.com>

On Thu, May 14, 2026 at 09:28:28AM +0530, Varadarajan Narayanan wrote:
> Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
> as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.
> 
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> index f60804687412..1ac31439c20a 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> @@ -17,6 +17,7 @@ properties:
>    compatible:
>      oneOf:
>        - enum:
> +          - qcom,ipq5210-qmp-gen3x1-pcie-phy

5210-qmp-gen3x1 here

>            - qcom,ipq6018-qmp-pcie-phy
>            - qcom,ipq8074-qmp-gen3-pcie-phy
>            - qcom,ipq8074-qmp-pcie-phy
> @@ -24,10 +25,12 @@ properties:
>            - qcom,ipq9574-qmp-gen3x2-pcie-phy
>        - items:
>            - enum:
> +              - qcom,ipq5210-qmp-gen3x1-pcie-phy

and here?

>                - qcom,ipq5424-qmp-gen3x1-pcie-phy
>            - const: qcom,ipq9574-qmp-gen3x1-pcie-phy

So it is or it is not compatible with 9574?

Best regards,
Krzysztof


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

^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Krzysztof Kozlowski @ 2026-05-15 10:45 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260514-pci-phy-v1-1-482429192746@oss.qualcomm.com>

On Thu, May 14, 2026 at 09:28:28AM +0530, Varadarajan Narayanan wrote:
> Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
> as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.

I don't understand that. You claim to use fallback only because
they are "similar", which is clearly incomplete reason. Many things are
similar. And your driver explicitly does not use fallback, which MUST be
explained WHY.

Best regards,
Krzysztof


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

^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: qcom: Introduce Shikra SoC base dtsi
From: Konrad Dybcio @ 2026-05-15 10:37 UTC (permalink / raw)
  To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Wesley Cheng, Ulf Hansson
  Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
	Imran Shaik, Krishna Kurapati, Monish Chunara, Rakesh Kota,
	Raviteja Laggyshetty, Sneh Mankad, Vishnu Santhosh, Xueyao An
In-Reply-To: <20260512-shikra-dt-v1-2-716438330dd0@oss.qualcomm.com>

On 5/12/26 6:08 AM, Komal Bajaj wrote:
> Add initial device tree support for the Qualcomm Shikra SoC,
> an IoT-focused platform built around a heterogeneous CPU cluster
> (Cortex-A55 + Cortex-A78C) with RPM-based power and clock management.

[...]

> +	pmu {
> +		compatible = "arm,armv8-pmuv3";
> +		interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH>;

Considering there's 2 core types, you may need something like:

9ce52e908bd5 ("arm64: dts: qcom: sm8650: switch to interrupt-cells 4 to add PPI partitions")
2c06e0797c32 ("arm64: dts: qcom: sm8650: add PPI interrupt partitions for the ARM PMUs")

> +	};
> +
> +	psci: psci {

Unused label, please drop

otherwise:

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context
From: David Laight @ 2026-05-15  9:47 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Claudiu Beznea, yoshihiro.shimoda.uh, vkoul, neil.armstrong,
	geert+renesas, magnus.damm, prabhakar.mahadev-lad.rj,
	linux-renesas-soc, linux-phy, linux-kernel, Claudiu Beznea,
	stable, Nobuhiro Iwamatsu
In-Reply-To: <agY8NAyCcHkhBvBv@duo.ucw.cz>

On Thu, 14 May 2026 23:18:44 +0200
Pavel Machek <pavel@nabladev.com> wrote:

> Hi!
> 
> > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > 
> > The OTG PHY initialization sequence needs to wait for 20 ms at a specific
> > step, as described in commit 72c0339c115b ("phy: renesas:
> > rcar-gen3-usb2: follow the hardware manual procedure").
> > 
> > Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware
> > registers and driver data") tried to address various problems in the
> > rcar-gen3-usb2 driver and converted the mutex protecting HW register
> > accesses to a spin lock, leaving, however, a long delay in the critical
> > section protected by the spin lock. This may become a problem,
> > especially on RT kernels.
> > 
> > To address this, release the spin lock before sleeping for 20 ms as
> > required by the HW manual and reacquire it afterwards. To avoid other
> > threads entering the critical section and configuring the HW while the
> > software is waiting for the OTG initialization to complete, introduce the
> > otg_initializing variable alongside the otg_init_done completion. Any
> > other thread trying to configure the HW while the OTG PHY initialization
> > is in progress waits for the completion instead of immediately returning
> > errors to PHY users. The IRQs were also disabled while waiting for the OTG
> > PHY initialization to complete, as the interrupt handler may also apply HW
> > settings.  
> 
> Just... there has to be a better way.
> 
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +static int rcar_gen3_phy_wait_otg_init(struct rcar_gen3_chan *channel,
> > +				       unsigned long *flags)
> > +{
> > +	unsigned long timeout = msecs_to_jiffies(25);
> > +	unsigned long ret = 1;
> > +
> > +	lockdep_assert_held(&channel->lock);
> > +
> > +	/*
> > +	 * The OTG can be initialized only once and needs to release the lock
> > +	 * and wait for 20 ms due to hardware constraints. Wait for the OTG PHY
> > +	 * initialization to complete if another PHY executes configuration
> > +	 * code while the OTG PHY is waiting. This avoids returning failures to
> > +	 * PHY users.
> > +	 */
> > +	if (READ_ONCE(channel->otg_initializing)) {
> > +		spin_unlock_irqrestore(&channel->lock, *flags);  
> 
> This is not nice, passing flags between functions like this is a red flag.

It would be better to just inline the code.
And I'd guess you need to redo the initial tests after re-acquiring the lock?
Or even need to do a state change/reference count before releasing the
lock to stop other threads 'doing anything nasty'.

-- David

> 
> You are only accessing otg_initializing under the spinlock. That means
> that READ_ONCE is reduntant.
> 
> But AFAICT spinlock is only held over this function to protect
> channel->otg_initializing access. I suspect correct answer here is
> getting rid of spinlock over this function, and using
> test_bit(BIT_INITIALIZING, ...) or something similar.
> 
> Best regards,
> 								Pavel
> 


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

^ permalink raw reply
* Re: [PATCH phy-next 1/2] dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
From: Ioana Ciornei @ 2026-05-15  9:23 UTC (permalink / raw)
  To: Conor Dooley
  Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy,
	devicetree, linux-kernel
In-Reply-To: <20260514-scorebook-uproot-c9766b3e1be4@spud>

On Thu, May 14, 2026 at 07:09:13PM +0100, Conor Dooley wrote:
> On Wed, May 13, 2026 at 09:51:02PM +0300, Ioana Ciornei wrote:
> > Add device tree binding for the TI DS125DF111 Retimer PHY.
> > 
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > ---
> >  .../bindings/phy/ti,ds125df111.yaml           | 46 +++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
> > 

(...)

> > +
> > +examples:
> > +  - |
> > +    i2c {
> > +      #address-cells = <1>;
> > +      #size-cells = <0>;
> > +
> > +      ti_retimer: retimer@18 {
> 
> Drop the unused label here please. How come the node name isn't phy@
> btw?
> Otherwise,
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: changes-requested

Ok, will drop the label, change the node name to phy and add your
Acked-by.

Thanks!

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

^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom: Document Shikra and its EVK boards
From: Krzysztof Kozlowski @ 2026-05-15  8:51 UTC (permalink / raw)
  To: Komal Bajaj
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
	Ulf Hansson, linux-arm-msm, devicetree, linux-kernel, linux-phy,
	linux-mmc
In-Reply-To: <20260512-shikra-dt-v1-1-716438330dd0@oss.qualcomm.com>

On Tue, May 12, 2026 at 09:38:04AM +0530, Komal Bajaj wrote:
> Shikra is a Qualcomm IoT SoC available in a System-on-Module (SoM)
> form factor. The SoM integrates the Shikra SoC, PMICs, and essential
> passives, and is designed to be mounted on carrier boards.
> 
> One SoM variant is introduced:
>   - CQM: retail variant with integrated modem (PM4125 PMIC)
> 
> Two EVK boards are supported:
>   - shikra-cqm-evk: pairs with the CQM SoM
>   - shikra-cqs-evk: pairs with the CQM SoM, with no modem support

s/CQM/CQS/

but anyway I would prefer to use full product names from
include/dt-bindings/arm/qcom,ids.h (so CQXXXXM).

> 
> Each EVK provides debug UART, USB, and other peripheral interfaces.
> 
> Add compatible strings for the CQM SoM variant and its two
> corresponding EVK boards.
> 
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 2741c07e9f41..f041d71d7957 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -963,6 +963,13 @@ properties:
>            - const: qcom,qcs9100
>            - const: qcom,sa8775p
>  
> +      - items:
> +          - enum:
> +              - qcom,shikra-cqm-evk
> +              - qcom,shikra-cqs-evk
> +          - const: qcom,shikra-cqm-som

This is not accurate. The SoM has physically different SoC - either CQM
or CQS. You either need two lists, like Toradex is doing (e.g.
toradex,verdin-imx95), or enum in the middle of the lists, like Renesas
is doing (e.g. renesas,rzt2h-evk).

I prefer the first option, so Toradex choice.

But for sure you do not get the third solution... Really, you are not
supposed to invent these things, but look at existing solutions (and I
was mentioning Toradex during internal meetings whenever someone asked
me how the SoM and carrier should be organized).

Best regards,
Krzysztof


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

^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: net: Document Infineon/Intel XMM6260 modem
From: Svyatoslav Ryhel @ 2026-05-15  8:39 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260515-precious-ginger-lori-d1fde7@quoll>

пт, 15 трав. 2026 р. о 11:18 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Mon, May 11, 2026 at 04:56:58PM +0300, Svyatoslav Ryhel wrote:
> > +  ap-wake-gpios:
> > +    description: GPIO connected to the EINT3 pin
> > +    maxItems: 1
> > +
> > +  cp-wake-gpios:
> > +    description: GPIO connected to the EINT2 pin
> > +    maxItems: 1
> > +
> > +  phys:
> > +    maxItems: 1
> > +
> > +  vbat-supply:
> > +    description: Supply connected to the VBAT lines.
>
> This should be rather name of the pin on this device, not the provider
> name. VBAT suggests the latter. Please double check.
>

There is no documentation on this device from Infineon, I have used
schematics of the P895 where this modem is used. According to it power
supply is connected to pin with name VBAT (and yes, I am not mixing it
up since supplies have different names)

> Rest looks fine, with respect to Sashiko comment on description:
>
> 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
* Re: [PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY
From: Svyatoslav Ryhel @ 2026-05-15  8:37 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260515-utopian-malamute-of-patience-367e8e@quoll>

пт, 15 трав. 2026 р. о 11:20 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Mon, May 11, 2026 at 04:57:00PM +0300, Svyatoslav Ryhel wrote:
> > Document the XMM6260 PHY used by various devices based on the Nvidia Tegra
> > SoC, describing its usage
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  .../bindings/phy/nvidia,tegra-xmm6260.yaml    | 58 +++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> > new file mode 100644
> > index 000000000000..0346433c9772
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> > @@ -0,0 +1,58 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/nvidia,tegra-xmm6260.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Nvidia Tegra PHY for XMM6260 modem
>
> XMM6260 is Infineon modem, so any combination with nvidia,tegra is very
> confusing.
>

May you please suggest how to adjust the name then? Thank you.

> > +
> > +description:
> > +  A hardware configuration used in Tegra SoCs to provide proper interaction
> > +  between the application processor and the modem, as well as control over
> > +  one of the SoC's USB lines for the modem.
> > +
> > +maintainers:
> > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra-xmm6260
>
> Also here.
>
> What sort of phy is this? So far looks more like a software construct.
>

Infineon XMM6260 does not work as an ordinary USB modem, it is a
standalone CPU which just exposes itself to AP via USB. In order to do
so, it has to have control over a USB bus of AP which is dedicated to
it. In case of Tegra - XMM6260 interaction it looks like this: second
Tegra USB controller is set into HSIC mode and is dedicated solely to
the modem, modem controls this USB bus. Then the main XMM6260 driver
performs power and init sequence and once it is ready it calls phy to
register controller. Phy has its own supply, controls USB controller
de/register and using enable GPIO sends signal to modem to proceed.
Additionally, since some XMM626 versions have a few steps to setup
exposing different USB devices, phy handles controller reinit for each
step. If treat XMM6260 as an simple USB modem it will never init.

One more benefit of having PHY is that modem driver itself is generic
and PHY handles SoC specific configurations required by the modem.
Since this modem was used on a variety of different SoC's (Exynos and
OMAP for example) they can reuse modem's driver and provide only PHY
which handles modem interactions with the USB bus.

> Best regards,
> Krzysztof
>

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

^ permalink raw reply
* Re: [PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY
From: Krzysztof Kozlowski @ 2026-05-15  8:20 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260511135703.62470-6-clamor95@gmail.com>

On Mon, May 11, 2026 at 04:57:00PM +0300, Svyatoslav Ryhel wrote:
> Document the XMM6260 PHY used by various devices based on the Nvidia Tegra
> SoC, describing its usage
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../bindings/phy/nvidia,tegra-xmm6260.yaml    | 58 +++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> new file mode 100644
> index 000000000000..0346433c9772
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nvidia,tegra-xmm6260.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nvidia Tegra PHY for XMM6260 modem

XMM6260 is Infineon modem, so any combination with nvidia,tegra is very
confusing.

> +
> +description:
> +  A hardware configuration used in Tegra SoCs to provide proper interaction
> +  between the application processor and the modem, as well as control over
> +  one of the SoC's USB lines for the modem.
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-xmm6260

Also here.

What sort of phy is this? So far looks more like a software construct.

Best regards,
Krzysztof


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

^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: net: Document Infineon/Intel XMM6260 modem
From: Krzysztof Kozlowski @ 2026-05-15  8:18 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260511135703.62470-4-clamor95@gmail.com>

On Mon, May 11, 2026 at 04:56:58PM +0300, Svyatoslav Ryhel wrote:
> +  ap-wake-gpios:
> +    description: GPIO connected to the EINT3 pin
> +    maxItems: 1
> +
> +  cp-wake-gpios:
> +    description: GPIO connected to the EINT2 pin
> +    maxItems: 1
> +
> +  phys:
> +    maxItems: 1
> +
> +  vbat-supply:
> +    description: Supply connected to the VBAT lines.

This should be rather name of the pin on this device, not the provider
name. VBAT suggests the latter. Please double check.

Rest looks fine, with respect to Sashiko comment on description:

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
* Re: [PATCH v1 1/6] dt-bindings: usb: ci-hdrc-usb2: Document nvidia,external-control property
From: Krzysztof Kozlowski @ 2026-05-15  8:15 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
	devicetree, linux-kernel, linux-phy, linux-tegra, linux-usb
In-Reply-To: <CAPVz0n2GkucfHqvgusF=K_KakqaJmZSLP=8VYMyVT5HAVDD_XQ@mail.gmail.com>

On Wed, May 13, 2026 at 08:34:45PM +0300, Svyatoslav Ryhel wrote:
> пн, 11 трав. 2026 р. о 16:57 Svyatoslav Ryhel <clamor95@gmail.com> пише:
> >
> > Document the nvidia,external-control property required, for example, for
> > USB lines in HSIC mode connected to a modem, where the modem requires
> > precise control over the USB bus to properly enumerate all its stages and
> > intermediate devices.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > index 691d6cf02c27..a13c1ef49a57 100644
> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > @@ -75,6 +75,13 @@ properties:
> >      type: boolean
> >      deprecated: true
> >
> > +  nvidia,external-control:
> > +    description:
> > +      Indicates that the controller is configured externally and that the host
> > +      should not attempt to touch it. Usually used by a modem which requires
> > +      precise bus configuration.
> > +    type: boolean
> > +
> 
> Would schema maintainers mind if I create separate schema like
> chipidea,usb2-imx.yaml is handled? At the moment ci-hdrc-usb2 holds a
> mixed properties of several SoC and can cause unwanted/unsupported
> node combinations.

This is a good idea. All nvidia devices and their properties should be
moved there.

Best regards,
Krzysztof


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

^ permalink raw reply
* Re: 回复: Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-05-15  7:32 UTC (permalink / raw)
  To: Vinod Koul, 曾红玲
  Cc: sashiko-bot, linux-phy, neil.armstrong, olteanv
In-Reply-To: <agbCaI490NQN37te@vaman>

Hi Vinod,

Apologies for the earlier HTML mail — that was unintentional.

I have resent the patches. They include:
- Fix for clock resource leak on probe errors
- Correct handling of -EPROBE_DEFER for sysclk and SATA refclk

Please let me know if anything else needs adjustment.

Best regards,
Hongling

在 2026年05月15日 14:51, Vinod Koul 写道:
> On 15-05-26, 13:14, 曾红玲 wrote:
>
> Please send text only emails on the list!!!
>
>> <div style="font-family:Microsoft YaHei;font-size:14px;color:#000000;" class="l_node_has_color"><div>Hi,</div>
>> <div>Thanks for pointing out the probe deferral problems.</div>
>> <div>Both issues you mentioned are valid:</div>
>> <ul>
>> <li>
>> <div>sysclk should not convert <code>-EPROBE_DEFER</code>to <code>-EINVAL</code>.</div>
>> </li>
>> <li>
>> <div>SATA refclk must not ignore <code>-EPROBE_DEFER</code>, although <code>-ENOENT</code>can still be tolerated for compatibility.</div>
>> </li>
>> </ul>
>> <div>I have fix them together with the clock leak fix in .</div>
>> <div>[PATCH 1/2 v3] phy: ti: pipe3: Fix clock resource leak on probe errors</div>
>> <div>[PATCH 2/2] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources</div>
>> <div>&nbsp;</div>
>> <div>Appreciate the careful review.</div>
>> <div>&nbsp;</div>
>> <div>Regards,</div>
>> <div>Hongling</div>
>> <p>&nbsp;</p>
>> <div id="signatureTop"></div>
>> <div id="cs2c_re" style="margin-left: 0.5em; padding-left: 0.5em; border-left: 1px solid #cacaca; -webkit-user-modify: read-only; -moz-user-modify: read-only; -ms-user-modify: read-only; -o-user-modify: read-only;"><br><br><br>
>> <div style="background-color: #f8f8f8; padding: 8px 10px; font-family: Microsoft YaHei; font-size: 14px; color: #000;"><strong>主&nbsp;&nbsp;&nbsp;题：</strong><span id="cs2c_subject">Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors</span> <br><strong>日&nbsp;&nbsp;&nbsp;期：</strong><span id="cs2c_date">2026年05月15日10:32</span> <br><strong>发件人：</strong><span id="cs2c_from">sashiko-bot</span> <br><strong>收件人：</strong><span id="cs2c_to" style="word-break: break-all;">sashiko-bot</span> <br><strong>抄送人：</strong><span id="cs2c_to" style="word-break: break-all;">linux-phy,neil.armstrong,olteanv,vkoul</span></div>
>> <br>
>> <div id="cs2c_content">Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Masking of -EPROBE_DEFER to -EINVAL when fetching sysclk. - [High] Ignoring -EPROBE_DEFER for the SATA refclk. -- commit 4f2fbd627ee80455cac194a4ae1b559d48180075 Author: Hongling Zeng &lt;zenghongling@kylinos.cn&gt; phy: ti: pipe3: Fix clock resource leak on probe errors When devm_phy_create() or devm_of_phy_provider_register() fails, the refclk that was enabled earlier is not disabled, causing a resource leak. Fix this by adding an error handling path to disable the clock when these functions fail. &gt; diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c &gt; index b5543b5c674c8..58fbc3b278130 100644 &gt; --- a/drivers/phy/ti/phy-ti-pipe3.c &gt; +++ b/drivers/phy/ti/phy-ti-pipe3.c [ ... ] This isn't a regression introduced by this patch, but looking at ti_pipe3_get_clk() called earlier in the probe sequence: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... if (phy-&gt;mode != PIPE3_MODE_PCIE || phy-&gt;phy_power_syscon) { phy-&gt;sys_clk = devm_clk_get(dev, "sysclk"); if (IS_ERR(phy-&gt;sys_clk)) { dev_err(dev, "unable to get sysclk\n"); return -EINVAL; } } ... } Does this code mask -EPROBE_DEFER to -EINVAL when fetching sysclk? If devm_clk_get() for the sysclk returns -EPROBE_DEFER, the function explicitly converts the error and returns -EINVAL. This completely breaks the lifecycle of probe deferral for the sysclk resource. Instead of retrying when the clock provider becomes available later in the boot process, the driver initialization fails permanently, rendering the PHY device unusable on systems with non-deterministic probe orders. Similarly, looking at the SATA refclk handling in the same function: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... phy-&gt;refclk = devm_clk_get(dev, "refclk"); if (IS_ERR(phy-&gt;refclk)) { dev_err(dev, "unable to get refclk\n"); /* older DTBs have missing refclk in SATA PHY * so don't bail out in case of SATA PHY. */ if (phy-&gt;mode != PIPE3_MODE_SATA) return PTR_ERR(phy-&gt;refclk); } ... } Are errors returned by devm_clk_get() for the refclk ignored when the mode is PIPE3_MODE_SATA? While ignoring -ENOENT is intentionally done to support older DTBs missing the clock, indiscriminately ignoring -EPROBE_DEFER breaks the probe deferral mechanism. The driver will proceed immediately without waiting for the clock provider to probe, resulting in the SATA PHY being initialized without its required reference clock and subsequently failing to function properly. -- Sashiko AI review · https://sashiko.dev/#/patchset/20260515021635.13444-1-zenghongling@kylinos.cn?part=1 &lt;/zenghongling@kylinos.cn&gt;</div>
>> </div>
>> <p>&nbsp;</p>
>> <p>&nbsp;</p>
>> <div id="signatureBom">
>> <div>
>> <p>&nbsp;</p>
>> <br>
>> <p style="color: #000; font-size: 16px;">---</p>
>> <div id="cs2c_mail_sigature" style="color: #000; font-size: 16px; font-family: Microsoft YaHei;"></div>
>> <p>&nbsp;</p>
>> </div>
>> </div></div>



-- 
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