[PATCH v9 11/12] reset: zte: Add a zx297520v3 reset driver
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Sun Aug 2 14:04:47 PDT 2026
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ösinger <stefandoesinger at gmail.com>
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-zte-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[] = {
[ ... ]
> + /* 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] = { .reg = 0x80, .mask = BIT(4) | BIT(5) },
> + [ZX297520V3_HSIC_RESET] = { .reg = 0x80, .mask = BIT(1) | BIT(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
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 driver
accesses them via regmap?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260802-zx29clk-v9-0-d05530d85d28@gmail.com?part=11
More information about the linux-phy
mailing list