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

[Philipp Zabel]

On Mi, 2026-06-03 at 23:49 +0300, Stefan Dösinger wrote:
> 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? 

Yes.

> 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.

If it is not used, please just drop it.

The .reset callback exists for self-clearing resets [1]. It's ok to
emulate those in software for the benefit of consumer drivers that have
to work with both types of reset controllers, but I'd like this to be
limited to those case where it's actually needed.

[1] https://docs.kernel.org/driver-api/reset.html#c.reset_control_ops

> 
regards
Philipp