Re: [PATCH v3] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Undocumented compatible strings for new hardware variants
- [Low] Inverted brightness-levels array violating semantics and causing logic error
--

commit 8e773037ec40fa18ba2cb58aa7b9d32280d8b5cb
Author: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>

arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist

Add support for the Geist board based on the Renesas R-Car R8A779MD (M3Le)
SoC, a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals.

> diff --git a/arch/arm64/boot/dts/renesas/r8a779md-geist.dts b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
> new file mode 100644
> index 0000000000000..11024bd12eb63
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Device Tree Source for the Geist board with R-Car M3Le
> + *
> + * Copyright (C) 2025-2026 Renesas Electronics Corp.
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "r8a779md.dtsi"
> +
> +/ {
> +	model = "Renesas Geist board based on r8a779md";
> +	compatible = "renesas,geist", "renesas,r8a779md", "renesas,r8a77965";

[Severity: Low]
Are the YAML device tree bindings for the new renesas,geist and
renesas,r8a779md compatible strings included in a separate patch?

According to the subsystem guidelines, new compatible strings must be added
to the schema. For renesas,r8a779md (a variant of renesas,r8a77965),
omitting it from existing if-then conditional blocks where previous
generations appear causes schema validation to be incomplete, rendering
dtbs_check unable to validate the node correctly.

[ ... ]

> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 50000>;
> +
> +		brightness-levels = <256 128 64 16 8 4 0>;

[Severity: Low]
Does this inverted brightness-levels array violate the device tree
specification to work around missing PWM_POLARITY_INVERTED support?

The DT common.yaml specification requires brightness levels to be strictly
increasing, with 0 being the darkest.

This inverted array introduces a logic error in
drivers/video/backlight/pwm_bl.c. In pwm_backlight_is_linear(), max_val (0)
- min_val (256) triggers an unsigned integer underflow (4294967040).

This underflow creates a massive arbitrary error margin, completely
breaking the linearity check and causing the driver to unconditionally
misclassify the backlight as linear in sysfs.

> +		default-brightness-level = <6>;
> +
> +		power-supply = <&reg_12v>;
> +		enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> +	};

[ ... ]

> +&i2c2 {
> +	pinctrl-0 = <&i2c2_pins>;
> +	pinctrl-names = "default";
> +	clock-frequency = <100000>;
> +	status = "okay";

[ ... ]

> +	/* Pin-to-pin, register map, and control compatible with CS2000 and CS2200 */
> +	cs2500: clock-controller@4f {
> +		#clock-cells = <0>;
> +		compatible = "cirrus,cs2500", "cirrus,cs2000-cp";

[Severity: Low]
Is the cirrus,cs2500 compatible string missing its YAML binding schema?

Just like the board compatible strings above, adding a new hardware variant
requires updating the device tree bindings.

> +		reg = <0x4f>;
> +		clocks = <&audio_clkout>, <&x12_clk>;
> +		clock-names = "clk_in", "ref_clk";
> +
> +		assigned-clocks = <&cs2500>;
> +		assigned-clock-rates = <24576000>; /* 1/1 divide */
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522172000.15096-1-marek.vasut+renesas@mailbox.org?part=1