* Re: [PATCH RFC v2 02/11] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
From: Mark Brown @ 2026-04-15 16:26 UTC (permalink / raw)
To: Jerome Brunet
Cc: Valerio Setti, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <1jy0ios3f9.fsf@starbuckisacylon.baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
On Wed, Apr 15, 2026 at 04:28:58PM +0200, Jerome Brunet wrote:
> Valerio maybe you could keep function above just to set the rate, but
> enabling the clocks through a DAPM supply widget ? This is kind of what
> the AXG is doing.
> what do you think ?
FWIW this seems like a sensible plan to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Antony Kurniawan Soemardi @ 2026-04-15 15:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <caa589af-f026-4664-8fb9-6b23b0e087f9@oss.qualcomm.com>
On 4/14/2026 3:07 PM, Konrad Dybcio wrote:
> On 4/14/26 10:06 AM, Konrad Dybcio wrote:
>> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>>
>>> msm8960 uses the same clock descriptor as apq8064 but lacked the
>>
>> This doesn't quite seem to be the case, some fields differ and
>> apq8064 additionally has:
>>
>> QCOM_RPM_PM8821_SMPS1
>> QCOM_RPM_PM8821_SMPS2
>> QCOM_RPM_PM8821_LDO1
>> QCOM_RPM_VDDMIN_GPIO
>
> Ah hmm, the MFD driver seems to provide *all* RPM resources..
What I meant by "clock descriptor" in the commit message was
specifically the subset corresponding to RPM managed clocks. From what I
can tell based on downstream code, msm8960 and apq8064 seem to share the
same set of RPM clocks, even though the overall resource lists differ.
Is that understanding correct?
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH] arm64: dts: st: Fix SAI addresses on stm32mp251
From: Olivier MOYSAN @ 2026-04-15 17:00 UTC (permalink / raw)
To: Marek Vasut, linux-arm-kernel
Cc: Alexandre Torgue, Conor Dooley, Krzysztof Kozlowski,
Maxime Coquelin, Rob Herring, devicetree, linux-kernel,
linux-stm32
In-Reply-To: <20260411130300.19603-1-marex@nabladev.com>
Hi Marek,
On 4/11/26 15:02, Marek Vasut wrote:
> The second field of SAI register addresses should be within 0x3f0 bytes
> from the start of the SAI register addresses, the second field describes
> the ID registers which are at that addrses. Currently, the second field
> does not match RM, fix it.
>
> Fixes: bf26d75a95f1 ("arm64: dts: st: add sai support on stm32mp251")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Olivier Moysan <olivier.moysan@foss.st.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> ---
> arch/arm64/boot/dts/st/stm32mp251.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> index 673fbc5632e69..9c63fdb5a885a 100644
> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> @@ -1202,7 +1202,7 @@ spi5: spi@40280000 {
>
> sai1: sai@40290000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x40290000 0x4>, <0x4029a3f0 0x10>;
> + reg = <0x40290000 0x4>, <0x402903f0 0x10>;
> ranges = <0 0x40290000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1236,7 +1236,7 @@ sai1b: audio-controller@40290024 {
>
> sai2: sai@402a0000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x402a0000 0x4>, <0x402aa3f0 0x10>;
> + reg = <0x402a0000 0x4>, <0x402a03f0 0x10>;
> ranges = <0 0x402a0000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1270,7 +1270,7 @@ sai2b: audio-controller@402a0024 {
>
> sai3: sai@402b0000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x402b0000 0x4>, <0x402ba3f0 0x10>;
> + reg = <0x402b0000 0x4>, <0x402b03f0 0x10>;
> ranges = <0 0x402b0000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1362,7 +1362,7 @@ usart1: serial@40330000 {
>
> sai4: sai@40340000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x40340000 0x4>, <0x4034a3f0 0x10>;
> + reg = <0x40340000 0x4>, <0x403403f0 0x10>;
> ranges = <0 0x40340000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com>
Thanks for your patch
BRs
Olivier
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-04-15 17:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260415-sensible-kiwi-of-argument-44d6ed@quoll>
On 2026-04-15 09:03 +02:00, Krzysztof Kozlowski wrote:
> On Tue, Apr 14, 2026 at 12:02:54PM +0530, Kaustabh Chakraborty wrote:
>> +description: |
>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> + 8-bit brightness control for each channel, typically used as status
>> + indicators in mobile phones.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: common.yaml#
>
> Rob's comment is still valid:
> 1. How do you address one of three LEDs in non-RGB case?
> 2. Where is multi-color?
Yes, multi-color should have been added here.
>
> And based on this alone without other properties, I say this should be
> part of top-level schema. Separate node is fine, but no need for
> separate binding.
BTW, for loading the sub-device driver via platform (as it won't be a
separate binding) the driver *must* be built-in. Although not related to
bindings, this seems counter-intuitive. I see the same problem with the
PMIC charger.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Dawid Glazik @ 2026-04-15 18:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <d74e7aa8-1110-469a-ac7e-3829c2458852@kernel.org>
On 4/9/2026 9:30 AM, Krzysztof Kozlowski wrote:
> On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
>> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>>> Introduce the device-tree bindings for I3C global registers found on
>>> AST2600 SoCs.
>>>
>>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>>> ---
>>> I wasn't sure if I should add newline at the end of the
>>> file or not so I took
>>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>>> as an example.
>>
>> Answer is: you cannot have patch warnings.
>>
>> Documentation/devicetree/bindings/i3c does not have patch warning, does
>> it?
>
> And if you tested this code with standard tools, you would see that...
>
> Best regards,
> Krzysztof
Thank you for the review and feedback. This is my first contribution to
Linux kernel so I'm still learning the process and toolchain. I
apologize for the rookie mistakes. I will address all the issues you've
pointed out and resubmit the series.
Best regards,
Dawid
^ permalink raw reply
* Re: [PATCH] dt-bindings: firmware: qcom,scm: Document SCM on Hawi SoC
From: Rob Herring (Arm) @ 2026-04-15 20:30 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Guru Das Srinagesh, linux-kernel, Konrad Dybcio, linux-arm-msm,
devicetree, Krzysztof Kozlowski, Bjorn Andersson, Robert Marko,
Conor Dooley
In-Reply-To: <20260401123825.589452-1-mukesh.ojha@oss.qualcomm.com>
On Wed, 01 Apr 2026 18:08:25 +0530, Mukesh Ojha wrote:
> Document SCM compatible for the Qualcomm Hawi SoC.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 01/24] dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
From: Rob Herring (Arm) @ 2026-04-15 20:32 UTC (permalink / raw)
To: John Madieu
Cc: Claudiu Beznea, Mark Brown, Jaroslav Kysela, Krzysztof Kozlowski,
Philipp Zabel, Frank Li, Takashi Iwai, Geert Uytterhoeven,
Biju Das, linux-renesas-soc, devicetree, Fabrizio Castro,
Vinod Koul, linux-sound, Stephen Boyd, Conor Dooley,
Thomas Gleixner, Michael Turquette, dmaengine, linux-kernel,
Liam Girdwood, linux-clk, John Madieu, Magnus Damm, Lad Prabhakar,
Kuninori Morimoto
In-Reply-To: <20260402090524.9137-2-john.madieu.xa@bp.renesas.com>
On Thu, 02 Apr 2026 11:05:00 +0200, John Madieu wrote:
> RZ/V2H, RZ/V2N, and RZ/G3E support external audio clock inputs
> (AUDIO_CLKA, AUDIO_CLKB, AUDIO_CLKC) that can be used by the Audio Clock
> Generator (ADG) to derive internal audio clocks. These clocks are optional
> and their frequencies are set by the board.
>
> Update the bindings to allow these optional clocks for all RZ/V2H family
> SoCs.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: Remove maxItems as it not needed with items lists.
>
> .../devicetree/bindings/clock/renesas,rzv2h-cpg.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 05/24] ASoC: dt-bindings: renesas,rsnd: Split into generic and SoC-specific parts
From: Rob Herring @ 2026-04-15 20:51 UTC (permalink / raw)
To: John Madieu
Cc: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260402090524.9137-6-john.madieu.xa@bp.renesas.com>
On Thu, Apr 02, 2026 at 11:05:04AM +0200, John Madieu wrote:
> The current renesas,rsnd.yaml binding file handles all supported SoCs
> in a single schema, resulting in deeply nested if/else/then constructs
> that become increasingly difficult to maintain. Each new SoC addition
> amplifies this complexity, making reviews harder and diffs noisier than
> they need to be.
>
> Refactor the binding by extracting the common properties shared across
> all SoCs into a dedicated renesas,rsnd-common.yaml schema, and keeping
> only SoC-specific constraints (required nodes, port counts, clock names,
> etc.) in per-SoC or per-family files that $ref the common part.
>
> This prepares the ground for upcoming SoCs such as the RZ/G3E, which
> introduces a different set of audio resources compared to existing
> R-Car Gen variants. With the split in place, adding RZ/G3E support
> becomes a self-contained change that neither bloats a monolithic schema
> nor buries new constraints inside ever-deeper conditional blocks.
>
> No functional change in validation behaviour for existing device trees.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: New patch
>
> .../bindings/sound/renesas,rsnd-common.yaml | 196 +++++++++++
> .../bindings/sound/renesas,rsnd.yaml | 319 +++++-------------
> 2 files changed, 274 insertions(+), 241 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> new file mode 100644
> index 000000000000..ec6bf644d1a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> @@ -0,0 +1,196 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,rsnd-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car/RZ Sound Common Properties
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> +
> +description:
> + Common property and subnode definitions shared by Renesas R-Car and RZ
> + sound controller bindings.
> +
> +select: false
> +
> +properties:
> + compatible: true
> +
> + reg: true
> +
> + reg-names: true
Drop these as they should be defined in the device specfic schemas.
> +
> + "#sound-dai-cells":
> + description:
> + Must be 0 for a single-DAI system and 1 for a multi-DAI system.
> + enum: [0, 1]
> +
> + "#clock-cells":
> + description:
> + Must be 0 when the system has audio_clkout and 1 when it has
> + audio_clkout0/1/2/3.
> + enum: [0, 1]
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + clock-frequency:
> + description: Audio clock output frequency for audio_clkout0/1/2/3.
> +
> + clkout-lr-asynchronous:
> + description: audio_clkoutn is asynchronous with lr-clock.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + power-domains: true
> +
> + resets: true
> +
> + reset-names: true
> +
> + clocks: true
> +
> + clock-names: true
And drop these unless you have some global constraints.
> +
> + port:
> + $ref: audio-graph-port.yaml#/definitions/port-base
> + unevaluatedProperties: false
Blank line
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + $ref: audio-graph-port.yaml#/definitions/endpoint-base
Blank line
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Blank line
(and similar throughout)
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + unevaluatedProperties: false
Move after $ref.
> +
> + rcar_sound,dvc:
> + description: DVC subnode.
> + type: object
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
Move after 'type'.
> +
> + rcar_sound,mix:
> + description: MIX subnode.
> + type: object
> + patternProperties:
> + "^mix-[0-1]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,ctu:
> + description: CTU subnode.
> + type: object
> + patternProperties:
> + "^ctu-[0-7]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,ssi:
> + description: SSI subnode.
> + type: object
> + patternProperties:
> + "^ssi-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + shared-pin:
> + description: Shared clock pin.
> + $ref: /schemas/types.yaml#/definitions/flag
> + pio-transfer:
> + description: PIO transfer mode.
> + $ref: /schemas/types.yaml#/definitions/flag
> + no-busif:
> + description: BUSIF is not used for the mem-to-SSI via DMA case.
> + $ref: /schemas/types.yaml#/definitions/flag
> + required:
> + - interrupts
> + additionalProperties: false
> +
> +patternProperties:
> + 'rcar_sound,dai(@[0-9a-f]+)?$':
Why does this have a unit-address, but no 'reg' property? That should be
dropped.
> + description: DAI subnode.
> + type: object
> + patternProperties:
> + "^dai([0-9]+)?$":
> + type: object
> + additionalProperties: false
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + anyOf:
> + - required:
> + - playback
> + - required:
> + - capture
> + additionalProperties: false
> +
> + 'ports(@[0-9a-f]+)?$':
> + $ref: audio-graph-port.yaml#/definitions/port-base
This is 'ports', not 'port', so not the right ref.
> + unevaluatedProperties: false
> + patternProperties:
> + '^port(@[0-9a-f]+)?$':
> + $ref: "#/properties/port"
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> index e8a2acb92646..0d989922a5b4 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> @@ -9,8 +9,11 @@ title: Renesas R-Car Sound Driver
> maintainers:
> - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> -properties:
> +description:
> + Binding for Renesas R-Car Gen1/Gen2/Gen3/Gen4 and RZ/G1/G2 sound
> + controllers using the standard RSND layout.
>
> +properties:
> compatible:
> oneOf:
> # for Gen1 SoC
> @@ -67,34 +70,6 @@ properties:
> minItems: 1
> maxItems: 5
>
> - "#sound-dai-cells":
> - description: |
> - it must be 0 if your system is using single DAI
> - it must be 1 if your system is using multi DAIs
> - This is used on simple-audio-card
> - enum: [0, 1]
> -
> - "#clock-cells":
> - description: |
> - it must be 0 if your system has audio_clkout
> - it must be 1 if your system has audio_clkout0/1/2/3
> - enum: [0, 1]
> -
> - "#address-cells":
> - const: 1
> -
> - "#size-cells":
> - const: 0
> -
> - clock-frequency:
> - description: for audio_clkout0/1/2/3
> -
> - clkout-lr-asynchronous:
> - description: audio_clkoutn is asynchronizes with lr-clock.
> - $ref: /schemas/types.yaml#/definitions/flag
> -
> - power-domains: true
> -
> resets:
> minItems: 1
> maxItems: 11
> @@ -109,181 +84,45 @@ properties:
> maxItems: 31
>
> clock-names:
> - description: List of necessary clock names.
> - # details are defined below
> -
> - # ports is below
> - port:
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - "^endpoint(@[0-9a-f]+)?":
> - $ref: audio-graph-port.yaml#/definitions/endpoint-base
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - unevaluatedProperties: false
> -
> - rcar_sound,dvc:
> - description: DVC subnode.
> - type: object
> - patternProperties:
> - "^dvc-[0-1]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 1
> - dma-names:
> - const: tx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,mix:
> - description: MIX subnode.
> - type: object
> - patternProperties:
> - "^mix-[0-1]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,ctu:
> - description: CTU subnode.
> - type: object
> - patternProperties:
> - "^ctu-[0-7]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,src:
> - description: SRC subnode.
> - type: object
> - patternProperties:
> - "^src-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - additionalProperties: false
> -
> - rcar_sound,ssiu:
> - description: SSIU subnode.
> - type: object
> - patternProperties:
> - "^ssiu-[0-9]+$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,ssi:
> - description: SSI subnode.
> - type: object
> - patternProperties:
> - "^ssi-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - minItems: 2
> - maxItems: 4
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - - txu # if no ssiu node
> - - rxu # if no ssiu node
> -
> - shared-pin:
> - description: shared clock pin
> - $ref: /schemas/types.yaml#/definitions/flag
> - pio-transfer:
> - description: PIO transfer mode
> - $ref: /schemas/types.yaml#/definitions/flag
> - no-busif:
> - description: BUSIF is not used when [mem -> SSI] via DMA case
> - $ref: /schemas/types.yaml#/definitions/flag
> - required:
> - - interrupts
> - additionalProperties: false
> + description: List of clock names.
> + minItems: 1
> + maxItems: 31
> +
> + "#sound-dai-cells": true
> +
> + "#clock-cells": true
> +
> + "#address-cells": true
> +
> + "#size-cells": true
> +
> + clock-frequency: true
> +
> + clkout-lr-asynchronous: true
> +
> + power-domains: true
> +
> + port: true
> +
> + rcar_sound,dvc: true
> +
> + rcar_sound,mix: true
> +
> + rcar_sound,ctu: true
> +
> + rcar_sound,src: true
> +
> + rcar_sound,ssiu: true
> +
> + rcar_sound,ssi: true
Use 'unevaluatedProperties' and drop all of these.
>
> patternProperties:
> - # For DAI base
> - 'rcar_sound,dai(@[0-9a-f]+)?$':
> - description: DAI subnode.
> - type: object
> - patternProperties:
> - "^dai([0-9]+)?$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - anyOf:
> - - required:
> - - playback
> - - required:
> - - capture
> - additionalProperties: false
> -
> - 'ports(@[0-9a-f]+)?$':
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - '^port(@[0-9a-f]+)?$':
> - $ref: "#/properties/port"
> -
> -required:
> - - compatible
> - - reg
> - - reg-names
> - - clocks
> - - clock-names
> + 'rcar_sound,dai(@[0-9a-f]+)?$': true
> + 'ports(@[0-9a-f]+)?$': true
>
> allOf:
> - - $ref: dai-common.yaml#
> + - $ref: renesas,rsnd-common.yaml#
>
> - # --------------------
> - # reg/reg-names
> - # --------------------
> - # for Gen1
> - if:
> properties:
> compatible:
> @@ -295,11 +134,10 @@ allOf:
> maxItems: 3
> reg-names:
> items:
> - enum:
> - - sru
> - - ssi
> - - adg
> - # for Gen2/Gen3
> + - const: sru
> + - const: ssi
> + - const: adg
> +
> - if:
> properties:
> compatible:
> @@ -310,16 +148,34 @@ allOf:
> then:
> properties:
> reg:
> - minItems: 5
> + maxItems: 5
> reg-names:
> items:
> - enum:
> - - scu
> - - adg
> - - ssiu
> - - ssi
> - - audmapp
> - # for Gen4
> + - const: scu
> + - const: adg
> + - const: ssiu
> + - const: ssi
> + - const: audmapp
> + resets:
> + maxItems: 11
> + reset-names:
> + items:
> + oneOf:
> + - const: ssi-all
> + - pattern: '^ssi\.[0-9]$'
> + clocks:
> + maxItems: 31
> + clock-names:
> + items:
> + oneOf:
> + - const: ssi-all
> + - pattern: '^ssi\.[0-9]$'
> + - pattern: '^src\.[0-9]$'
> + - pattern: '^mix\.[0-1]$'
> + - pattern: '^ctu\.[0-1]$'
> + - pattern: '^dvc\.[0-1]$'
> + - pattern: '^clk_(a|b|c|i)$'
> +
> - if:
> properties:
> compatible:
> @@ -336,38 +192,19 @@ allOf:
> - ssiu
> - ssi
> - sdmc
> -
> - # --------------------
> - # clock-names
> - # --------------------
> - - if:
> - properties:
> - compatible:
> - contains:
> - const: renesas,rcar_sound-gen4
> - then:
> - properties:
> - clock-names:
> - maxItems: 3
> + resets:
> + maxItems: 2
> + reset-names:
> items:
> - enum:
> - - ssi.0
> - - ssiu.0
> - - clkin
> - else:
> - properties:
> + - const: ssiu.0
> + - const: ssi.0
> + clocks:
> + maxItems: 3
> clock-names:
> - minItems: 1
> - maxItems: 31
> items:
> - oneOf:
> - - const: ssi-all
> - - pattern: '^ssi\.[0-9]$'
> - - pattern: '^src\.[0-9]$'
> - - pattern: '^mix\.[0-1]$'
> - - pattern: '^ctu\.[0-1]$'
> - - pattern: '^dvc\.[0-1]$'
> - - pattern: '^clk_(a|b|c|i)$'
> + - const: ssiu.0
> + - const: ssi.0
> + - const: clkin
>
> unevaluatedProperties: false
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 06/24] ASoC: dt-bindings: Add RZ/G3E (R9A09G047) sound binding
From: Rob Herring @ 2026-04-15 20:57 UTC (permalink / raw)
To: John Madieu
Cc: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260402090524.9137-7-john.madieu.xa@bp.renesas.com>
On Thu, Apr 02, 2026 at 11:05:05AM +0200, John Madieu wrote:
> The RZ/G3E shares the same audio IP as the R-Car variants but differs
> in several aspects: it supports up to 5 DMA controllers per audio
> channel, requires additional clocks (47 total including per-SSI ADG
> clocks, SCU domain clocks and SSIF supply) and additional reset lines
> (14 total including SCU, ADG and Audio DMAC peri-peri resets).
>
> Add a dedicated devicetree binding for the RZ/G3E sound controller.
> The binding references the common renesas,rsnd-common.yaml schema for
> shared property and subnode definitions.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: New patch
>
> .../sound/renesas,r9a09g047-sound.yaml | 371 ++++++++++++++++++
> 1 file changed, 371 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> new file mode 100644
> index 000000000000..1dfe9bab3382
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> @@ -0,0 +1,371 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,r9a09g047-sound.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas RZ/G3E Sound Controller
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> + - John Madieu <john.madieu.xa@bp.renesas.com>
> +
> +description:
> + The RZ/G3E (R9A09G047) integrates an R-Car compatible sound controller
> + with extended DMA channel support (up to 5 DMACs per direction), additional
> + clock domains, and additional reset lines compared to the R-Car Gen2/Gen3
> + variants.
> +
> +allOf:
> + - $ref: renesas,rsnd-common.yaml#
> +
> +properties:
> + compatible:
> + const: renesas,r9a09g047-sound
> +
> + reg:
> + maxItems: 5
> +
> + reg-names:
> + items:
> + - const: scu
> + - const: adg
> + - const: ssiu
> + - const: ssi
> + - const: audmapp
> +
> + clocks:
> + maxItems: 47
> +
> + clock-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: src.9
> + - const: src.8
> + - const: src.7
> + - const: src.6
> + - const: src.5
> + - const: src.4
> + - const: src.3
> + - const: src.2
> + - const: src.1
> + - const: src.0
> + - const: mix.1
> + - const: mix.0
> + - const: ctu.1
> + - const: ctu.0
> + - const: dvc.0
> + - const: dvc.1
> + - const: clk_a
> + - const: clk_b
> + - const: clk_c
> + - const: clk_i
> + - const: ssif_supply
> + - const: scu
> + - const: scu_x2
> + - const: scu_supply
> + - const: adg.ssi.9
> + - const: adg.ssi.8
> + - const: adg.ssi.7
> + - const: adg.ssi.6
> + - const: adg.ssi.5
> + - const: adg.ssi.4
> + - const: adg.ssi.3
> + - const: adg.ssi.2
> + - const: adg.ssi.1
> + - const: adg.ssi.0
> + - const: audmapp
> + - const: adg
> +
> + resets:
> + maxItems: 14
> +
> + reset-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: scu
> + - const: adg
> + - const: audmapp
> +
> + rcar_sound,dvc:
> + description: DVC subnode.
> + type: object
Move 'additionalProperties' here.
blank line after.
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
blank line
> + properties:
> + dmas:
> + maxItems: 5
blank line
> + dma-names:
> + maxItems: 5
> + allOf:
Don't need 'allOf'
> + - items:
> + enum:
> + - tx
blank line
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
Most of these are already required by the common schema. No need to
duplicate.
> +
> +unevaluatedProperties: false
^ permalink raw reply
* Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst @ 2026-04-15 20:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <125cad6c-fb58-4498-a967-41778f6f91f6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]
On Sun, 2026-04-12 at 15:22 +0200, Krzysztof Kozlowski wrote:
> On 12/04/2026 15:21, Markus Probst wrote:
> > On Sun, 2026-04-12 at 10:26 +0200, Krzysztof Kozlowski wrote:
> > > On Sat, Apr 11, 2026 at 05:27:35PM +0200, Markus Probst wrote:
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - synology,ds923p-microp
> > > > + - synology,ds918p-microp
> > > > + - synology,ds214play-microp
> > > > + - synology,ds225p-microp
> > > > + - synology,ds425p-microp
> > > > + - synology,ds710p-microp
> > > > + - synology,ds1010p-microp
> > > > + - synology,ds723p-microp
> > > > + - synology,ds1522p-microp
> > > > + - synology,rs422p-microp
> > > > + - synology,ds725p-microp
> > > > + - synology,ds118-microp
> > > > + - synology,ds124-microp
> > > > + - synology,ds223-microp
> > > > + - synology,ds223j-microp
> > > > + - synology,ds1823xsp-microp
> > > > + - synology,rs822p-microp
> > > > + - synology,rs1221p-microp
> > > > + - synology,rs1221rpp-microp
> > > > + - synology,ds925p-microp
> > > > + - synology,ds1525p-microp
> > > > + - synology,ds1825p-microp
> > >
> > > Previous comment is not resolved. For example you stated that ds723p is
> > > compatible with ds725p, so this should be expressed.
> > Using this expression?
> >
> > properties:
> > compatible:
> > oneOf:
> > - enum:
> > - synology,ds923p-microp
> > - synology,ds1522p-microp
> > - enum:
> > - synology,ds918p-microp
> > - synology,ds415p-microp
> > - const: synology,ds214play-microp
> > ...
> > ?
> > If so shall there each be a description?
>
> No, you changed nothing. You need fallbacks, please read example-schema
> or DTS101 slides.
The documentation says to "use fallback compatibles when devices are
the same as or a superset of prior implementations" [1].
Differences are not publicly documented in this device, making it hard
to tell if it is a superset or the same implementation. This would make
no device a fallback, as compatibility is not guaranteed. I could
imagine it would be an ABI breakage if a fallback is no longer
considered compatible with a device later on.
If deciding based on driver compatibility (accepting loss of features
and accounting for future driver features), one device entry would look
like this:
- items:
- const: synology,ds923p-microp
- const: synology,ds1522p-microp
- const: synology,ds925p-microp # no current sensor from here
- const: synology,ds425p-microp
- const: synology,ds1525p-microp
- const: synology,ds918p-microp
- const: synology,ds1823xsp-microp # no fan failure check from here
- const: synology,ds1825p-microp
which isn't maintainable in this size for ~22 entries.
But the example schema
- items:
- enum:
- vendor,soc4-ip
- vendor,soc3-ip
- vendor,soc2-ip
- enum:
- vendor,soc1-ip
also does not have all of the previous devices as fallbacks (assuming
"vendor,soc3-ip" is compatible with "vendor,soc2-ip" and so on).
Only adding devices as fallbacks with the exact same known feature set
would ignore the other devices with less features which would still
work (e.g. "synology,ds925p-microp" would still work on a ds923+, but
the "current sensor" would not be accessible).
So my question is, what makes a device eligible to be a fallback for
another device?
Just using the one device that is compatible with most of the devices
(having the least features) for all of the compatible devices as
fallback like in the example?
I would prefer a generic "synology,microp-x64" entry as fallback only,
which only supports the baseline of features (power led, status led,
shutdown/reboot, power button, fan speed), which all devices I am aware
of support.
But documentation explicitly states "DON’T use wildcards or device-
family names in compatible strings" [1], so I think I am not allowed to
do that.
Thanks
- Markus Probst
[1] https://docs.kernel.org/devicetree/bindings/writing-bindings.html
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: pm660: add thermal monitor
From: Richard Acayan @ 2026-04-15 21:05 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <4311c618-f084-44c5-86e2-7f97661d887b@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 11:15:57AM +0200, Konrad Dybcio wrote:
> On 3/3/26 3:25 AM, Richard Acayan wrote:
> > On Tue, Feb 10, 2026 at 10:59:20AM +0100, Konrad Dybcio wrote:
> >> On 2/10/26 3:18 AM, Richard Acayan wrote:
> >>> The thermal monitor is used to monitor arbitrary ADC-based thermal
> >>> sensors. It is suitable for use in thermal zones. Add support for it in
> >>> PM660.
> >>>
> >>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >>> ---
> >>> arch/arm64/boot/dts/qcom/pm660.dtsi | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> index 156b2ddff0dc..7cedf6980b34 100644
> >>> --- a/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> @@ -197,6 +197,16 @@ channel@85 {
> >>> };
> >>> };
> >>>
> >>> + pm660_adc_tm: adc-tm@3400 {
> >>> + compatible = "qcom,spmi-adc-tm-hc";
> >>> + reg = <0x3400>;
> >>> + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
> >>> + #thermal-sensor-cells = <1>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + status = "disabled";
> >>
> >> Can we enable it by default?
> >
> > This is for the ADC thermal monitor, and not the ADC itself. I don't see
> > the need to allocate channels just so this can be enabled by default,
> > since the thermal monitor's purpose is mostly to send interrupts when
> > the ADC values go above or below a certain threshold.
>
> Sorry, this fell through the cracks
>
> I see your argument, but at the same time, there are channels that are
> always present (e.g. VPH_PWR) and any way to reduce the boilerplate is
> welcome
If you saw my first sentence in the reply, why are we talking about
VPH_PWR? I don't understand if you're asking for the thermal monitor to
handle a voltage sensor here.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Rob Herring (Arm) @ 2026-04-15 21:29 UTC (permalink / raw)
To: Biju
Cc: linux-spi, Biju Das, devicetree, Geert Uytterhoeven, Mark Brown,
Magnus Damm, Krzysztof Kozlowski, Prabhakar Mahadev Lad,
linux-kernel, Conor Dooley, linux-renesas-soc, Fabrizio Castro
In-Reply-To: <20260402131020.143123-2-biju.das.jz@bp.renesas.com>
On Thu, 02 Apr 2026 14:10:16 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
> the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v1->v2:
> * Collected tag
> ---
> .../bindings/spi/renesas,rzv2h-rspi.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 05/11] dt-bindings: media: Add nxp neoisp support
From: Rob Herring (Arm) @ 2026-04-15 21:31 UTC (permalink / raw)
To: Antoine Bouyer
Cc: anthony.mcgivern, linux-media, alexi.birlinger, conor+dt,
ai.luthra, devicetree, julien.vuillaumier, krzk+dt, imx, mchehab,
laurent.pinchart, frank.li, michael.riesch, linux-kernel,
paul.elder, daniel.baluta, jacopo.mondi, peng.fan
In-Reply-To: <20260413160331.2611829-6-antoine.bouyer@nxp.com>
On Mon, 13 Apr 2026 18:03:25 +0200, Antoine Bouyer wrote:
> Add the yaml binding for NXP's Neo Image Signal Processor (ISP).
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> ---
> .../bindings/media/nxp,imx95-neoisp.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/media/nxp,neoisp.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
Documentation/devicetree/bindings/media/nxp,imx95-neoisp.example.dtb: /example-0/isp@4ae00000: failed to match any schema with compatible: ['nxp,neoisp-imx95-b0']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260413160331.2611829-6-antoine.bouyer@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: Rob Herring (Arm) @ 2026-04-15 21:34 UTC (permalink / raw)
To: phucduc.bui
Cc: tglx, linux-input, krzk, dmitry.torokhov, linux-kernel, conor+dt,
conor, devicetree, mingo, krzk+dt, marex
In-Reply-To: <20260403040714.106093-1-phucduc.bui@gmail.com>
On Fri, 03 Apr 2026 11:07:14 +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Document the "wakeup-source" property for the ti,tsc2005 touchscreen
> controllers to allow the device to wake the system from suspend.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>
> changes:
> v4: Drop redundant "type: boolean" for wakeup-source to use the core
> definition from dt-schema (as suggested by Rob Herring).
> v3: Remove blank lines (suggested by Conor).
> v2: Revise the commit content and remove patch1 related to I2C and SPI
> wakeup handling
> .../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Rob Herring @ 2026-04-15 21:48 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Andi Shyti, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-1-70536b22439a@aliel.fr>
On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> index 084960fd5a1fd..67769ef5d58b1 100644
> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> @@ -18,6 +18,7 @@ properties:
> compatible:
> enum:
> - khadas,mcu # MCU revision is discoverable
The revision is no longer discoverable as was claimed?
> + - khadas,vim4-mcu
>
> "#cooling-cells": # Only needed for boards having FAN control feature
> const: 2
> @@ -25,6 +26,10 @@ properties:
> reg:
> maxItems: 1
>
> + fan-supply:
> + description: Phandle to the regulator that powers the fan.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> required:
> - compatible
> - reg
>
> --
> 2.49.0
>
^ permalink raw reply
* Re: [PATCH v2 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Rob Herring (Arm) @ 2026-04-15 21:48 UTC (permalink / raw)
To: Ronald Claveau
Cc: Jerome Brunet, Neil Armstrong, linux-i2c, Kevin Hilman, linux-pm,
Lukasz Luba, linux-amlogic, linux-kernel, Zhang Rui, Lee Jones,
devicetree, Conor Dooley, Andi Shyti, Daniel Lezcano,
Martin Blumenstingl, Beniamino Galvani, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, linux-arm-kernel, Rafael J. Wysocki
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-2-70536b22439a@aliel.fr>
On Fri, 03 Apr 2026 18:08:35 +0200, Ronald Claveau wrote:
> Add the T7 SOC compatible which fallback to AXG compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: simple: Move AUO 21.5" FHD to dual-link
From: Rob Herring (Arm) @ 2026-04-15 21:50 UTC (permalink / raw)
To: Marek Vasut
Cc: Simona Vetter, Krzysztof Kozlowski, devicetree, Maarten Lankhorst,
Liu Ying, Maxime Ripard, Neil Armstrong, David Airlie,
Thierry Reding, linux-kernel, Sam Ravnborg, Jessica Zhang,
Conor Dooley, Thomas Zimmermann, dri-devel
In-Reply-To: <20260404034321.341210-1-marex@nabladev.com>
On Sat, 04 Apr 2026 05:42:49 +0200, Marek Vasut wrote:
> AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
> is a dual-link LVDS panel. Move it into the correct schema, which is
> panel-simple-lvds-dual-ports.yaml.
>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Jessica Zhang <jesszhan0024@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liu Ying <victor.liu@nxp.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> ---
> .../bindings/display/panel/panel-simple-lvds-dual-ports.yaml | 2 ++
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: simple: Move Innolux G156HCE-L01 panel to dual-link
From: Rob Herring (Arm) @ 2026-04-15 21:50 UTC (permalink / raw)
To: Marek Vasut
Cc: Thomas Zimmermann, Maxime Ripard, devicetree, Krzysztof Kozlowski,
Neil Armstrong, Sam Ravnborg, Simona Vetter, Jessica Zhang,
Conor Dooley, dri-devel, Thierry Reding, Maarten Lankhorst,
Liu Ying, linux-kernel, David Airlie
In-Reply-To: <20260404034321.341210-2-marex@nabladev.com>
On Sat, 04 Apr 2026 05:42:50 +0200, Marek Vasut wrote:
> The Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel
> is exactly that, dual-link LVDS panel. Move it into the correct schema,
> which is panel-simple-lvds-dual-ports.yaml.
>
> Fixes: 3c5e8aa44dfc ("dt-bindings: display: simple: Add Innolux G156HCE-L01 panel")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Jessica Zhang <jesszhan0024@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liu Ying <victor.liu@nxp.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> ---
> .../bindings/display/panel/panel-simple-lvds-dual-ports.yaml | 2 ++
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: qcom,kaanapali-gxclkctl: Correctly use additionalProperties
From: Rob Herring (Arm) @ 2026-04-15 21:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
Michael Turquette, linux-kernel, Conor Dooley, Stephen Boyd,
Bjorn Andersson, Taniya Das
In-Reply-To: <20260404105436.138110-2-krzysztof.kozlowski@oss.qualcomm.com>
On Sat, 04 Apr 2026 12:54:37 +0200, Krzysztof Kozlowski wrote:
> The binding does not reference any other schema, thus should use
> "additionalProperties: false" to disallow any undocumented properties.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl-sai: Document RX/TX BCLK swap support
From: Rob Herring (Arm) @ 2026-04-15 21:51 UTC (permalink / raw)
To: Marek Vasut
Cc: Nicolin Chen, Xiubo Li, linuxppc-dev, linux-sound,
Krzysztof Kozlowski, Fabio Estevam, Mark Brown, Takashi Iwai,
Jaroslav Kysela, Liam Girdwood, devicetree, Shengjiu Wang,
linux-kernel, Conor Dooley
In-Reply-To: <20260404183547.46509-1-marex@nabladev.com>
On Sat, 04 Apr 2026 20:35:00 +0200, Marek Vasut wrote:
> Document support for setting the Bit Clock Swap bit in CR2 register
> via new "fsl,sai-bit-clock-swap" DT property. This bit swaps the
> bit clock used by the transmitter or receiver in asynchronous mode,
> i.e. makes transmitter use RX_BCLK and TX_SYNC, and vice versa,
> makes receiver use TX_BCLK and RX_SYNC.
>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Nicolin Chen <nicoleotsuka@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Shengjiu Wang <shengjiu.wang@gmail.com>
> Cc: Takashi Iwai <tiwai@suse.com>
> Cc: Xiubo Li <Xiubo.Lee@gmail.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-sound@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> V2: - Drop | from description
> - Update email, rebase on next
> ---
> Documentation/devicetree/bindings/sound/fsl,sai.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: rockchip: dw-hdmi: Allow resets for Rockchip HDMI
From: Rob Herring @ 2026-04-15 22:04 UTC (permalink / raw)
To: Fabio Estevam
Cc: heiko, hjc, andy.yan, krzk+dt, conor+dt, dri-devel, devicetree,
linux-rockchip, linux-kernel
In-Reply-To: <20260404200434.1954651-1-festevam@gmail.com>
On Sat, Apr 04, 2026 at 05:04:34PM -0300, Fabio Estevam wrote:
> The Rockchip DW HDMI binding sets unevaluatedProperties: false while
> also inheriting from synopsys,dw-hdmi.yaml via allOf.
>
> The Synopsys binding defines the optional properties resets and
> reset-names, but due to dt-schema rules these are not considered
> allowed once unevaluatedProperties: false is set in the Rockchip
> schema unless they are re-declared locally.
That's not how unevaluatedProperties works. There is no resets nor
reset-names in synopsys,dw-hdmi.yaml.
>
> This went unnoticed because most Rockchip SoCs do not wire a reset line
> to the HDMI controller in their DTS. The rk3228, however, does use a
> reset, which causes dtbs_check to emit:
>
> Unevaluated properties are not allowed ('resets', 'reset-names')
>
> Re-declare these properties in the Rockchip schema so they are accepted
> when present, matching the capabilities of the underlying Synopsys IP
> and fixing the dtbs_check warning for rk3228.
>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
> .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 29716764413a..59fb084bb4fb 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -113,6 +113,12 @@ properties:
> - port@0
> - port@1
>
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + const: hdmi
> +
> rockchip,grf:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: display/msm: dp-controller: Correct SM8650 IO range
From: Rob Herring (Arm) @ 2026-04-15 22:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marijn Suijten, Abhinav Kumar, Dmitry Baryshkov, freedreno,
Dmitry Baryshkov, Maarten Lankhorst, linux-kernel,
Thomas Zimmermann, Simona Vetter, Konrad Dybcio,
Krzysztof Kozlowski, Rob Clark, Jessica Zhang, Kuogee Hsieh,
devicetree, Maxime Ripard, Neil Armstrong, linux-arm-msm,
David Airlie, Bjorn Andersson, Sean Paul, Krzysztof Kozlowski,
dri-devel, Conor Dooley
In-Reply-To: <20260405-dts-qcom-display-regs-v2-1-34f4024c65dc@oss.qualcomm.com>
On Sun, 05 Apr 2026 16:33:57 +0200, Krzysztof Kozlowski wrote:
> DP on Qualcomm SM8650 come with nine address ranges, so describe the
> remaining ones as optional to keep ABI backwards compatible. Driver
> also does not need them to operate correctly.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../bindings/display/msm/dp-controller.yaml | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: display/msm: sm8650: Correct VBIF range in example
From: Rob Herring (Arm) @ 2026-04-15 22:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marijn Suijten, Maarten Lankhorst, Krzysztof Kozlowski,
Konrad Dybcio, Neil Armstrong, Simona Vetter, David Airlie,
Kuogee Hsieh, Sean Paul, Krzysztof Kozlowski, Bjorn Andersson,
Conor Dooley, Jessica Zhang, Dmitry Baryshkov, devicetree,
Rob Clark, Thomas Zimmermann, linux-kernel, linux-arm-msm,
Dmitry Baryshkov, Abhinav Kumar, freedreno, Maxime Ripard,
dri-devel
In-Reply-To: <20260405-dts-qcom-display-regs-v2-3-34f4024c65dc@oss.qualcomm.com>
On Sun, 05 Apr 2026 16:33:59 +0200, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long, so correct the example. No
> practical impact, except when existing code is being re-used in new
> contributions.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 2 +-
> Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 5/8] dt-bindings: display/msm: qcom,eliza-mdss: Correct DPU and DP ranges in example
From: Rob Herring (Arm) @ 2026-04-15 22:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, linux-arm-msm, Conor Dooley, freedreno,
Rob Clark, Marijn Suijten, Maarten Lankhorst, David Airlie,
Konrad Dybcio, Krzysztof Kozlowski, Simona Vetter, linux-kernel,
Krzysztof Kozlowski, Thomas Zimmermann, Dmitry Baryshkov,
Abhinav Kumar, devicetree, Jessica Zhang, Maxime Ripard,
Kuogee Hsieh, Neil Armstrong, Sean Paul, dri-devel
In-Reply-To: <20260405-dts-qcom-display-regs-v2-5-34f4024c65dc@oss.qualcomm.com>
On Sun, 05 Apr 2026 16:34:01 +0200, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long. DisplayPort block has few too short
> ranges and misses four more address spaces. Similarly first part of DSI
> space should be 0x300 long.
>
> No practical impact, except when existing code is being re-used in new
> contributions.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../bindings/display/msm/qcom,eliza-mdss.yaml | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 1/1] dt-bindings: media: mt9m114: document common video device properties
From: Rob Herring (Arm) @ 2026-04-15 22:07 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Laurent Pinchart, Krzysztof Kozlowski, Mauro Carvalho Chehab,
devicetree, linux-kernel, Conor Dooley, linux-media
In-Reply-To: <20260406081330.30362-2-clamor95@gmail.com>
On Mon, 06 Apr 2026 11:13:30 +0300, Svyatoslav Ryhel wrote:
> Document common video interface device properties, such as rotation and
> orientation.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/media/i2c/onnn,mt9m114.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox