From: sashiko-bot@kernel.org
To: "Zhentao Guo" <zhentao.guo@amlogic.com>
Cc: linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org,
robh@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org,
media-ci@linuxtv.org
Subject: Re: [PATCH v10 3/6] media: dt-bindings: Add Amlogic V4L2 video decoder
Date: Thu, 24 Sep 2026 08:01:56 +0000 [thread overview]
Message-ID: <20260924080156.9E0161F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924-b4-s4-vdec-upstream-v10-3-1289303a58a4@amlogic.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: amlogic,s4-vdec: missing interrupt-names in required list and example
- [Low] dt-bindings: amlogic,s4-vdec: unbounded array properties missing maxItems
--
commit ea1e1b5dce46c139b8fcb208da9bf35c4469463a
Author: Zhentao Guo <zhentao.guo@amlogic.com>
media: dt-bindings: Add Amlogic V4L2 video decoder
Add bindings for Amlogic hardware decoder accelerator.
> diff --git a/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
> new file mode 100644
> index 0000000000000..751043c3d9ccf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
> @@ -0,0 +1,114 @@
[ ... ]
> +properties:
> + compatible:
> + const: amlogic,s4-vdec
> +
> + reg:
> + minItems: 2
[Severity: Low]
Should the reg property include a maxItems: 2 limit?
Since the reg-names property strictly enforces exactly 2 entries via its
items list, omitting maxItems: 2 allows the schema to incorrectly pass
validation for device trees with 3 or more entries.
> +
> + reg-names:
> + items:
> + - const: dos
> + - const: dmc
> +
> + interrupts:
> + minItems: 2
[Severity: Low]
Is a maxItems: 2 limit missing for the interrupts property?
Since the interrupt-names property strictly enforces exactly 2 entries,
omitting maxItems: 2 allows device trees with 3 or more entries to pass schema
validation.
> +
> + interrupt-names:
> + items:
> + - const: hvdec
> + - const: vdec
> +
[ ... ]
> + power-domains:
> + minItems: 2
[Severity: Low]
Should the power-domains property specify a maxItems: 2 limit?
Since the power-domain-names property strictly enforces exactly 2 entries,
omitting maxItems: 2 allows device trees with 3 or more entries to pass
validation.
> +
> + power-domain-names:
> + items:
> + - const: vdec
> + - const: hvdec
[ ... ]
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - resets
> + - amlogic,canvas
> + - amlogic,secure-monitor
[Severity: Low]
Should interrupt-names be included in this required list?
The interrupt-names property is defined with exactly two items but is
omitted here. Since all other -names properties (reg-names, clock-names,
power-domain-names) are explicitly required, this omission allows incomplete
device tree nodes to pass schema validation.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/amlogic,s4-pll-clkc.h>
> + #include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
> + #include <dt-bindings/power/meson-s4-power.h>
> + #include <dt-bindings/reset/amlogic,meson-s4-reset.h>
> + video-codec@fe320000 {
> + compatible = "amlogic,s4-vdec";
> + reg = <0xfe320000 0x10000>,
> + <0xfe036000 0x20>;
> + reg-names = "dos",
> + "dmc";
> + interrupts = <GIC_SPI 91 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 92 IRQ_TYPE_EDGE_RISING>;
[Severity: Low]
Should the device tree example include interrupt-names?
The example fails to provide interrupt-names, which reflects the omission in
the required list and results in an incomplete DT node.
> + clocks = <&clkc_periphs CLKID_DOS>,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-b4-s4-vdec-upstream-v10-0-1289303a58a4@amlogic.com?part=3
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Zhentao Guo" <zhentao.guo@amlogic.com>
Cc: linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org,
robh@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org,
media-ci@linuxtv.org
Subject: Re: [PATCH v10 3/6] media: dt-bindings: Add Amlogic V4L2 video decoder
Date: Thu, 24 Sep 2026 08:01:56 +0000 [thread overview]
Message-ID: <20260924080156.9E0161F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924-b4-s4-vdec-upstream-v10-3-1289303a58a4@amlogic.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: amlogic,s4-vdec: missing interrupt-names in required list and example
- [Low] dt-bindings: amlogic,s4-vdec: unbounded array properties missing maxItems
--
commit ea1e1b5dce46c139b8fcb208da9bf35c4469463a
Author: Zhentao Guo <zhentao.guo@amlogic.com>
media: dt-bindings: Add Amlogic V4L2 video decoder
Add bindings for Amlogic hardware decoder accelerator.
> diff --git a/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
> new file mode 100644
> index 0000000000000..751043c3d9ccf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/amlogic,s4-vdec.yaml
> @@ -0,0 +1,114 @@
[ ... ]
> +properties:
> + compatible:
> + const: amlogic,s4-vdec
> +
> + reg:
> + minItems: 2
[Severity: Low]
Should the reg property include a maxItems: 2 limit?
Since the reg-names property strictly enforces exactly 2 entries via its
items list, omitting maxItems: 2 allows the schema to incorrectly pass
validation for device trees with 3 or more entries.
> +
> + reg-names:
> + items:
> + - const: dos
> + - const: dmc
> +
> + interrupts:
> + minItems: 2
[Severity: Low]
Is a maxItems: 2 limit missing for the interrupts property?
Since the interrupt-names property strictly enforces exactly 2 entries,
omitting maxItems: 2 allows device trees with 3 or more entries to pass schema
validation.
> +
> + interrupt-names:
> + items:
> + - const: hvdec
> + - const: vdec
> +
[ ... ]
> + power-domains:
> + minItems: 2
[Severity: Low]
Should the power-domains property specify a maxItems: 2 limit?
Since the power-domain-names property strictly enforces exactly 2 entries,
omitting maxItems: 2 allows device trees with 3 or more entries to pass
validation.
> +
> + power-domain-names:
> + items:
> + - const: vdec
> + - const: hvdec
[ ... ]
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - resets
> + - amlogic,canvas
> + - amlogic,secure-monitor
[Severity: Low]
Should interrupt-names be included in this required list?
The interrupt-names property is defined with exactly two items but is
omitted here. Since all other -names properties (reg-names, clock-names,
power-domain-names) are explicitly required, this omission allows incomplete
device tree nodes to pass schema validation.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/amlogic,s4-pll-clkc.h>
> + #include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
> + #include <dt-bindings/power/meson-s4-power.h>
> + #include <dt-bindings/reset/amlogic,meson-s4-reset.h>
> + video-codec@fe320000 {
> + compatible = "amlogic,s4-vdec";
> + reg = <0xfe320000 0x10000>,
> + <0xfe036000 0x20>;
> + reg-names = "dos",
> + "dmc";
> + interrupts = <GIC_SPI 91 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 92 IRQ_TYPE_EDGE_RISING>;
[Severity: Low]
Should the device tree example include interrupt-names?
The example fails to provide interrupt-names, which reflects the omission in
the required list and results in an incomplete DT node.
> + clocks = <&clkc_periphs CLKID_DOS>,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-b4-s4-vdec-upstream-v10-0-1289303a58a4@amlogic.com?part=3
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-09-24 8:01 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 7:55 [PATCH v10 0/6] Add Amlogic stateless H.264 video decoder for S4 Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` [PATCH v10 1/6] firmware: meson: sm: video firmware loading via secure monitor Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` [PATCH v10 2/6] firmware: meson: sm: Add video firmware loading SMC call Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` [PATCH v10 3/6] media: dt-bindings: Add Amlogic V4L2 video decoder Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 8:01 ` sashiko-bot [this message]
2026-09-24 8:01 ` sashiko-bot
2026-09-28 10:58 ` Krzysztof Kozlowski
2026-09-28 10:58 ` Krzysztof Kozlowski
2026-09-29 2:59 ` Zhentao Guo
2026-09-29 2:59 ` Zhentao Guo
2026-09-29 5:40 ` Krzysztof Kozlowski
2026-09-29 5:40 ` Krzysztof Kozlowski
2026-09-29 5:57 ` Zhentao Guo
2026-09-29 5:57 ` Zhentao Guo
2026-09-29 6:00 ` Krzysztof Kozlowski
2026-09-29 6:00 ` Krzysztof Kozlowski
2026-09-29 6:23 ` Zhentao Guo
2026-09-29 6:23 ` Zhentao Guo
2026-09-29 6:36 ` Krzysztof Kozlowski
2026-09-29 6:36 ` Krzysztof Kozlowski
2026-09-29 8:21 ` Zhentao Guo
2026-09-29 8:21 ` Zhentao Guo
2026-09-29 8:25 ` Krzysztof Kozlowski
2026-09-29 8:25 ` Krzysztof Kozlowski
2026-09-29 9:41 ` Zhentao Guo
2026-09-29 9:41 ` Zhentao Guo
2026-09-24 7:55 ` [PATCH v10 4/6] decoder: Add V4L2 stateless H.264 decoder driver Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 8:16 ` sashiko-bot
2026-09-24 8:16 ` sashiko-bot
2026-09-24 7:55 ` [PATCH v10 5/6] arm64: dts: amlogic: Add video decoder driver support for S4 SOCs Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` [PATCH v10 6/6] arm64: defconfig: Enable CONFIG_VIDEO_AMLOGIC_VDEC Zhentao Guo
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
2026-09-24 7:55 ` Zhentao Guo via B4 Relay
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=20260924080156.9E0161F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=media-ci@linuxtv.org \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhentao.guo@amlogic.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.