Re: [PATCH v3 17/18] dt-bindings: display: ste,mcde: Deprecate EPOD supply

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] drm/mcde: DT ABI breakage drops legacy power support
- [Medium] dt-bindings: ste,mcde: missing power source requirement
--

commit 789856cac8c2df0e09f5a48ab8bacf3e0a2e001e
Author: Linus Walleij <linusw@kernel.org>

dt-bindings: display: ste,mcde: Deprecate EPOD supply

This commit makes epod-supply optional and marks it as deprecated. It 
instructs the MCDE to use its power domain instead.

> diff --git a/Documentation/devicetree/bindings/display/ste,mcde.yaml b/Documentation/devicetree/bindings/display/ste,mcde.yaml
> index 05e7e4ebc8820..ee34b65dd13bf 100644
> --- a/Documentation/devicetree/bindings/display/ste,mcde.yaml
> +++ b/Documentation/devicetree/bindings/display/ste,mcde.yaml
> @@ -39,7 +39,8 @@ properties:
>      maxItems: 1
>  
>    epod-supply:
> -    description: a phandle to the EPOD regulator
> +    description: a phandle to the legacy EPOD regulator
> +    deprecated: true

[Severity: Critical]
The dt-binding deprecates epod-supply in favor of generic power-domains. If
companion driver changes in this series completely drop parsing of
epod-supply and rely solely on pm_runtime to power the hardware, could this
break existing device trees?

Older Device Tree Blobs (DTBs) lack the power-domains property. Because
epod-supply is no longer parsed, the core will not attach the device to the
power domain, and the driver will fail to turn on the hardware.

Could accessing unpowered display registers cause a synchronous external
abort or silent display failure?

Would it be possible to maintain legacy fallback logic in the driver or
dynamically map the regulator to the power domain in the core, rather than
breaking existing DTBs?

[ ... ]
> @@ -103,7 +104,6 @@ required:
>    - interrupts
>    - clocks
>    - clock-names
> -  - epod-supply
>    - vana-supply
>  
>  additionalProperties: false

[Severity: Medium]
Since epod-supply is being removed from the required list to transition to
power-domains, should power-domains be added to the required list, or
perhaps an anyOf block used to enforce that at least one power source is
provided?

The MCDE hardware requires a power source to function. Without either
epod-supply or power-domains in the required properties, it seems a device
tree omitting both would silently pass schema validation, allowing
incomplete hardware descriptions to be accepted.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-ux500-power-domains-v7-1-v3-0-9352be6b86b1@kernel.org?part=17