* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-20 16:25 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252BD7967D2567AD6DA7A1D8B2F2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5939 bytes --]
On Mon, Apr 20, 2026 at 07:22:57AM +0000, Billy Tsai wrote:
> > > > > + properties:
> > > > > + function:
> > > > > + enum:
> > > > > + - EMMC
> > > > > + - JTAGDDR
> > > > > + - JTAGM0
> > > > > + - JTAGPCIEA
> > > > > + - JTAGPCIEB
> > > > > + - JTAGPSP
> > > > > + - JTAGSSP
> > > > > + - JTAGTSP
> > > > > + - JTAGUSB3A
> > > > > + - JTAGUSB3B
> > > > > + - PCIERC0PERST
> > > > > + - PCIERC1PERST
> > > > > + - TSPRSTN
> > > > > + - UFSCLKI
> > > > > + - USB2AD0
> > > > > + - USB2AD1
> > > > > + - USB2AH
> > > > > + - USB2AHP
> > > > > + - USB2AHPD0
> > > > > + - USB2AXH
> > > > > + - USB2AXH2B
> > > > > + - USB2AXHD1
> > > > > + - USB2AXHP
> > > > > + - USB2AXHP2B
> > > > > + - USB2AXHPD1
> > > > > + - USB2BD0
> > > > > + - USB2BD1
> > > > > + - USB2BH
> > > > > + - USB2BHP
> > > > > + - USB2BHPD0
> > > > > + - USB2BXH
> > > > > + - USB2BXH2A
> > > > > + - USB2BXHD1
> > > > > + - USB2BXHP
> > > > > + - USB2BXHP2A
> > > > > + - USB2BXHPD1
> > > > > + - USB3AXH
> > > > > + - USB3AXH2B
> > > > > + - USB3AXHD
> > > > > + - USB3AXHP
> > > > > + - USB3AXHP2B
> > > > > + - USB3AXHPD
> > > > > + - USB3BXH
> > > > > + - USB3BXH2A
> > > > > + - USB3BXHD
> > > > > + - USB3BXHP
> > > > > + - USB3BXHP2A
> > > > > + - USB3BXHPD
> > > > > + - VB
> > > > > + - VGADDC
> > > > > +
> > > > > + groups:
> > > > > + enum:
> > > > > + - EMMCCDN
> > > > > + - EMMCG1
> > > > > + - EMMCG4
> > > > > + - EMMCG8
> > > > > + - EMMCWPN
> > > > > + - JTAG0
> > > > > + - PCIERC0PERST
> > > > > + - PCIERC1PERST
> > > > > + - TSPRSTN
> > > > > + - UFSCLKI
> > > > > + - USB2A
> > > > > + - USB2AAP
> > > > > + - USB2ABP
> > > > > + - USB2ADAP
> > > > > + - USB2AH
> > > > > + - USB2AHAP
> > > > > + - USB2B
> > > > > + - USB2BAP
> > > > > + - USB2BBP
> > > > > + - USB2BDBP
> > > > > + - USB2BH
> > > > > + - USB2BHBP
> > > > > + - USB3A
> > > > > + - USB3AAP
> > > > > + - USB3ABP
> > > > > + - USB3B
> > > > > + - USB3BAP
> > > > > + - USB3BBP
> > > > > + - VB0
> > > > > + - VB1
> > > > > + - VGADDC
> > > > > + pins:
> > > > > + enum:
> > > > > + - AB13
> > > > > + - AB14
> > > > > + - AC13
> > > > > + - AC14
> > > > > + - AD13
> > > > > + - AD14
> > > > > + - AE13
> > > > > + - AE14
> > > > > + - AE15
> > > > > + - AF13
> > > > > + - AF14
> > > > > + - AF15
>
> > > > Why do you have groups and pins?
> > > > Is it valid in your device to have groups and pins in the same node?
>
> > > The intent is to support both group-based mux selection and
> > > configuration, as well as per-pin configuration.
>
> > > In our hardware:
> > > - `function` + `groups` are used for pinmux selection.
> > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > bias settings).
> > > - `groups` may also be used for group-level configuration.
>
> > > As a result, both `groups` and `pins` may appear in the same node,
> > > but they serve different purposes and do not conflict:
> > > - `groups` selects the mux function and may apply configuration to
> > > the entire group.
> > > - `pins` allows overriding or specifying configuration for individual
> > > pins.
>
> > > In most cases, only one of them is needed, but both are allowed when
> > > both group-level and per-pin configuration are required.
>
> > To be honest, that sounds like your groups are not sufficiently
> > granular and should be reduced such that you can use them for pin
> > settings.
>
> The intent was to keep the binding flexible, but in practice the mixed
> use of `groups` and `pins` in the same node is not expected to be used.
>
> Given that, I agree this flexibility is unnecessary and makes the
> binding semantics less clear. I'll rework the binding to make the
> expected usage explicit rather than allowing combinations that do not
> correspond to a real use case.
>
> In particular, I'll split the constraints as follows:
>
> - For pinmux, the presence of `function` will require `groups`, and
> `pins` will not be allowed. This reflects the hardware design, where
> the groups are defined by the pins affected by a given mux expression
>
> - For pin configuration, exactly one of `groups` or `pins` will be
> required (using oneOf), so that configuration is applied either at
> group level or per-pin, but not both.
>
>
> - if:
> required:
> - function
> then:
> required:
> - groups
> not:
> required:
> - pins
> else:
> oneOf:
> - required:
> - groups
> not:
> required:
> - pins
> - required:
> - pins
> not:
> required:
> - groups
> Does this match what you had in mind?
It's an improvement I think, but I am wondering why you cannot do
without pins entirely and apply pinconf stuff at the group level?
Of course that may not be possible with the current groups, but if you
made the groups more granular, would it be possible?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-20 16:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeIGxfQ7AoIVR5n6@monoceros>
Hi Uwe,
On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
<...snip...>
> > I stand corrected here: after some more investigation it seems that only the
> > enable/disable (plus osme other not currently used registers) depends on the
> > global update flag, while the period and duty per-channel registers are
> > independtly updatable while they are latched on the end of (specific channel)
> > period strobe.
> > I'd say that this should avoid any cross-channel glitches since they are managed
> > independently. Unfortunately I'm not able to test this with my current (and
> > rather old) equipment, this would require at least an external trigger channel.
> > Regarding the setup of a new value exactly during the strobe: I think this is
> > quite hard to achieve.
>
> To sum up: period and duty_cycle changes might result in glitches unless
> the channel is disabled. This is ok, please just document it.
Maybe the glitch can occur if we're changing period and duty exactly during
the strobe, unless the register writing is somehow in sync with the PWM clock.
Disabling the channel immediately stops any execution and the line goes suddenly
low (if polarity is normal, otherwise stays high). See also next.
>
> The purpose of the update flag then is only to start several channels in
> sync?
Citing the datasheet:
"To prevent mis-sampling of multi-bit bus signals in the PWM clock domain,
this bit (SET_UPDATE) should be used to trigger a settings update. This
ensures that all PWM channel settings update on the same PWM clock cycle."
From my testing though, channels can be started in sync only if they have the
same period. I'll add a comment for all this, and other edge cases.
> What happens if sync is asserted while a disabled channel didn't
> complete the last period yet?
The output stops immediately without waiting for the current period to finish.
>
> Maybe it's worth to test the following procedure for updating duty and
> period:
>
> disable channel
> configure duty
> configure period
> enable
> set update flag
>
> Assumint disable is delayed until the end of the currently running
> period, the effect of this procedure might be that no glitch happens if
> the update flag is asserted before the currently running period ends and
> the anormality is reduced to a longer inactive state if the updates are
> not that lucky (in contrast to more severe glitches).
The disable isn't delayed as explained above. Setting just the new period/duty
(which do not depend on the sync bit) correctly waits for the end of the current
period without noticeable glitches (tested with a scope).
>
> If you can configure a short and a long period that is distinguishable
> "manually" with an LED I think this should be testable even without
> further equipment.
>
> > > > > > + if (ticks > U32_MAX)
> > > > > > + ticks = U32_MAX;
> > > > > > + wfhw->period_ticks = ticks;
> > > > >
> > > > > What happens if wf->period_length_ns > 0 but ticks == 0?
> > > >
> > > > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > > > in this case.
> > >
> > > Sounds good. Are you able to verify that there is no +1 missing in the
> > > calculation, e.g. using 1 as register value really gives you a period of
> > > 1 tick and not 2?
> >
> > You are right. The scope reveals there's always one extra (low signal) tick at the
> > end of each period.
>
> So the hardware cannot do 100% relative duty, right? Please document
> that.
>
> > Let's say that teh user want 10 tick period, we have to use
> > 9 instead to account for the extra tick at the end, so that the complete period
> > contains that extra tick?
>
> I would describe that a bit differently, but in general: yes.
>
> The more straight forward description is that setting
>
> RP1_PWM_RANGE(pwm->hwpwm) := x
>
> results in a period of x + 1 ticks.
Exactly. So whatever the user request I have to subtract one from the value
to be written to the RANGE register.
>
> > This also means that if we ask for 100% duty cycle, the output waveform will
> > have the high part of the signal lasting one tick less than expected.a I guess
> > this is the accepted compromise.
>
> I assume you considered something like:
>
> RP1_PWM_RANGE(pwm->hwpwm) := 17
> RP1_PWM_DUTY(pwm->hwpwm) := 18
>
> to get a 100% relative duty?
Ah right! It's working fine and I've got 100% duty. So at hw register level
the duty can be greater that the period.
>
> If this doesn't work that means that this has to be formalized in the
> callbacks. That is the fromhw function has to always report
> duty_length_ns less than period_length_ns.
No need, it's working indeed.
>
> > OTOH, the minimum tick period would be 2 tick, less than that will otherwise
> > degenerate in a disabled channel.
>
> It's expected that in general for a period_length of 1 tick you can only
> have 0% and 100% relative duty. IIUC for this hardware you cannot do the
> 100% case so there is only a single valid duty_length for period_length
> = 1 tick.
Minimum tick confirmed to be 1.
>
> I think it would be more complicated to consistently filter out
> period_length = 1 tick in the driver than to just accept the conceptual
> limitations. (Otherwise: What would you report in the fromhw callback if
> period_length = 1 tick is configured in wfhw? Would you refuse to commit
> that wfhw to hardware in .write_waveform()? The pwm core handles that
> just fine and consumers have all the means to detect and prevent that if
> they care enough.)
>
> > > > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> > > >
> > > > Since this driver now exports a syscon, it's only builtin (=Y) so
> > > > it cannot be unloaded.
> > > > I've also avoided the .remove callback via .suppress_bind_attrs.
> > >
> > > Oh no, please work cleanly here and make the driver unbindable. This
> > > yields better code quality and also helps during development and
> > > debugging.
> >
> > I wish to, but the issue here is that this driver exports a syscon via
> > of_syscon_register_regmap() which I think doesn't have the unregister
> > counterpart. So the consumer will break in case we can unbind/unload
> > the module and the syscon will leak.
> > If you have any alternative I'll be glad to discuss.
>
> My (not so well articulated) point is: Please be stringent about clock
> handling to not bank up technical dept more than necessary and such that
> the driver can be made unbindable if and when syscons grow
> that feature. Optionally wail at the syscon guys :-)
Hmmm not sure I've understood your point: is it a requirement that the driver
must be unbindable? In this case I should avoid registering the syscon. Or
should I just provide a .remove callback in case there will be a way to
unregister the syscon (even if this callback will not be called as of now)?
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Conor Dooley @ 2026-04-20 16:22 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Lee Jones, Rob Herring, 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: <20260417-add-mcu-fan-khadas-vim4-v3-1-a6a7f570b11b@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Fri, Apr 17, 2026 at 06:27:17PM +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..a80718f7595ce 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
> + - khadas,vim4-mcu # Different MCU variant, not discoverable
>
> "#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
Can you limit this by compatible please?
pw-bot: changes-requested
> +
> required:
> - compatible
> - reg
>
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mfd: syscon: Document the LVDS_CMN syscon for the RZ/G3L
From: Conor Dooley @ 2026-04-20 16:21 UTC (permalink / raw)
To: Biju
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad,
Tommaso Merciai
In-Reply-To: <20260417175235.224809-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Fri, Apr 17, 2026 at 06:52:28PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The RZ/G3{E,L} SoCs have an LVDS Common (LVDS_CMN) region which is common
> to all LVDS channels. The RZ/G3L has single-link, but the RZ/G3E has both
> single and dual-link.
>
> Use the syscon interface to access these registers for scalability.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: display: bridge: Document Renesas RZ/G3L LVDS encoder
From: Conor Dooley @ 2026-04-20 16:21 UTC (permalink / raw)
To: Biju
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Tommaso Merciai, dri-devel,
devicetree, linux-kernel, linux-renesas-soc,
Prabhakar Mahadev Lad
In-Reply-To: <20260417175235.224809-3-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
On Fri, Apr 17, 2026 at 06:52:29PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document the LVDS encoder IP found on the RZ/G3L SoC. It supports
> single-link mode. LVDS and the DSI interface share a peripheral clock and
> the MIPI_DSI_PRESET_N reset signal. However, the LVDS module cannot be
> used at the same time as MIPI-DSI.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Conor Dooley @ 2026-04-20 16:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab, linux-leds,
devicetree, linux-kernel, linux-media
In-Reply-To: <20260419093412.40796-2-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]
On Sun, Apr 19, 2026 at 12:34:08PM +0300, Svyatoslav Ryhel wrote:
> Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
> LEDs.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/leds/ti,lm3560.yaml | 131 ++++++++++++++++++
> 1 file changed, 131 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> new file mode 100644
> index 000000000000..c6c553ad23f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> @@ -0,0 +1,131 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI LM3560 Synchronous Boost Flash Driver
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
> + 1000-mA constant current drivers for high-current white LEDs. The dual high-
> + side current sources allow for grounded cathode LED operation and can be
> + tied together for providing flash currents at up to 2 A through a single LED.
> + An adaptive regulation method ensures the current for each LED remains in
> + regulation and maximizes efficiency.
> +
> +allOf:
> + - $ref: /schemas/leds/common.yaml
> +
> +properties:
> + compatible:
> + enum:
> + - ti,lm3559
> + - ti,lm3560
What differentiates these devices to the point that fallback compatibles
are not suitable?
Cheers,
Conor.
> +
> + reg:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + enable-gpios:
> + description: GPIO connected to the HWEN pin.
> + maxItems: 1
> +
> + vin-supply:
> + description: Supply connected to the IN line.
> +
> + flash-max-timeout-us:
> + minimum: 32000
> + maximum: 1024000
> + default: 32000
> +
> + ti,peak-current-microamp:
> + description:
> + The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
> + When the current limit is reached, the LM3560 stops switching for the
> + remainder of the switching cycle.
> + enum: [16000000, 23000000, 30000000, 36000000]
> + default: 16000000
> +
> +patternProperties:
> + '^led@[01]$':
> + description: LED control bank nodes.
> + $ref: /schemas/leds/common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Control bank selection (0 = bank A, 1 = bank B).
> + maximum: 1
> +
> + flash-max-microamp:
> + minimum: 62500
> + maximum: 1000000
> +
> + led-max-microamp:
> + minimum: 31250
> + maximum: 250000
> +
> + required:
> + - reg
> + - flash-max-microamp
> + - led-max-microamp
> +
> +required:
> + - compatible
> + - reg
> + - '#address-cells'
> + - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@53 {
> + compatible = "ti,lm3560";
> + reg = <0x53>;
> +
> + enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vdd_3v3_sys>;
> +
> + flash-max-timeout-us = <1024000>;
> + ti,peak-current-microamp = <16000000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> +
> + label = "white::flash";
> + linux,default-trigger = "flash";
> +
> + flash-max-microamp = <562500>;
> + led-max-microamp = <156250>;
> + };
> +
> + led@1 {
> + reg = <1>;
> +
> + label = "yellow::flash";
> + linux,default-trigger = "flash";
> +
> + flash-max-microamp = <562500>;
> + led-max-microamp = <156250>;
> + };
> + };
> + };
> --
> 2.51.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
From: Conor Dooley @ 2026-04-20 16:17 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-2-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Sun, Apr 19, 2026 at 09:35:32PM +0200, Marek Vasut wrote:
> Extend the Renesas DU display bindings to support the Renesas R-Car
> R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC,
> except the HDMI port@1 is not present.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Conor Dooley @ 2026-04-20 16:14 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-5-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Sun, Apr 19, 2026 at 09:35:35PM +0200, Marek Vasut wrote:
> Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
> SoC and the Renesas Geist development board. The Renesas M3Le SoC is
> a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals. The Geist board is derived from Renesas Salvator-X/XS
> boards, with adjustment for the R8A779MD SoC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Conor Dooley @ 2026-04-20 16:13 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-4-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
On Sun, Apr 19, 2026 at 09:35:34PM +0200, Marek Vasut wrote:
> Document backward compatibility support for CS2500 chip, which
> is a drop-in replacement for CS2000 chip.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCHv2 1/2] dt-bindings: arm: altera: document the Agilex7-M devkit
From: Conor Dooley @ 2026-04-20 16:13 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <20260419232416.68331-1-dinguyen@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
On Sun, Apr 19, 2026 at 06:24:15PM -0500, Dinh Nguyen wrote:
> The Agilex7-M is a rebranded version of the original Agilex SoC. The
> Agilex7-M SoC has the same core peripherals as the Agilex device.
>
> This change is to document the Agilex7m devkit which has the Agilex7-M
> device. The Agilex7-M SoC supports DDR4, DDR5, LPDDR5, PCIE 5.0(x16), but
> not QSPI.
>
> Also, now that Altera has separated from Intel, use the "altr" company
> prefix.
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: amlogic: add X98Q compatible
From: Conor Dooley @ 2026-04-20 16:11 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, funderscore, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20260420061854.5421-2-christian.koever-draxl@student.uibk.ac.at>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On Mon, Apr 20, 2026 at 08:18:53AM +0200, christian.koever-draxl@student.uibk.ac.at wrote:
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
Even if a patch is simple, you still need a commit message.
pw-bot: changes-requested
Cheers,
Conor.
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
> index a885278bc4e2..82671d58d1da 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
> @@ -254,6 +254,13 @@ properties:
> - khadas,vim1s
> - const: amlogic,s905y4
> - const: amlogic,s4
> +
> + - description: Boards with the Amlogic Meson S4 S905W2 SoC
> + items:
> + - enum:
> + - amediatech,x98q
> + - const: amlogic,s905w2
> + - const: amlogic,s4
>
> - description: Boards with the Amlogic S6 S905X5 SoC
> items:
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: trivial-devices: add toradex,lava-hat-spi
From: Krzysztof Kozlowski @ 2026-04-20 16:10 UTC (permalink / raw)
To: Conor Dooley, Francesco Dolcini
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Mark Brown,
Francesco Dolcini, devicetree, linux-kernel, linux-spi
In-Reply-To: <20260420-task-navy-370ea247fe1d@spud>
On 20/04/2026 18:02, Conor Dooley wrote:
> On Mon, Apr 20, 2026 at 01:45:35PM +0200, Francesco Dolcini wrote:
>> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>>
>> Add a compatible string for the SPI loopback device present on the
>> Toradex LAVA HAT test fixture.
>>
>> The Toradex LAVA HAT is a board used for automated hardware-in-the-loop
>> (HIL) testing, it provides several test-related functionalities, and
>> exists in multiple variants depending on the board it is mated with. The
>> SPI function is implemented with a loopback on the MISO/MOSI signals.
>>
>> As the device can be fully described using only "compatible" and "reg",
>> it is appropriate to list it under trivial-devices.yaml rather than
>> introducing a dedicated binding.
>>
>> The SPI implementation is identical across all Toradex LAVA HAT
>> variants, so a single compatible string is sufficient.
>>
>> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/
>> Link: https://lore.kernel.org/all/20260316073547.11437-3-francesco@dolcini.it/
>> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable
Heh, let's wait. That's a test device, so it won't be ever used in any
final product, right? So not in final DTS?
Then why it's here? I think I directed previously to document it with
the rest of test devices - in incomplete-devices schema?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: Remove sifive,fine-ctr-bits property
From: Conor Dooley @ 2026-04-20 16:09 UTC (permalink / raw)
To: Nick Hu
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Samuel Holland, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Anup Patel, Conor Dooley,
linux-kernel, devicetree, linux-riscv
In-Reply-To: <20260419-clintv2-remove-fine-ctr-v1-1-7527f4d45850@sifive.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
On Sun, Apr 19, 2026 at 11:18:55PM -0700, Nick Hu wrote:
> The counter width can be inferred from the compatible string, making the
> explicit "sifive,fine-ctr-bits" property redundant. Remove the property
> to simplify the bindings.
And there are no users of this, because the only permitted compatible
string combination contains {}.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Fixes: 0f920690a82c ("dt-bindings: timer: Add SiFive CLINT2")
> Suggested-by: Conor Dooley <conor+dt@kernel.org>
> Link: https://lore.kernel.org/linux-riscv/20260330-relative-hardened-5ce35fe1ef57@spud/
> Signed-off-by: Nick Hu <nick.hu@sifive.com>
> ---
> .../devicetree/bindings/timer/sifive,clint.yaml | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> index 3c16b260db04..051edb1da0d7 100644
> --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> @@ -72,22 +72,6 @@ properties:
> minItems: 1
> maxItems: 4095
>
> - sifive,fine-ctr-bits:
> - maximum: 15
> - description: The width in bits of the fine counter.
> -
> -if:
> - properties:
> - compatible:
> - contains:
> - const: sifive,clint2
> -then:
> - required:
> - - sifive,fine-ctr-bits
> -else:
> - properties:
> - sifive,fine-ctr-bits: false
> -
> additionalProperties: false
>
> required:
>
> ---
> base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428
> change-id: 20260409-clintv2-remove-fine-ctr-d5caeda27863
>
> Best regards,
> --
> Nick Hu <nick.hu@sifive.com>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
From: Conor Dooley @ 2026-04-20 16:06 UTC (permalink / raw)
To: dongxuyang
Cc: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, benoit.monin, bmasney, ningyu,
linmin, pinkesh.vaghela
In-Reply-To: <20260420094014.1955-1-dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
On Mon, Apr 20, 2026 at 05:40:14PM +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> Add bindings for the high-speed peripherals clock and reset generator
> on the ESWIN EIC7700 HSP.
>
> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Jared Kangas @ 2026-04-20 16:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <aeKn2dvOOO43zdev@jkangas-thinkpadp1gen3.rmtuswa.csb>
Fixing Dan's address based on mailmap update, sorry for the noise.
On Fri, Apr 17, 2026 at 02:36:25PM -0700, Jared Kangas wrote:
> Hi Dan,
>
> On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> > Add the GPR syscon region for the s32 chipset.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > ---
> >
> > [snip]
> >
> > diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > index e314f3c7d61d..be03db737384 100644
> > --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> > };
> > };
> >
> > + gpr: syscon@4007c000 {
> > + compatible = "nxp,s32g3-gpr", "syscon";
> > + reg = <0x4007c000 0x3000>;
> > + };
> > +
> > ocotp: nvmem@400a4000 {
> > compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> > reg = <0x400a4000 0x400>;
> > @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> > compatible = "nxp,s32g2-dwmac";
> > reg = <0x4033c000 0x2000>, /* gmac IP */
> > <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> > + nxp,phy-sel = <&gpr 0x4>;
> > interrupt-parent = <&gic>;
> > interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > interrupt-names = "macirq";
>
> I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
> dwmac-s32 side, but this appears to trigger a panic when reading the new
> debugfs regmap/*/registers file for the syscon node:
>
> # grep 4007c000 /proc/vmallocinfo
> 0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
> # cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
> Internal error: synchronous external abort: 0000000096000210 [#1] SMP
> [...]
> CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
> Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
> [...]
> pc : regmap_mmio_read32le+0x44/0xa0
> lr : regmap_mmio_read32le+0x44/0xa0
> [...]
> x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
> x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
> [...]
> x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
> x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
> Call trace:
> regmap_mmio_read32le+0x44/0xa0 (P)
> regmap_mmio_read+0x4c/0x80
> [...]
> Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: synchronous external abort: Fatal exception
>
> Running this through decodecode gives:
>
> All code
> ========
> 0: 52800400 mov w0, #0x20 // #32
> 4: 8b214093 add x19, x4, w1, uxtw
> 8: aa1303e1 mov x1, x19
> c: 97f4caf0 bl 0xffffffffffd32bcc
> 10:* b9400275 ldr w21, [x19] <-- trapping instruction
>
> Code starting with the faulting instruction
> ===========================================
> 0: b9400275 ldr w21, [x19]
>
> x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
> points to a bad read at physical address 0x4007c10c; I also confirmed
> that the preceding memory reads back without issues:
>
> # head -c 990 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0104: 00000000
> # head -c 1005 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0108: 00000000
> # head -c 1020 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> <panic>
>
> Best,
> Jared
>
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Brian Masney @ 2026-04-20 16:02 UTC (permalink / raw)
To: Sebastian Reichel, Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea, Maxime Ripard
In-Reply-To: <aeKtNf8CCAWduI-f@venus>
[-- Attachment #1: Type: text/plain, Size: 5457 bytes --]
Hi Alexey,
On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > Dear all,
> >
> > Need the help of the collective wisdom of the community.
> >
> > The problem I'm trying to solve is reliably obtaining the exact pixel
> > clock for arbitrary display modes supported by the RK3576 SoC.
> >
> > Rockchip RK3576 has three display output processors VP0~VP2, each
> > supporting different ranges of display modes, roughly as follows:
> > - VP0: 4K 120Hz
> > - VP1: 2.5k 60Hz
> > - VP2: 1080p 60Hz
> >
> > Each one obviously needs a pixel clock. The required frequencies for the
> > pixel clocks vary greatly depending on the display mode, and need to be
> > matched within a tight tolerance, or else many displays will refuse to
> > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > be obtained using integer dividers from its default clock source (GPLL
> > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > outside the tolerance of e.g. DP specification, resulting in a blank
> > screen on most displays by default.
> >
> > The clock sources are of course configurable, in particular there are muxes
> > connected to each VP for selecting the source of the pixel clock:
> > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > its dedicated dclk_vpX_src mux
> > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > (GPLL, CPLL, VPLL, BPLL, LPLL)
> >
> > While the system PLLs can be configured to output a wide range of
> > frequencies, they are shared between many system components. E.g. on the
> > current mainline kernel on one of my RK3576 boards I've got the following:
> > GPLL: 1188 MHz, enable count 20
> > CPLL: 1000 MHz, enable count 17
> > VPLL: 594 MHz, enable count 0 (yaay!)
> > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > predividers, so are less flexible)
> >
> > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > used to generate arbitrary pixel clocks, but we have up to three consumers
> > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > frequency on the fly to satisfy the requirements of the selected display
> > mode.
> >
> > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > three consumers while changing the PLL frequency on the fly sounds like
> > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > HDMI output out of the equation, because it can be driven from the HDMI
> > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > makes the decision of which dclk source to use for a VP block dependent on
> > which downstream consumer is connected to it (HDMI vs. something else).
>
> It becomes more messy: The HDMI PHY cannot be used as clock source
> for modes exceeding 4K@60Hz.
>
> > Even then we somehow need two devices to cooperate in picking a PLL
> > frequency that satisfies the requirements of both of them, and change to it
> > without display corruption. I'm not even sure if the CCF has mechanisms
> > for that?..
> >
> > What follows is a brief set of patches which illustrate a partial solution
> > for the case of "I just need 2.5k60Hz on VP1 via DP and don't care about
> > the rest". It switches the VP1 unconditionally to use VPLL as the source
> > for its dclk mux, allows changing the VPLL frequency on the fly, and also
> > changes the frequency calculation logic to allow for nearest-match
> > frequencies which are not necessarily rounded down. These are not meant
> > to be merged as-is, as I see the following issues:
> > - The flag allowing the PLL to change rate is in the clock driver, while
> > the reparenting to an unused PLL is in the device tree. If these go out
> > of sync, we might end up trying to change the frequency of a PLL which
> > is used by other consumers (I presume that could be dangerous)
>
> It is a problem, see e.g. this patch from Heiko removing the flag
> for an RK3588 VOP source clock:
>
> https://lore.kernel.org/linux-rockchip/20251008133135.3745785-1-heiko@sntech.de/
>
> Also note, that there is some more general ongoing work regarding
> this:
>
> See: https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/
I'm working on the patch set above to fix the clk scaling issues. You'll
have issues on clks that have CLK_SET_RATE_PARENT enabled, and there are
multiple children under that parent. Patches 2 and 4 in my series has
kunit tests that demonstrates the current behavior.
I attached a patch to drivers/clk/rockchip/clk-pll.c that adds support
for the v2 rate negotiation logic. You'll need to apply this on top my
clk scaling patch set. I only compile tested this, however it should work
based on the changes that I made to clk-divider.c.
You'll also need to add the flag CLK_V2_RATE_NEGOTIATION to your three
display clks. Otherwise, without the flag, it will just fall back to the
existing behavior.
Hopefully this will let you be able to use one of the PLLs that has a
high enable count as the parent.
Feel free to reach out to me if you have any questions or issues with
my patch set.
Brian
[-- Attachment #2: 0001-clk-rockchip-pll-add-support-for-v2-rate-negotiation.patch --]
[-- Type: text/plain, Size: 1326 bytes --]
From 66b44d756dba0152b415cc8eb8528b55c4253058 Mon Sep 17 00:00:00 2001
From: Brian Masney <bmasney@redhat.com>
Date: Mon, 20 Apr 2026 11:13:53 -0400
Subject: [PATCH] clk: rockchip: pll: add support for v2 rate negotiation logic
Content-type: text/plain
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
drivers/clk/rockchip/clk-pll.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6b853800cb6b..30e0722f872f 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -66,8 +66,20 @@ static int rockchip_pll_determine_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
+ struct clk_hw *parent = req->best_parent_hw;
int i;
+ if (parent && (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) &&
+ clk_has_v2_rate_negotiation(parent->core)) {
+ unsigned long lcm_rate;
+
+ lcm_rate = clk_hw_get_children_lcm(parent, hw, req->rate);
+ if (lcm_rate > 0) {
+ lcm_rate = clk_hw_round_rate(parent, lcm_rate);
+ req->best_parent_rate = lcm_rate;
+ }
+ }
+
/* Assuming rate_table is in descending order */
for (i = 0; i < pll->rate_count; i++) {
if (req->rate >= rate_table[i].rate) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: trivial-devices: add toradex,lava-hat-spi
From: Conor Dooley @ 2026-04-20 16:02 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Mark Brown,
Francesco Dolcini, devicetree, linux-kernel, linux-spi
In-Reply-To: <20260420114537.78160-2-francesco@dolcini.it>
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
On Mon, Apr 20, 2026 at 01:45:35PM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> Add a compatible string for the SPI loopback device present on the
> Toradex LAVA HAT test fixture.
>
> The Toradex LAVA HAT is a board used for automated hardware-in-the-loop
> (HIL) testing, it provides several test-related functionalities, and
> exists in multiple variants depending on the board it is mated with. The
> SPI function is implemented with a loopback on the MISO/MOSI signals.
>
> As the device can be fully described using only "compatible" and "reg",
> it is appropriate to list it under trivial-devices.yaml rather than
> introducing a dedicated binding.
>
> The SPI implementation is identical across all Toradex LAVA HAT
> variants, so a single compatible string is sufficient.
>
> Link: https://lore.kernel.org/all/20260310133254.GA51497@francesco-nb/
> Link: https://lore.kernel.org/all/20260316073547.11437-3-francesco@dolcini.it/
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: simple: Add Raspberry Pi 7" DSI Display module panel
From: Conor Dooley @ 2026-04-20 16:01 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Dave Stevenson, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260420-rpi-7inch-v1-1-e68d5c9c44bc@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Mon, Apr 20, 2026 at 04:13:35PM +0300, Tomi Valkeinen wrote:
> Add compatible string for panel used in Raspberry Pi 7" DSI Display
> module. The different display module versions have panels from multiple
> undisclosed vendors.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 0/2] Introduce Synology Microp driver
From: Markus Probst @ 2026-04-20 15:55 UTC (permalink / raw)
To: 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
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux
In-Reply-To: <20260420-synology_microp_initial-v8-0-7946a9124491@posteo.de>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
On Mon, 2026-04-20 at 14:24 +0000, Markus Probst wrote:
>
> To: Markus Probst <markus.probst@posteo.de>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Miguel Ojeda <ojeda@kernel.org>
> To: Boqun Feng <boqun@kernel.org>
> To: Gary Guo <gary@garyguo.net>
> To: Björn Roy Baron <bjorn3_gh@protonmail.com>
> To: Benno Lossin <lossin@kernel.org>
> To: Andreas Hindborg <a.hindborg@kernel.org>
> To: Alice Ryhl <aliceryhl@google.com>
> To: Trevor Gross <tmgross@umich.edu>
> To: Danilo Krummrich <dakr@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: rust-for-linux@vger.kernel.org
Thats unintentional. b4 seems to have messed up my cover letter.
Caused by
https://github.com/mricon/b4/commit/bf7beca19f723300d9a911cbf57d2f6aee3d4493
(according to my bisect).
Thanks
- Markus Probst
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-20 15:53 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2480203.yKrmzQ4Hd0@phil>
On 4/20/26 6:18 PM, Heiko Stuebner wrote:
> Am Montag, 20. April 2026, 13:00:25 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> Hi Heiko,
>>
>> On 4/18/26 2:12 AM, Heiko Stuebner wrote:
>>> Hi Cristian,
>>>
>>> Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
>>>>> the comments below apply sort of to all patches in that series.
>>>>>
>>>>> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>>>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>>>>>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>>>>>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>>>>>
>>>>>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>>>>>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>>>>>> adjusting the bias when transitioning between TMDS and FRL operating
>>>>>> modes.
>>
>> [...]
>>
>>>>>
>>>>>
>>>>>> @@ -231,6 +228,8 @@ &gpu {
>>>>>> };
>>>>>>
>>>>>> &hdmi {
>>>>>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>>>>>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>>>
>>>>> this should be sorted the other way around I think.
>>>>>
>>>>> Also please provide a pinctrl-names property too. If for whatever reason
>>>>> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
>>>>> board DTs are staying in the "old" compatible mode until they are adapted.
>>>>
>>>> Just to make sure I fully understand, the convention is that
>>>>
>>>> pinctrl-names = "default";
>>>>
>>>> should be always provided, even when the node overrides an existing pinctrl-0
>>>> property?
>>>>
>>>> E.g. in rk3576.dtsi we have:
>>>>
>>>> hdmi: hdmi@27da0000 {
>>>> ...
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
>>>> ...
>>>> }
>>>>
>>>> Hence I omitted pinctrl-names which doesn't change and just appended
>>>> &hdmi_frl_en to pinctrl-0's original value.
>>>
>>> correct, please always provide a pinctrl-names entry when setting a new
>>> pinctrl-0 .
>>>
>>> The background is, imagine you have a base:
>>>
>>> pinctrl-names = "default";
>>> pinstrl-0 = <....>;
>>>
>>> and override pinctrl-0 in a board.
>>>
>>> Now a newer binding introduces a 2nd pinctrl state "foo". Of course
>>> we're backwards compatible, and both are valid and the driver checks
>>> what states are defined.
>>>
>>> So the base sets:
>>> pinctrl-names = "default", "foo";
>>> pinctrl-0 = <...>;
>>> pinctrl-1 = <...>;
>>>
>>> in your (old) board you override pinctrl-0, but the driver still sees
>>> the new variant with 2 pinctrl states, where it should've stayed with
>>> the legacy 1-state, until the board-dts might get adapted in the future.
>>>
>>>
>>> And I know, we're likely not doing that everywhere, and also in most
>>> cases it won't really matter, but still it is safer and sets the better
>>> precedent :-) .
>>
>> Thanks for the detailed explanation, that clears things up!
>>
>> There are several other nodes (e.g. i2c, pwm, uart) that also lack
>> pinctrl-names despite providing pinctrl-0 - I can address those in a
>> separate patch.
>
> As said above it is an ideal to aspire to (having -names together with
> defining states), but if you want to add the "missing" -names,
> go ahead :-) .
>
>
>> I also noticed an inconsistency in property ordering: some nodes place
>> pinctrl-names before pinctrl-<n> and others after. I have always used
>> the former, but we should probably prefer the latter to stay consistent
>> with how clocks, resets, phys, etc. are ordered.
>>
>> Thoughts?
>
> There is sort of a "conflict" between regular ordering and possibly
> better readability. I.e. the dt-writing guidelines propose alphabetical
> ordering which I guess puts numbers before letters.
>
> On the other hand the semantic definition of list the states and then
> define them (names first, -0, -1, etc second) looks more sensible from
> a understanding standpoint.
>
>
> But there we'd end up with special rules, so just sticking to the
> base sorting will cause less friction in the long run I think.
> Aka, -0, -1 first; -names after, follows the main sorting suggestions
> so it's easy to explain to newcomers.
Yes, that seems like a good enough reason to go with this approach.
> But please don't re-sort existing entries :-)
Oh, no, it's just for the current changes. :-)
Thanks,
Cristian
^ permalink raw reply
* [PATCH 2/2] dt-bindings: wire example style check into dt_binding_check
From: Daniel Golle @ 2026-04-20 15:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Daniel Golle, devicetree, linux-kernel
In-Reply-To: <cover.1776700167.git.daniel@makrotopia.org>
Run dt-check-example-style as part of dt_binding_check_one to catch
formatting issues in DTS examples during schema validation.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
Documentation/devicetree/bindings/Makefile | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
index 7b668f7fd4007..364d167e8dd27 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -46,6 +46,14 @@ quiet_cmd_chk_bindings = CHKDT $(src)
xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(src)) \
&& touch $@ || true
+DT_CHK_EX_STYLE = $(srctree)/scripts/dtc/dt-check-example-style
+
+quiet_cmd_chk_ex_style = STYLE $(src)
+ cmd_chk_ex_style = ($(find_cmd) | \
+ xargs -n200 -P$$(nproc) \
+ $(PYTHON3) $(DT_CHK_EX_STYLE) --diff) \
+ && touch $@ || true
+
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
$(find_all_cmd) > $$f ; \
@@ -62,13 +70,16 @@ override DTC_FLAGS := \
$(obj)/processed-schema.json: $(DT_DOCS) check_dtschema_version FORCE
$(call if_changed,mk_schema)
-targets += .dt-binding.checked .yamllint.checked
+targets += .dt-binding.checked .yamllint.checked .dt-example-style.checked
$(obj)/.yamllint.checked: $(DT_DOCS) $(src)/.yamllint FORCE
$(if $(DT_SCHEMA_LINT),$(call if_changed,yamllint),)
$(obj)/.dt-binding.checked: $(DT_DOCS) FORCE
$(call if_changed,chk_bindings)
+$(obj)/.dt-example-style.checked: $(DT_DOCS) FORCE
+ $(call if_changed,chk_ex_style)
+
always-y += processed-schema.json
targets += $(patsubst $(obj)/%,%, $(CHK_DT_EXAMPLES))
targets += $(patsubst $(obj)/%.dtb,%.dts, $(CHK_DT_EXAMPLES))
@@ -82,7 +93,7 @@ dt_compatible_check: $(obj)/processed-schema.json
$(Q)$(srctree)/scripts/dtc/dt-extract-compatibles $(srctree) | xargs dt-check-compatible -v -s $<
PHONY += dt_binding_check_one
-dt_binding_check_one: $(obj)/.dt-binding.checked $(obj)/.yamllint.checked
+dt_binding_check_one: $(obj)/.dt-binding.checked $(obj)/.yamllint.checked $(obj)/.dt-example-style.checked
PHONY += dt_binding_check
dt_binding_check: dt_binding_check_one $(CHK_DT_EXAMPLES)
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: add DTS example style checker
From: Daniel Golle @ 2026-04-20 15:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Daniel Golle, devicetree, linux-kernel
In-Reply-To: <cover.1776700167.git.daniel@makrotopia.org>
Add a Python script that enforces coding style rules from
dts-coding-style.rst on examples embedded in YAML binding files.
Checks indentation, property and child node ordering, blank line
placement, node naming, tabs, trailing whitespace and unused labels.
Produces a canonical form and diffs it against the original.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
scripts/dtc/dt-check-example-style | 712 +++++++++++++++++++++++++++++
1 file changed, 712 insertions(+)
create mode 100755 scripts/dtc/dt-check-example-style
diff --git a/scripts/dtc/dt-check-example-style b/scripts/dtc/dt-check-example-style
new file mode 100755
index 0000000000000..3daccee3a6f61
--- /dev/null
+++ b/scripts/dtc/dt-check-example-style
@@ -0,0 +1,712 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Check DTS example style in YAML binding files.
+#
+# Enforces the coding style rules from
+# Documentation/devicetree/bindings/dts-coding-style.rst on the examples:
+# sections of devicetree binding YAML files.
+
+import argparse
+import difflib
+import re
+import sys
+from enum import Enum, auto
+
+import ruamel.yaml
+
+
+class LineType(Enum):
+ BLANK = auto()
+ COMMENT = auto()
+ COMMENT_START = auto()
+ COMMENT_BODY = auto()
+ COMMENT_END = auto()
+ PREPROCESSOR = auto()
+ NODE_OPEN = auto()
+ NODE_CLOSE = auto()
+ PROPERTY = auto()
+ CONTINUATION = auto()
+
+
+class DtsLine:
+ __slots__ = ('raw', 'linetype', 'indent', 'stripped', 'prop_name',
+ 'continuations', 'node_name', 'node_addr', 'label',
+ 'ref_name')
+
+ def __init__(self, raw, linetype, indent, stripped):
+ self.raw = raw
+ self.linetype = linetype
+ self.indent = indent
+ self.stripped = stripped
+ self.prop_name = None
+ self.continuations = []
+ self.node_name = None
+ self.node_addr = None
+ self.label = None
+ self.ref_name = None
+
+
+re_cpp_directive = re.compile(
+ r'^#\s*(include|define|undef|ifdef|ifndef|if|else|elif|endif|'
+ r'pragma|error|warning)\b')
+
+
+def is_preprocessor(stripped):
+ """Distinguish C preprocessor directives from DTS # properties.
+
+ DTS properties like #address-cells, #size-cells, #interrupt-cells
+ start with # but are followed by a property name pattern and = or ;.
+ """
+ return re_cpp_directive.match(stripped) is not None
+
+
+def classify_lines(text):
+ """Classify each line of a DTS example into structural types."""
+ lines = text.split('\n')
+ result = []
+ in_block_comment = False
+ prev_complete = True
+
+ for raw in lines:
+ stripped = raw.lstrip()
+ indent = len(raw) - len(stripped) if stripped else 0
+
+ if not stripped:
+ result.append(DtsLine(raw, LineType.BLANK, 0, ''))
+ continue
+
+ if in_block_comment:
+ if '*/' in stripped:
+ in_block_comment = False
+ result.append(DtsLine(raw, LineType.COMMENT_END,
+ indent, stripped))
+ else:
+ result.append(DtsLine(raw, LineType.COMMENT_BODY,
+ indent, stripped))
+ continue
+
+ if stripped.startswith('/*'):
+ if '*/' in stripped:
+ result.append(DtsLine(raw, LineType.COMMENT,
+ indent, stripped))
+ else:
+ in_block_comment = True
+ result.append(DtsLine(raw, LineType.COMMENT_START,
+ indent, stripped))
+ continue
+
+ if stripped.startswith('//'):
+ result.append(DtsLine(raw, LineType.COMMENT, indent, stripped))
+ continue
+
+ if stripped.startswith('#') and is_preprocessor(stripped):
+ result.append(DtsLine(raw, LineType.PREPROCESSOR,
+ indent, stripped))
+ prev_complete = True
+ continue
+
+ if not prev_complete:
+ dl = DtsLine(raw, LineType.CONTINUATION, indent, stripped)
+ result.append(dl)
+ prev_complete = (stripped.endswith(';') or
+ stripped.endswith('{') or
+ stripped.rstrip().endswith('};'))
+ continue
+
+ if stripped.rstrip(';').rstrip() == '}' or stripped == '};':
+ result.append(DtsLine(raw, LineType.NODE_CLOSE,
+ indent, stripped))
+ prev_complete = True
+ continue
+
+ if stripped.endswith('{'):
+ dl = DtsLine(raw, LineType.NODE_OPEN, indent, stripped)
+ parse_node_header(dl)
+ result.append(dl)
+ prev_complete = True
+ continue
+
+ # Property or boolean property
+ dl = DtsLine(raw, LineType.PROPERTY, indent, stripped)
+ parse_property_name(dl)
+ result.append(dl)
+ prev_complete = stripped.endswith(';')
+ continue
+
+ return result
+
+
+# Regex for node header: optional "label: " then name optionally @addr
+# then optional whitespace and {
+re_node_header = re.compile(
+ r'^(?:([a-zA-Z_][a-zA-Z0-9_]*):\s*)?' # optional label
+ r'([a-zA-Z][a-zA-Z0-9,._+-]*|/)' # node name or /
+ r'(?:@([0-9a-fA-F,]+))?' # optional @address
+ r'\s*\{$'
+)
+
+# Regex for &reference node: &label { ... }
+re_ref_node = re.compile(
+ r'^&([a-zA-Z_][a-zA-Z0-9_]*)\s*\{$'
+)
+
+
+def parse_node_header(dl):
+ """Extract label, node name, and unit address from a NODE_OPEN line."""
+ m = re_node_header.match(dl.stripped)
+ if m:
+ dl.label = m.group(1)
+ dl.node_name = m.group(2)
+ dl.node_addr = m.group(3)
+ return
+
+ m = re_ref_node.match(dl.stripped)
+ if m:
+ dl.ref_name = m.group(1)
+
+
+def parse_property_name(dl):
+ """Extract the property name from a PROPERTY line."""
+ s = dl.stripped
+ # "prop-name = value;" or "prop-name;"
+ m = re.match(r'^([a-zA-Z#][a-zA-Z0-9,._+#-]*)\s*[=;]', s)
+ if m:
+ dl.prop_name = m.group(1)
+
+
+def group_continuations(lines):
+ """Attach CONTINUATION lines to their preceding PROPERTY."""
+ grouped = []
+ for dl in lines:
+ if dl.linetype == LineType.CONTINUATION and grouped:
+ # Find the last PROPERTY in grouped
+ for prev in reversed(grouped):
+ if prev.linetype == LineType.PROPERTY:
+ prev.continuations.append(dl)
+ break
+ else:
+ grouped.append(dl)
+ else:
+ grouped.append(dl)
+ return grouped
+
+
+def collect_labels_and_refs(text):
+ """Collect all label definitions and &references in example text."""
+ labels_defined = set()
+ labels_referenced = set()
+
+ for m in re.finditer(r'([a-zA-Z_][a-zA-Z0-9_]*):', text):
+ # Exclude things like http: or property names before =
+ ctx_after = text[m.end():m.end() + 20].lstrip()
+ # A label is followed by a node name or another label
+ # Property names are followed by = or ;
+ if not ctx_after or ctx_after[0] not in ('=', ';', '"', '<'):
+ labels_defined.add(m.group(1))
+
+ for m in re.finditer(r'&([a-zA-Z_][a-zA-Z0-9_]*)', text):
+ labels_referenced.add(m.group(1))
+
+ return labels_defined, labels_referenced
+
+
+def prop_sort_key(dl, orig_index):
+ """Sort key for property ordering within a node.
+
+ Order: compatible, reg, ranges, standard props (original order),
+ vendor props (original order), status.
+
+ Within the standard and vendor groups, original order is preserved
+ (stable sort) because the coding style examples are not fully
+ consistent on natural sort within groups.
+ """
+ name = dl.prop_name or ''
+ check_name = name.lstrip('#')
+
+ if name == 'compatible':
+ return (0, 0)
+ if name == 'reg':
+ return (1, 0)
+ if name == 'reg-names':
+ return (1, 1)
+ if name == 'ranges':
+ return (2, 0)
+ if name == 'status':
+ return (5, 0)
+
+ # Vendor-specific: name contains a comma
+ if ',' in check_name:
+ return (4, orig_index)
+
+ # Standard property -- preserve original order
+ return (3, orig_index)
+
+
+def natural_sort_key(s):
+ """Sort key that handles embedded numbers naturally."""
+ parts = []
+ for part in re.split(r'(\d+)', s):
+ if part.isdigit():
+ parts.append((0, int(part)))
+ else:
+ parts.append((1, part))
+ return parts
+
+
+def node_sort_key(dl):
+ """Sort key for child node ordering.
+
+ Nodes with unit addresses sort by address (numeric), then nodes
+ without addresses sort by name (natural).
+ """
+ if dl.node_addr is not None:
+ # Parse comma-separated hex address parts
+ parts = dl.node_addr.split(',')
+ try:
+ nums = tuple(int(p, 16) for p in parts)
+ return (0, nums, '')
+ except ValueError:
+ return (0, (0,), dl.node_addr)
+ name = dl.node_name or ''
+ return (1, (0,), natural_sort_key(name))
+
+
+def continuation_align_col(first_line_stripped):
+ """Find the column to align continuation lines to.
+
+ Aligns to the first < or " after = in the property's first line.
+ Returns None if no alignment target found.
+ """
+ eq_pos = first_line_stripped.find('=')
+ if eq_pos < 0:
+ return None
+ rest = first_line_stripped[eq_pos + 1:]
+ for i, ch in enumerate(rest):
+ if ch in '<"':
+ return eq_pos + 1 + i
+ return None
+
+
+def canonicalize_node_body(lines, depth):
+ """Re-emit a node body in canonical form.
+
+ lines: list of DtsLine within a single { } scope (excluding the
+ { and } lines themselves).
+ depth: nesting depth of contents (1 for top-level node body).
+ Returns list of canonical output lines (strings).
+ """
+ indent = ' ' * depth
+ output = []
+
+ # Separate into properties, comments attached to properties,
+ # and child nodes
+ properties = []
+ child_nodes = []
+ i = 0
+ pending_comments = []
+
+ while i < len(lines):
+ dl = lines[i]
+
+ if dl.linetype == LineType.BLANK:
+ i += 1
+ continue
+
+ if dl.linetype in (LineType.COMMENT, LineType.COMMENT_START,
+ LineType.COMMENT_BODY, LineType.COMMENT_END):
+ pending_comments.append(dl)
+ i += 1
+ continue
+
+ if dl.linetype == LineType.PREPROCESSOR:
+ # Preprocessor lines within a node are unusual but pass through
+ properties.append(('preproc', pending_comments[:], dl))
+ pending_comments.clear()
+ i += 1
+ continue
+
+ if dl.linetype == LineType.PROPERTY:
+ properties.append(('prop', pending_comments[:], dl))
+ pending_comments.clear()
+ i += 1
+ continue
+
+ if dl.linetype == LineType.NODE_OPEN:
+ # Collect the entire child node
+ child_lines = []
+ child_open = dl
+ child_depth = 1
+ i += 1
+ while i < len(lines) and child_depth > 0:
+ if lines[i].linetype == LineType.NODE_OPEN:
+ child_depth += 1
+ elif lines[i].linetype == LineType.NODE_CLOSE:
+ child_depth -= 1
+ if child_depth == 0:
+ i += 1
+ break
+ child_lines.append(lines[i])
+ i += 1
+ child_nodes.append(('node', pending_comments[:],
+ child_open, child_lines))
+ pending_comments.clear()
+ continue
+
+ # Unexpected line type -- pass through
+ properties.append(('other', pending_comments[:], dl))
+ pending_comments.clear()
+ i += 1
+
+ # Sort properties by canonical order (with original index for stability)
+ prop_items = [(p, idx) for idx, p in enumerate(properties)
+ if p[0] == 'prop']
+ sorted_props = sorted(
+ prop_items,
+ key=lambda pi: prop_sort_key(pi[0][2], pi[1])
+ )
+ sorted_props = [p for p, _ in sorted_props]
+ # Keep preprocessor and other lines in their relative position
+ # (prepend them before the sorted properties)
+ preprocs = [p for p in properties if p[0] != 'prop']
+
+ # Sort child nodes
+ sorted_children = sorted(child_nodes, key=lambda c: node_sort_key(c[2]))
+
+ # Emit preprocessor lines first (if any within node)
+ for kind, comments, dl in preprocs:
+ for c in comments:
+ output.append(format_comment_line(c, indent))
+ output.append(dl.raw.rstrip()) # preprocessor: preserve original
+ need_blank = True
+
+ # Emit sorted properties
+ prev_was_status = False
+ for idx, (kind, comments, dl) in enumerate(sorted_props):
+ # Blank line before status
+ if dl.prop_name == 'status' and output:
+ output.append('')
+
+ for c in comments:
+ output.append(format_comment_line(c, indent))
+
+ output.append(format_property(dl, indent))
+ for cont in dl.continuations:
+ output.append(format_continuation(dl, cont, indent))
+
+ # Emit sorted child nodes
+ for kind, comments, child_open, child_body in sorted_children:
+ # Blank line before each child node
+ if output:
+ output.append('')
+
+ for c in comments:
+ output.append(format_comment_line(c, indent))
+
+ output.append(indent + format_node_open(child_open))
+ body_output = canonicalize_node_body(child_body, depth + 1)
+ output.extend(body_output)
+ output.append(indent + '};')
+
+ # Trailing comments that weren't attached
+ if pending_comments:
+ for c in pending_comments:
+ output.append(format_comment_line(c, indent))
+
+ return output
+
+
+def format_comment_line(dl, indent):
+ """Format a comment line with canonical indent."""
+ # Block comment body/end lines get extra space for " * " style
+ if dl.linetype in (LineType.COMMENT_BODY, LineType.COMMENT_END):
+ return indent + ' ' + dl.stripped
+ return indent + dl.stripped
+
+
+def format_property(dl, indent):
+ """Format a property line with canonical indent."""
+ return indent + dl.stripped
+
+
+def format_continuation(prop_dl, cont_dl, indent):
+ """Format a continuation line aligned to the property's value."""
+ col = continuation_align_col(prop_dl.stripped)
+ if col is not None:
+ # Align to that column relative to indent
+ total_col = len(indent) + col
+ return ' ' * total_col + cont_dl.stripped
+ # Fallback: indent + 4 extra spaces
+ return indent + ' ' + cont_dl.stripped
+
+
+def format_node_open(dl):
+ """Format a node opening line canonically."""
+ if dl.ref_name:
+ return '&{} {{'.format(dl.ref_name)
+ parts = []
+ if dl.label:
+ parts.append(dl.label + ': ')
+ if dl.node_name:
+ parts.append(dl.node_name)
+ if dl.node_addr is not None:
+ parts.append('@' + dl.node_addr)
+ parts.append(' {')
+ return ''.join(parts)
+
+
+def canonicalize_example(text):
+ """Produce canonical form of a DTS example."""
+ lines = classify_lines(text)
+ lines = group_continuations(lines)
+
+ output = []
+ # Top-level: preprocessor lines first, then nodes
+ top_preprocs = []
+ top_nodes = []
+ i = 0
+ pending_comments = []
+
+ while i < len(lines):
+ dl = lines[i]
+
+ if dl.linetype == LineType.BLANK:
+ i += 1
+ continue
+
+ if dl.linetype in (LineType.COMMENT, LineType.COMMENT_START,
+ LineType.COMMENT_BODY, LineType.COMMENT_END):
+ pending_comments.append(dl)
+ i += 1
+ continue
+
+ if dl.linetype == LineType.PREPROCESSOR:
+ top_preprocs.append((pending_comments[:], dl))
+ pending_comments.clear()
+ i += 1
+ continue
+
+ if dl.linetype == LineType.NODE_OPEN:
+ node_lines = []
+ node_open = dl
+ depth = 1
+ i += 1
+ while i < len(lines) and depth > 0:
+ if lines[i].linetype == LineType.NODE_OPEN:
+ depth += 1
+ elif lines[i].linetype == LineType.NODE_CLOSE:
+ depth -= 1
+ if depth == 0:
+ i += 1
+ break
+ node_lines.append(lines[i])
+ i += 1
+ top_nodes.append((pending_comments[:], node_open, node_lines))
+ pending_comments.clear()
+ continue
+
+ # Top-level property (unusual but possible, e.g. /delete-node/)
+ output.append(dl.raw.rstrip())
+ pending_comments.clear()
+ i += 1
+
+ # Emit preprocessor includes
+ for comments, dl in top_preprocs:
+ for c in comments:
+ output.append(format_comment_line(c, ''))
+ output.append(dl.stripped)
+
+ # Blank line between preprocessor and first node
+ if top_preprocs and top_nodes:
+ output.append('')
+
+ # Emit top-level nodes
+ for idx, (comments, node_open, node_body) in enumerate(top_nodes):
+ if idx > 0:
+ output.append('')
+
+ for c in comments:
+ output.append(format_comment_line(c, ''))
+
+ output.append(format_node_open(node_open))
+ body = canonicalize_node_body(node_body, 1)
+ output.extend(body)
+ output.append('};')
+
+ # Trailing comments
+ for c in pending_comments:
+ output.append(format_comment_line(c, ''))
+
+ return '\n'.join(output)
+
+
+def check_node_names(lines, errors, filepath, base_line):
+ """Check node name coding style rules."""
+ re_valid_name = re.compile(r'^[a-z][a-z0-9-]*$')
+
+ for dl in lines:
+ if dl.linetype != LineType.NODE_OPEN:
+ continue
+ if dl.node_name is None:
+ continue
+ # Skip root node "/"
+ if dl.node_name == '/':
+ continue
+
+ name = dl.node_name
+ if not re_valid_name.match(name):
+ errors.append(
+ "node name '{}' must use only [a-z0-9-]".format(name))
+
+ if dl.node_addr is not None:
+ addr = dl.node_addr
+ # Check no leading zeros in each address part
+ for part in addr.split(','):
+ if len(part) > 1 and part.startswith('0'):
+ errors.append(
+ "unit address '{}' has leading zeros"
+ .format(addr))
+ break
+ # Must be valid hex
+ try:
+ int(part, 16)
+ except ValueError:
+ errors.append(
+ "unit address '{}' is not valid hex"
+ .format(addr))
+ break
+
+
+def check_unused_labels(text, errors):
+ """Check for labels that are defined but never referenced."""
+ labels_defined, labels_referenced = collect_labels_and_refs(text)
+ for label in sorted(labels_defined - labels_referenced):
+ # Skip fake_intc labels (injected by dt-extract-example wrapper)
+ if label.startswith('fake_intc'):
+ continue
+ errors.append(
+ "label '{}' defined but never referenced".format(label))
+
+
+def check_tabs(lines, errors):
+ """Check for tabs in non-preprocessor DTS lines."""
+ for dl in lines:
+ if dl.linetype == LineType.PREPROCESSOR:
+ continue
+ if dl.linetype == LineType.BLANK:
+ continue
+ if '\t' in dl.raw:
+ errors.append("tab character in DTS line: {}".format(
+ dl.raw.rstrip()))
+
+
+def check_trailing_whitespace(lines, errors):
+ """Check for trailing whitespace."""
+ for dl in lines:
+ if dl.raw != dl.raw.rstrip():
+ errors.append("trailing whitespace: {}".format(
+ repr(dl.raw.rstrip()[-30:])))
+
+
+def check_example(text, filepath, yaml_line, show_diff=False):
+ """Check a single DTS example. Returns list of error strings."""
+ errors = []
+ lines = classify_lines(text)
+
+ check_trailing_whitespace(lines, errors)
+ check_tabs(lines, errors)
+ check_node_names(lines, errors, filepath, yaml_line)
+ check_unused_labels(text, errors)
+
+ # Generate canonical form and compare
+ canonical = canonicalize_example(text)
+
+ # Strip trailing newlines for comparison
+ orig_stripped = text.rstrip('\n')
+ canon_stripped = canonical.rstrip('\n')
+
+ if orig_stripped != canon_stripped:
+ if show_diff:
+ orig_lines = orig_stripped.splitlines()
+ canon_lines = canon_stripped.splitlines()
+ diff = difflib.unified_diff(
+ orig_lines, canon_lines,
+ fromfile='{} (original)'.format(filepath),
+ tofile='{} (canonical)'.format(filepath),
+ lineterm='')
+ errors.append('canonical form differs:\n' + '\n'.join(diff))
+ else:
+ # Generate concise per-line errors
+ orig_l = orig_stripped.splitlines()
+ canon_l = canon_stripped.splitlines()
+ maxlen = max(len(orig_l), len(canon_l))
+ for i in range(maxlen):
+ o = orig_l[i] if i < len(orig_l) else '<missing>'
+ c = canon_l[i] if i < len(canon_l) else '<missing>'
+ if o != c:
+ errors.append(
+ 'line {}: expected: {}'.format(i + 1, c.rstrip()))
+
+ return errors
+
+
+def process_file(filepath, show_diff=False):
+ """Process a single YAML binding file. Returns total error count."""
+ yaml = ruamel.yaml.YAML()
+ try:
+ with open(filepath, encoding='utf-8') as f:
+ data = yaml.load(f)
+ except Exception as e:
+ print('{}: error loading YAML: {}'.format(filepath, e),
+ file=sys.stderr)
+ return 0
+
+ if not isinstance(data, dict) or 'examples' not in data:
+ return 0
+
+ examples = data['examples']
+ total_errors = 0
+
+ for i, ex in enumerate(examples):
+ if not isinstance(ex, str):
+ continue
+
+ # Get YAML line number for error reporting
+ try:
+ yaml_line = examples.lc.item(i)[0] + 2
+ except Exception:
+ yaml_line = 0
+
+ errors = check_example(str(ex), filepath, yaml_line,
+ show_diff=show_diff)
+ for err in errors:
+ total_errors += 1
+ if yaml_line:
+ print('{}:{}: example {}: {}'.format(
+ filepath, yaml_line, i, err), file=sys.stderr)
+ else:
+ print('{}: example {}: {}'.format(
+ filepath, i, err), file=sys.stderr)
+
+ return total_errors
+
+
+def main():
+ ap = argparse.ArgumentParser(
+ description='Check DTS example style in YAML binding files.',
+ fromfile_prefix_chars='@')
+ ap.add_argument('yamlfiles', nargs='+', metavar='yamlfile',
+ help='YAML binding files to check')
+ ap.add_argument('--diff', action='store_true',
+ help='Show unified diff of original vs. canonical')
+ args = ap.parse_args()
+
+ total_errors = 0
+ for filepath in args.yamlfiles:
+ total_errors += process_file(filepath, show_diff=args.diff)
+
+ sys.exit(1 if total_errors > 0 else 0)
+
+
+if __name__ == '__main__':
+ main()
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] dt-bindings: automated coding style check for DTS examples
From: Daniel Golle @ 2026-04-20 15:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
Daniel Golle, devicetree, linux-kernel
Reviewing DTS examples in binding YAML files for coding style is
tedious and repetitive. The rules in dts-coding-style.rst are well
defined but currently not enforced by any tooling -- dtc does not
care about whitespace, and yamllint only sees the YAML structure,
not the DTS content inside literal block scalars.
This series adds a Python script that produces a canonical form of
each DTS example and diffs it against the original. Any difference
is a style violation. The checks cover:
- 4-space indentation per nesting level
- property ordering (compatible, reg, ranges, standard, vendor, status)
- child node ordering by unit address
- blank line placement (before child nodes and status, nowhere else)
- no trailing whitespace, no tabs in DTS lines
- node names using only [a-z0-9-]
- no unused labels (defined but never &-referenced)
The script uses only ruamel.yaml (already required by dtschema) and
has no other dependencies. It is wired into dt_binding_check_one
with || true, so currently informational.
Running it against the current tree finds issues in roughly 70% of
existing binding files -- mostly indentation (many older bindings
use 2-space indent) and unused labels. These can be cleaned up in
follow-up series; the immediate value is catching problems in new
submissions before reviewers have to.
A --diff flag produces unified diffs showing exactly what needs to
change, making fixes trivial. A future --fix mode could rewrite
examples in-place.
As someone who has repeatedly annoyed DT maintainers with exactly
the kind of mistakes this tool catches, I hope this makes up for
some of that. And since my Python is even much worse than my DTS
coding style, the script was written with generous help from
Claude Opus 4.6.
Daniel Golle (2):
dt-bindings: add DTS example style checker
dt-bindings: wire example style check into dt_binding_check
Documentation/devicetree/bindings/Makefile | 15 +-
scripts/dtc/dt-check-example-style | 712 +++++++++++++++++++++
2 files changed, 725 insertions(+), 2 deletions(-)
create mode 100755 scripts/dtc/dt-check-example-style
--
2.53.0
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Krzysztof Kozlowski @ 2026-04-20 15:43 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Karthik S, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <vgrw3n5invft2zxmeh2gsknxvkgluqus4dfb4h2ipea7lvma4k@wrumrkki54s7>
On 18/04/2026 01:06, Dmitry Baryshkov wrote:
> On Fri, Apr 17, 2026 at 12:12:46PM +0200, Krzysztof Kozlowski wrote:
>> On 17/04/2026 11:42, Krzysztof Kozlowski wrote:
>>>
>>> And finally:
>>>
>>> Please run scripts/checkpatch.pl on the patches and fix reported
>>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>>> patches and (probably) fix more warnings. Some warnings can be ignored,
>>> especially from --strict run, but the code here looks like it needs a
>>> fix. Feel free to get in touch if the warning is not clear.
>>
>> As you pointed correctly after offline talk, checkpatch does not report
>> undocumented compatible for the sound card qcs6490-rb3gen2-ia-snd-card.
>>
>> Unfortunately this patch did not go through internal toolset fully
>> (PatchWise), which could have flag the issue. Let's discuss it
>> internally next week.
>>
>>>
>>> Undocumented ABI (without any reference in changelog where to find
>>> posted patch).
>> You still need to solve the undocumented sound card ABI - new
>> compatible. If it is already sent to mailing lists, then provide link in
>> patch changelog (---).
>
> Which compatible is new there? I think it is a model and not compatible.
Ahh, damn, you are right. It's not adding any new compatible.
It's fine, I got confused, no new ABI here.
Thanks Dmitry, for pointing this out.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] media: v4l2-common: Add YUV24 format info
From: Nicolas Dufresne @ 2026-04-20 15:39 UTC (permalink / raw)
To: Nas Chung, mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo,
s.hauer
Cc: linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, marek.vasut, ming.qian
In-Reply-To: <20260415092529.577-2-nas.chung@chipsnmedia.com>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
Le mercredi 15 avril 2026 à 18:25 +0900, Nas Chung a écrit :
> The YUV24 format is missing an entry in the v4l2_format_info().
> The YUV24 format is the packed YUV 4:4:4 formats with 8 bits
> per component.
>
> Fixes: 0376a51fbe5e ("media: v4l: Add packed YUV444 24bpp pixel format")
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Unless you disagree, I might cherry-pick this one. Would it be ok with you ?
Nicolas
> ---
> drivers/media/v4l2-core/v4l2-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 554c591e1113..55bcd5975d9f 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -281,6 +281,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_Y212, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_Y216, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_YUV48_12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 6, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> + { .format = V4L2_PIX_FMT_YUV24, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 3, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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