On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote: > 在 2026-06-26五的 08:19 +0100，Conor Dooley写道： > > On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote: > > > 在 2026-06-25四的 17:33 +0100，Conor Dooley写道： > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote: > > > > > +allOf: > > > > > + - if: > > > > > + properties: > > > > > + compatible: > > > > > + contains: > > > > > + const: thead,th1520-dc8200 > > > > > + then: > > > > > + properties: > > > > > + clocks: > > > > > + minItems: 5 > > > > > + maxItems: 5 > > > > > + > > > > > + clock-names: > > > > > + minItems: 5 > > > > > + maxItems: 5 > > > > > > > > All the maxItems here repeat the maximum constraint and do > > > > nothing. > > > > > > > > Since you didn't change the minimum constraint at the top level, > > > > your > > > > minItems also do nothing. > > > > > > > > > + > > > > > + resets: > > > > > + minItems: 3 > > > > > + maxItems: 3 > > > > > + > > > > > + reset-names: > > > > > + minItems: 3 > > > > > + maxItems: 3 > > > > > + > > > > > + required: > > > > > + - resets > > > > > + - reset-names > > > > > > > > Both conditional sections have this, but the original binding > > > > doesn't > > > > require these for the thead device. This is a functional change > > > > therefore and shouldn't be in a patch calling itself "generalise > > > > for > > > > single ended variants". > > > > > > Well yes they're required. > > > > > > Should I send a patch adding the `thead,th1520-dc8200` part of the > > > schema? > > > > If you mean the code above, no. Adding a conditional section when > > there's only that compatible doesn't make sense. > > > > What you could do is just add it at the top level though, which would > > also benefit this patch since it'd not have to be conditionally added > > for the new nuvoton device. > > Just note in your commit message about what the ABI impact of the > > change > > to required properties is (effectively nothing because it's optional > > in > > the driver and the only user has the properties). > > Okay, I will craft such a patch and send it. > > > > > > > > + > > > > > + resets: > > > > > + minItems: 1 > > > > > + maxItems: 1 > > > > > + > > > > > + reset-names: > > > > > + items: > > > > > + - const: core > > > > > > > > This is just maxItems: 1. > > > > > > Well the implicit rules of DT binding schemas are quite weird... > > > > I don't think it is that strange, as the binding has > > reset-names: > > items: > > - const: core > > - const: axi > > - const: ahb > > Ah does the list constraint the order of items? If it constrains the
It does, yes. Alternatively, using an enum permits free ordering. > order, it partly breaks the intention of having names; if it does not > constrain the order, it needs to be clarified that the required 1 reset > is core instead of the other two. Given the discussion we're having on the clocks, I wonder if this is also an oversimplification and the IP has three resets inputs hooked up to one output of the reset controller (or 3 outputs controlled by one bit..).
signature.asc
Description: PGP signature
