From: sashiko-bot@kernel.org
To: "Nikolai Burov" <nikolai.burov@jolla.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller
Date: Wed, 15 Jul 2026 14:02:05 +0000 [thread overview]
Message-ID: <20260715140205.AA0281F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715-mt6858-pmdomain-v2-1-6293e87fc093@jolla.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The conditional block for `mediatek,mt6858-power-controller` does not enforce the required number of `access-controllers` phandles with explicit `minItems` and `maxItems`.
- [Medium] Increasing the global `maxItems` for `access-controllers` from 3 to 6 relaxes validation rules for older hardware generations that do not have their own conditional overrides.
--
--- Patch [1]: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller ---
commit eeb672419310866e8b79518dc171a08dbb0367dd
Author: Nikolai Burov <nikolai.burov@jolla.com>
dt-bindings: power: Add MediaTek MT6858 power domain controller
This patch introduces the compatible string and documents the bindings for
the power domain controller on the MediaTek MT6858 SoC.
> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> index 070c6e5666dc0..d03e4a9251635 100644
> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
[ ... ]
> @@ -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
[Severity: Medium]
Does increasing this global limit unintentionally relax validation for
older hardware generations?
Because older platforms like mt6735 or mt6795 lack an explicit conditional
override, wouldn't they now erroneously pass validation even if they define
up to 6 access controllers? Is there a way to introduce a restrictive
conditional block for those older generations to retain their 3-item limit?
[ ... ]
> allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - mediatek,mt6858-power-controller
> + then:
> + properties:
> + access-controllers:
[Severity: Medium]
Does this conditional block also need explicit minItems and maxItems
constraints set to 6?
In JSON Schema, providing a list of schemas under the items property only
validates the elements that are actually present. Because the global
minItems is 1, wouldn't an incomplete device tree node providing only 1 to 5
phandles silently pass validation here?
> + items:
> + - description: handle to INFRACFG register block
> + - description: handle to IMG_SUB0 register block
> + - description: handle to CAM_SUB1 register block
> + - description: handle to CAM_SUB0 register block
> + - description: handle to IPE_SUB0 register block
> + - description: handle to VLPCFG register block
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-mt6858-pmdomain-v2-0-6293e87fc093@jolla.com?part=1
next prev parent reply other threads:[~2026-07-15 14:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 13:54 [PATCH v2 0/3] pmdomain: mediatek: Add MT6858 support Nikolai Burov via B4 Relay
2026-07-15 13:54 ` [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller Nikolai Burov via B4 Relay
2026-07-15 14:02 ` sashiko-bot [this message]
2026-07-15 13:54 ` [PATCH v2 2/3] pmdomain: mediatek: Add support for secure modem power domain control Nikolai Burov via B4 Relay
2026-07-15 14:04 ` sashiko-bot
2026-07-15 13:54 ` [PATCH v2 3/3] pmdomain: mediatek: Add support for MT6858 SoC Nikolai Burov via B4 Relay
2026-07-15 14:17 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260715140205.AA0281F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=nikolai.burov@jolla.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox