Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C

["Heiko Stübner" <heiko@sntech.de>]

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@kwiboo.se>
> >>>>> Reviewed-by: Andrew Lunn <andrew@lunn.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/ ;-)