[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3331537.aV6nBDHxoP@diego>
Date: Wed, 10 Sep 2025 10:07:49 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Jonas Karlman <jonas@...boo.se>, FUKAUMI Naoki <naoki@...xa.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Yao Zi <ziyao@...root.org>,
Chukun Pan <amadeus@....edu.cn>, devicetree@...r.kernel.org,
linux-rockchip@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
Am Mittwoch, 10. September 2025, 04:43:30 Mitteleuropäische Sommerzeit schrieb FUKAUMI Naoki:
> Hi Jonas, Heiko,
>
> On 9/10/25 04:36, Jonas Karlman wrote:
> > On 9/9/2025 5:39 PM, Heiko Stübner wrote:
> >> Am Dienstag, 9. September 2025, 16:48:25 Mitteleuropäische Sommerzeit schrieb Jonas Karlman:
> >>> On 9/9/2025 2:28 PM, FUKAUMI Naoki wrote:
> >>>> Hi Jonas,
> >>>>
> >>>> On 7/27/25 23:44, Jonas Karlman wrote:
> >>>>> The Radxa E24C is a compact, high-performance network computer
> >>>>> developed by Radxa, based on the Rockchip RK3528A SoC.
> >>>>>
> >>>>> Add initial device tree for the Radxa E24C.
> >>>>>
> >>>>> Signed-off-by: Jonas Karlman <jonas@...boo.se>
> >>>>> Reviewed-by: Andrew Lunn <andrew@...n.ch>
> >>>>> ---
> >>>>> Schematics: https://dl.radxa.com/e/e24c/docs/radxa_e24c_v1200_schematic.pdf
> >>>>> ---
> >>>>> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> >>>>> .../boot/dts/rockchip/rk3528-radxa-e24c.dts | 519 ++++++++++++++++++
> >>>>> 2 files changed, 520 insertions(+)
> >>>>> create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-radxa-e24c.dts
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> >>>>> index 0662fcf00628..dc62fd5305be 100644
> >>>>> --- a/arch/arm64/boot/dts/rockchip/Makefile
> >>>>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> >>>>> @@ -92,6 +92,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-armsom-sige1.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-nanopi-zero2.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
> >>>>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e24c.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
> >>>>> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3562-evb2-v10.dtb
> >>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-radxa-e24c.dts b/arch/arm64/boot/dts/rockchip/rk3528-radxa-e24c.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..225f2b0c5339
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3528-radxa-e24c.dts
> >>>>> @@ -0,0 +1,519 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +
> >>>>> +#include <dt-bindings/input/input.h>
> >>>>> +#include <dt-bindings/leds/common.h>
> >>>>> +#include "rk3528.dtsi"
> >>>>> +
> >>>>> +/ {
> >>>>> + model = "Radxa E24C";
> >>>>> + compatible = "radxa,e24c", "rockchip,rk3528";
> >>>>> +
> >>>>> + aliases {
> >>>>> + ethernet0 = &gmac1;
> >>>>> + i2c0 = &i2c0;
> >>>>> + i2c1 = &i2c1;
> >>>>> + i2c5 = &i2c5;
> >>>>> + mmc0 = &sdhci;
> >>>>> + mmc1 = &sdmmc;
> >>>>> + rtc0 = &hym8563;
> >>>>> + rtc1 = &rk805;
> >>>>> + serial0 = &uart0;
> >>>>> + };
> >>>>> +
> >>>>> + chosen {
> >>>>> + stdout-path = "serial0:1500000n8";
> >>>>> + };
> >>>>> +
> >>>>> + adc-keys {
> >>>>> + compatible = "adc-keys";
> >>>>> + io-channels = <&saradc 0>;
> >>>>> + io-channel-names = "buttons";
> >>>>> + keyup-threshold-microvolt = <1800000>;
> >>>>> + poll-interval = <100>;
> >>>>> +
> >>>>> + button-maskrom {
> >>>>> + label = "MASKROM";
> >>>>> + linux,code = <KEY_SETUP>;
> >>>>> + press-threshold-microvolt = <0>;
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + gpio-keys {
> >>>>> + compatible = "gpio-keys";
> >>>>> + pinctrl-names = "default";
> >>>>> + pinctrl-0 = <&gpio0_a0_user>;
> >>>>> +
> >>>>> + button-user {
> >>>>> + gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
> >>>>> + label = "USER";
> >>>>> + linux,code = <BTN_1>;
> >>>>
> >>>> I prefer to assign BTN_0 to the 1st button :)
> >>>
> >>> The E20C (and other RK boards) already use BTN_1 for user button, it
> >>> only seem to be the recently added E54C that is using BTN_0.
> >>>
> >>> For consistency I suggest we keep using BTN_1 for this user button and
> >>> possible fixup E54C, if you want to use same button for all variants.
> >>
> >> Yep, that would also keep the amount of userspace-facing changes
> >> minimal.
> >
> > I mixed up e54c and e52c so my statement was not fully correct above,
> > however there is a mixed use of BTN_1 and BTN_0 for user button:
> >
> > - rk3588s-nanopi-r6c/r6s uses BTN_1, added in v6.9-rc1
> > - rk3588-friendlyelec-cm3588-nas uses BTN_1, added in v6.11-rc1
> > - rk3582-radxa-e52c uses BTN_0, added in v6.14-rc1
> > - rk3528-radxa-e20c uses BTN_1, added in v6.15-rc1
> > - rk3576-nanopi-m5 uses BTN_1, added in v6.17-rc1
> >
> > Majority seem to be using BTN_1 for a user button.
>
> If we can unify to BTN_1 even if it breaks backward compatibility, I
> wouldn't be opposed to it.
>
> (I remember a "sync with others" patch being rejected in the past, but I
> might be remembering it wrong.)
you remember correctly :-) .
Changing the reported key just for "syncing" is generally not desired.
It'd be like your "a" key reporting "z" with a new kernel version, even
if the label on the key states "z" since the beginning [0]
So any adaptation always is on a case-by-case basis.
My hunch right now is that we might be able to adapt the button
on that rk3582 board, because I assume due to the lottery soc
(disabled cores and/or disabled gpu/...) it might not be overly
spread out in the wild?
[0] https://xkcd.com/1172/ ;-)
Powered by blists - more mailing lists