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

["Stefan Dösinger" <stefandoesinger@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]