[PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver

[Stefan Dösinger]

Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp 
Zabel:
> On Di, 2026-06-16 at 23:26 +0300, Stefan Dösinger wrote:
> > This drives the auxiliary devices created by the clock driver.
> 
> Which auxiliary devices? Which clock driver?

The ones from patches 7-10. But I guess you're telling me to spell this out 
for readers who see my patch in the kernel commit log rather than the 
submission series.

> > +	[ZX297520V3_UART0_RESET]     = { .reg = 0x78,  .mask = BIT(6)  | 
BIT(7) 
> > },
> Is this a single reset line controlled by two bits (do you know what
> they are)? Or might these actually be two different reset controls that
> are just always set together?

Most devices on this SoC have two reset lines. In most cases asserting one is 
enough to reset the device, and consequently both need to be deasserted to 
bring the device out of reset. In some cases both need to be asserted to reset 
the device and it keeps operating fine with only one asserted. I believe I 
documented some of that in comments, but maybe I forgot to move it from the 
clock part of the driver.

Exceptions apply - some devices have only one reset bit and for some I haven't 
found any. USB as you noticed has 3.

I don't really know the difference between the two lines. I don't have a 
datasheet and ZTE's downstream kernel only operates on the USB resets. The old 
upstream zx2967xx code had no reset driver at all. So I found the resets by 
setting the registers and then single bits to 0 and seeing what disappears 
from mmio space. Everything on this board except USB comes with resets 
deasserted on boot.

I'm pretty sure that what I identified as resets are actually resets and not 
extra clocks because previous device configuration gets lost after asserting a 
reset, whereas it is retained when disabling pclk.

I absolutely expect to run into surprises and epiphanies in the future and 
problems on as of yet untested types of zx297520v3 devices.

> > +	[ZX297520V3_USB_RESET]      =  { .reg = 0x80,   .mask = BIT(3) | 
BIT(4)
> > | BIT(5), +		.wait_mask = BIT(1)},
> 
> Same as above, are these actually three separate reset lines?

It is likely a combination of the same 2 indistinguishable lines (4, 5) and a 
separate USB PHY line (3) - this is what ZTE's code suggests, but it is a mess 
of #ifdefs and redirection, so I don't know if I isolated the correct 
codepath. (No, a kernel built from that ugly code doesn't boot, so I can't add 
printks).

The PHY reset line does not do anything observable on my device if I recall 
correctly. It might be nonexistent, it might be a leftover from older 
revisions or some devices might have different PHYs, similarly to how Ethernet 
PHYs differ.

I'll double check those USB resets before I resend. It's been months since I 
looked at this particular part of the board, and maybe I missed something. On 
the booted ZTE kernel and in the bootloader, when booted via USB, all 3 are 
deasserted. When booted via the NAND boot chain they are asserted when the 
kernel takes over.


-------------- 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/20260618/96eb69de/attachment-0001.sig>