[PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller

[Nikolai Burov]

On 7/20/26 8:05 AM, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 04:54:05PM +0300, Nikolai Burov wrote:
>> Add a new compatible and document bindings for the power domain
>> controller of the MT6858 SoC.
>>
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> 
> To provide review, please open and read the entire file.
> 
>> Signed-off-by: Nikolai Burov <nikolai.burov at jolla.com>
>> ---
>>  .../bindings/power/mediatek,power-controller.yaml  | 21 +++++++++++++++++++-
>>  include/dt-bindings/power/mediatek,mt6858-power.h  | 23 ++++++++++++++++++++++
>>  2 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> index 070c6e5666dc..d03e4a925163 100644
>> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> @@ -25,6 +25,7 @@ properties:
>>      enum:
>>        - mediatek,mt6735-power-controller
>>        - mediatek,mt6795-power-controller
>> +      - mediatek,mt6858-power-controller
>>        - mediatek,mt6893-power-controller
>>        - mediatek,mt8167-power-controller
>>        - mediatek,mt8173-power-controller
>> @@ -56,7 +57,7 @@ properties:
>>        faults while enabling or disabling a power domain.
>>        For example, this may hold phandles to INFRACFG and SMI.
>>      minItems: 1
>> -    maxItems: 3
>> +    maxItems: 6
> 
> And the rest? Why does this device have flexible number of access
> controllers?

For mt6858, the "items" list I provided already overrides both minItems 
and maxItems, so it has a fixed number (6) of access controllers.

The top-level constraints are intentionally broad so that the 
SoC-specific constraints below, which all have minItems == maxItems, 
don't contradict them. Those are missing for some SoCs, but isn't that 
an existing weakness in the bindings?

Looking at the driver, apparently those missing SoCs are the ones that 
only need infracfg. That's a single access controller. So they would 
never have 3 or 2 items, only 1. This is not specified in the bindings 
though.

If you mean that it can't stay like this, I could change the bindings to 
add such a constraint for the remaining SoCs, provided that this is 
allowed - theoretically it could break some hypothetical device trees 
with excess items in access-controllers.

Alternatively, I guess one solution would be to add a minItems: 1 and 
maxItems: 3 constraint for the remaining SoCs to keep their bindings 
unaffected, even though that seems wrong from a HW point of view. But 
I'm not sure if that is what you mean.


-- 
Best regards,
Nikolai