On Mon, Jan 12, 2026 at 2:20 PM Rob Herring robh@kernel.org wrote:
On Mon, Jan 12, 2026 at 10:01:50AM +0100, Krzysztof Kozlowski wrote:
Review given to v2 [1] of commit fc259b024cb3 ("dt-bindings: usb: Add binding for PS5511 hub controller") asked to use unevaluatedProperties, but this was ignored by the author probably because current dtschema does not allow to use both additionalProperties and unevaluatedProperties. As an effect, this binding does not end with unevaluatedProperties and allows any properties to be added.
Fix this by reverting the approach suggested at v2 review and using simpler definition of "reg" constraints.
Link: https://lore.kernel.org/r/20250416180023.GB3327258-robh@kernel.org/ [1] Fixes: fc259b024cb3 ("dt-bindings: usb: Add binding for PS5511 hub controller") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@oss.qualcomm.com
.../devicetree/bindings/usb/parade,ps5511.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/parade,ps5511.yaml b/Documentation/devicetree/bindings/usb/parade,ps5511.yaml index 10d002f09db8..154d779e507a 100644 --- a/Documentation/devicetree/bindings/usb/parade,ps5511.yaml +++ b/Documentation/devicetree/bindings/usb/parade,ps5511.yaml @@ -15,6 +15,10 @@ properties: - usb1da0,5511 - usb1da0,55a1
- reg:
- minimum: 1
- maximum: 5
This 'reg' would be the upstream USB port. We have no idea what its constraints are for the value.
reset-gpios: items: - description: GPIO specifier for RESETB pin. @@ -41,12 +45,6 @@ properties: minimum: 1 maximum: 5
-additionalProperties:
- properties:
- reg:
minimum: 1maximum: 5Removing this is wrong. This is defining the number of downstream USB ports for this hub.
What's wrong here is 'type: object' is missing, so any property that's not a object passes (no, 'properties' doesn't imply it's an object).
We should fix dtschema to allow additionalProperties when not a boolean property to coexist with unevaluatedProperties. I'll look into it.
Actually, allowing both wouldn't make sense here.
If you rely on usb-hub.yaml (via usb-device.yaml) to define 'reg', the additionalProperties schema is still going to be applied to 'reg' as unevaluatedProperties has no impact on it. That would happen to work since there's no 'type: object'.
I think the additionalProperties should be a patternProperties instead because we need to define the unit-address format:
patternProperties: '@[1-5$': type: object ...
Rob