Re: Question about ancient TARGET_CFLAGS in rules.mk?
On Sat, Jul 16, 2022 at 4:52 PM Ansuel Smith wrote: > > Hi, > some background about this. > > I'm trying to improve our CI system more and more by finally adding > support for real > EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI > to make sure everything works and all compiles correctly... > > While testing it I notice a specific target fails to compile ubox package. > While still to investigate why this is only present on that target, i > found out why > this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build. > > The error is this > > kmodloader.c: In function 'main_loader': > 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf' > declared with attribute 'warn_unused_result' [-Werror=unused-result] > 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] Error 1 > 1341 1027 | asprintf(>opts, "%s %s", prev, opts); > 1342 | ^~~ > 1343cc1: all warnings being treated as errors > > The package is compiled with -Wall so it does make sense that the > error is printed... > > Fact is that the error(warning) is actually correct but I couldn't > understand why it was > not flagged on normal build and here the reason... > > In rules.mk we have > TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable > -Wno-error=unused-result > and this is only applied if EXTERNAL_TOOLCHAIN is not selected... > > Now the question... WHY? > > Considering even the linux kernel started to use Wall by default, > should we also start > enforcing correct code and fix every package that present such error? Yes > Fixing these kind of error is trivial enough and IMHO we should drop these > warning disable. I've had issues getting stuff merged to core openwrt utilities in the past, especially when it comes to fixing compilation warnings. > > I will create a PR in the next few days but wonder if anyone wants to > give some feedback > about why these extra flags are set. To me it seems they are just > leftover from older times? Most likely. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFT 0/5] realtek: support boards similar to DGS-1210-10
> On Tue, 2021-10-05 at 22:40 +0300, Paul Fertser wrote: > > I only have D-Link DGS-1210-10P R1 for testing but other devices should be > > very > > similar judging by the photos. Would be nice to share support for all the > > features available rather than get just R1 fully working. > > > > Paul Fertser (5): > > realtek: split DGS-1210-10P DTS > > realtek: add all LEDs, buttons and SFP signals to DGS-1210-10 > > realtek: add non-PoE version of DGS-1210-10 F1 > > realtek: support D-Link DGS-1210-10P H/W:R1 > > realtek: support Trendnet TPE-082WS V1 > > Recently you two have provided some patches for the DGS-1210 switches, and you > apear to have a nice collection of different devices. I would like to draw > your > attention to these (old) patches, with some improvments Paul suggested. Sadly > nobody showed up to test them at the time. I was wondering if these changes > are > still relevant and if you could have a look at them. I didn't have any DGS-1210 switches back then. Now I have hundreds. It looks like an interesting submission, still relevant but it requires a v2 rebasing and with the suggested changes. It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use rtl8382 (except for the pending -52 variant). The commit didn't mention why that happened. I'm not sure which one is correct here. However, if it is really a different SoC and with what we currently know, we could create a generic rtl83xx_d-link_dgs-1210.dtsi as the -52 variant uses even a more different SoC (rtl8393). They share a lot of stuff like flash layout and gpios (and the vendor firmware even uses the same image). I could do some generic and family review but I only have -28 and -52 variants. > The different patches can be found at, and downloaded from: > https://patchwork.ozlabs.org/project/openwrt/list/?series=265587=* > > In case you weren't subscribed to the mailing list at the time and you would > like to reply to one of the patches, they can be downloaded from patchwork in > mbox format and imported into a mail client. > > Best, > Sander Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Question about ancient TARGET_CFLAGS in rules.mk?
Hi, some background about this. I'm trying to improve our CI system more and more by finally adding support for real EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI to make sure everything works and all compiles correctly... While testing it I notice a specific target fails to compile ubox package. While still to investigate why this is only present on that target, i found out why this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build. The error is this kmodloader.c: In function 'main_loader': 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf' declared with attribute 'warn_unused_result' [-Werror=unused-result] 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] Error 1 1341 1027 | asprintf(>opts, "%s %s", prev, opts); 1342 | ^~~ 1343cc1: all warnings being treated as errors The package is compiled with -Wall so it does make sense that the error is printed... Fact is that the error(warning) is actually correct but I couldn't understand why it was not flagged on normal build and here the reason... In rules.mk we have TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result and this is only applied if EXTERNAL_TOOLCHAIN is not selected... Now the question... WHY? Considering even the linux kernel started to use Wall by default, should we also start enforcing correct code and fix every package that present such error? Fixing these kind of error is trivial enough and IMHO we should drop these warning disable. I will create a PR in the next few days but wonder if anyone wants to give some feedback about why these extra flags are set. To me it seems they are just leftover from older times? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/7] realtek: MFD for switch core
Hi, On 7/16/22 21:31, Sander Vanheule wrote: On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote: This RFC series introduces a new MFD device for the switch core found in the Realtek SoCs. Currently only an implementation is provided for RTL8380, but it written with the register structure of other generations in mind. this looks very promising as it offers the pin control we always needed. I have not looked through the code in detail, yet. The biggest question I have at this point is that at this point the code does not include the other SoC generations. Especially when it comes to the LEDs, they are very different. In fact the RTL838x is the odd-man-out. I would really like to see how they will be included. In the past several design decision turned out to be not so optimal after we learned about the newer SoCs. Today we have all of them very well understood, so it should not be an issue to add at least some code for the RTL93xx generation, which has the LEDs modernized quite a bit. The other question I have is whether this allows us to solve the other big issue we have with these SoCs: Providing information between drivers. For example you have written the 2nd copy of the model name reading function in rtl8380_probe_model_name(), and it does not even probe the other 3 SoC generations. But this information is needed already at the very start of the boot process and several other drivers. So why not provide a global structure like on other MIPS architectures and populate it with information such as machine name and especially switch structure for other drivers to use plus all the other configuration details of a particular SoC (there are nearly 2 dozen different RTL9300 SoCs all having a different structure for the MII ports). In a very simple example, NOR access needs information about the 3/4 byte strapping pin from the switch core, but its registers live at a completely different place in the SoC. The lack of such global information is evident from e.g. your Netgear .dts. Although you know that the first used port is 8, from the fact its an RTL8382M SoC or alternatively the ports in the .dts, you need to add another time the information about port to LED number. Another point I have is more general: The pinctrl driver is a lot of code for controlling the LEDs, which are not even pins on the SoC, but controlled through a serial bus. Is this really the right type of driver? Many of the LED drivers in Linux work similarly and provide a standard interface to users. Also the LEDs are actually controlled by the RTL8231 via a serial link on many models, not the Switch Core. Placing the LED control into the switch core is a bit confusing, should there not at least be a node for the RTL8231 in the .dts reflecting the actual HW setup? Why not a small setup function for automatic HW control of all LEDs as already done for the other SoC generations and a dedicated LED driver. This might reduce code complexity and reflect the actual hardware setup. Cheers, Birger ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/7] realtek: MFD for switch core
On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote:
> This RFC series introduces a new MFD device for the switch core found
> in the Realtek SoCs. Currently only an implementation is provided for
> RTL8380, but it written with the register structure of other generations
> in mind.
>
> The MFD comes with a set of new drivers:
> - core MFD driver for global register management, sundry small
> peripherals that don't warrant a specific driver
> - pin control driver to manage different pin muxes, so we can replace
> all those pinctrl-single nodes
> - switch port LED driver with port status HW offloading
>
> The port LED support will probably be what draws most attention, as this
> is something many users have been requesting. There are two example
> implementations:
> - ZyXEL GS1900-8, with one LED per port
> - Netgear GS110TPP, with two LEDs per port
>
> If you have time, please test these patches and provide some feedback on
> the structure and implementation of the different parts. My plan is for
> this to be the starting point to (finally) start upstreaming the most
> important part of the Realtek SoCs; the ethernet switch.
>
> Best,
> Sander
>
> Sander Vanheule (7):
> kernel: backport devm_bitmap_{alloc,zalloc}
> realtek: add switch core MFD driver
> realtek: add pinctrl for Realtek maple
> realtek: add RTL8380 switch port LED driver
> realtek: rtl838x: replace pinctrl-single
> realtek: Zyxel GS1900-8: define port LEDs
> realtek: Netgear GS110TPPv1: define port LEDs
For your convenience, I've also pushed the (amended) patch series to my staging
tree:
https://git.openwrt.org/?p=openwrt/staging/svanheule.git;a=shortlog;h=refs/heads/rfc/rtl-swcore
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 3/7] realtek: add pinctrl for Realtek maple
On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote: > Adds a pin control driver for RTL838x managed gigabit switch SoCs, and > RTL833x managed fast ethernet switch SoCs, both codenamed "Maple". Only > RTL838x has been tested, but functionality should be near identical. > > Since control bits for different muxes are scattered throughout the > switch core's register space, pin control features are provided by a > table of regmap fields. This should be flexible enough to allow > extension to other SoC generations providing similar features. > > Signed-off-by: Sander Vanheule > --- > .../drivers/leds/leds-rtl-switch-port.c | 668 ++ > ...inctrl-add-pinctrl-for-Realtek-maple.patch | 51 ++ > target/linux/realtek/rtl838x/config-5.10 | 1 + > 3 files changed, 720 insertions(+) > create mode 100644 target/linux/realtek/files-5.10/drivers/leds/leds-rtl- > switch-port.c > create mode 100644 target/linux/realtek/patches-5.10/201-pinctrl-add-pinctrl- > for-Realtek-maple.patch It appears I have mixed up the contents and description of the pinctrl and leds patches. The end result of applying both will be the same, but applying only the first won't work. Sorry the trouble. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 7/7] realtek: Netgear GS110TPPv1: define port LEDs
Add the port LEDs for lan1-lan8 to the device tree for the GS110TPP v1.
To reproduce the same behaviour as stock firmware, green should be
LINK/ACT 1G, and amber should be LINK/ACT 100M/10M:
for i in $(seq 1 8); do
echo 13 > /sys/class/leds/green:lan-$i/rtl_hw_trigger
echo realtek-switchport > /sys/class/leds/green:lan-$i/trigger
echo f > /sys/class/leds/amber:lan-$i/rtl_hw_trigger
echo realtek-switchport > /sys/class/leds/amber:lan-$i/trigger
done
Signed-off-by: Sander Vanheule
---
.../dts-5.10/rtl8380_netgear_gs110tpp-v1.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gs110tpp-v1.dts
b/target/linux/realtek/dts-5.10/rtl8380_netgear_gs110tpp-v1.dts
index 1ff209cee363..897699bea2c3 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gs110tpp-v1.dts
+++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gs110tpp-v1.dts
@@ -43,3 +43,33 @@
{
status = "okay";
};
+
+#define LAN_LED_LABEL(p, n)STRINGIZE(p ## n)
+#define LED_LABEL_GREEN(p) LAN_LED_LABEL(green:lan-, p)
+#define LED_LABEL_AMBER(p) LAN_LED_LABEL(amber:lan-, p)
+#define NETGEAR_LED(_phy, _port) \
+ led@ ## _phy ##.0 { \
+ reg = < _phy 0 >; \
+ label = LED_LABEL_GREEN(_port) ;\
+ }; \
+ led@ ## _phy ## .1 {\
+ reg = < _phy 1 >; \
+ label = LED_LABEL_AMBER(_port) ;\
+ }
+
+ {
+ port-leds {
+ compatible = "realtek,rtl8380-port-led";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ NETGEAR_LED(8,1);
+ NETGEAR_LED(9,2);
+ NETGEAR_LED(10,3);
+ NETGEAR_LED(11,4);
+ NETGEAR_LED(12,5);
+ NETGEAR_LED(13,6);
+ NETGEAR_LED(14,7);
+ NETGEAR_LED(15,8);
+ };
+};
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 5/7] realtek: rtl838x: replace pinctrl-single
Replace the pinctrl-single node with the dedicated pinctrl driver for
RTL838x SoCs. The node names are kept to stay compatible with existing
references.
Signed-off-by: Sander Vanheule
---
target/linux/realtek/dts-5.10/rtl838x.dtsi | 38 ++
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/target/linux/realtek/dts-5.10/rtl838x.dtsi
b/target/linux/realtek/dts-5.10/rtl838x.dtsi
index 11cabc3f63cb..6aac2be95368 100644
--- a/target/linux/realtek/dts-5.10/rtl838x.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl838x.dtsi
@@ -169,33 +169,29 @@
};
};
- pinmux: pinmux@1b001000 {
- compatible = "pinctrl-single";
- reg = <0x1b001000 0x4>;
+ switchcore: switchcore-bus@1b00 {
+ compatible = "realtek,rtl8380-switchcore", "syscon";
+ reg = <0x1b00 0x1>;
- pinctrl-single,bit-per-mux;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x1>;
- #pinctrl-cells = <2>;
+ hw_led_sys: led-sys {
+ status = "disabled";
- enable_uart1: pinmux_enable_uart1 {
- pinctrl-single,bits = <0x0 0x10 0x10>;
+ label = "green:status";
};
- };
- /* LED_GLB_CTRL */
- pinmux_led: pinmux@1b00a000 {
- compatible = "pinctrl-single";
- reg = <0x1b00a000 0x4>;
+ pinctrl {
+ compatible = "realtek,rtl8380-pinctrl";
- pinctrl-single,bit-per-mux;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x1>;
- #pinctrl-cells = <2>;
+ /* enable GPIO 0 */
+ pinmux_disable_sys_led: sys-led-mux {
+ groups = "sys-led";
+ function = "gpio";
+ };
- /* enable GPIO 0 */
- pinmux_disable_sys_led: disable_sys_led {
- pinctrl-single,bits = <0x0 0x0 0x8000>;
+ enable_uart1: uart1-mux {
+ groups = "uart1";
+ function = "uart1";
+ };
};
};
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 3/7] realtek: add pinctrl for Realtek maple
Adds a pin control driver for RTL838x managed gigabit switch SoCs, and
RTL833x managed fast ethernet switch SoCs, both codenamed "Maple". Only
RTL838x has been tested, but functionality should be near identical.
Since control bits for different muxes are scattered throughout the
switch core's register space, pin control features are provided by a
table of regmap fields. This should be flexible enough to allow
extension to other SoC generations providing similar features.
Signed-off-by: Sander Vanheule
---
.../drivers/leds/leds-rtl-switch-port.c | 668 ++
...inctrl-add-pinctrl-for-Realtek-maple.patch | 51 ++
target/linux/realtek/rtl838x/config-5.10 | 1 +
3 files changed, 720 insertions(+)
create mode 100644
target/linux/realtek/files-5.10/drivers/leds/leds-rtl-switch-port.c
create mode 100644
target/linux/realtek/patches-5.10/201-pinctrl-add-pinctrl-for-Realtek-maple.patch
diff --git
a/target/linux/realtek/files-5.10/drivers/leds/leds-rtl-switch-port.c
b/target/linux/realtek/files-5.10/drivers/leds/leds-rtl-switch-port.c
new file mode 100644
index ..76dfede7ba15
--- /dev/null
+++ b/target/linux/realtek/files-5.10/drivers/leds/leds-rtl-switch-port.c
@@ -0,0 +1,668 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Realtek switch port LED
+ *
+ * The switch ASIC can control up to three LEDs per phy, based on a number of
+ * matching conditions. Alternatively, each individual LED output can also be
+ * configured for manual control.
+ */
+#define PTRG_NONE 0
+#define PTRG_ACT_RXBIT(0)
+#define PTRG_ACT_TXBIT(1)
+#define PTRG_ACT PTRG_ACT_RX | PTRG_ACT_TX
+#define PTRG_LINK_10 BIT(2)
+#define PTRG_LINK_100 BIT(3)
+#define PTRG_LINK_1000 BIT(4)
+
+struct led_port_blink_mode {
+ u16 interval; /* Toggle interval in ms */
+ u8 mode; /* ASIC mode bits */
+};
+
+#define REALTEK_PORT_LED_BLINK_COUNT 6
+struct led_port_modes {
+ u8 off;
+ u8 on;
+ struct led_port_blink_mode blink[REALTEK_PORT_LED_BLINK_COUNT];
+};
+
+struct led_port_group {
+ struct regmap_field *setting;
+ unsigned int size;
+ /* bitmap to keep track of associated ports */
+ unsigned long *ports;
+};
+
+struct switch_port_led_config;
+
+struct switch_port_led_ctrl {
+ struct device *dev;
+ struct regmap *map;
+ const struct switch_port_led_config *cfg;
+ struct mutex lock;
+ struct led_port_group *groups;
+};
+
+struct switch_port_led {
+ struct led_classdev led;
+ struct switch_port_led_ctrl *ctrl;
+ unsigned int port;
+ unsigned int index;
+ u32 trigger_flags;
+ struct led_port_group *current_group;
+};
+
+struct switch_port_led_config {
+ unsigned int port_count;
+ unsigned int port_led_count;
+ unsigned int group_count;
+ const struct led_port_modes *modes;
+ /* Set the number of LEDs per port */
+ int (*port_led_init)(struct switch_port_led_ctrl *ctrl,
+ unsigned int led_count);
+ /* Enable or disable all LEDs for a certain port */
+ int (*set_port_enabled)(struct switch_port_led *led, bool enabled);
+ int (*set_hw_managed)(struct switch_port_led *led, bool hw_managed);
+ int (*write_mode)(struct switch_port_led *led, unsigned int mode);
+ int (*read_mode)(struct switch_port_led *led);
+ int (*trigger_xlate)(u32 trigger);
+ struct led_port_group *(*map_group)(struct switch_port_led *led, u32
trigger);
+ struct reg_field group_settings[];
+};
+
+static struct led_port_group *switch_port_led_get_group(
+ struct switch_port_led *pled, unsigned int group)
+{
+ return >ctrl->groups[group * pled->ctrl->cfg->port_led_count +
pled->index];
+}
+
+/*
+ * SoC specific implementation for RTL8380 series (Maple)
+ */
+#define RTL8380_REG_LED_MODE_SEL 0x1004
+#define RTL8380_REG_LED_GLB_CTRL 0xa000
+#define RTL8380_REG_LED_MODE_CTRL 0xa004
+#define RTL8380_REG_LED_P_EN_CTRL 0xa008
+#define RTL8380_REG_LED_SW_P_EN_CTRL(led) (0xa010 + 4 * (led))
+#define RTL8380_REG_LED_SW_CTRL(port) (0xa01c + 4 * (port))
+
+#define RTL8380_PORT_LED_COUNT 3
+#define RTL8380_GROUP_SETTING_WIDTH5
+#define RTL8380_GROUP_SETTING_OFFSET(_grp, _idx) \
+ (RTL8380_GROUP_SETTING_WIDTH * ((_idx) + RTL8380_PORT_LED_COUNT *
(_grp)))
+#define RTL8380_GROUP_SETTING(_grp, _idx) {
\
+ .reg = RTL8380_REG_LED_MODE_CTRL,
\
+ .lsb = RTL8380_GROUP_SETTING_OFFSET(_grp, _idx),
\
+ .msb = RTL8380_GROUP_SETTING_OFFSET(_grp, (_idx) + 1) - 1,
\
+ }
+
+enum rtl83xx_port_trigger {
[RFC PATCH 0/7] realtek: MFD for switch core
This RFC series introduces a new MFD device for the switch core found
in the Realtek SoCs. Currently only an implementation is provided for
RTL8380, but it written with the register structure of other generations
in mind.
The MFD comes with a set of new drivers:
- core MFD driver for global register management, sundry small
peripherals that don't warrant a specific driver
- pin control driver to manage different pin muxes, so we can replace
all those pinctrl-single nodes
- switch port LED driver with port status HW offloading
The port LED support will probably be what draws most attention, as this
is something many users have been requesting. There are two example
implementations:
- ZyXEL GS1900-8, with one LED per port
- Netgear GS110TPP, with two LEDs per port
If you have time, please test these patches and provide some feedback on
the structure and implementation of the different parts. My plan is for
this to be the starting point to (finally) start upstreaming the most
important part of the Realtek SoCs; the ethernet switch.
Best,
Sander
Sander Vanheule (7):
kernel: backport devm_bitmap_{alloc,zalloc}
realtek: add switch core MFD driver
realtek: add pinctrl for Realtek maple
realtek: add RTL8380 switch port LED driver
realtek: rtl838x: replace pinctrl-single
realtek: Zyxel GS1900-8: define port LEDs
realtek: Netgear GS110TPPv1: define port LEDs
...de-devm_bitmap_alloc-and-devm_bitmap.patch | 88 +++
.../dts-5.10/rtl8380_netgear_gs110tpp-v1.dts | 30 +
.../dts-5.10/rtl8380_zyxel_gs1900-8.dts | 41 ++
target/linux/realtek/dts-5.10/rtl838x.dtsi| 38 +-
.../drivers/leds/leds-rtl-switch-port.c | 668 ++
.../drivers/mfd/realtek-switchcore.c | 244 +++
.../drivers/pinctrl/pinctrl-rtl-switchcore.c | 370 ++
...0-mfd-add-Realtek-switch-core-driver.patch | 50 ++
...inctrl-add-pinctrl-for-Realtek-maple.patch | 51 ++
...s-add-RTL8380-switch-port-LED-driver.patch | 64 ++
target/linux/realtek/rtl838x/config-5.10 | 4 +
11 files changed, 1627 insertions(+), 21 deletions(-)
create mode 100644
target/linux/generic/backport-5.10/201-lib-bitmap-provide-devm_bitmap_alloc-and-devm_bitmap.patch
create mode 100644
target/linux/realtek/files-5.10/drivers/leds/leds-rtl-switch-port.c
create mode 100644
target/linux/realtek/files-5.10/drivers/mfd/realtek-switchcore.c
create mode 100644
target/linux/realtek/files-5.10/drivers/pinctrl/pinctrl-rtl-switchcore.c
create mode 100644
target/linux/realtek/patches-5.10/200-mfd-add-Realtek-switch-core-driver.patch
create mode 100644
target/linux/realtek/patches-5.10/201-pinctrl-add-pinctrl-for-Realtek-maple.patch
create mode 100644
target/linux/realtek/patches-5.10/202-leds-add-RTL8380-switch-port-LED-driver.patch
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 2/7] realtek: add switch core MFD driver
Realtek managed switch SoCs such as the RTL8380 consist of a MIPS CPU
with a number of basic peripherals, and an ethernet switch peripheral.
Besides performing ethernet related tasks, this switch core also
provides SoC management features. These switch core features are badly
separated, and cannot be divided into distinct IO ranges.
This MFD core driver is intended to manage the switch core regmap, and
to expose some limited features that don't warrant their own driver.
These include SoC identification and system LED management.
Signed-off-by: Sander Vanheule
---
.../drivers/mfd/realtek-switchcore.c | 244 ++
...0-mfd-add-Realtek-switch-core-driver.patch | 50
target/linux/realtek/rtl838x/config-5.10 | 2 +
3 files changed, 296 insertions(+)
create mode 100644
target/linux/realtek/files-5.10/drivers/mfd/realtek-switchcore.c
create mode 100644
target/linux/realtek/patches-5.10/200-mfd-add-Realtek-switch-core-driver.patch
diff --git a/target/linux/realtek/files-5.10/drivers/mfd/realtek-switchcore.c
b/target/linux/realtek/files-5.10/drivers/mfd/realtek-switchcore.c
new file mode 100644
index ..5b3f6eee6fe2
--- /dev/null
+++ b/target/linux/realtek/files-5.10/drivers/mfd/realtek-switchcore.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct realtek_switchcore_ctrl;
+
+struct realtek_switchcore_data {
+ struct reg_field sys_led_field;
+ const struct mfd_cell *mfd_devices;
+ unsigned int mfd_device_count;
+ void (*probe_model_name)(const struct realtek_switchcore_ctrl *ctrl);
+};
+
+struct realtek_switchcore_ctrl {
+ struct device *dev;
+ struct regmap *map;
+ const struct realtek_switchcore_data *data;
+ struct led_classdev sys_led;
+ struct regmap_field *sys_led_field;
+ bool active_low;
+};
+
+/*
+ * Model name probe
+ *
+ * Reads the family-specific MODEL_NAME_INFO register
+ * to identify the SoC model and revision
+ */
+#define RTL8380_REG_MODEL_NAME_INFO0x00d4
+#define RTL8380_REG_CHIP_INFO 0x00d8
+#define MODEL_NAME_CHAR_XLATE(val) ((val) ? 'A' + (val) - 1 : '\0')
+#define MODEL_NAME_CHAR(reg, msb, lsb)
(MODEL_NAME_CHAR_XLATE(FIELD_GET(GENMASK((msb), (lsb)), (val
+
+#define RTL8380_REG_INT_RW_CTRL0x0058
+
+static void rtl8380_probe_model_name(const struct realtek_switchcore_ctrl
*ctrl)
+{
+char model_char[4] = {0, 0, 0, 0};
+char chip_rev;
+u32 model_id;
+u32 val = 0;
+
+regmap_read(ctrl->map, RTL8380_REG_MODEL_NAME_INFO, );
+model_id = FIELD_GET(GENMASK(31, 16), val);
+model_char[0] = MODEL_NAME_CHAR(val, 15, 11);
+model_char[1] = MODEL_NAME_CHAR(val, 10, 6);
+model_char[2] = MODEL_NAME_CHAR(val, 5, 1);
+
+/* CHIP_INFO register must be unlocked by writing 0xa to the top bits */
+regmap_write(ctrl->map, RTL8380_REG_CHIP_INFO, FIELD_PREP(GENMASK(31, 28),
0xa));
+regmap_read(ctrl->map, RTL8380_REG_CHIP_INFO, );
+chip_rev = MODEL_NAME_CHAR(val, 20, 16) ?: '0';
+
+dev_info(ctrl->dev, "found RTL%04x%s rev. %c\n", model_id, model_char,
chip_rev);
+}
+
+/*
+ * Realtek hardware system LED
+ *
+ * The switch SoC supports one hardware managed direct LED output
+ * to manage a system LED, with two supported blinking rates.
+ */
+enum {
+ SWITCHCORE_SYS_LED_OFF = 0,
+ SWITCHCORE_SYS_LED_BLINK_64MS,
+ SWITCHCORE_SYS_LED_BLINK_1024MS,
+ SWITCHCORE_SYS_LED_ON
+};
+
+static void switchcore_sys_led_set_rate(const struct realtek_switchcore_ctrl
*ctrl,
+ unsigned int mode)
+{
+ regmap_field_write(ctrl->sys_led_field, mode);
+}
+
+static void switchcore_sys_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct realtek_switchcore_ctrl *ctrl =
+ container_of(led_cdev, struct realtek_switchcore_ctrl, sys_led);
+
+ if ((!ctrl->active_low && brightness == LED_OFF) ||
+ (ctrl->active_low && brightness != LED_OFF))
+ switchcore_sys_led_set_rate(ctrl, SWITCHCORE_SYS_LED_OFF);
+ else
+ switchcore_sys_led_set_rate(ctrl, SWITCHCORE_SYS_LED_ON);
+}
+
+static enum led_brightness switchcore_sys_led_brightness_get(
+ struct led_classdev *led_cdev)
+{
+ struct realtek_switchcore_ctrl *ctrl =
+ container_of(led_cdev, struct realtek_switchcore_ctrl, sys_led);
+ u32 val;
+
+ regmap_field_read(ctrl->sys_led_field, );
+
+ if ((!ctrl->active_low && val == SWITCHCORE_SYS_LED_OFF) ||
+ (ctrl->active_low && val == SWITCHCORE_SYS_LED_ON))
+ return LED_OFF;
+ else
+ return LED_ON;
+}
+
+static int switchcore_sys_led_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on, unsigned long *delay_off)
+{
+
[RFC PATCH 1/7] kernel: backport devm_bitmap_{alloc,zalloc}
devm_* helpers are useful for driver resource management. Backport these
helpers for bitmap allocations from v5.13.
Signed-off-by: Sander Vanheule
---
...de-devm_bitmap_alloc-and-devm_bitmap.patch | 88 +++
1 file changed, 88 insertions(+)
create mode 100644
target/linux/generic/backport-5.10/201-lib-bitmap-provide-devm_bitmap_alloc-and-devm_bitmap.patch
diff --git
a/target/linux/generic/backport-5.10/201-lib-bitmap-provide-devm_bitmap_alloc-and-devm_bitmap.patch
b/target/linux/generic/backport-5.10/201-lib-bitmap-provide-devm_bitmap_alloc-and-devm_bitmap.patch
new file mode 100644
index ..515ee68749c4
--- /dev/null
+++
b/target/linux/generic/backport-5.10/201-lib-bitmap-provide-devm_bitmap_alloc-and-devm_bitmap.patch
@@ -0,0 +1,88 @@
+From e829c2e4744850bab4d8f8ffebd00df10b4c6c2b Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski
+Date: Mon, 15 Mar 2021 10:13:56 +0100
+Subject: [PATCH] lib: bitmap: provide devm_bitmap_alloc() and
+ devm_bitmap_zalloc()
+
+Provide managed variants of bitmap_alloc() and bitmap_zalloc().
+
+Signed-off-by: Bartosz Golaszewski
+Reviewed-by: Andy Shevchenko
+---
+ include/linux/bitmap.h | 8
+ lib/bitmap.c | 33 +
+ 2 files changed, 41 insertions(+)
+
+--- a/include/linux/bitmap.h
b/include/linux/bitmap.h
+@@ -9,6 +9,8 @@
+ #include
+ #include
+
++struct device;
++
+ /*
+ * bitmaps provide bit arrays that consume one or more unsigned
+ * longs. The bitmap interface and available operations are listed
+@@ -122,6 +124,12 @@ extern unsigned long *bitmap_alloc(unsig
+ extern unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
+ extern void bitmap_free(const unsigned long *bitmap);
+
++/* Managed variants of the above. */
++unsigned long *devm_bitmap_alloc(struct device *dev,
++ unsigned int nbits, gfp_t flags);
++unsigned long *devm_bitmap_zalloc(struct device *dev,
++unsigned int nbits, gfp_t flags);
++
+ /*
+ * lib/bitmap.c provides these functions:
+ */
+--- a/lib/bitmap.c
b/lib/bitmap.c
+@@ -6,6 +6,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -1262,6 +1263,38 @@ void bitmap_free(const unsigned long *bi
+ }
+ EXPORT_SYMBOL(bitmap_free);
+
++static void devm_bitmap_free(void *data)
++{
++ unsigned long *bitmap = data;
++
++ bitmap_free(bitmap);
++}
++
++unsigned long *devm_bitmap_alloc(struct device *dev,
++ unsigned int nbits, gfp_t flags)
++{
++ unsigned long *bitmap;
++ int ret;
++
++ bitmap = bitmap_alloc(nbits, flags);
++ if (!bitmap)
++ return NULL;
++
++ ret = devm_add_action_or_reset(dev, devm_bitmap_free, bitmap);
++ if (ret)
++ return NULL;
++
++ return bitmap;
++}
++EXPORT_SYMBOL_GPL(devm_bitmap_alloc);
++
++unsigned long *devm_bitmap_zalloc(struct device *dev,
++unsigned int nbits, gfp_t flags)
++{
++ return devm_bitmap_alloc(dev, nbits, flags | __GFP_ZERO);
++}
++EXPORT_SYMBOL_GPL(devm_bitmap_zalloc);
++
+ #if BITS_PER_LONG == 64
+ /**
+ * bitmap_from_arr32 - copy the contents of u32 array of bits to bitmap
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 6/7] realtek: Zyxel GS1900-8: define port LEDs
Add all port LEDs to the device tree for the GS1900-8. To reproduce the
same behaviour as stock firmware, the LEDs need to light up on all
link speeds, and blink on link activity:
echo 1f > /sys/class/leds/lan?/rtl_hw_trigger
echo realtek-switchport > /sys/class/leds/lan?/trigger
Signed-off-by: Sander Vanheule
---
.../dts-5.10/rtl8380_zyxel_gs1900-8.dts | 41 +++
1 file changed, 41 insertions(+)
diff --git a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900-8.dts
b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900-8.dts
index e9c5efe60392..41266b701aca 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900-8.dts
+++ b/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900-8.dts
@@ -10,3 +10,44 @@
{
/delete-node/ poe_enable;
};
+
+ {
+ port-leds {
+ compatible = "realtek,rtl8380-port-led";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ led@8.0 {
+ reg = <8 0>;
+ label = "lan1";
+ };
+ led@9.0 {
+ reg = <9 0>;
+ label = "lan2";
+ };
+ led@10.0 {
+ reg = <10 0>;
+ label = "lan3";
+ };
+ led@11.0 {
+ reg = <11 0>;
+ label = "lan4";
+ };
+ led@12.0 {
+ reg = <12 0>;
+ label = "lan5";
+ };
+ led@13.0 {
+ reg = <13 0>;
+ label = "lan6";
+ };
+ led@14.0 {
+ reg = <14 0>;
+ label = "lan7";
+ };
+ led@15.0 {
+ reg = <15 0>;
+ label = "lan8";
+ };
+ };
+};
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 4/7] realtek: add RTL8380 switch port LED driver
RTL8380 switch SoCs can control up to 3×28 LEDs to display status of the
switch's ethernet port. This driver allows to address these LEDs and
provides direct control, blink offloading, and switch port status
offloading.
Since offloading of the generic netdev trigger does not exist, this
driver provides a private trigger which achieves the same and is named
"realtek-switchport". Each LED will have a file name "rtl_hw_trigger" in
/sys/class/leds/$LED, where the requested trigger mode can be written
to. If an unsupported mode is requested, this will be reported to the
user. When the trigger is then activated, the LED will be added to a
group of LEDs with the same trigger conditions. If it is not possible to
add the LED to a group, the user must use an already existing trigger
condition, or use direct LED control with a software trigger.
Some common modes (i.e. values for "rtl_hw_trigger") are:
- Link present, blink on activity: 1f
- 100M/10M link, blink on activity: f
- 1G link present: 10
Signed-off-by: Sander Vanheule
---
.../drivers/pinctrl/pinctrl-rtl-switchcore.c | 370 ++
...s-add-RTL8380-switch-port-LED-driver.patch | 64 +++
target/linux/realtek/rtl838x/config-5.10 | 1 +
3 files changed, 435 insertions(+)
create mode 100644
target/linux/realtek/files-5.10/drivers/pinctrl/pinctrl-rtl-switchcore.c
create mode 100644
target/linux/realtek/patches-5.10/202-leds-add-RTL8380-switch-port-LED-driver.patch
diff --git
a/target/linux/realtek/files-5.10/drivers/pinctrl/pinctrl-rtl-switchcore.c
b/target/linux/realtek/files-5.10/drivers/pinctrl/pinctrl-rtl-switchcore.c
new file mode 100644
index ..0caf925989b6
--- /dev/null
+++ b/target/linux/realtek/files-5.10/drivers/pinctrl/pinctrl-rtl-switchcore.c
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "pinmux.h"
+
+/**
+ * struct rtl_swcore_mux_desc - switchcore pin group information
+ *
+ * Pins are frequently muxed between alternative functions, but the control
+ * bits for the muxes are scattered throught the switchcore's register space.
+ * Provide a regmap-based interface to flexibly manage these mux fields, which
+ * may vary in size and do not always provide a GPIO function.
+ *
+ * @name: name to identify the pin group
+ * @field_desc: description of the register field with mux control bits
+ * @functions: NULL terminated array of function names
+ * @pins: array of numbers of the pins in this group
+ * @npins: number of pins in this group
+ */
+struct rtl_swcore_mux_desc {
+ const char *name;
+ struct reg_field field;
+ const unsigned int *pins;
+ unsigned int npins;
+};
+
+#define SWITCHCORE_MUX(_name, _field, _pins) { \
+ .name = (_name),\
+ .field = _field,\
+ .pins = (_pins),\
+ .npins = ARRAY_SIZE(_pins), \
+ }
+
+/**
+ * struct rtl_swcore_mux_setting - stored mux setting
+ *
+ * @mux: pointer to the mux descriptor
+ * @value: value to write in the mux's register field to apply this setting
+ */
+struct rtl_swcore_mux_setting {
+ const struct rtl_swcore_mux_desc *mux;
+ unsigned int value;
+};
+
+/**
+ * struct rtl_swcore_function_desc - switchcore function information
+ *
+ * @name: name of this function
+ * @settings: list of mux settings that enable this function on said mux
+ * @nsettings: length of the @settings list
+ */
+struct rtl_swcore_function_desc {
+ const char *name;
+ const struct rtl_swcore_mux_setting *settings;
+ unsigned int nsettings;
+};
+
+#define SWITCHCORE_FUNCTION(_name, _settings) { \
+ .name = (_name),\
+ .settings = (_settings),\
+ .nsettings = ARRAY_SIZE(_settings), \
+ }
+
+struct rtl_swcore_config {
+ const struct pinctrl_pin_desc *pins;
+ unsigned int npins;
+ const struct rtl_swcore_function_desc *functions;
+ unsigned int nfunctions;
+ const struct rtl_swcore_mux_desc **groups;
+ unsigned int ngroups;
+};
+
+struct rtl_swcore_pinctrl {
+ struct pinctrl_desc pdesc;
+ struct device *dev;
+ const struct rtl_swcore_config *config;
+ struct regmap_field **mux_fields;
+};
+
+/*
+ * RTL838x chips come in LQFP packages with 216 pins. Pins are indexed
+ * counter-clockwise, starting with pin 1 at the bottom left.
+ * Map package pin {1..216} to pinctrl pin number {0..215}.
+ */
+static const struct pinctrl_pin_desc rtl8380_swcore_pins[] = {
+ /* JTAG pins */
+ PINCTRL_PIN(27, "tck"),
+ PINCTRL_PIN(28, "tms"),
+ PINCTRL_PIN(29, "tdo"),
+ PINCTRL_PIN(30, "tdi"),
