gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Lukas Zeller [2022-10-18 23:10:48]: Hi, > I did investigate this in June on this list [1] and in the openwrt forum [2] > and tried to ask some questions about the right way to handle this, but > apparently it did not echo for some reason back then. IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. Bjørn Mork [2022-10-19 08:24:44]: > Sergio Paracuellos via openwrt-devel > writes: > > > This is the reason we have 'gpio-line-names' property so you can set > > up names for your pins and use it together with actual user space > > tools libgpiod and gpiod. Any other gpio user space library is > > considered deprecated in these days. > > Interesting. This property doesn't seem to be used much in OpenWrt if > my grep foo is good. It should probably be added at least to every > system where we want to access GPIOs from userspace? Yes, that is my[1] understanding as well. 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Petr Štetiar writes: >> Interesting. This property doesn't seem to be used much in OpenWrt if >> my grep foo is good. It should probably be added at least to every >> system where we want to access GPIOs from userspace? > > Yes, that is my[1] understanding as well. > > 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 If my qucik read of that is correct, then the main reason it didn't go anywhere was because it was about libgpiod transition. A simple start by adding properties to the board DTs where we already have a named userspace GPIO in for example /etc/board.d/03_gpio_switches should be a no brainer, or? Having the names in the device tree won't force any userspace changes, but will allow them to happen later. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Hi, > On 19 Oct 2022, at 08:55, Petr Štetiar wrote: > > IMO there should be `ugpiod` daemon available over ubus, probably written in > ucode using libgpiod bindings. It should provide ubus events for GPIO inputs > and should be able to control GPIO outputs using ubus calls. What would that mean for performance, compared to more direct call chains as when using legacy /sys/class/gpio and current libgpiod? I suspect it would be much slower via an extra daemon. But I see a basic underlying question here: how to look at GPIOs in the general context of OpenWrt? - From a systems designers perspective, a GPIO is a I/O pin of the SoC or one of the peripheral chips in the system which has no specific function determined by the silicon, but gets one by the board/device design. This is the main perspective in Linux, and DT is the layer to "wire" the GPIOs for the specific task to run a certain board or device. - From the perspective of people who build educational or experimental devices, where reconfiguring GPIOs is a essential part of the USER experience, changing DT bindings (be it just `gpio-line-names`) is not a viable solution. Especially not since the mechanism to do so without rebuilding firmware images - dynamically loading DT overlays - is not approved of as well [1]. For this perspective, deprecating old GPIO numbering and retiring spi-gpio-custom et. al. drivers with no real substitute is a serious step backwards, and a reason not to upgrade to newer versions. I see that the first of the two perspectives is the correct one for the main usage of OpenWrt, an OS for network boxes and boards, and obviously has priority. However, OpenWrt is also a very good base for other uses, maybe summarizable as "user configurable hardware controllers" (as said, education, but also controllers for exhibitions and art installations - one of my primary applications). After years using and trying to contribute to OpenWrt for this use case I still don't really understand the sentinents of core OpenWrt towards this sideline - is it rather seen as a distracting nuisance or an opportunity? ;-) Somehow I need to have a clearer view on this meta level to do more than just patch the missing things for myself. I would like to not only profit, but also contribute, but can do only so from and for the second of the two perspectives above, because that's what I understand and work with. Any thoughts? Best Regards Lukas [1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037164.html > Bjørn Mork [2022-10-19 08:24:44]: > >> Sergio Paracuellos via openwrt-devel >> writes: >> >>> This is the reason we have 'gpio-line-names' property so you can set >>> up names for your pins and use it together with actual user space >>> tools libgpiod and gpiod. Any other gpio user space library is >>> considered deprecated in these days. >> >> Interesting. This property doesn't seem to be used much in OpenWrt if >> my grep foo is good. It should probably be added at least to every >> system where we want to access GPIOs from userspace? > > Yes, that is my[1] understanding as well. > > 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 > > -- ynezz signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: do not use GPIO function on switch pins on certain devices
The pins of the MT7530 switch that translate to GPIO 0, 3, 6, 9 and 12 has
got a function, by default, which does the same thing as the netdev
trigger. Because of bridge offloading on DSA, the netdev trigger won't see
the frames between the switch ports whilst the default function will.
Do not use the GPIO function on switch pins on devices that fall under this
category.
Keep it for:
mt7621_belkin_rt1800.dts: There's only one LED which is for the wan
interface and there's no bridge offloading between the "wan" interface and
other interfaces.
mt7621_yuncore_ax820.dts: There's no bridge offloading between the "wan"
and "lan" interfaces.
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_linksys_e7350.dts | 37 ---
.../ramips/dts/mt7621_netgear_wax202.dts | 18 -
.../ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi | 37 ---
.../mt7621/base-files/etc/board.d/01_leds | 17 -
4 files changed, 109 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_linksys_e7350.dts
b/target/linux/ramips/dts/mt7621_linksys_e7350.dts
index d7b8c214b9..ea8a684148 100644
--- a/target/linux/ramips/dts/mt7621_linksys_e7350.dts
+++ b/target/linux/ramips/dts/mt7621_linksys_e7350.dts
@@ -57,40 +57,6 @@
function = LED_FUNCTION_WAN;
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
};
-
- led-wan2 {
- color = ;
- function = LED_FUNCTION_WAN;
- gpios = <&switch0 0 GPIO_ACTIVE_LOW>;
- };
-
- led-lan4 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <4>;
- gpios = <&switch0 3 GPIO_ACTIVE_LOW>;
- };
-
- led-lan3 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <3>;
- gpios = <&switch0 6 GPIO_ACTIVE_LOW>;
- };
-
- led-lan2 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <2>;
- gpios = <&switch0 9 GPIO_ACTIVE_HIGH>;
- };
-
- led-lan1 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <1>;
- gpios = <&switch0 12 GPIO_ACTIVE_LOW>;
- };
};
};
@@ -185,9 +151,6 @@
};
&switch0 {
- gpio-controller;
- #gpio-cells = <2>;
-
ports {
port@1 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7621_netgear_wax202.dts
b/target/linux/ramips/dts/mt7621_netgear_wax202.dts
index f17a805363..02f540d743 100644
--- a/target/linux/ramips/dts/mt7621_netgear_wax202.dts
+++ b/target/linux/ramips/dts/mt7621_netgear_wax202.dts
@@ -53,31 +53,16 @@
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
- led_lan1_green: lan1_green {
- label = "green:lan1";
- gpios = <&switch0 3 GPIO_ACTIVE_LOW>;
- };
-
led_lan1_orange: lan1_orange {
label = "orange:lan1";
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
};
- led_lan2_green: lan2_green {
- label = "green:lan2";
- gpios = <&switch0 6 GPIO_ACTIVE_LOW>;
- };
-
led_lan2_orange: lan2_orange {
label = "orange:lan2";
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
- led_lan3_green: lan3_green {
- label = "green:lan3";
- gpios = <&switch0 12 GPIO_ACTIVE_LOW>;
- };
-
led_lan3_orange: lan3_orange {
label = "orange:lan3";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
@@ -256,9 +241,6 @@
};
&switch0 {
- gpio-controller;
- #gpio-cells = <2>;
-
ports {
port@1 {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
index f19cb4db17..59fab90ed1 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi
@@ -51,40 +51,6 @@
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy1tpt";
};
-
- lan1 {
- color = ;
- function = LED_FUNCTION_LAN;
- function-enumerator = <1>;
- gpios = <&switch0 0 GPIO_ACTI
[PATCH] netifd: add vif in ascending order instead of lexicographic
We are using vif_idx for listing vif.
But wlan vif ordering is done in lexicographical manner by avl_strcmp()
which is casuing in bringing up vap with higher index added first.
Instead of using avl_strcmp(), we can use avl_vif_idx_cmp() for interfaces.
Signed-off-by: Prasun Maiti
---
wireless.c | 8 +++-
wireless.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/wireless.c b/wireless.c
index bd847e7..b6b45bb 100644
--- a/wireless.c
+++ b/wireless.c
@@ -122,6 +122,12 @@ wireless_handler_stop(struct wireless_device *wdev)
}
}
+int
+avl_vif_idx_cmp(const void *k1, const void *k2, void *ptr)
+{
+ return (*(int *)k1 - *(int *)k2);
+}
+
static void
put_container(struct blob_buf *buf, struct blob_attr *attr, const char *name)
{
@@ -1045,7 +1051,7 @@ wireless_device_create(struct wireless_driver *drv, const
char *name, struct blo
wdev->retry_setup_failed = false;
wdev->autostart = true;
INIT_LIST_HEAD(&wdev->script_proc);
- vlist_init(&wdev->interfaces, avl_strcmp, vif_update);
+ vlist_init(&wdev->interfaces, avl_vif_idx_cmp, vif_update);
wdev->interfaces.keep_old = true;
vlist_init(&wdev->vlans, avl_strcmp, vlan_update);
wdev->vlans.keep_old = true;
diff --git a/wireless.h b/wireless.h
index 7b87611..9a2c0ee 100644
--- a/wireless.h
+++ b/wireless.h
@@ -146,5 +146,6 @@ int wireless_device_notify(struct wireless_device *wdev,
struct blob_attr *data,
void wireless_start_pending(void);
void wireless_init(void);
void wireless_device_hotplug_event(const char *name, bool add);
+int avl_vif_idx_cmp(const void *k1, const void *k2, void *ptr);
#endif
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firewall: config: drop input traffic by default
From: Baptiste Jonglez This is necessary with firewall4 to avoid a hard-to-diagnose race condition during boot, causing DNAT rules not to be taken into account correctly. The root cause is that, during boot, the ruleset is mostly empty, and interface-related rules (including DNAT rules) are added incrementally. If a packet hits the input chain before the DNAT rules are setup, it can create buggy conntrack entries that will persist indefinitely. This new default should be safe because firewall4 explicitly accepts authorized traffic and rejects the rest. Thus, in normal operations, the default policy is not used. Fixes: #10749 Ref: https://github.com/openwrt/openwrt/issues/10749 Signed-off-by: Baptiste Jonglez --- package/network/config/firewall/files/firewall.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/config/firewall/files/firewall.config b/package/network/config/firewall/files/firewall.config index 61cfe665e4..b90ac7af0a 100644 --- a/package/network/config/firewall/files/firewall.config +++ b/package/network/config/firewall/files/firewall.config @@ -1,6 +1,6 @@ config defaults option syn_flood1 - option inputACCEPT + option inputREJECT option output ACCEPT option forward REJECT # Uncomment this line to disable ipv6 rules -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
On 10/19/22 05:51, Lukas Zeller wrote: Hi, Lukas, thanks for this. I've read through everything and I agree with your concerns. I'll note also that Linus W's commentary is from 2018. On 19 Oct 2022, at 08:55, Petr Štetiar wrote: IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. What would that mean for performance, compared to more direct call chains as when using legacy /sys/class/gpio and current libgpiod? I suspect it would be much slower via an extra daemon. Regarding performance, this is a practical concern. In one case using a GPIO- driven 3-color LED, using explicit user-space tools (albeit a clunky vendor program), to blink, there was a enough of a delay between the blinks to give a disconcerting display when trying to blink white. I'm sure there's a better way to do this, but changing the code to direct file access to the GPIOs produced a more satisfactory result. And I still haven't seen a rationale for the "non-fixed" base - I understand there's probably a desire for abstraction somewhere, but figuring out offsets becomes a hassle. I get that some boards have some wacky GPIO assignments due to chip design, but this is surely a DTS concern. I'm sure also it's trivial to extend the legacy GPIO export function to export named GPIOs too (if it doesn't already, I haven't looked). So for the moment, there doesn't seem to be general-purpose solution in OpenWrt, especially for script use. I'll gladly migrate to that if there is one in future, but I think for now I need to stick to my patch and named GPIO exports in the DTS. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] netifd: add vif in ascending order instead of lexicographic
We are using vif_idx for listing vif.
But wlan vif ordering is done in lexicographical manner by avl_strcmp()
which is casuing in bringing up vap with higher index added first.
Instead of using avl_strcmp(), we can use avl_vif_idx_cmp() for interfaces.
Signed-off-by: Prasun Maiti
---
wireless.c | 8 +++-
wireless.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/wireless.c b/wireless.c
index bd847e7..b6b45bb 100644
--- a/wireless.c
+++ b/wireless.c
@@ -122,6 +122,12 @@ wireless_handler_stop(struct wireless_device *wdev)
}
}
+int
+avl_vif_idx_cmp(const void *k1, const void *k2, void *ptr)
+{
+ return (atoi(k1) - atoi(k2));
+}
+
static void
put_container(struct blob_buf *buf, struct blob_attr *attr, const char *name)
{
@@ -1045,7 +1051,7 @@ wireless_device_create(struct wireless_driver *drv, const
char *name, struct blo
wdev->retry_setup_failed = false;
wdev->autostart = true;
INIT_LIST_HEAD(&wdev->script_proc);
- vlist_init(&wdev->interfaces, avl_strcmp, vif_update);
+ vlist_init(&wdev->interfaces, avl_vif_idx_cmp, vif_update);
wdev->interfaces.keep_old = true;
vlist_init(&wdev->vlans, avl_strcmp, vlan_update);
wdev->vlans.keep_old = true;
diff --git a/wireless.h b/wireless.h
index 7b87611..9a2c0ee 100644
--- a/wireless.h
+++ b/wireless.h
@@ -146,5 +146,6 @@ int wireless_device_notify(struct wireless_device *wdev,
struct blob_attr *data,
void wireless_start_pending(void);
void wireless_init(void);
void wireless_device_hotplug_event(const char *name, bool add);
+int avl_vif_idx_cmp(const void *k1, const void *k2, void *ptr);
#endif
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
