[PATCH RFC v5 00/12] ZTE zx297520v3 clock bindings and driver
Stefan Dösinger
stefandoesinger at gmail.com
Wed Jul 1 10:22:21 PDT 2026
Am Montag, 29. Juni 2026, 18:49:08 Ostafrikanische Zeit schrieb Conor Dooley:
> Bindings seem fine to me, I'll be happy to give you some r-b tags when
> you go non-RFC. To be frank, I think you should drop them as you've got
> no significant questions here I think and you'll be taken a bt more
> seriously.
Thanks for all the advice so far!
Here's one more binding related question: Philipp's request to give the PHY
reset its own reset ID means I need a node and driver to consume that reset.
My question is if it should be another MFD subdevice of topcrm or not. I am
leaning towards not:
usb_phy: phy at 2 {
compatible = "zte,zx29-usb2-phy";
interrupts = <GIC_SPI 42 IRQ_TYPE_EDGE_RISING>, <GIC_SPI 43
IRQ_TYPE_EDGE_RISING>;
interrupt-names = "powerup", "powerdown";
syscon = <&topcrm 0x84 0x2>;
resets = <&topcrm ZX297520V3_USB_PHY_RESET>;
reset-names = "phy";
#phy-cells = <0>;
};
usb0: usb at 1500000 {
compatible = "snps,dwc2";
reg = <0x01500000 0x1000>;
...
phys = <&usb_phy>;
phy-names = "usb2-phy";
};
I am not aware of any IO region to configure the PHY, although one may exist.
topcrm + 0x84 has two status bits reporting if USB and HSIC are powered and
out of reset. Nevertheless, the PHY feels distinct enough from topcrm that it
should have its own binding. The phy driver would merely deassert the reset
and wait for the ready bit and maybe in the future do something useful with
the connect/disconnect IRQs.
Interestingly the USB IO region is actually downstream of the AHB bus and
matrix controller, but it has its clocks and resets in topcrm. I suspect the
purpose of this setup is to allow wake-by-USB IRQs while shutting down the
main data path.
Cheers,
Stefan
-------------- 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/20260701/ab6c1e99/attachment.sig>
More information about the linux-arm-kernel
mailing list