[PATCH RFC v3 3/5] clk: zte: Introduce a driver for zx297520v3 top clocks and resets.

[Stefan Dösinger]

Hi,

Thanks for the comments!

Am Mittwoch, 3. Juni 2026, 12:14:21 Ostafrikanische Zeit schrieb Philipp 
Zabel:

> Is this delay long enough for all potential users of reset_control_reset()?
> Are there actually any at all?

You mean drivers that are in use on this SoC that call reset_control_reset? 
Afaics not, they all call reset_assert/reset_deassert, or only ever deassert a 
reset that is set on boot. It isn't called at runtime and the only driver 
calling it that is in use on zx297520v3 is stmmac, which only calls it if 
assert/deassert aren't available.

I implemented the reset() callback because other drivers had it and grabbed 
the magic usleep(100) from ZTE's USB code. It looks like I should just /dev/
null it.

> I'd move the spinlock in here ...
> 
> > ```
> 
> +	/* This is a special case used only by USB reset */
> +	if (data->resets[id].wait_mask) {
> +		return readl_poll_timeout(data->resets[id].reg + 4, val,
> +					  val & data-
>resets[id].wait_mask, 1, 100);
> ```
> 
> 
> ... because this might sleep.

Ack

> +	return val & data->resets[id].mask;
> ```
> 
> 
> This will return a negative value for bit BIT(31), I'd wrap this with a
> double negation.

Sounds good
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260603/ea7672b1/attachment.sig>