* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 14:44 ` [PATCH 3/3] arm64: dts: " Jonas Karlman
@ 2025-07-27 16:15 ` Andrew Lunn
2025-07-27 16:26 ` Jonas Karlman
2025-07-28 12:50 ` Chukun Pan
` (2 subsequent siblings)
3 siblings, 1 reply; 24+ messages in thread
From: Andrew Lunn @ 2025-07-27 16:15 UTC (permalink / raw)
To: Jonas Karlman
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
> +&gmac1 {
> + clock_in_out = "output";
> + phy-mode = "rgmii-id";
> + phy-supply = <&avdd_rtl8367rb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
> + status = "okay";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
A fixed-link without an obvious reason gets me asking questions...
The schematic indicates there is a realtek 6387 switch on the other
end. rtl8365mb.c seems to support this. Is there a reason you did not
include this now?
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 16:15 ` Andrew Lunn
@ 2025-07-27 16:26 ` Jonas Karlman
2025-07-27 16:44 ` Andrew Lunn
0 siblings, 1 reply; 24+ messages in thread
From: Jonas Karlman @ 2025-07-27 16:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
Hi Andrew,
On 7/27/2025 6:15 PM, Andrew Lunn wrote:
>> +&gmac1 {
>> + clock_in_out = "output";
>> + phy-mode = "rgmii-id";
>> + phy-supply = <&avdd_rtl8367rb>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
>> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
>> + status = "okay";
>> +
>> + fixed-link {
>> + speed = <1000>;
>> + full-duplex;
>> + };
>
> A fixed-link without an obvious reason gets me asking questions...
>
> The schematic indicates there is a realtek 6387 switch on the other
> end. rtl8365mb.c seems to support this. Is there a reason you did not
> include this now?
Sorry, this was mentioned in the cover letter, and patches to enable use
of the switch is incoming in a separate series very shortly.
"""
This also leaves out describing the RTL8367RB-VB switch as support for
the switch requires dt-binding and/or driver changes to make it work,
something that will be handled in a separate follow-up series.
"""
Basically the dt-bindings prevents describing a mdio child node, yet the
driver requires it. I have prepared a patch that relaxes the driver to
make it all work and it should be on the list shortly.
Regards,
Jonas
>
> Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 16:26 ` Jonas Karlman
@ 2025-07-27 16:44 ` Andrew Lunn
0 siblings, 0 replies; 24+ messages in thread
From: Andrew Lunn @ 2025-07-27 16:44 UTC (permalink / raw)
To: Jonas Karlman
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
On Sun, Jul 27, 2025 at 06:26:03PM +0200, Jonas Karlman wrote:
> Hi Andrew,
>
> On 7/27/2025 6:15 PM, Andrew Lunn wrote:
> >> +&gmac1 {
> >> + clock_in_out = "output";
> >> + phy-mode = "rgmii-id";
> >> + phy-supply = <&avdd_rtl8367rb>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
> >> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
> >> + status = "okay";
> >> +
> >> + fixed-link {
> >> + speed = <1000>;
> >> + full-duplex;
> >> + };
> >
> > A fixed-link without an obvious reason gets me asking questions...
> >
> > The schematic indicates there is a realtek 6387 switch on the other
> > end. rtl8365mb.c seems to support this. Is there a reason you did not
> > include this now?
>
> Sorry, this was mentioned in the cover letter, and patches to enable use
> of the switch is incoming in a separate series very shortly.
>
> """
> This also leaves out describing the RTL8367RB-VB switch as support for
> the switch requires dt-binding and/or driver changes to make it work,
> something that will be handled in a separate follow-up series.
> """
Ah, sorry, missed that.
Please Cc: me when you post these patches.
For the gmac1 node only:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
It is nice to see the correct phy-mode being used.
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 14:44 ` [PATCH 3/3] arm64: dts: " Jonas Karlman
2025-07-27 16:15 ` Andrew Lunn
@ 2025-07-28 12:50 ` Chukun Pan
2025-07-28 17:09 ` Jonas Karlman
2025-08-15 4:46 ` FUKAUMI Naoki
2025-09-09 12:28 ` FUKAUMI Naoki
3 siblings, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-07-28 12:50 UTC (permalink / raw)
To: jonas
Cc: amadeus, conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, robh, ziyao
Hi,
> + avddl_1v1: avddh_3v3: avdd_rtl8367rb: regulator-avdd-rtl8367rb {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_8367_en>;
> + regulator-name = "avdd_rtl8367rb";
I don't see the avdd_rtl8367rb regulator in the schematics. It looks like
DVDDIO (RTL8367RB power) is connected to AVDDH_3V3 via a magnetic bead.
> +&gmac1 {
> + clock_in_out = "output";
> + phy-mode = "rgmii-id";
> + phy-supply = <&avdd_rtl8367rb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
Should the pinctrl of gmac1_rstn_l be written together with the
reset-gpios of the rtl8367rb switch?
```
reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&gmac1_rstn_l>;
```
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0m0_xfer>;
> + status = "okay";
> +
> + rk805: pmic@18 {
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "rk805-clkout1", "rk805-clkout2";
The clkout pin is not connected, but the dt-bindings require it.
Maybe clock-output-names could be made optional?
+&mdio1 {
+ reset-delay-us = <25000>;
+ reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+ reset-post-delay-us = <100000>;
+};
I don't think this is correct, reset-gpios should be written on the
rtl8365mb switch node. The switch driver has defined the reset time.
```
&mdio1 {
switch@29 {
compatible = "realtek,rtl8365mb";
reg = <29>;
reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
```
Thanks,
Chukun
--
2.25.1
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-28 12:50 ` Chukun Pan
@ 2025-07-28 17:09 ` Jonas Karlman
2025-07-29 13:20 ` Chukun Pan
0 siblings, 1 reply; 24+ messages in thread
From: Jonas Karlman @ 2025-07-28 17:09 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, robh, ziyao
Hi Chukun,
On 7/28/2025 2:50 PM, Chukun Pan wrote:
> Hi,
>
>> + avddl_1v1: avddh_3v3: avdd_rtl8367rb: regulator-avdd-rtl8367rb {
>> + compatible = "regulator-fixed";
>> + enable-active-high;
>> + gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gpio_8367_en>;
>> + regulator-name = "avdd_rtl8367rb";
>
> I don't see the avdd_rtl8367rb regulator in the schematics. It looks like
> DVDDIO (RTL8367RB power) is connected to AVDDH_3V3 via a magnetic bead.
Both avddl_1v1 and avddh_3v3 are controlled by the same gpio, I do not
remember if using two regulators with same gpios is supported, can only
remember it being an issue in the past, so I opted to just describe it
as a single regulator and gave it a new name and added labels for the
name used in schematic.
Would calling it vdd_8367 (after gpio_8367_en) be better or do you have
any other suggestion on how to describe these?
I will at least add a comment related to this regulator for v2.
>
>> +&gmac1 {
>> + clock_in_out = "output";
>> + phy-mode = "rgmii-id";
>> + phy-supply = <&avdd_rtl8367rb>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
>> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
>
> Should the pinctrl of gmac1_rstn_l be written together with the
> reset-gpios of the rtl8367rb switch?
When defining pinctrl to the mdio1 node they are not applied, and there
was issues probing the switch when using reset-gpios of the switch.
So I opted to describe the switch reset as the mdio bus reset.
I guess we should describe the HW and not work around SW issues, will
change in v2.
>
> ```
> reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> pinctrl-0 = <&gmac1_rstn_l>;
> ```
>
>> +&i2c0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c0m0_xfer>;
>> + status = "okay";
>> +
>> + rk805: pmic@18 {
>> + compatible = "rockchip,rk805";
>> + reg = <0x18>;
>> + interrupt-parent = <&gpio4>;
>> + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>;
>> + #clock-cells = <1>;
>> + clock-output-names = "rk805-clkout1", "rk805-clkout2";
>
> The clkout pin is not connected, but the dt-bindings require it.
> Maybe clock-output-names could be made optional?
Seem the using just #clock-cells = <0> is valid without
clock-output-names, will use that in v2, thanks.
>
> +&mdio1 {
> + reset-delay-us = <25000>;
> + reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> + reset-post-delay-us = <100000>;
> +};
>
> I don't think this is correct, reset-gpios should be written on the
> rtl8365mb switch node. The switch driver has defined the reset time.
See above, I had issues using the reset-gpios of the switch, because the
switch was probed twice, once deferred by gmac, and by the second probe
failed with -BUSY because of the reset-gpios still being claimd by the
first probe.
I can change to describe the reset pin in the switch, however that will
likely mean Ethernet is unusable until the issue in devres/gpiolib is
tracked down and fixed by someone.
>
> ```
> &mdio1 {
> switch@29 {
> compatible = "realtek,rtl8365mb";
> reg = <29>;
> reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> ```
As mentioned above, this caused probe issues and an unusable switch.
I would rather skip describing this reset pin as it does not seem to be
needed it self reset when the regulator is powered on.
Any thoughts on what is better of the two? Skip describing the reset pin
or describe it and leave the switch possible unusable? Probing gmac
before the switch should leave it in a working state.
Regards,
Jonas
>
> Thanks,
> Chukun
>
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-28 17:09 ` Jonas Karlman
@ 2025-07-29 13:20 ` Chukun Pan
2025-07-29 21:15 ` Jonas Karlman
0 siblings, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-07-29 13:20 UTC (permalink / raw)
To: jonas
Cc: amadeus, conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, ziyao
Hi,
> Both avddl_1v1 and avddh_3v3 are controlled by the same gpio, I do not
> remember if using two regulators with same gpios is supported, can only
> remember it being an issue in the past, so I opted to just describe it
> as a single regulator and gave it a new name and added labels for the
> name used in schematic.
>
> Would calling it vdd_8367 (after gpio_8367_en) be better or do you have
> any other suggestion on how to describe these?
Would it be better to just call it avddh_3v3 and add a comment?
This makes it easier to find in the schematics and match phy-supply.
> See above, I had issues using the reset-gpios of the switch, because the
> switch was probed twice, once deferred by gmac, and by the second probe
> failed with -BUSY because of the reset-gpios still being claimd by the
> first probe.
>
> I can change to describe the reset pin in the switch, however that will
> likely mean Ethernet is unusable until the issue in devres/gpiolib is
> tracked down and fixed by someone.
I don't think it's a devres/gpiolib issue.
It looks like these two resets are competing:
priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
reset-gpios works if reset-names is specified:
- priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
+ priv->reset_ctl = devm_reset_control_get_optional(dev, "switch");
Or just remove the reset controller, I'm not sure if it's really needed:
- priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
- if (IS_ERR(priv->reset_ctl))
- return dev_err_cast_probe(dev, priv->reset_ctl,
- "failed to get reset control\n");
Thanks,
Chukun
--
2.25.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-29 13:20 ` Chukun Pan
@ 2025-07-29 21:15 ` Jonas Karlman
0 siblings, 0 replies; 24+ messages in thread
From: Jonas Karlman @ 2025-07-29 21:15 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, ziyao
On 7/29/2025 3:20 PM, Chukun Pan wrote:
> Hi,
>
>> Both avddl_1v1 and avddh_3v3 are controlled by the same gpio, I do not
>> remember if using two regulators with same gpios is supported, can only
>> remember it being an issue in the past, so I opted to just describe it
>> as a single regulator and gave it a new name and added labels for the
>> name used in schematic.
>>
>> Would calling it vdd_8367 (after gpio_8367_en) be better or do you have
>> any other suggestion on how to describe these?
>
> Would it be better to just call it avddh_3v3 and add a comment?
> This makes it easier to find in the schematics and match phy-supply.
It already had a label for avddh_3v3, I am currently thinking something
like following, includes the names from schematic and a name for humans:
/* Common enable line for the avdd rails mentioned in the labels */
vdd_switch: avddl_1v1: avddh_3v3: regulator-vdd-switch {
compatible = "regulator-fixed";
enable-active-high;
gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&gpio_8367_en>;
regulator-name = "vdd_switch";
startup-delay-us = <10000>;
vin-supply = <&vcc5v0_sys>;
};
>
>> See above, I had issues using the reset-gpios of the switch, because the
>> switch was probed twice, once deferred by gmac, and by the second probe
>> failed with -BUSY because of the reset-gpios still being claimd by the
>> first probe.
>>
>> I can change to describe the reset pin in the switch, however that will
>> likely mean Ethernet is unusable until the issue in devres/gpiolib is
>> tracked down and fixed by someone.
>
> I don't think it's a devres/gpiolib issue.
> It looks like these two resets are competing:
>
> priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
> priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
>
> reset-gpios works if reset-names is specified:
>
> - priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
> + priv->reset_ctl = devm_reset_control_get_optional(dev, "switch");
>
> Or just remove the reset controller, I'm not sure if it's really needed:
>
> - priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
> - if (IS_ERR(priv->reset_ctl))
> - return dev_err_cast_probe(dev, priv->reset_ctl,
> - "failed to get reset control\n");
Very interesting, my initial testing was to include a call to
devm_gpiod_put() in rtl83xx_remove() but was afraid it could result in a
WARN_ON in case driver was properly unloaded/removed.
void rtl83xx_remove(struct realtek_priv *priv)
{
if (priv->reset)
devm_gpiod_put(priv-dev, priv->reset);
}
With reset_control_get using a gpio fallback, this complicates things a
little bit, will run some more tests and probably include a driver patch
for v2, thanks for finding this!
Regards,
Jonas
>
> Thanks,
> Chukun
>
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 14:44 ` [PATCH 3/3] arm64: dts: " Jonas Karlman
2025-07-27 16:15 ` Andrew Lunn
2025-07-28 12:50 ` Chukun Pan
@ 2025-08-15 4:46 ` FUKAUMI Naoki
2025-08-15 10:01 ` Chukun Pan
2025-09-09 12:28 ` FUKAUMI Naoki
3 siblings, 1 reply; 24+ messages in thread
From: FUKAUMI Naoki @ 2025-08-15 4:46 UTC (permalink / raw)
To: Jonas Karlman, Heiko Stuebner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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>;
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "on";
> + function = LED_FUNCTION_HEARTBEAT;
> + gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
> + label = "SYS";
"label" is deprecated. "color" and "function" should be enough to
explain what they are.
(Personally, I prefer LED_FUNCTION_STATUS to LED_FUNCTION_HEARTBEAT)
> + linux,default-trigger = "heartbeat";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sys_led_g>;
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_WAN;
> + gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_HIGH>;
> + label = "WAN";
Ditto.
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wan_led_g>;
> + };
> +
> + led-2 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_HIGH>;
> + label = "LAN1";
Ditto.
You can use the following instead:
function-enumerator = <1>;
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan1_led_g>;
> + };
> +
> + led-3 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB1 GPIO_ACTIVE_HIGH>;
> + label = "LAN2";
function-enumerator = <2>;
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan2_led_g>;
> + };
> +
> + led-4 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
> + label = "LAN3";
function-enumerator = <3>;
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan3_led_g>;
> + };
> + };
> +
> + vcc3v3_mkey: regulator-3v3-vcc-mkey {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mkey_pwr_en>;
> + regulator-name = "vcc3v3_mkey";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc5v0_sys: regulator-5v0-vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc_12v>;
> + };
> +
> + vcc5v0_usb20: regulator-5v0-vcc-usb20 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb_host_en>;
> + regulator-name = "vcc5v0_usb20";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc_12v: regulator-12v0-vcc {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + avddl_1v1: avddh_3v3: avdd_rtl8367rb: regulator-avdd-rtl8367rb {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_8367_en>;
> + regulator-name = "avdd_rtl8367rb";
> + startup-delay-us = <10000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vccio_sd: regulator-vccio-sd {
> + compatible = "regulator-gpio";
> + gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_vol_ctrl_h>;
> + regulator-name = "vccio_sd";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + states = <1800000 0x0>, <3300000 0x1>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu1 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu2 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu3 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&gmac1 {
> + clock_in_out = "output";
> + phy-mode = "rgmii-id";
> + phy-supply = <&avdd_rtl8367rb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
> + status = "okay";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_logic>;
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0m0_xfer>;
> + status = "okay";
> +
> + rk805: pmic@18 {
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "rk805-clkout1", "rk805-clkout2";
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int>;
> + system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc5v0_sys>;
> + vcc2-supply = <&vcc5v0_sys>;
> + vcc3-supply = <&vcc5v0_sys>;
> + vcc4-supply = <&vcc5v0_sys>;
> + vcc5-supply = <&vcc5v0_sys>;
> + vcc6-supply = <&vcc5v0_sys>;
> +
> + regulators {
> + vdd_arm: DCDC_REG1 {
> + regulator-name = "vdd_arm";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-ramp-delay = <12500>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vdd_logic: DCDC_REG2 {
> + regulator-name = "vdd_logic";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-ramp-delay = <12500>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_3v3: DCDC_REG4 {
> + regulator-name = "vcc_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_1v8: LDO_REG1 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc1v8_emmc: LDO_REG2 {
> + regulator-name = "vcc1v8_emmc";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vdd_0v9_p: LDO_REG3 {
> + regulator-name = "vdd_0v9_p";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> + };
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m0_xfer>;
> + status = "okay";
> +
> + eeprom@50 {
> + compatible = "belling,bl24c16a", "atmel,24c16";
> + reg = <0x50>;
> + pagesize = <16>;
> + read-only;
> + vcc-supply = <&vcc_3v3>;
> + };
> +};
> +
> +&i2c5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c5m0_xfer>;
> + status = "okay";
> +
> + hym8563: rtc@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rtc_int_l>;
> + wakeup-source;
> + };
> +};
> +
> +&mdio1 {
> + reset-delay-us = <25000>;
> + reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> + reset-post-delay-us = <100000>;
> +};
> +
> +&pinctrl {
> + ethernet {
> + gmac1_rstn_l: gmac1-rstn-l {
> + rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + gpio_8367_en: gpio-8367-en {
> + rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + rtl8367rb_eint: rtl8367rb-eint {
> + rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + gpio-keys {
> + gpio0_a0_user: gpio0-a0-user {
> + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + lan1_led_g: lan1-led-g {
> + rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + lan2_led_g: lan2-led-g {
> + rockchip,pins = <1 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + lan3_led_g: lan3-led-g {
> + rockchip,pins = <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + sys_led_g: sys-led-g {
> + rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + wan_led_g: wan-led-g {
> + rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pcie {
> + mkey_pwr_en: mkey-pwr-en {
> + rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int: pmic-int {
> + rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + rtc {
> + rtc_int_l: rtc-int-l {
> + rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + sdmmc {
> + sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
> + rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb {
> + usb_host_en: usb-host-en {
> + rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&saradc {
> + vref-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> + no-sd;
> + no-sdio;
> + non-removable;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vcc1v8_emmc>;
> + status = "fail";
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + disable-wp;
> + sd-uhs-sdr104;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vccio_sd>;
> + status = "okay";
> +};
> +
> +&sfc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&fspi_csn0>, <&fspi_pins>;
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <1>;
> + vcc-supply = <&vcc1v8_emmc>;
> + };
> +};
> +
> +&u2phy {
> + status = "okay";
> +};
> +
> +&u2phy_host {
> + phy-supply = <&vcc5v0_usb20>;
> + status = "okay";
> +};
> +
> +&u2phy_otg {
> + status = "okay";
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0m0_xfer>;
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_xhci {
> + extcon = <&u2phy>;
> + maximum-speed = "high-speed";
> + phys = <&u2phy_otg>;
> + phy-names = "usb2-phy";
> + status = "okay";
> +};
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-08-15 4:46 ` FUKAUMI Naoki
@ 2025-08-15 10:01 ` Chukun Pan
2025-08-18 6:17 ` FUKAUMI Naoki
0 siblings, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-08-15 10:01 UTC (permalink / raw)
To: naoki
Cc: amadeus, conor+dt, devicetree, heiko, jonas, krzk+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, robh, ziyao
Hi,
> "label" is deprecated. "color" and "function" should be enough to
> explain what they are.
>
> (Personally, I prefer LED_FUNCTION_STATUS to LED_FUNCTION_HEARTBEAT)
BTW, will there be versions of Radxa E24C and Radxa E54C with
onboard eMMC? It seems that they are all onboard SPI instead
of eMMC. If there is no onboard eMMC version, we can remove
the sdhci node in dts.
Thanks,
Chukun
--
2.25.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-08-15 10:01 ` Chukun Pan
@ 2025-08-18 6:17 ` FUKAUMI Naoki
0 siblings, 0 replies; 24+ messages in thread
From: FUKAUMI Naoki @ 2025-08-18 6:17 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, jonas, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, robh, ziyao
Hi Chukun,
On 8/15/25 19:01, Chukun Pan wrote:
> Hi,
>
>> "label" is deprecated. "color" and "function" should be enough to
>> explain what they are.
>>
>> (Personally, I prefer LED_FUNCTION_STATUS to LED_FUNCTION_HEARTBEAT)
>
> BTW, will there be versions of Radxa E24C and Radxa E54C with
> onboard eMMC? It seems that they are all onboard SPI instead
> of eMMC. If there is no onboard eMMC version, we can remove
> the sdhci node in dts.
Although optional, there are also E24C/E54C versions with eMMC.
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> Thanks,
> Chukun
>
> --
> 2.25.1
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-07-27 14:44 ` [PATCH 3/3] arm64: dts: " Jonas Karlman
` (2 preceding siblings ...)
2025-08-15 4:46 ` FUKAUMI Naoki
@ 2025-09-09 12:28 ` FUKAUMI Naoki
2025-09-09 14:48 ` Jonas Karlman
3 siblings, 1 reply; 24+ messages in thread
From: FUKAUMI Naoki @ 2025-09-09 12:28 UTC (permalink / raw)
To: Jonas Karlman, Heiko Stuebner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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 :)
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "on";
> + function = LED_FUNCTION_HEARTBEAT;
> + gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
> + label = "SYS";
> + linux,default-trigger = "heartbeat";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sys_led_g>;
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_WAN;
> + gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_HIGH>;
> + label = "WAN";
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wan_led_g>;
> + };
> +
> + led-2 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_HIGH>;
> + label = "LAN1";
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan1_led_g>;
> + };
> +
> + led-3 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB1 GPIO_ACTIVE_HIGH>;
> + label = "LAN2";
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan2_led_g>;
> + };
> +
> + led-4 {
> + color = <LED_COLOR_ID_GREEN>;
> + default-state = "off";
> + function = LED_FUNCTION_LAN;
> + gpios = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
> + label = "LAN3";
> + linux,default-trigger = "netdev";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan3_led_g>;
> + };
> + };
> +
> + vcc3v3_mkey: regulator-3v3-vcc-mkey {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mkey_pwr_en>;
> + regulator-name = "vcc3v3_mkey";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc5v0_sys: regulator-5v0-vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc_12v>;
> + };
> +
> + vcc5v0_usb20: regulator-5v0-vcc-usb20 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb_host_en>;
> + regulator-name = "vcc5v0_usb20";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc_12v: regulator-12v0-vcc {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + avddl_1v1: avddh_3v3: avdd_rtl8367rb: regulator-avdd-rtl8367rb {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_8367_en>;
> + regulator-name = "avdd_rtl8367rb";
> + startup-delay-us = <10000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vccio_sd: regulator-vccio-sd {
> + compatible = "regulator-gpio";
> + gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_vol_ctrl_h>;
> + regulator-name = "vccio_sd";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + states = <1800000 0x0>, <3300000 0x1>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu1 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu2 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu3 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&gmac1 {
> + clock_in_out = "output";
> + phy-mode = "rgmii-id";
> + phy-supply = <&avdd_rtl8367rb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
> + <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>, <&gmac1_rstn_l>;
> + status = "okay";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_logic>;
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0m0_xfer>;
> + status = "okay";
> +
> + rk805: pmic@18 {
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "rk805-clkout1", "rk805-clkout2";
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int>;
> + system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc5v0_sys>;
> + vcc2-supply = <&vcc5v0_sys>;
> + vcc3-supply = <&vcc5v0_sys>;
> + vcc4-supply = <&vcc5v0_sys>;
> + vcc5-supply = <&vcc5v0_sys>;
> + vcc6-supply = <&vcc5v0_sys>;
> +
> + regulators {
> + vdd_arm: DCDC_REG1 {
> + regulator-name = "vdd_arm";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-ramp-delay = <12500>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vdd_logic: DCDC_REG2 {
> + regulator-name = "vdd_logic";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-ramp-delay = <12500>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_3v3: DCDC_REG4 {
> + regulator-name = "vcc_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_1v8: LDO_REG1 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc1v8_emmc: LDO_REG2 {
> + regulator-name = "vcc1v8_emmc";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vdd_0v9_p: LDO_REG3 {
> + regulator-name = "vdd_0v9_p";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> + };
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m0_xfer>;
> + status = "okay";
> +
> + eeprom@50 {
> + compatible = "belling,bl24c16a", "atmel,24c16";
> + reg = <0x50>;
> + pagesize = <16>;
> + read-only;
> + vcc-supply = <&vcc_3v3>;
> + };
> +};
> +
> +&i2c5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c5m0_xfer>;
> + status = "okay";
> +
> + hym8563: rtc@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rtc_int_l>;
> + wakeup-source;
> + };
> +};
> +
> +&mdio1 {
> + reset-delay-us = <25000>;
> + reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
> + reset-post-delay-us = <100000>;
> +};
> +
> +&pinctrl {
> + ethernet {
> + gmac1_rstn_l: gmac1-rstn-l {
> + rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + gpio_8367_en: gpio-8367-en {
> + rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + rtl8367rb_eint: rtl8367rb-eint {
> + rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + gpio-keys {
> + gpio0_a0_user: gpio0-a0-user {
> + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + lan1_led_g: lan1-led-g {
> + rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + lan2_led_g: lan2-led-g {
> + rockchip,pins = <1 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + lan3_led_g: lan3-led-g {
> + rockchip,pins = <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + sys_led_g: sys-led-g {
> + rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + wan_led_g: wan-led-g {
> + rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pcie {
> + mkey_pwr_en: mkey-pwr-en {
> + rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int: pmic-int {
> + rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + rtc {
> + rtc_int_l: rtc-int-l {
> + rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + sdmmc {
> + sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
> + rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb {
> + usb_host_en: usb-host-en {
> + rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&saradc {
> + vref-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> + no-sd;
> + no-sdio;
> + non-removable;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vcc1v8_emmc>;
> + status = "fail";
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + disable-wp;
> + sd-uhs-sdr104;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vccio_sd>;
> + status = "okay";
> +};
> +
> +&sfc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&fspi_csn0>, <&fspi_pins>;
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <1>;
> + vcc-supply = <&vcc1v8_emmc>;
> + };
> +};
> +
> +&u2phy {
> + status = "okay";
> +};
> +
> +&u2phy_host {
> + phy-supply = <&vcc5v0_usb20>;
> + status = "okay";
> +};
> +
> +&u2phy_otg {
> + status = "okay";
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0m0_xfer>;
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_xhci {
> + extcon = <&u2phy>;
> + maximum-speed = "high-speed";
> + phys = <&u2phy_otg>;
> + phy-names = "usb2-phy";
> + status = "okay";
> +};
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-09 12:28 ` FUKAUMI Naoki
@ 2025-09-09 14:48 ` Jonas Karlman
2025-09-09 15:39 ` Heiko Stübner
0 siblings, 1 reply; 24+ messages in thread
From: Jonas Karlman @ 2025-09-09 14:48 UTC (permalink / raw)
To: FUKAUMI Naoki
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yao Zi, Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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.
Regards,
Jonas
>
> Best regards,
>
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
>
>> + wakeup-source;
>> + };
>> + };
[snip]
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-09 14:48 ` Jonas Karlman
@ 2025-09-09 15:39 ` Heiko Stübner
2025-09-09 19:36 ` Jonas Karlman
0 siblings, 1 reply; 24+ messages in thread
From: Heiko Stübner @ 2025-09-09 15:39 UTC (permalink / raw)
To: FUKAUMI Naoki, Jonas Karlman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yao Zi,
Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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.
Heiko
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-09 15:39 ` Heiko Stübner
@ 2025-09-09 19:36 ` Jonas Karlman
2025-09-10 2:43 ` FUKAUMI Naoki
0 siblings, 1 reply; 24+ messages in thread
From: Jonas Karlman @ 2025-09-09 19:36 UTC (permalink / raw)
To: Heiko Stübner, FUKAUMI Naoki
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yao Zi,
Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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.
Regards,
Jonas
>
> Heiko
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-09 19:36 ` Jonas Karlman
@ 2025-09-10 2:43 ` FUKAUMI Naoki
2025-09-10 8:07 ` Heiko Stübner
0 siblings, 1 reply; 24+ messages in thread
From: FUKAUMI Naoki @ 2025-09-10 2:43 UTC (permalink / raw)
To: Jonas Karlman, Heiko Stübner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yao Zi,
Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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.)
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> Regards,
> Jonas
>
>>
>> Heiko
>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-10 2:43 ` FUKAUMI Naoki
@ 2025-09-10 8:07 ` Heiko Stübner
2025-09-10 9:50 ` FUKAUMI Naoki
0 siblings, 1 reply; 24+ messages in thread
From: Heiko Stübner @ 2025-09-10 8:07 UTC (permalink / raw)
To: Jonas Karlman, FUKAUMI Naoki
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yao Zi,
Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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/ ;-)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/3] arm64: dts: rockchip: Add Radxa E24C
2025-09-10 8:07 ` Heiko Stübner
@ 2025-09-10 9:50 ` FUKAUMI Naoki
0 siblings, 0 replies; 24+ messages in thread
From: FUKAUMI Naoki @ 2025-09-10 9:50 UTC (permalink / raw)
To: Heiko Stübner, Jonas Karlman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yao Zi,
Chukun Pan, devicetree, linux-rockchip, linux-arm-kernel,
linux-kernel
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@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?
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/ ;-)
>
>
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread