Re: [PATCH v2 2/3] dt-bindings: i3c: dw: Add apb reset
Conor Dooley <[email protected]> Tue, 12 May 2026 17:44:41 +0100
| Newsgroups | dev.linux.lists.sashiko,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <20260512-curvy-ashes-bde0e8e8d473@spud> |
On Mon, May 11, 2026 at 11:00:00PM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [Medium] Adding a second item to the `resets` and `reset-names` list without specifying `minItems: 1` makes both resets strictly required whenever the property is present, breaking DT schema backward compatibility. > -- > > commit 0c4b11b6e45b719eb15a1a87171391a4bfb310b9 > Author: Jisheng Zhang <[email protected]> > > dt-bindings: i3c: dw: Add apb reset > > This commit updates the DesignWare I3C master binding to support an > optional APB interface reset signal. > > > diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml > > index 613dce7757bc3..2575442b28ff4 100644 > > --- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml > > +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml > > @@ -38,10 +38,12 @@ properties: > > resets: > > items: > > - description: Reset signal > > + - description: APB interface reset signal > > Does adding this second item inadvertently make the APB reset strictly > mandatory for validation? In dt-schema, when items are defined as a list, > minItems implicitly defaults to the length of that list. Without an > explicit minItems: 1 constraint, device trees defining only the single > core_rst reset might fail schema validation. > > > > > reset-names: > > items: > > - const: core_rst > > + - const: apb_rst > > Should minItems: 1 be added to both the resets and reset-names properties > to maintain backward compatibility? > > Since the driver gracefully handles a missing apb_rst by using > devm_reset_control_get_optional_exclusive_deasserted(), adding the minItems > constraint would keep single-reset configurations perfectly valid. Obviously this is all crap and can be ignored, since the other reset is added in the series.
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCagNY+QAKCRB4tDGHoIJi 0ikJAQC7LIxijJWf+xlPboDCs5YDj39wv60+tEqfC2s3l3kC6wD/TXs6yuBmbGkH S+dgxRcbFt05dFBbleuaebnfXJckbA8= =vDjU -----END PGP SIGNATURE-----