Re: [OpenWrt-Devel] openwrt based router
On 26/09/19 11:25, sagar jain wrote: Can I sell openwrt based router ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel If you meancreate and sell new routers using OpenWrt as firmware, yes if you follow rules in trademark article here https://openwrt.org/trademark -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libubox, jshn: add option to write output to a file
On 2019-09-14 01:22, Roman Yeryomin wrote: This would allow board_config_flush to run one command instead of two and would be faster and safer than redirecting output and moving a file between filesystems. Originally discussed here: http://lists.openwrt.org/pipermail/openwrt-devel/2017-December/010127.html Anybody? I would like to submit a patch to base files which depends on this. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] ramips: harmonize device vendor Zbtlink
Spelling of Zbtlink varies across image definitions and DTS files.
This patch uses Zbtlink consistently and also updates the model
in DTS files to contain the vendor in all cases.
This patch is cosmetical, as there should be no dependencies on
device model name in ramips anymore.
Signed-off-by: Adrian Schmutzler
---
v2: No changes, just added second patch
---
.../linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts | 2 +-
.../linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts | 2 +-
.../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts | 2 +-
.../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts | 2 +-
.../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts | 2 +-
target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts | 2 +-
target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts | 2 +-
target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts | 2 +-
.../linux/ramips/dts/mt7621_zbtlink_zbt-wg3526-16m.dts | 2 +-
.../linux/ramips/dts/mt7621_zbtlink_zbt-wg3526-32m.dts | 2 +-
target/linux/ramips/image/mt7621.mk| 10 +-
target/linux/ramips/image/mt76x8.mk| 2 +-
12 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
index e2eb5b6329..a05e8d4b47 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
@@ -37,7 +37,7 @@
/ {
compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
- model = "ZBT WE1026-5G (16M)";
+ model = "Zbtlink ZBT-WE1026-5G (16M)";
};
{
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
index 70ad0f0b58..665dd5ba3c 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
@@ -7,7 +7,7 @@
/ {
compatible = "zbtlink,zbt-ape522ii", "ralink,mt7620a-soc";
- model = "ZBT-APE522II";
+ model = "Zbtlink ZBT-APE522II";
chosen {
bootargs = "console=ttyS0,115200";
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
index 7f2b2646b2..d115b8a096 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
@@ -4,7 +4,7 @@
/ {
compatible = "zbtlink,zbt-we826-16m", "zbtlink,zbt-we826",
"ralink,mt7620a-soc";
- model = "ZBT-WE826 (16M)";
+ model = "Zbtlink ZBT-WE826 (16M)";
};
{
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
index e7cdcab5e9..94a67dd5de 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
@@ -4,7 +4,7 @@
/ {
compatible = "zbtlink,zbt-we826-32m", "zbtlink,zbt-we826",
"ralink,mt7620a-soc";
- model = "ZBT-WE826 (32M)";
+ model = "Zbtlink ZBT-WE826 (32M)";
};
{
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
index 243126125b..2496a16a29 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
@@ -5,7 +5,7 @@
/ {
compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826",
"ralink,mt7620a-soc";
- model = "ZBT-WE826-E";
+ model = "Zbtlink ZBT-WE826-E";
/delete-node/ leds;
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
index 819c851c73..d7c48c6d9f 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
@@ -7,7 +7,7 @@
/ {
compatible = "zbtlink,zbt-we1326", "mediatek,mt7621-soc";
- model = "ZBT-WE1326";
+ model = "Zbtlink ZBT-WE1326";
aliases {
label-mac-device =
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
index 7973626fad..b1d3e4e812 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
@@ -7,7 +7,7 @@
/ {
compatible = "zbtlink,zbt-we3526", "mediatek,mt7621-soc";
- model = "ZBT-WE3526";
+ model = "Zbtlink ZBT-WE3526";
chosen {
bootargs = "console=ttyS0,115200";
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
index ca2044f73e..1a2a89a31e 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
@@ -7,7 +7,7 @@
[OpenWrt-Devel] [PATCH v2 2/2] ramips: apply consistent device name/compatible to ZBT-WE1026-5G
All Zbtlink ramips devices except the ZBT-WE1026-5G include the
zbt-/ZBT- prefix in their model name.
This changes ZBT-WE1026-5G to also follow that scheme.
The patch moves some block to keep alphatical order.
Signed-off-by: Adrian Schmutzler
---
v2: new in v2
This is not tested on device and is only meant as base for
Kristian Evensen's patches (DTSI rearrangement and addition of
WE1026-H).
---
.../ramips/base-files/etc/board.d/01_leds | 8 +++
.../ramips/base-files/etc/board.d/02_network | 2 +-
... => mt7620a_zbtlink_zbt-we1026-5g-16m.dts} | 4 ++--
...tsi => mt7620a_zbtlink_zbt-we1026-5g.dtsi} | 2 +-
target/linux/ramips/image/mt7620.mk | 22 +--
5 files changed, 19 insertions(+), 19 deletions(-)
rename target/linux/ramips/dts/{mt7620a_zbtlink_we1026-5g-16m.dts =>
mt7620a_zbtlink_zbt-we1026-5g-16m.dts} (95%)
rename target/linux/ramips/dts/{mt7620a_zbtlink_we1026-5g.dtsi =>
mt7620a_zbtlink_zbt-we1026-5g.dtsi} (98%)
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 46202b4117..f8a270b6b0 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -445,10 +445,6 @@ youku,yk1)
set_wifi_led "$boardname:blue:air"
ucidef_set_led_switch "wan" "wan" "$boardname:blue:wan" "switch0" "0x10"
;;
-zbtlink,we1026-5g-16m)
- ucidef_set_led_netdev "lan" "LAN" "we1026-5g:green:lan" "eth0"
- set_wifi_led "we1026-5g:green:wifi"
- ;;
zbtlink,zbt-ape522ii)
ucidef_set_led_netdev "wlan2g4" "wlan1-link" "$boardname:green:wlan2g4"
"wlan1"
ucidef_set_led_netdev "sys1" "wlan1" "$boardname:green:sys1" "wlan1"
"tx rx"
@@ -461,6 +457,10 @@ zbtlink,zbt-we826-16m|\
zbtlink,zbt-we826-32m)
set_wifi_led "zbt-we826:green:wifi"
;;
+zbtlink,zbt-we1026-5g-16m)
+ ucidef_set_led_netdev "lan" "LAN" "we1026-5g:green:lan" "eth0"
+ set_wifi_led "we1026-5g:green:wifi"
+ ;;
zbtlink,zbt-we1226)
set_wifi_led "$boardname:green:wlan"
ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0"
"0x01"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 947bf1428d..ae05c827bc 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -451,7 +451,7 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "9@eth0"
;;
sparklan,wcr-150gn|\
- zbtlink,we1026-5g-16m)
+ zbtlink,zbt-we1026-5g-16m)
ucidef_add_switch "switch0" \
"0:lan" "6t@eth0"
;;
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
similarity index 95%
rename from target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
rename to target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
index a05e8d4b47..feba29763b 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
@@ -33,10 +33,10 @@
/dts-v1/;
-#include "mt7620a_zbtlink_we1026-5g.dtsi"
+#include "mt7620a_zbtlink_zbt-we1026-5g.dtsi"
/ {
- compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
+ compatible = "zbtlink,zbt-we1026-5g-16m", "ralink,mt7620a-soc";
model = "Zbtlink ZBT-WE1026-5G (16M)";
};
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g.dtsi
similarity index 98%
rename from target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
rename to target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g.dtsi
index e7e64e251a..68a74ede39 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g.dtsi
@@ -37,7 +37,7 @@
#include
/ {
- compatible = "zbtlink,we1026-5g", "ralink,mt7620a-soc";
+ compatible = "zbtlink,zbt-we1026-5g", "ralink,mt7620a-soc";
chosen {
bootargs = "console=ttyS0,115200";
diff --git a/target/linux/ramips/image/mt7620.mk
b/target/linux/ramips/image/mt7620.mk
index 36898c99bc..6543958bd0 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -943,17 +943,6 @@ define Device/yukai_bocco
endef
TARGET_DEVICES += yukai_bocco
-define Device/zbtlink_we1026-5g-16m
- MTK_SOC := mt7620a
- IMAGE_SIZE := 16064k
- DEVICE_VENDOR := Zbtlink
- DEVICE_MODEL := ZBT-WE1026-5G
- DEVICE_VARIANT := 16M
- DEVICE_PACKAGES := kmod-mt76x2 kmod-usb2 kmod-usb-ohci kmod-sdhci-mt7620
- SUPPORTED_DEVICES += we1026-5g-16m
-endef
-TARGET_DEVICES += zbtlink_we1026-5g-16m
-
define Device/zbtlink_zbt-ape522ii
MTK_SOC := mt7620a
IMAGE_SIZE :=
Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
On Thu, 2019-09-26 at 14:00 +0200, Rafał Miłecki wrote: > > You can't seriously be suggesting that the driver doesn't *have* enough > > information - everything passed through it :) > > Precisely: it doesn't store (cache) enough info. But nothing stops it (the driver) from doing so! > In brcmfmac on .add_virtual_intf() we: > 1) Send request to the FullMAC firmware > 2) Wait for a reply > 3) On success we create interface > 4) We wake up .add_virtual_intf() handler > > I'll need to find a way to skip step 3 in recovery path since interface > on host side already exists. Sure, we skip lots of things in all drivers, look at iwlwifi for example with IWL_MVM_STATUS_IN_HW_RESTART. > OK, so basically I need to work on caching setup data. Should I try > doing that at my selected driver level (brcmfmac)? Or should I focus on > generic solution (cfg80211) and consider offloading mac80211 if > possible? I think doing it generically will not work well, you have different code paths and different formats, different data that you need etc. Sometimes there's information cfg80211 doesn't even *have*, because the driver is responsible for things (e.g. elements). I guess you can try, but my gut feeling is that it'd simpler in the driver. Now you can argue that everything passes through cfg80211 so it must have enough data too (just like I'm arguing the driver certainly has enough data), but ... it seems to me the cfg80211 is usually more action-based, where the restore flow needs to keep the *state*, not replay the series of actions that happened. johannes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
On 26.09.2019 13:55, Johannes Berg wrote: On Thu, 2019-09-26 at 13:52 +0200, Rafał Miłecki wrote: Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't cache all settings, consider e.g. nl80211_start_ap(). It builds struct cfg80211_ap_settings using info from nl80211 message and passes it to the driver (rdev_start_ap()). Once it's done it caches only a small subset of all setup data. In other words driver doesn't have enough info to recover interfaces setup. So the driver can cache it, just like mac80211. You can't seriously be suggesting that the driver doesn't *have* enough information - everything passed through it :) Precisely: it doesn't store (cache) enough info. I meant that hardware has been recovered & is operational again (driver can talk to it). I expected user space to reconfigure all interfaces using the same settings that were used on previous run. If driver were able to recover interfaces setup on its own (with a help of cfg80211) then user space wouldn't need to be involved. The driver can do it, mac80211 does. It's just a matter of what the driver will do or not. First of all I was wondering how to handle interfaces creation. After a firmware crash we have: 1) Interfaces created in Linux 2) No corresponsing interfaces in firmware Syncing that (re-creating in-firmware firmwares) may be a bit tricky depending on a driver and hardware. We do that in mac80211, it works fine. Why would it be tricky? In brcmfmac on .add_virtual_intf() we: 1) Send request to the FullMAC firmware 2) Wait for a reply 3) On success we create interface 4) We wake up .add_virtual_intf() handler I'll need to find a way to skip step 3 in recovery path since interface on host side already exists. If something fails, I think we force that interface to go down. For some cases it could be easier to delete all interfaces and ask user space to setup wiphy (create required interfaces) again. I'm not sure if that's acceptable though? If we agree interfaces should stay and driver simply should configure firmware properly, then we need all data as explained earlier. struct cfg80211_ap_settings is not available during runtime. How should we handle that problem? You can cache it in the driver in whatever format makes sense. I was aiming for a brutal force solution: just make user space interfaces need a full setup just at they were just created. You can still do that btw, just unregister and re-register the wiphy. OK, so basically I need to work on caching setup data. Should I try doing that at my selected driver level (brcmfmac)? Or should I focus on generic solution (cfg80211) and consider offloading mac80211 if possible? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
Resending from my subscribed e-mail On 20.09.2019 16:01, Jouni Malinen wrote: > On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote: >> Hardware or firmware instability may result in unusable wiphy. In such >> cases usually a hardware reset is needed. To allow a full recovery >> kernel has to indicate problem to the user space. > > Why? Shouldn't the driver be able to handle this on its own since all > the previous configuration was done through the driver anyway. As far as > I know, there are drivers that do indeed try to do this and handle it > successfully at least for station mode. AP mode may be more complex, but > for that one, I guess it would be fine to drop all associations (and > provide indication of that to user space) and just restart the BSS. Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't cache all settings, consider e.g. nl80211_start_ap(). It builds struct cfg80211_ap_settings using info from nl80211 message and passes it to the driver (rdev_start_ap()). Once it's done it caches only a small subset of all setup data. In other words driver doesn't have enough info to recover interfaces setup. >> This new nl80211 command lets user space known wiphy has crashed and has >> been just recovered. When applicable it should result in supplicant or >> authenticator reconfiguring all interfaces. > > For me, that is not really "recovered" if some additional > reconfiguration steps are needed.. I'd like to get a more detailed view > on what exactly might need to be reconfigured and how would user space > know what exactly to do. Or would the plan here be that the driver would > not even indicate this crash if it is actually able to internally > recover fully from the firmware restart? I meant that hardware has been recovered & is operational again (driver can talk to it). I expected user space to reconfigure all interfaces using the same settings that were used on previous run. If driver were able to recover interfaces setup on its own (with a help of cfg80211) then user space wouldn't need to be involved. >> I'd like to use this new cfg80211_crash_report() in brcmfmac after a >> successful recovery from a FullMAC firmware crash. >> >> Later on I'd like to modify hostapd to reconfigure wiphy using a >> previously used setup. > > So this implies that at least something would need to happen in AP mode. > Do you have a list of items that the driver cannot do on its own and why > it would be better to do them from user space? First of all I was wondering how to handle interfaces creation. After a firmware crash we have: 1) Interfaces created in Linux 2) No corresponsing interfaces in firmware Syncing that (re-creating in-firmware firmwares) may be a bit tricky depending on a driver and hardware. For some cases it could be easier to delete all interfaces and ask user space to setup wiphy (create required interfaces) again. I'm not sure if that's acceptable though? If we agree interfaces should stay and driver simply should configure firmware properly, then we need all data as explained earlier. struct cfg80211_ap_settings is not available during runtime. How should we handle that problem? >> I'm OpenWrt developer & user and I got annoyed by my devices not auto >> recovering after various failures. There are things I cannot fix (hw >> failures or closed fw crashes) but I still expect my devices to get >> back to operational state as soon as possible on their own. > > I fully agree with the auto recovery being important thing to cover for > this, but I'm not yet convinced that this needs user space action. Or if > it does, there would need to be more detailed way of indicating what > exactly is needed for user space to do. The proposed change here is just > saying "hey, I crashed and did something to get the hardware/firmware > responding again" which does not really tell much to user space other > than potentially requiring full disable + re-enable for the related > interfaces. And that is something that should not actually be done in > all cases of firmware crashes since there are drivers that handle > recovery in a manner that is in practice completely transparent to user > space. I was aiming for a brutal force solution: just make user space interfaces need a full setup just at they were just created. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
On Thu, 2019-09-26 at 13:52 +0200, Rafał Miłecki wrote: > > Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't > cache all settings, consider e.g. nl80211_start_ap(). It builds > struct cfg80211_ap_settings using info from nl80211 message and > passes it to the driver (rdev_start_ap()). Once it's done it > caches only a small subset of all setup data. > > In other words driver doesn't have enough info to recover interfaces > setup. So the driver can cache it, just like mac80211. You can't seriously be suggesting that the driver doesn't *have* enough information - everything passed through it :) > I meant that hardware has been recovered & is operational again (driver > can talk to it). I expected user space to reconfigure all interfaces > using the same settings that were used on previous run. > > If driver were able to recover interfaces setup on its own (with a help > of cfg80211) then user space wouldn't need to be involved. The driver can do it, mac80211 does. It's just a matter of what the driver will do or not. > First of all I was wondering how to handle interfaces creation. After a > firmware crash we have: > 1) Interfaces created in Linux > 2) No corresponsing interfaces in firmware > Syncing that (re-creating in-firmware firmwares) may be a bit tricky > depending on a driver and hardware. We do that in mac80211, it works fine. Why would it be tricky? If something fails, I think we force that interface to go down. > For some cases it could be easier to > delete all interfaces and ask user space to setup wiphy (create required > interfaces) again. I'm not sure if that's acceptable though? > > If we agree interfaces should stay and driver simply should configure > firmware properly, then we need all data as explained earlier. struct > cfg80211_ap_settings is not available during runtime. How should we > handle that problem? You can cache it in the driver in whatever format makes sense. > I was aiming for a brutal force solution: just make user space > interfaces need a full setup just at they were just created. You can still do that btw, just unregister and re-register the wiphy. johannes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
On 20.09.2019 16:01, Jouni Malinen wrote: On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote: Hardware or firmware instability may result in unusable wiphy. In such cases usually a hardware reset is needed. To allow a full recovery kernel has to indicate problem to the user space. Why? Shouldn't the driver be able to handle this on its own since all the previous configuration was done through the driver anyway. As far as I know, there are drivers that do indeed try to do this and handle it successfully at least for station mode. AP mode may be more complex, but for that one, I guess it would be fine to drop all associations (and provide indication of that to user space) and just restart the BSS. Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't cache all settings, consider e.g. nl80211_start_ap(). It builds struct cfg80211_ap_settings using info from nl80211 message and passes it to the driver (rdev_start_ap()). Once it's done it caches only a small subset of all setup data. In other words driver doesn't have enough info to recover interfaces setup. This new nl80211 command lets user space known wiphy has crashed and has been just recovered. When applicable it should result in supplicant or authenticator reconfiguring all interfaces. For me, that is not really "recovered" if some additional reconfiguration steps are needed.. I'd like to get a more detailed view on what exactly might need to be reconfigured and how would user space know what exactly to do. Or would the plan here be that the driver would not even indicate this crash if it is actually able to internally recover fully from the firmware restart? I meant that hardware has been recovered & is operational again (driver can talk to it). I expected user space to reconfigure all interfaces using the same settings that were used on previous run. If driver were able to recover interfaces setup on its own (with a help of cfg80211) then user space wouldn't need to be involved. I'd like to use this new cfg80211_crash_report() in brcmfmac after a successful recovery from a FullMAC firmware crash. Later on I'd like to modify hostapd to reconfigure wiphy using a previously used setup. So this implies that at least something would need to happen in AP mode. Do you have a list of items that the driver cannot do on its own and why it would be better to do them from user space? First of all I was wondering how to handle interfaces creation. After a firmware crash we have: 1) Interfaces created in Linux 2) No corresponsing interfaces in firmware Syncing that (re-creating in-firmware firmwares) may be a bit tricky depending on a driver and hardware. For some cases it could be easier to delete all interfaces and ask user space to setup wiphy (create required interfaces) again. I'm not sure if that's acceptable though? If we agree interfaces should stay and driver simply should configure firmware properly, then we need all data as explained earlier. struct cfg80211_ap_settings is not available during runtime. How should we handle that problem? I'm OpenWrt developer & user and I got annoyed by my devices not auto recovering after various failures. There are things I cannot fix (hw failures or closed fw crashes) but I still expect my devices to get back to operational state as soon as possible on their own. I fully agree with the auto recovery being important thing to cover for this, but I'm not yet convinced that this needs user space action. Or if it does, there would need to be more detailed way of indicating what exactly is needed for user space to do. The proposed change here is just saying "hey, I crashed and did something to get the hardware/firmware responding again" which does not really tell much to user space other than potentially requiring full disable + re-enable for the related interfaces. And that is something that should not actually be done in all cases of firmware crashes since there are drivers that handle recovery in a manner that is in practice completely transparent to user space. I was aiming for a brutal force solution: just make user space interfaces need a full setup just at they were just created. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] sunxi: enable audio for sun4i
On 26/09/2019 11:55, Yousong Zhou wrote: On Mon, 23 Sep 2019 at 22:01, Andre Heider wrote: Enable SND_SUN4I_CODEC and SND_SUN4I_SPDIF. Tested on cubieboard2. Signed-off-by: Andre Heider The module should be available as package kmod-sound-soc-sunxi. See target/linux/sunxi/modules.mk . Does this work for you? yousong D'oh, I was looking for such a kmod package, but obviously missed it. Yes, that works too, thanks! Feel free to decide if patch 1/2 should be applied or not. Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] sunxi: enable audio for sun4i
On Mon, 23 Sep 2019 at 22:01, Andre Heider wrote: > > Enable SND_SUN4I_CODEC and SND_SUN4I_SPDIF. > > Tested on cubieboard2. > > Signed-off-by: Andre Heider The module should be available as package kmod-sound-soc-sunxi. See target/linux/sunxi/modules.mk . Does this work for you? yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H
Hi Adrian, On Tue, Sep 24, 2019 at 6:22 PM wrote: > I'm all about consistency. I just scanned the image definitions in ramips: > > ... > > The only device deviating from the pattern "zbtlink_zbt-something" is > zbtlink_we1026-5g-16m. > > So, IMO the correct solution _in terms of consistency_ would be to rename > zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your > device support for the -H to that scheme. > > Do you agree? If yes, you could either implement all changes within or before > your patch 1/2. Or I could send a patch for that and you rebase on it. > > What do you think? I am fine with either approach. I will not have time to look at this device again before the weekend, so I will take whatever is in the tree then and rebase + apply fixes. If you patch has not been accepted/merged, I will change the naming of the 1026-devices. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] openwrt based router
Can I sell openwrt based router ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
