[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3dd2dcc9-5fbb-4384-985f-a61e26cc8a5f@collabora.com>
Date: Tue, 16 Jul 2024 11:24:44 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>,
Matthias Brugger <matthias.bgg@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Thomas Weißschuh
<linux@...ssschuh.net>, Tzung-Bi Shih <tzungbi@...nel.org>,
kernel@...labora.com, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH RFC] arm64: dts: mediatek: mt8195-cherry: Remove
keyboard-backlight node
Il 15/07/24 18:09, Nícolas F. R. A. Prado ha scritto:
> Commit 970c3a6b7aa3 ("mfd: cros_ec: Register keyboard backlight
> subdevice") introduced support for detecting keyboard backlight
> fuctionality through communication with the ChromeOS EC. This means that
> the DT node is no longer used. Remove the unneeded node.
>
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
> ---
> Different CrosEC FW versions could potentially not support discovering
> the keyboard backlight functionality, but I've tested both a recent
>
> tomato_v2.0.23149-099cd3e539 tomato_15699.72.0 2024-01-03
>
> and an old
>
> tomato_v2.0.10686-234e646fd8 tomato_14268.0.0 2021-10-07
>
> version on mt8195-cherry-tomato and on both relying only on the
> discoverability works. I've tested on both tomato-r2 and tomato-r3. I
> have not tested on dojo, however, as I don't have access to it.
>
Dojo will work anyway because those machines do share the same base FW... but
anyway, I'm not sure that this is the right thing to do.
The commit that you mentioned says that it is meant to make that "work on machines
without specific ACPI or OF support for the keyboard backlight", but not that the
intention is to stop using either ACPI nor DT nodes for that.
The DT kselftest is relatively young, and I suspect that anyway this is not the
only affected device, so the justification is only barely valid.
Don't misunderstand me, I'm not saying that I'm not okay with this, but I'd like to
have more opinions about this.
If we choose to go this way, ideally we should remove this from all of the upstream
Chromebook devicetrees (not only MediaTek, clearly!) so that would require a bit
more effort to test here and there.
Any opinion from anyone?
Cheers,
Angelo
> My motivation to remove the node is because the DT kselftest expects DT
> nodes that can match to a driver to be probed, and with the "breaking"
> commit, the DT node goes unprobed which results in a failure:
>
> not ok 225 /soc/spi@...0a000/ec@...eyboard-backlight
>
> I can also solve this in a different way, by adding this driver to the
> ignore list of the test. But this solution seemed better as the DT
> isn't meant to describe devices that can be discovered at run time
> anyway.
> ---
> arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index fe5400e17b0f..20dfa18c9dda 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -1228,10 +1228,6 @@ cros_ec: ec@0 {
> spi-max-frequency = <3000000>;
> wakeup-source;
>
> - keyboard-backlight {
> - compatible = "google,cros-kbd-led-backlight";
> - };
> -
> i2c_tunnel: i2c-tunnel {
> compatible = "google,cros-ec-i2c-tunnel";
> google,remote-bus = <0>;
>
> ---
> base-commit: 91e3b24eb7d297d9d99030800ed96944b8652eaf
> change-id: 20240715-cros-backlight-dt-probe-7754a832ad60
>
> Best regards,
Powered by blists - more mailing lists