[PATCH V3 0/4] phy: tegra: xusb: Add Tegra264 support

[PATCH V3 0/4] phy: tegra: xusb: Add Tegra264 support

[Wayne Chang]

Add Tegra264 support to the Tegra XUSB PHY driver and its binding, as
part of enabling USB host functions on the Tegra264 Jetson AGX Thor
platform.

This series was previously posted as part of a single 8-patch series
covering phy, USB host and arm64 DTS changes together [1]. Per review
feedback, it has been split by subsystem so each maintainer can pick
up only what belongs to their tree:

- phy: tegra: xusb: this series (dt-bindings/phy + drivers/phy/tegra)
- usb: host: xhci-tegra + its dt-bindings/usb: separate series, to
  follow shortly (will reference this series once posted)
- arm64: tegra DTS enablement: separate series, to be sent once both
  of the above have landed, since it depends on both

Patch 1/4 (dt-bindings: phy) now spells out in the commit message why
Tegra264 needs its own compatible string instead of falling back to
nvidia,tegra234-xusb-padctl, per Conor's and Krzysztof's repeated
question on v1/v2.

[1] https://lore.kernel.org/linux-tegra/20260831185835.3732707-1-waynec@nvidia.com/

Sing-Han Chen (1):
  phy: tegra: xusb: Use devm_clk_get_optional to fetch USB2 tracking
    clock

Wayne Chang (3):
  dt-bindings: phy: tegra-xusb: Add support for Tegra264
  phy: tegra: xusb: Increase timeout for USB2_TRK_COMPLETED polling
  phy: tegra: xusb: Add Tegra264 support

 .../bindings/phy/nvidia,tegra194-xusb-padctl.yaml |  1 +
 drivers/phy/tegra/Makefile                        |  1 +
 drivers/phy/tegra/xusb-tegra186.c                 | 31 +++++++++++++++++++---
 drivers/phy/tegra/xusb.c                          |  6 +++++
 drivers/phy/tegra/xusb.h                          |  3 +++
 5 files changed, 39 insertions(+), 3 deletions(-)


base-commit: 940de590b839f71d6dc846160534bf202401b8b7
--
2.25.1

[PATCH V3 1/4] dt-bindings: phy: tegra-xusb: Add support for Tegra264

[Wayne Chang]

Add the compatible string for the Tegra264 XUSB PHY.

A dedicated compatible string is used instead of falling back to
nvidia,tegra234-xusb-padctl, because Tegra264 is not
programming-compatible with Tegra234, even though they share the same
DT property set. The driver selects per-SoC data from the compatible
string, and Tegra264 differs from Tegra234 in at least:

- Tegra264 uses hardware tracking mode (trk_hw_mode), while Tegra234
  disables it.
- On Tegra234, CYA_TRK_CODE_UPDATE_ON_IDLE needs to be cleared so that
  the calibration values can be captured while the controller is
  still in reset. Tegra264 does not require this, and the
  corresponding handling is not even present for it.

A fallback of nvidia,tegra234-xusb-padctl would let an OS that only
knows about Tegra234 probe Tegra264 with the wrong programming
sequence. This is also why Tegra234 did not fall back to
nvidia,tegra194-xusb-padctl in this same binding: the DT schema is
shared, but each generation needs its own compatible.

Signed-off-by: Wayne Chang <waynec@nvidia.com>
---
V2 -> V3: Add rationale to the commit message for why Tegra264 does
not use a fallback compatible, per Krzysztof's and Conor's review.
V1 -> V2: No change
 .../devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
index d8de900a4fce..f6fe3c90b5b0 100644
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
@@ -45,6 +45,7 @@ properties:
     enum:
       - nvidia,tegra194-xusb-padctl
       - nvidia,tegra234-xusb-padctl
+      - nvidia,tegra264-xusb-padctl
 
   reg:
     items:
-- 
2.25.1

[PATCH V3 2/4] phy: tegra: xusb: Use devm_clk_get_optional to fetch USB2 tracking clock

[Wayne Chang]

From: Sing-Han Chen <singhanc@nvidia.com>

The USB2 PAD tracking clock is an optional clock so use
devm_clk_get_optional() so a missing clock in devicetree is
represented as NULL and probe can continue. clk_prepare_enable()
and clk_disable_unprepare() already treat a NULL clock as a no-op.

Signed-off-by: Sing-Han Chen <singhanc@nvidia.com>
Signed-off-by: Wayne Chang <waynec@nvidia.com>
---
V2 -> V3: No change
V1 -> V2: No change
 drivers/phy/tegra/xusb-tegra186.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 60156aea2707..800be0cbb3f9 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -1045,7 +1045,7 @@ tegra186_usb2_pad_probe(struct tegra_xusb_padctl *padctl,
 		goto out;
 	}
 
-	priv->usb2_trk_clk = devm_clk_get(&pad->dev, "trk");
+	priv->usb2_trk_clk = devm_clk_get_optional(&pad->dev, "trk");
 	if (IS_ERR(priv->usb2_trk_clk)) {
 		err = PTR_ERR(priv->usb2_trk_clk);
 		dev_dbg(&pad->dev, "failed to get usb2 trk clock: %d\n", err);
-- 
2.25.1

[PATCH V3 3/4] phy: tegra: xusb: Increase timeout for USB2_TRK_COMPLETED polling

[Wayne Chang]

On Tegra264, the UTMI bias tracking circuit runs at 1 MHz and needs
more cycles for the biases to settle than on earlier SoCs such as
Tegra234. The existing timeout is therefore not long enough and can
cause spurious polling failures during bias pad power-on. Therefore,
increase the timeout to 200 cycles to support Tegra264 devices

Signed-off-by: Wayne Chang <waynec@nvidia.com>
---
V2 -> V3: No change
V1 -> V2: No change
 drivers/phy/tegra/xusb-tegra186.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 800be0cbb3f9..9c1bcd4a72ac 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -636,7 +636,7 @@ static void tegra186_utmi_bias_pad_power_on(struct tegra_xusb_padctl *padctl)
 
 	if (padctl->soc->poll_trk_completed) {
 		err = padctl_readl_poll(padctl, XUSB_PADCTL_USB2_BIAS_PAD_CTL1,
-					USB2_TRK_COMPLETED, USB2_TRK_COMPLETED, 100);
+					USB2_TRK_COMPLETED, USB2_TRK_COMPLETED, 200);
 		if (err) {
 			/* The failure with polling on trk complete will not
 			 * cause the failure of powering on the bias pad.
-- 
2.25.1

[PATCH V3 4/4] phy: tegra: xusb: Add Tegra264 support

[Wayne Chang]

Add support for the XUSB pad controller for Tegra264. Most of
the Tegra264 XUSB PADCTL registers definition and programming sequence
are the same as Tegra234, Tegra264 XUSB PADCTL can share the same
driver with Tegra186, Tegra194, and Tegra234 XUSB PADCTL.

Signed-off-by: Wayne Chang <waynec@nvidia.com>
---
V2 -> V3: No change
V1 -> V2 : Rebase and update the has_per_pad_term for Tegra264
 drivers/phy/tegra/Makefile        |  1 +
 drivers/phy/tegra/xusb-tegra186.c | 27 ++++++++++++++++++++++++++-
 drivers/phy/tegra/xusb.c          |  6 ++++++
 drivers/phy/tegra/xusb.h          |  3 +++
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
index eeeea72de117..33a695d4ed59 100644
--- a/drivers/phy/tegra/Makefile
+++ b/drivers/phy/tegra/Makefile
@@ -8,4 +8,5 @@ phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
 phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_186_SOC) += xusb-tegra186.o
 phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_194_SOC) += xusb-tegra186.o
 phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_234_SOC) += xusb-tegra186.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_264_SOC) += xusb-tegra186.o
 obj-$(CONFIG_PHY_TEGRA194_P2U) += phy-tegra194-p2u.o
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 9c1bcd4a72ac..322efdea0d80 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -1668,7 +1668,8 @@ EXPORT_SYMBOL_GPL(tegra186_xusb_padctl_soc);
 #endif
 
 #if IS_ENABLED(CONFIG_ARCH_TEGRA_194_SOC) || \
-	IS_ENABLED(CONFIG_ARCH_TEGRA_234_SOC)
+	IS_ENABLED(CONFIG_ARCH_TEGRA_234_SOC) || \
+	IS_ENABLED(CONFIG_ARCH_TEGRA_264_SOC)
 static const char * const tegra194_xusb_padctl_supply_names[] = {
 	"avdd-usb",
 	"vclamp-usb",
@@ -1753,6 +1754,30 @@ const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc = {
 	.has_per_pad_term = true,
 };
 EXPORT_SYMBOL_GPL(tegra234_xusb_padctl_soc);
+
+const struct tegra_xusb_padctl_soc tegra264_xusb_padctl_soc = {
+	.num_pads = ARRAY_SIZE(tegra194_pads),
+	.pads = tegra194_pads,
+	.ports = {
+		.usb2 = {
+			.ops = &tegra186_usb2_port_ops,
+			.count = 4,
+		},
+		.usb3 = {
+			.ops = &tegra186_usb3_port_ops,
+			.count = 4,
+		},
+	},
+	.ops = &tegra186_xusb_padctl_ops,
+	.supply_names = tegra194_xusb_padctl_supply_names,
+	.num_supplies = ARRAY_SIZE(tegra194_xusb_padctl_supply_names),
+	.supports_gen2 = true,
+	.poll_trk_completed = true,
+	.trk_hw_mode = true,
+	.supports_lp_cfg_en = true,
+	.has_per_pad_term = true,
+};
+EXPORT_SYMBOL_GPL(tegra264_xusb_padctl_soc);
 #endif
 
 MODULE_AUTHOR("JC Kuo <jckuo@nvidia.com>");
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 9d74c0ecc31b..d0d0b252a205 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -77,6 +77,12 @@ static const struct of_device_id tegra_xusb_padctl_of_match[] = {
 		.compatible = "nvidia,tegra234-xusb-padctl",
 		.data = &tegra234_xusb_padctl_soc,
 	},
+#endif
+#if defined(CONFIG_ARCH_TEGRA_264_SOC)
+	{
+		.compatible = "nvidia,tegra264-xusb-padctl",
+		.data = &tegra264_xusb_padctl_soc,
+	},
 #endif
 	{ }
 };
diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
index 77609e54de66..d8d799d9e752 100644
--- a/drivers/phy/tegra/xusb.h
+++ b/drivers/phy/tegra/xusb.h
@@ -514,5 +514,8 @@ extern const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc;
 #if defined(CONFIG_ARCH_TEGRA_234_SOC)
 extern const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc;
 #endif
+#if defined(CONFIG_ARCH_TEGRA_264_SOC)
+extern const struct tegra_xusb_padctl_soc tegra264_xusb_padctl_soc;
+#endif
 
 #endif /* __PHY_TEGRA_XUSB_H */
-- 
2.25.1

Re: [PATCH V3 2/4] phy: tegra: xusb: Use devm_clk_get_optional to fetch USB2 tracking clock

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Double-free of the `usb2` pad structure when `tegra_xusb_pad_init()` fails.
- [High] Invalid `device_unregister()` call on `device_add()` failure path.
- [High] NULL pointer dereference and memory leak in `tegra_xusb_port_init()` error path.
--

commit cbc965ddabaa3e83cea8e6b268dbf34122daa3cd
Author: Sing-Han Chen <singhanc@nvidia.com>

phy: tegra: xusb: Use devm_clk_get_optional to fetch USB2 tracking clock
    
The USB2 PAD tracking clock is an optional clock so use
devm_clk_get_optional() so a missing clock in devicetree is
represented as NULL and probe can continue. clk_prepare_enable()
and clk_disable_unprepare() already treat a NULL clock as a no-op.

> diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
> index 60156aea27071..800be0cbb3f9f 100644
> --- a/drivers/phy/tegra/xusb-tegra186.c
> +++ b/drivers/phy/tegra/xusb-tegra186.c
> @@ -1045,7 +1045,7 @@ tegra186_usb2_pad_probe(struct tegra_xusb_padctl *padctl,
>  		goto out;
>  	}
>  
> -	priv->usb2_trk_clk = devm_clk_get(&pad->dev, "trk");
> +	priv->usb2_trk_clk = devm_clk_get_optional(&pad->dev, "trk");
>  	if (IS_ERR(priv->usb2_trk_clk)) {

[Severity: High]
This isn't a bug introduced by this patch, but is there a double-free of the
usb2 pad structure if tegra_xusb_pad_init() fails?

Looking at tegra186_usb2_pad_probe() just above this change:

drivers/phy/tegra/xusb-tegra186.c:tegra186_usb2_pad_probe() {
	...
	err = tegra_xusb_pad_init(pad, padctl, np);
	if (err < 0) {
		kfree(usb2);
		goto out;
	}
	...
}

If device_add() fails inside tegra_xusb_pad_init(), it calls
device_unregister(), dropping the device reference count to zero and
triggering the release callback, which eventually calls
tegra186_usb2_pad_remove() and frees usb2. Does the explicit kfree(usb2)
here result in freeing the same pointer twice?

[Severity: High]
This is a pre-existing issue, but does tegra_xusb_pad_init() call
device_unregister() incorrectly on its failure path?

drivers/phy/tegra/xusb.c:tegra_xusb_pad_init() {
	...
	err = device_add(&pad->dev);
	if (err < 0)
		goto unregister;

	return 0;

unregister:
	device_unregister(&pad->dev);
	return err;
}

If device_add() fails, the device was never added to the system. Does
calling device_unregister() (which executes device_del() before
put_device()) attempt to tear down sysfs entries that were never created,
potentially leading to kernel warnings or crashes? Should it call
put_device() instead?

[Severity: High]
This is a pre-existing issue, but is there a NULL pointer dereference in the
error path for port initialization?

drivers/phy/tegra/xusb.c:tegra_xusb_add_usb2_port() {
	...
	err = tegra_xusb_port_init(&usb2->base, padctl, np, "usb2", index);
	if (err < 0)
		goto out;

	usb2->base.ops = padctl->soc->ports.usb2.ops;
	...
}

If tegra_xusb_port_init() fails (e.g., due to device_add() failing), it rolls
back by dropping the device reference, triggering the port release callback:

drivers/phy/tegra/xusb.c:tegra_xusb_port_release() {
	struct tegra_xusb_port *port = to_tegra_xusb_port(dev);

	if (port->ops->release)
		port->ops->release(port);
}

Since port->ops is only assigned after tegra_xusb_port_init() returns
successfully, it will be NULL during the failure rollback. Does the
unconditional dereference of port->ops in tegra_xusb_port_release() lead to
a kernel panic?

>  		err = PTR_ERR(priv->usb2_trk_clk);
>  		dev_dbg(&pad->dev, "failed to get usb2 trk clock: %d\n", err);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903071937.533646-1-waynec@nvidia.com?part=2

Re: [PATCH V3 1/4] dt-bindings: phy: tegra-xusb: Add support for Tegra264

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]