Re: [PATCH v2 4/4] usb: chipidea: tegra: Expose tegra_usb structure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Exposing the private driver data structure `struct tegra_usb` in a public header violates driver encapsulation.
--

commit 458c2154b4c34aa542cc2d5d1ce84db0b5258a4b
Author: Svyatoslav Ryhel <clamor95@gmail.com>
usb: chipidea: tegra: Expose tegra_usb structure

This commit moves the tegra_usb structure from the tegra chipidea driver into
a public header file. The commit message states this is required for proper
manipulation when init and deinit are externally controlled.

> diff --git a/include/linux/usb/tegra_usb_phy.h b/include/linux/usb/tegra_usb_phy.h
> index 6343f88df5de8..ba74b7ebfba0e 100644
> --- a/include/linux/usb/tegra_usb_phy.h
> +++ b/include/linux/usb/tegra_usb_phy.h
[ ... ]
> @@ -62,6 +63,20 @@ enum tegra_usb_phy_port_speed {
>  	TEGRA_USB_PHY_PORT_SPEED_HIGH,
>  };
>  
> +struct tegra_usb_soc_info;
> +
> +struct tegra_usb {
> +	struct ci_hdrc_platform_data data;
> +	struct platform_device *dev;
> +
> +	const struct tegra_usb_soc_info *soc;
> +	struct usb_phy *phy;
> +	struct clk *clk;
> +
> +	bool needs_double_reset;
> +	bool externally_controlled;
> +};

[Severity: Low]
Does moving this private runtime state into a public header break driver
encapsulation?

Exposing the raw internal state structure allows external entities to
directly manipulate the controller's internal state, tightly coupling the
PHY and controller drivers.

Would it be better to provide explicit API functions, such as init and
deinit helpers, for cross-driver manipulation instead of exposing the
internal structure?

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