Re: [PATCH v9 11/12] reset: zte: Add a zx297520v3 reset driver

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Mismatch between v9 changelog and driver code regarding removed =
resets.
--

--- Patch [11]: [PATCH v9 11/12] reset: zte: Add a zx297520v3 reset driver =
---
commit eead351b367c470bc2a440f3b28b22580a7eb179
Author: Stefan D=C3=B6singer <[email protected]>

reset: zte: Add a zx297520v3 reset driver

This commit adds a new reset driver for the ZTE zx297520v3 SoCs. It manages
the resets for MFD child devices created by the zte-zx297520v3-crm driver.

> diff --git a/drivers/reset/reset-zte-zx297520v3.c b/drivers/reset/reset-z=
te-zx297520v3.c
> new file mode 100644
> index 0000000000000..bc2801d43d10d
> --- /dev/null
> +++ b/drivers/reset/reset-zte-zx297520v3.c

[ ... ]

> +static const struct zte_reset_reg zx297520v3_top_resets[] =3D {

[ ... ]

> +	/* USB reset. 0x84 returns the USB device status (0x1 for HSIC up, 0x2 =
for USB up, but
> +	 * all 3 bits (PCLK, WCLK, PHY) need to be deasserted for the device to=
 report ready.
> +	 * Thus polling the status is the responsibility of the USB PHY driver.
> +	 */
> +	[ZX297520V3_USB_RESET]       =3D { .reg =3D  0x80, .mask =3D BIT(4) | B=
IT(5)   },
> +	[ZX297520V3_HSIC_RESET]      =3D { .reg =3D  0x80, .mask =3D BIT(1) | B=
IT(2)   },
> +};

[Severity: Medium]
The v9 changelog mentions "Remove HSIC and USB PHY resets, the phy driver
will access them through the shared regmap directly", but the USB and HSIC=
=20
resets are still defined in zx297520v3_top_resets here.

Should these definitions be removed to match the changelog and prevent
potential concurrent modifications through the reset API while the PHY driv=
er
accesses them via regmap?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802-zx29clk-v9=
[email protected]?part=3D11