Re: [PATCH v3 2/8] dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The parent PMIC schema (`qcom-pm8xxx.yaml`) is not updated to allow the new `qcom,pm8921-misc` child node, causing validation errors for any DT using it.
- [High] The `if` condition uses `const: qcom,pm8941-misc` instead of `contains: const: qcom,pm8941-misc` for the `compatible` property, inadvertently making `reg` optional for `qcom,pm8941-misc` devices.
- [Medium] The schema allows `qcom,pm8921-misc` devices to have a `reg` property, even though the hardware variant does not use a register resource.
--

commit 8b3e7ba33de64864005f6ce3e91467d662e5662d
Author: Alexandre MINETTE <contact@alex-min.fr>

dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible

This commit adds the qcom,pm8921-misc compatible string to the PMIC USB
ID Extcon binding. It makes the reg property optional since the downstream
PM8xxx misc device does not use a register resource.

>     The device is modeled as a child of the SSBI-connected PM8921 PMIC.
>     Unlike PM8941, the downstream PM8xxx misc device is not instantiated with
>     a register resource for this path, and the mainline extcon driver only
>     needs the named USB ID interrupt. Allow qcom,pm8921-misc without requiring
>     reg.

The parent schema (qcom-pm8xxx.yaml) enforces additionalProperties: false
and strictly defines permitted children via patternProperties.

Without an update to the parent schema, will device trees including the
qcom,pm8921-misc node fail dt_binding_check?

> diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
> index 6b80518cbf629..4e3d0aadb83cc 100644
> --- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
> +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
[ ... ]
> @@ -37,10 +38,18 @@ properties:
>            - const: usb_vbus
>  required:
>    - compatible
> -  - reg
>    - interrupts
>    - interrupt-names
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          const: qcom,pm8941-misc

Devicetree schemas evaluate the compatible property as an array of strings.
Because comparing an array to a scalar string always evaluates to false,
this condition will never match, and the reg property will silently stop
being enforced for qcom,pm8941-misc devices.

Should this condition use "contains: const: qcom,pm8941-misc" instead?

> +    then:
> +      required:
> +        - reg

Even though reg is no longer globally required, the global properties block
still defines it. This means the schema will silently accept a bogus reg
property for qcom,pm8921-misc without an explicit disallowance.

Since the PM8921 variant is not instantiated with a register resource,
should this block include an "else" clause specifying "reg: false"?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=2