Re: [PATCH 2/3] dt-bindings: mfd: st,stmpe: let interrupt property optional

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [Medium] The commit makes the `interrupts` property optional to fix a DT warning, but fails to add the corresponding driver support, leaving the device unusable in Linux.
- [Medium] Making the parent's `interrupts` property optional creates a schema contradiction with the `gpio` subnode, which unconditionally requires `interrupt-controller`.
- [Low] The commit message description is not capitalized, violating the MFD subsystem guidelines.

Pre-existing issues:
- [High] Regulator enable counts are leaked on multiple probe error paths.
- [High] The IRQ domain is not removed on probe error paths, causing a dangling pointer and UAF vulnerability.
--

--- Patch [2]: [PATCH 2/3] dt-bindings: mfd: st,stmpe: let interrupt property optional ---
commit 4dfb528c2761ff56029b1d565357b3fc0352b520
Author: Frank Li <Frank.Li@nxp.com>

> dt-bindings: mfd: st,stmpe: let interrupt property optional

[Severity: Low]
This isn't a bug introduced by this patch, but the MFD subsystem guidelines
require the commit description to be capitalized after the subsystem prefix.
Could this be updated to "dt-bindings: mfd: st,stmpe: Let interrupt property
optional"?

This patch marks the interrupt property as optional to fix CHECK_DTBS
warnings on boards that do not connect IRQ lines to the STMPE811 device.

> diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
> index 32ccaafe91df9..8a6abc2f5b310 100644
> --- a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
> +++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
> @@ -221,7 +221,6 @@ additionalProperties: false
>  required:
>    - compatible
>    - reg
> -  - interrupts

[Severity: Medium]
Making the interrupts property optional creates a schema contradiction with
the gpio subnode. 

The child binding in Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
unconditionally requires interrupt-controller. If the parent lacks an
interrupt, how can it satisfy the child's requirement?

[Severity: Medium]
Does the driver currently support probing the STMPE811 without an interrupt?

Looking at the driver, it explicitly rejects the STMPE811 when configured
without an interrupt:

drivers/mfd/stmpe.c:stmpe_probe() {
    ...
    if (!stmpe_noirq_variant_info[stmpe->partnum]) {
        dev_err(stmpe->dev,
                "%s does not support no-irq mode!\n",
                stmpe->variant->name);
        return -ENODEV;
    }
    ...
}

Could this leave the device unusable in Linux when the device tree omits
the interrupt property?

[Severity: High]
This is a pre-existing issue, but I noticed regulator enable counts might be
leaking on probe error paths. 

If devm_gpiod_get_optional() defers or fails, do we leak the enable count
for the vcc regulator?

drivers/mfd/stmpe.c:stmpe_probe() {
    ...
    stmpe->vcc = devm_regulator_get_optional(ci->dev, "vcc");
    if (!IS_ERR(stmpe->vcc)) {
        ret = regulator_enable(stmpe->vcc);
        ...
    }
    ...
    irq_gpio = devm_gpiod_get_optional(ci->dev, "irq", GPIOD_ASIS);
    ret = PTR_ERR_OR_ZERO(irq_gpio);
    if (ret) {
        ...
        return ret;
    }
    ...
}

[Severity: High]
This is a pre-existing issue, but does the probe error path leave a dangling
pointer in the IRQ domain? 

If a failure occurs after stmpe_irq_init(), like during the IRQ request:

drivers/mfd/stmpe.c:stmpe_probe() {
    ...
    ret = devm_request_threaded_irq(ci->dev, stmpe->irq, NULL,
            stmpe_irq, pdata->irq_trigger | IRQF_ONESHOT,
            "stmpe", stmpe);
    if (ret) {
        dev_err(stmpe->dev, "failed to request IRQ: %d\n", ret);
        return ret;
    }
    ...
}

Since irq_domain_create_simple() isn't devres-managed, could this leave the
globally registered IRQ domain with a dangling host_data pointer when the
stmpe struct is freed?

>  
>  examples:
>    - |

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-dts-stmpe-v1-0-1f51d15bb358@nxp.com?part=2