Re: [PATCH v1 2/2] usb: phy: tegra: Disable internal USB sensing if extcon is used

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] usb: phy: tegra: spurious wakeups due to re-enabled floating VBUS sensor
- [High] usb: phy: tegra: unhandled extcon parsing for peripheral-only mode
- [Medium] usb: phy: tegra: brittle DT parsing via hardcoded absolute path
- [Medium] usb: phy: tegra: unconditional 100ms timeout delay on power-off due to active SW override
- [Low] usb: phy: tegra: unnecessary devm allocation for temporary string
--

commit 4cd162cd45681e0cd98b5676b09fbcbe3368c0d1
Author: Jordan Viknar <jordanviknar@gmail.com>

usb: phy: tegra: Disable internal USB sensing if extcon is used

This commit adds extcon parsing from the linked USB controller. If an extcon
property exists, it switches VBUS sensors to software mode and sets their
values to SET, allowing boards with extcon chips to function properly without
conflicting with Tegra's native mechanism.

> diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
> index 00443a7beaeb0..b5660910dfc7b 100644
> --- a/drivers/usb/phy/phy-tegra-usb.c
> +++ b/drivers/usb/phy/phy-tegra-usb.c

[ ... ]

> @@ -727,6 +741,12 @@ static int utmi_phy_power_off(struct tegra_usb_phy *phy)
>  					   val, !(val & VBUS_WAKEUP_STS),
>  					   5000, 100000);
>  

[Severity: Medium]
Does this code introduce an unconditional 100ms delay during power-off?

Since readl_relaxed_poll_timeout() executes before VBUS_SENSORS_SW_OVERRIDE
is disabled in the code below, the software override forces VBUS to 1. Will
this cause the status bit to never clear and the loop to hit the 100ms
timeout limit on extcon-enabled boards?

> +	if (phy->has_extcon) {
> +		val = readl_relaxed(base + USB_PHY_VBUS_SENSORS);
> +		val &= ~VBUS_SENSORS_SW_OVERRIDE;
> +		writel_relaxed(val, base + USB_PHY_VBUS_SENSORS);
> +	}

[Severity: High]
Can this clearing of the software override cause spurious system wakeups?

By clearing VBUS_SENSORS_SW_OVERRIDE here, the disconnected hardware sensors
are exposed. Later in utmi_phy_power_off(), if wakeup_enabled is true, the
code sets A_VBUS_VLD_WAKEUP_EN:

    val = readl_relaxed(base + USB_PHY_VBUS_SENSORS);
    val |= A_VBUS_VLD_WAKEUP_EN;
    writel_relaxed(val, base + USB_PHY_VBUS_SENSORS);

Because the physical pin is disconnected or floating on extcon-based designs,
will re-enabling this hardware sensor trigger spurious wakeups during system
suspend?

> +
>  	utmi_phy_clk_disable(phy);
>  
>  	/* PHY won't resume if reset is asserted */

[ ... ]

> @@ -1456,6 +1476,34 @@ static int tegra_usb_phy_parse_pmc(struct device *dev,
>  	return 0;
>  }
>  
> +static int tegra_usb_phy_parse_controller(struct device *dev,
> +					  struct tegra_usb_phy *phy)
> +{
> +	struct device_node *usb_node;
> +	char *node_path;
> +	u64 addr;
> +	int ret;
> +
> +	ret = of_property_read_reg(dev->of_node, 0, &addr, NULL);
> +	if (ret) {
> +		dev_err(dev, "Failed to read reg entry 0: %d\n", ret);
> +		return ret;
> +	}
> +
> +	node_path = devm_kasprintf(dev, GFP_KERNEL, "/usb@%08llx", addr);

[Severity: Low]
Is it necessary to use devm_kasprintf() for this temporary string?

Since node_path is only used once for of_find_node_by_path(), allocating it
with devm_kasprintf() binds the string to the device lifetime, unnecessarily
keeping it in heap memory until the device is unbound.

[Severity: Medium]
Will this hardcoded absolute path break if the device tree topology changes?

Using a hardcoded format string "/usb@%08llx" requires the controller node
to be named exactly "usb", placed at the root of the device tree, and its
address zero-padded to exactly 8 characters. If the node is moved under
"/soc/" or "/amba/", or if the address requires fewer than 8 hex digits
(as leading zeroes are prohibited for smaller addresses by the DT spec),
will this fail to find the node and break USB functionality?

> +	if (!node_path)
> +		return -ENOMEM;
> +
> +	usb_node = of_find_node_by_path(node_path);
> +	if (!usb_node)
> +		return -ENODEV;
> +
> +	phy->has_extcon = of_property_present(usb_node, "extcon");
> +	of_node_put(usb_node);
> +
> +	return 0;
> +}

[ ... ]

> @@ -1552,6 +1600,13 @@ static int tegra_usb_phy_probe(struct platform_device *pdev)
>  		return err;
>  	}
>  
> +	if (tegra_phy->mode == USB_DR_MODE_OTG) {
> +		err = tegra_usb_phy_parse_controller(&pdev->dev, tegra_phy);
> +		if (err)
> +			return dev_err_probe(&pdev->dev, err,
> +					     "Failed to get controller\n");
> +	}

[Severity: High]
Does this prevent extcon parsing for USB_DR_MODE_PERIPHERAL?

If dr_mode is "peripheral", the parser never runs and has_extcon remains
false. Since the software override (VBUS_SENSORS_SW_OVERRIDE) is not applied
during utmi_phy_power_on() without has_extcon, will peripheral-only
extcon-based designs fail to detect connections because they read the
disconnected hardware sensor instead?

> +
>  	tegra_phy->phy_type = of_usb_get_phy_mode(np);
>  	switch (tegra_phy->phy_type) {
>  	case USBPHY_INTERFACE_MODE_UTMI:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004165204.205660-1-clamor95@gmail.com?part=2