[PATCH v2 1/2] dt-bindings: phy: add binding for T-Head TH1520 USB PHY

[Icenowy Zheng]

在 2026-07-23四的 08:47 +0000，sashiko-bot at kernel.org写道：
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider:
> - [Medium] The 'reg' property is omitted from the 'required' list for
> a memory-mapped PHY.
> - [Medium] The 'avdd33-usb3-supply' is omitted from the 'required'
> list based on software limitations rather than hardware description.

Well this is also to workaround the problem raised by Sashiko yourself
at [1].

I didn't mention it in the log because I am not sure whether this is a
real problem.

[1]
https://sashiko.dev/#/patchset/20260507081710.4090814-1-zhengxingda%40iscas.ac.cn?part=6

> --
> 
> --- Patch [1]: [PATCH v2 1/2] dt-bindings: phy: add binding for T-
> Head TH1520 USB PHY ---
> commit 91b4840ee15364137facb1905580d4df2ba57663
> Author: Icenowy Zheng <zhengxingda at iscas.ac.cn>
> 
> dt-bindings: phy: add binding for T-Head TH1520 USB PHY
> 
> This commit adds a device tree binding for the T-Head TH1520 USB PHY,
> which is a Synopsys USB 3.0 FemtoPHY with custom glue logic.
> 
> > Changes in v2:
> > - Lifted avdd33-usb3-supply from required properties list. Because
> > of
> >   this the R-b from Conor isn't added yet for reconfirmation. (The
> >   related regulator isn't yet controllable because no driver is
> >   available.)
> 
> [Severity: Medium]
> Since device tree bindings must describe hardware independently of
> software
> state, shouldn't this physical supply be required if the hardware
> mandates it?
> 
> Software limitations are typically handled in the board DTS (e.g.,
> using a
> fixed-regulator), rather than compromising the generic hardware
> schema.
> 
> > diff --git a/Documentation/devicetree/bindings/phy/thead,th1520-
> > usb-phy.yaml b/Documentation/devicetree/bindings/phy/thead,th1520-
> > usb-phy.yaml
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/thead,th1520-usb-
> > phy.yaml
> [ ... ]
> > +required:
> > +  - compatible
> > +  - "#phy-cells"
> > +  - clocks
> > +  - clock-names
> > +  - resets
> > +  - reset-names
> 
> [Severity: Medium]
> Since this is a memory-mapped PHY, shouldn't the reg property be
> included in
> the required list?
> 
> Without it, device tree nodes missing the reg property will silently
> pass
> schema validation, leading to incomplete hardware descriptions that
> fail at
> runtime.