| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2DB98035A3401FCC+ed53497a-f817-422b-a1fc-16f72d166032@radxa.com>
Date: Wed, 10 Sep 2025 18:50:14 +0900
From: FUKAUMI Naoki <naoki@...xa.com>
To: Heiko Stübner <heiko@...ech.de>,
Jonas Karlman <jonas@...boo.se>
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
Hi Heiko,
On 9/10/25 17:07, Heiko Stübner wrote:
> 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?
Since the E52C is a "network computer," it may be in greater demand than
other RK3582 boards with HDMI. (This is just my guess, and I don't know
the exact number.)
However, I support changing the E52C's User button to BTN_1.
Similarly, I think it would be better to align the "Maskrom" button with
KEY_SETUP instead of KEY_VENDOR. Only rk3582-radxa-e52c.dts and
rk3588s-nanopi-r6.dtsi use KEY_VENDOR.
The latter may have a relatively large user base, but how many people
actually use the Maskrom button in Linux userland?
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> [0] https://xkcd.com/1172/ ;-)
>
>
>
>
>
Powered by blists - more mailing lists