On 6.06.2023 17:31, Liviu Dudau wrote:
On Tue, Jun 06, 2023 at 08:24:48AM +0300, Arınç ÜNAL wrote:
On 6.06.2023 00:01, Liviu Dudau wrote:
On Mon, Jun 05, 2023 at 07:35:44PM +0300, Arınç ÜNAL wrote:
On 5.06.2023 18:01, Liviu Dudau wrote:
This WiFi AP is based on a MT7621 SoC with 128MiB RAM, 128MiB NAND,
a MT7603 2.4GHz WiFi and a MT7613 5GHz WiFi chips integrated on the board,
connected to the main SoC over PCIe.
The device uses NMBM over NAND, which is not currently supported in the
mainline, so NAND node is skipped in this revision.
Signed-off-by: Liviu Dudau <liviu@xxxxxxxxxxx>
---
arch/mips/boot/dts/ralink/Makefile | 3 +-
.../dts/ralink/mt7621-tplink-hc220-g5-v1.dts | 92 +++++++++++++++++++
2 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/boot/dts/ralink/mt7621-tplink-hc220-g5-v1.dts
diff --git a/arch/mips/boot/dts/ralink/Makefile b/arch/mips/boot/dts/ralink/Makefile
index 11732b8c8163a..d27d7e8c700fe 100644
--- a/arch/mips/boot/dts/ralink/Makefile
+++ b/arch/mips/boot/dts/ralink/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_DTB_VOCORE2) += vocore2.dtb
dtb-$(CONFIG_SOC_MT7621) += \
mt7621-gnubee-gb-pc1.dtb \
- mt7621-gnubee-gb-pc2.dtb
+ mt7621-gnubee-gb-pc2.dtb \
+ mt7621-tplink-hc220-g5-v1.dtb
obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/ralink/mt7621-tplink-hc220-g5-v1.dts b/arch/mips/boot/dts/ralink/mt7621-tplink-hc220-g5-v1.dts
new file mode 100644
index 0000000000000..859aaa1c1bc2b
--- /dev/null
+++ b/arch/mips/boot/dts/ralink/mt7621-tplink-hc220-g5-v1.dts
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ compatible = "tplink,hc220-g5-v1", "mediatek,mt7621-soc";
+ model = "TP-Link HC220 G5 v1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
Please use 8 digit addressing for the memory start and size offsets:
0x00000000 0x08000000
Will do.
+ };
+
+ chosen {
+ bootargs = "earlycon console=ttyS0,115200";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-reset {
+ label = "reset";
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_RESTART>;
+ };
+
+ key-wps {
+ label = "wps";
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_WPS_BUTTON>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ red {
Usually the led name would point to the component the LED is used for.
These are "generic" LEDs controlled from the userspace. The original firmware
uses GREEN for normal operations, RED for faults and BLUE for when WPS is
enabled. I'm not sure if there are any standard bindings that I can use here.
Looking at:
https://www.kernel.org/doc/html/latest/leds/leds-class.html#led-device-naming
You could use red:fault, green:power, and blue:wps. For node names,
led-fault, led-power, and led-wps.
Without making any changes in the device tree, because of the use of 'function' property,
I get this:
# ls -al /sys/class/leds/
drwxr-xr-x 2 root root 0 Jun 6 14:24 .
drwxr-xr-x 37 root root 0 Jan 1 1970 ..
lrwxrwxrwx 1 root root 0 Jun 6 14:24 blue:wps -> ../../devices/platform/leds/leds/blue:wps
lrwxrwxrwx 1 root root 0 Jun 6 14:24 green:power -> ../../devices/platform/leds/leds/green:power
lrwxrwxrwx 1 root root 0 Jun 6 14:24 red:fault -> ../../devices/platform/leds/leds/red:fault
May I suggest that I change only the node names and not add a label, keeping the 'function' property instead?
It seems to achieve the same result so, sure.
Arınç
