Re: [OpenWrt-Devel] Wifi is broken
On Sat, 2019-11-16 at 17:27 +0100, Daniel Golle wrote: > Hi, > > On Sat, Nov 16, 2019 at 09:17:08AM +0100, e9hack wrote: > > Hi, > > > > this commit > > > > commit 000b7687bc50be5b0f1161f4bf8ceb85c495c395 > > mac80211: restore mac80211_interface_cleanup() > > > > breaks wifi on my tp-link archer C7 router. After update, only the > > 5G wifi will be activated. The 2.4G wifi doesn't start. I try to > > recover from this by shuting down and restart wifi by executing > > 'wifi down; sleep 30; wifi &'. Afterwards, wifi doesn't start > > anymore. I modify mac80211.sh to get some more log entries: > > I've reverted that commit and applied a more sophisticated fix > instead. > Please retest and report if that works better. > > > Cheers > > Daniel > Just another nitpick. Could you please expose the new "reconf" wifi parameter in the wifi --help? That makes it much easier for external scripts to check for that. Thanks! Dirk > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] mac80211: Adapt to changes to skb_get_hash_perturb()
From: Hauke Mehrtens
The skb_get_hash_perturb() function now takes a siphash_key_t instead of
an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
switch to siphash"). Use the correct type in the fq header file
depending on the kernel version.
Signed-off-by: Hauke Mehrtens
Signed-off-by: Stefan Lippers-Hollmann
---
...t-to-changes-to-skb_get_hash_perturb.patch | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
The second hunk was missing from include/net/fq_impl.h, which resulted
in a build error on 4.19.84:
Building backport-include/backport/autoconf.h ... done.
CC [M]
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o
In file included from
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.c:28:
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:
In function 'fq_init':
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:319:19:
error: incompatible types when assigning to type 'siphash_key_t' {aka 'struct
'} from type 'u32' {aka 'unsigned int'}
fq->perturbation = prandom_u32();
^
make[9]: *** [scripts/Makefile.build:304:
/tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o]
Error 1
This v2 version has been tested in ipq806x/ kernel v4.19.84
build-tested (master):
- ath79/ kernel v4.19.84
- ath79/ kernel v4.14.154
- ipq806x/ kernel v4.19.84
- lantiq/ kernel v4.19.84
runtime tested:
- ath79/ kernel v4.19.84 (only short testing)
- ath79/ kernel v4.14.154 (only short testing)
- ipq806x/ kernel v4.19.84 (running fine for the last 4 hours)
I have not tested old/ unaffected kernels (v4.19.82, ...) so far.
diff --git
a/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
new file mode 100644
index 00..7e40180b93
--- /dev/null
+++
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
@@ -0,0 +1,68 @@
+From e3c57dd949835419cee8d3b45db38de58bf6ebd5 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Mon, 18 Nov 2019 01:13:37 +0100
+Subject: [PATCH] backports: Adapt to changes to skb_get_hash_perturb()
+
+The skb_get_hash_perturb() function now takes a siphash_key_t instead of
+an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
+switch to siphash"). Use the correct type in the fq header file
+depending on the kernel version.
+
+Signed-off-by: Hauke Mehrtens
+---
+ include/net/fq.h | 8
+ include/net/fq_impl.h | 8
+ 2 files changed, 16 insertions(+)
+
+--- a/include/net/fq.h
b/include/net/fq.h
+@@ -69,7 +69,15 @@ struct fq {
+ struct list_head backlogs;
+ spinlock_t lock;
+ u32 flows_cnt;
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ siphash_key_t perturbation;
++#else
+ u32 perturbation;
++#endif
+ u32 limit;
+ u32 memory_limit;
+ u32 memory_usage;
+--- a/include/net/fq_impl.h
b/include/net/fq_impl.h
+@@ -108,7 +108,15 @@ begin:
+
+ static u32 fq_flow_idx(struct fq *fq, struct sk_buff *skb)
+ {
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ u32 hash = skb_get_hash_perturb(skb, >perturbation);
++#else
+ u32 hash = skb_get_hash_perturb(skb, fq->perturbation);
++#endif
+
+ return reciprocal_scale(hash, fq->flows_cnt);
+ }
+@@ -308,7 +316,15 @@ static int fq_init(struct fq *fq, int fl
+ INIT_LIST_HEAD(>backlogs);
+ spin_lock_init(>lock);
+ fq->flows_cnt = max_t(u32, flows_cnt, 1);
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ get_random_bytes(>perturbation, sizeof(fq->perturbation));
++#else
+ fq->perturbation = prandom_u32();
++#endif
+ fq->quantum = 300;
+ fq->limit = 8192;
+ fq->memory_limit = 16 << 20; /* 16 MBytes */
--
2.24.0
___
openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireless-regdb: Make it build with python2
Hauke Mehrtens [2019-11-17 23:59:37]: > This backports a patch to build it work with python2 in addition to > python3. > > Signed-off-by: Hauke Mehrtens Acked-by: Petr Štetiar > After this patch went into master I would like to backport all the > changes for wireless-regdb from master to OpenWrt 19.07. > There are already some changes to the regulatory rules in this database > and I would like to stay close to the current legal guidelines for > OpenWrt 19.07 as well. Makes sense. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireless-regdb: Make it build with python2
On 18/11/19 08:42, Etienne Champetier wrote: Hi Hauke, Le dim. 17 nov. 2019 à 15:00, Hauke Mehrtens a écrit : This backports a patch to build it work with python2 in addition to python3. Why not make the scripts "/usr/bin/env python3" and require python 3 in 19.07 ? (I'm stuborn but I don't understand trying to keep python2 alive or using unversionned python) Cheers Etienne I read some discussion about this on a Github PR. Other scripts that were ported to python3 had issues with python3 later and had to be fixed. They decided that switching all python scripts to python3 in 19.07 release was too risky, especially because it is late already so they are just making sure they are run with python2. Scripts in master are migrated to python3 and will have a lot of time to find bugs and be fixed before next stable release. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireless-regdb: Make it build with python2
Hi Hauke,
Le dim. 17 nov. 2019 à 15:00, Hauke Mehrtens a écrit :
>
> This backports a patch to build it work with python2 in addition to
> python3.
Why not make the scripts "/usr/bin/env python3" and require python 3 in 19.07 ?
(I'm stuborn but I don't understand trying to keep python2 alive or
using unversionned python)
Cheers
Etienne
>
> Signed-off-by: Hauke Mehrtens
> ---
>
> After this patch went into master I would like to backport all the
> changes for wireless-regdb from master to OpenWrt 19.07.
> There are already some changes to the regulatory rules in this database
> and I would like to stay close to the current legal guidelines for
> OpenWrt 19.07 as well.
>
> ...regdb-fix-compatibility-with-python2.patch | 58 +++
> 1 file changed, 58 insertions(+)
> create mode 100644
> package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
>
> diff --git
> a/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
>
> b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
> new file mode 100644
> index 00..81f50f5dc0
> --- /dev/null
> +++
> b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
> @@ -0,0 +1,58 @@
> +From 651e39dee8605995b736b6056c6f7dc5c5a9c948 Mon Sep 17 00:00:00 2001
> +From: Johannes Berg
> +Date: Thu, 22 Aug 2019 21:46:27 +0200
> +Subject: [PATCH] regdb: fix compatibility with python2
> +
> +Various changes in the commit mentioned below broke
> +compatibility with python2. Restore it in a way that
> +makes it worth with both versions.
> +
> +Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
> +Signed-off-by: Johannes Berg
> +Signed-off-by: Seth Forshee
> +---
> + db2bin.py | 2 +-
> + db2fw.py | 2 +-
> + dbparse.py | 3 +--
> + 3 files changed, 3 insertions(+), 4 deletions(-)
> +
> +--- a/db2bin.py
> b/db2bin.py
> +@@ -118,7 +118,7 @@ reg_country_ptr.set()
> + for alpha2 in countrynames:
> + coll = countries[alpha2]
> + # struct regdb_file_reg_country
> +-output.write(struct.pack('>BBxBI', alpha2[0], alpha2[1],
> coll.dfs_region, reg_rules_collections[coll.permissions]))
> ++output.write(struct.pack('>2sxBI', alpha2, coll.dfs_region,
> reg_rules_collections[coll.permissions]))
> +
> +
> + if len(sys.argv) > 3:
> +--- a/db2fw.py
> b/db2fw.py
> +@@ -85,7 +85,7 @@ countrynames = list(countries)
> + countrynames.sort()
> + for alpha2 in countrynames:
> + coll = countries[alpha2]
> +-output.write(struct.pack('>BB', alpha2[0], alpha2[1]))
> ++output.write(struct.pack('>2s', alpha2))
> + country_ptrs[alpha2] = PTR(output)
> + output.write(b'\x00' * 4)
> +
> +--- a/dbparse.py
> b/dbparse.py
> +@@ -1,6 +1,5 @@
> + #!/usr/bin/env python
> +
> +-from builtins import bytes
> + from functools import total_ordering
> + import sys, math
> + from math import ceil, log
> +@@ -359,7 +358,7 @@ class DBParser(object):
> + for cname in cnames:
> + if len(cname) != 2:
> + self._warn("country '%s' not alpha2" % cname)
> +-cname = bytes(cname, 'ascii')
> ++cname = cname.encode('ascii')
> + if not cname in self._countries:
> + self._countries[cname] = Country(dfs_region,
> comments=self._comments)
> + self._current_countries[cname] = self._countries[cname]
> --
> 2.20.1
>
>
> ___
> 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
[OpenWrt-Devel] [PATCH] mac80211: Adapt to changes to skb_get_hash_perturb()
The skb_get_hash_perturb() function now takes a siphash_key_t instead of
an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
switch to siphash"). Use the correct type in the fq header file
depending on the kernel version.
Signed-off-by: Hauke Mehrtens
---
Koen feel free to apply this to master and 19.07 branch, I only did a
compile test so far, but I think this is needed for more recent kernel
versions, see my mail to netdev.
...t-to-changes-to-skb_get_hash_perturb.patch | 52 +++
1 file changed, 52 insertions(+)
create mode 100644
package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
diff --git
a/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
new file mode 100644
index 00..3e2a684dca
--- /dev/null
+++
b/package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
@@ -0,0 +1,52 @@
+From e3c57dd949835419cee8d3b45db38de58bf6ebd5 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Mon, 18 Nov 2019 01:13:37 +0100
+Subject: [PATCH] backports: Adapt to changes to skb_get_hash_perturb()
+
+The skb_get_hash_perturb() function now takes a siphash_key_t instead of
+an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
+switch to siphash"). Use the correct type in the fq header file
+depending on the kernel version.
+
+Signed-off-by: Hauke Mehrtens
+---
+ include/net/fq.h | 8
+ include/net/fq_impl.h | 8
+ 2 files changed, 16 insertions(+)
+
+--- a/include/net/fq.h
b/include/net/fq.h
+@@ -69,7 +69,15 @@ struct fq {
+ struct list_head backlogs;
+ spinlock_t lock;
+ u32 flows_cnt;
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ siphash_key_t perturbation;
++#else
+ u32 perturbation;
++#endif
+ u32 limit;
+ u32 memory_limit;
+ u32 memory_usage;
+--- a/include/net/fq_impl.h
b/include/net/fq_impl.h
+@@ -108,7 +108,15 @@ begin:
+
+ static u32 fq_flow_idx(struct fq *fq, struct sk_buff *skb)
+ {
++#if LINUX_VERSION_IS_GEQ(5,3,10) || \
++LINUX_VERSION_IN_RANGE(4,19,83, 4,20,0) || \
++LINUX_VERSION_IN_RANGE(4,14,153, 4,15,0) || \
++LINUX_VERSION_IN_RANGE(4,9,200, 4,10,0) || \
++LINUX_VERSION_IN_RANGE(4,4,200, 4,5,0)
++ u32 hash = skb_get_hash_perturb(skb, >perturbation);
++#else
+ u32 hash = skb_get_hash_perturb(skb, fq->perturbation);
++#endif
+
+ return reciprocal_scale(hash, fq->flows_cnt);
+ }
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: nf_conntrack_rtcache: fix cleanup on netns delete and rmmod
On 11/13/19 6:12 PM, Yousong Zhou wrote:
> Fixes FS#1472, FS#2353, FS#2426
>
> Fixes: b3f95490 ("kernel: generic: Add kernel 4.14 support")
> Signed-off-by: Yousong Zhou
Acked-by: Hauke Mehrtens
Thanks for fixing this problem, this should also go into 19.07 and 18.06.
> ---
> .../020-backport_netfilter_rtcache.patch | 14 +-
> .../020-backport_netfilter_rtcache.patch | 14 +-
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git
> a/target/linux/generic/backport-4.14/020-backport_netfilter_rtcache.patch
> b/target/linux/generic/backport-4.14/020-backport_netfilter_rtcache.patch
> index 8a6fba4307..d745a97026 100644
> --- a/target/linux/generic/backport-4.14/020-backport_netfilter_rtcache.patch
> +++ b/target/linux/generic/backport-4.14/020-backport_netfilter_rtcache.patch
> @@ -127,7 +127,7 @@ Signed-off-by: Florian Westphal
> # netlink interface for nf_conntrack
> --- /dev/null
> +++ b/net/netfilter/nf_conntrack_rtcache.c
> -@@ -0,0 +1,428 @@
> +@@ -0,0 +1,440 @@
> +/* route cache for netfilter.
> + *
> + * (C) 2014 Red Hat GmbH
> @@ -444,6 +444,11 @@ Signed-off-by: Florian Westphal
> +.destroy = nf_conn_rtcache_destroy,
> +};
> +
> ++static int __net_init rtcache_net_init(struct net *net)
> ++{
> ++return nf_register_net_hooks(net, rtcache_ops, ARRAY_SIZE(rtcache_ops));
> ++}
> ++
> +static void __net_exit rtcache_net_exit(struct net *net)
> +{
> +/* remove hooks so no new connections get rtcache extension */
> @@ -451,6 +456,7 @@ Signed-off-by: Florian Westphal
> +}
> +
> +static struct pernet_operations rtcache_ops_net_ops = {
> ++.init = rtcache_net_init,
> +.exit = rtcache_net_exit,
> +};
> +
> @@ -531,6 +537,11 @@ Signed-off-by: Florian Westphal
> +synchronize_net();
> +
> +unregister_netdevice_notifier(_rtcache_notifier);
> ++unregister_pernet_subsys(_ops_net_ops);
> ++for_each_net(net)
> ++nf_unregister_net_hooks(net, rtcache_ops,
> ARRAY_SIZE(rtcache_ops));
> ++
> ++synchronize_net();
> +
> +rtnl_lock();
> +
> @@ -547,6 +558,7 @@ Signed-off-by: Florian Westphal
> +}
> +
> +rtnl_unlock();
> ++
> +synchronize_net();
> +nf_ct_extend_unregister(_extend);
> +}
> diff --git
> a/target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch
> b/target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch
> index 3a35381ce3..2d84bc2acf 100644
> --- a/target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch
> +++ b/target/linux/generic/backport-4.19/020-backport_netfilter_rtcache.patch
> @@ -127,7 +127,7 @@ Signed-off-by: Florian Westphal
> # netlink interface for nf_conntrack
> --- /dev/null
> +++ b/net/netfilter/nf_conntrack_rtcache.c
> -@@ -0,0 +1,428 @@
> +@@ -0,0 +1,440 @@
> +/* route cache for netfilter.
> + *
> + * (C) 2014 Red Hat GmbH
> @@ -444,6 +444,11 @@ Signed-off-by: Florian Westphal
> +.destroy = nf_conn_rtcache_destroy,
> +};
> +
> ++static int __net_init rtcache_net_init(struct net *net)
> ++{
> ++return nf_register_net_hooks(net, rtcache_ops, ARRAY_SIZE(rtcache_ops));
> ++}
> ++
> +static void __net_exit rtcache_net_exit(struct net *net)
> +{
> +/* remove hooks so no new connections get rtcache extension */
> @@ -451,6 +456,7 @@ Signed-off-by: Florian Westphal
> +}
> +
> +static struct pernet_operations rtcache_ops_net_ops = {
> ++.init = rtcache_net_init,
> +.exit = rtcache_net_exit,
> +};
> +
> @@ -531,6 +537,11 @@ Signed-off-by: Florian Westphal
> +synchronize_net();
> +
> +unregister_netdevice_notifier(_rtcache_notifier);
> ++unregister_pernet_subsys(_ops_net_ops);
> ++for_each_net(net)
> ++nf_unregister_net_hooks(net, rtcache_ops,
> ARRAY_SIZE(rtcache_ops));
> ++
> ++synchronize_net();
> +
> +rtnl_lock();
> +
> @@ -547,6 +558,7 @@ Signed-off-by: Florian Westphal
> +}
> +
> +rtnl_unlock();
> ++
> +synchronize_net();
> +nf_ct_extend_unregister(_extend);
> +}
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: switch to upstream owl-loader driver
On 11/17/19 2:44 AM, Christian Lamparter wrote: > The Owl Loader (named after the codename that Atheros gave > these devices back in the day) has been accepted upstream. > > This patch removes the "misc" driver OpenWrt had and adds > the remaining differences against the version that ships > with 5.4-rc1 into a separate "120-owl-loader-compat.patch" > file that can be cut down once AR71XX is being dealt with. > > Note: I decided to keep the existing (kmod-)owl-loader > package name around for now. The kernel module file in > the kmod package will be called ath9k_pci_owl_loader.ko > though. > > Signed-off-by: Christian Lamparter Acked-by: Hauke Mehrtens > --- > package/kernel/linux/modules/wireless.mk | 21 -- > package/kernel/mac80211/ath.mk| 20 +- > .../patches/ath/120-owl-loader-compat.patch | 67 + > .../generic/files/drivers/misc/owl-loader.c | 246 -- > .../hack-4.14/835-misc-owl_loader.patch | 52 > .../hack-4.19/835-misc-owl_loader.patch | 52 > .../hack-4.9/835-misc-owl_loader.patch| 52 > 7 files changed, 86 insertions(+), 424 deletions(-) > create mode 100644 > package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch > delete mode 100644 target/linux/generic/files/drivers/misc/owl-loader.c > delete mode 100644 target/linux/generic/hack-4.14/835-misc-owl_loader.patch > delete mode 100644 target/linux/generic/hack-4.19/835-misc-owl_loader.patch > delete mode 100644 target/linux/generic/hack-4.9/835-misc-owl_loader.patch > > diff --git a/package/kernel/linux/modules/wireless.mk > b/package/kernel/linux/modules/wireless.mk > index 7b1c663567..72e2bf477b 100644 > --- a/package/kernel/linux/modules/wireless.mk > +++ b/package/kernel/linux/modules/wireless.mk > @@ -41,24 +41,3 @@ define KernelPackage/net-rtl8192su/description > endef > > $(eval $(call KernelPackage,net-rtl8192su)) > - > - > -define KernelPackage/owl-loader > - SUBMENU:=$(WIRELESS_MENU) > - TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips > - DEPENDS:=@PCI_SUPPORT > - KCONFIG:=CONFIG_OWL_LOADER > - FILES:=$(LINUX_DIR)/drivers/misc/owl-loader.ko > - AUTOLOAD:=$(call AutoProbe,owl-loader) > -endef > - > -define KernelPackage/owl-loader/description > - Kernel module that helps to initialize certain Qualcomm > - Atheros' PCI(e) Wifi chips, which have the init data > - (which contains the PCI device ID for example) stored > - together with the calibration data in the file system. > - > - This is necessary for devices like the Cisco Meraki Z1. > -endef > - > -$(eval $(call KernelPackage,owl-loader)) > diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk > index 64aac41b4d..788131b751 100644 > --- a/package/kernel/mac80211/ath.mk > +++ b/package/kernel/mac80211/ath.mk > @@ -1,6 +1,6 @@ > PKG_DRIVERS += \ > ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc > ath10k \ > - carl9170 > + carl9170 owl-loader > > PKG_CONFIG_DEPENDS += \ > CONFIG_PACKAGE_ATH_DEBUG \ > @@ -38,6 +38,7 @@ config-$(CONFIG_PACKAGE_ATH_SPECTRAL) += > ATH9K_COMMON_SPECTRAL ATH10K_SPECTRAL > config-$(CONFIG_PACKAGE_ATH_DYNACK) += ATH9K_DYNACK > config-$(call config_package,ath9k) += ATH9K > config-$(call config_package,ath9k-common) += ATH9K_COMMON > +config-$(call config_package,owl-loader) += ATH9K_PCI_NO_EEPROM > config-$(CONFIG_TARGET_ar71xx) += ATH9K_AHB > config-$(CONFIG_TARGET_ath79) += ATH9K_AHB > config-$(CONFIG_TARGET_ipq40xx) += ATH10K_AHB > @@ -274,3 +275,20 @@ define KernelPackage/carl9170 >FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/carl9170/carl9170.ko >AUTOLOAD:=$(call AutoProbe,carl9170) > endef > + > +define KernelPackage/owl-loader > + $(call KernelPackage/mac80211/Default) > + TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips > + DEPENDS:=@PCI_SUPPORT +kmod-ath9k > + > FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.ko > + AUTOLOAD:=$(call AutoProbe,ath9k_pci_owl_loader) > +endef > + > +define KernelPackage/owl-loader/description > + Kernel module that helps to initialize certain Qualcomm > + Atheros' PCI(e) Wifi chips, which have the init data > + (which contains the PCI device ID for example) stored > + together with the calibration data in the file system. > + > + This is necessary for devices like the Cisco Meraki Z1. > +endef > diff --git a/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch > b/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch > new file mode 100644 > index 00..256fca45e4 > --- /dev/null > +++ b/package/kernel/mac80211/patches/ath/120-owl-loader-compat.patch > @@ -0,0 +1,67 @@ > +From: Christian Lamparter > +Date: Sat, 16 Nov 2019 19:25:24 +0100 > +Subject: [PATCH] owl_loader: compatibility patch > + > +This patch includes OpenWrt specific changes that are > +not included in the upstream owl-loader. > + > +These include: > +
[OpenWrt-Devel] [PATCH] wireless-regdb: Make it build with python2
This backports a patch to build it work with python2 in addition to
python3.
Signed-off-by: Hauke Mehrtens
---
After this patch went into master I would like to backport all the
changes for wireless-regdb from master to OpenWrt 19.07.
There are already some changes to the regulatory rules in this database
and I would like to stay close to the current legal guidelines for
OpenWrt 19.07 as well.
...regdb-fix-compatibility-with-python2.patch | 58 +++
1 file changed, 58 insertions(+)
create mode 100644
package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
diff --git
a/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
new file mode 100644
index 00..81f50f5dc0
--- /dev/null
+++
b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
@@ -0,0 +1,58 @@
+From 651e39dee8605995b736b6056c6f7dc5c5a9c948 Mon Sep 17 00:00:00 2001
+From: Johannes Berg
+Date: Thu, 22 Aug 2019 21:46:27 +0200
+Subject: [PATCH] regdb: fix compatibility with python2
+
+Various changes in the commit mentioned below broke
+compatibility with python2. Restore it in a way that
+makes it worth with both versions.
+
+Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
+Signed-off-by: Johannes Berg
+Signed-off-by: Seth Forshee
+---
+ db2bin.py | 2 +-
+ db2fw.py | 2 +-
+ dbparse.py | 3 +--
+ 3 files changed, 3 insertions(+), 4 deletions(-)
+
+--- a/db2bin.py
b/db2bin.py
+@@ -118,7 +118,7 @@ reg_country_ptr.set()
+ for alpha2 in countrynames:
+ coll = countries[alpha2]
+ # struct regdb_file_reg_country
+-output.write(struct.pack('>BBxBI', alpha2[0], alpha2[1], coll.dfs_region,
reg_rules_collections[coll.permissions]))
++output.write(struct.pack('>2sxBI', alpha2, coll.dfs_region,
reg_rules_collections[coll.permissions]))
+
+
+ if len(sys.argv) > 3:
+--- a/db2fw.py
b/db2fw.py
+@@ -85,7 +85,7 @@ countrynames = list(countries)
+ countrynames.sort()
+ for alpha2 in countrynames:
+ coll = countries[alpha2]
+-output.write(struct.pack('>BB', alpha2[0], alpha2[1]))
++output.write(struct.pack('>2s', alpha2))
+ country_ptrs[alpha2] = PTR(output)
+ output.write(b'\x00' * 4)
+
+--- a/dbparse.py
b/dbparse.py
+@@ -1,6 +1,5 @@
+ #!/usr/bin/env python
+
+-from builtins import bytes
+ from functools import total_ordering
+ import sys, math
+ from math import ceil, log
+@@ -359,7 +358,7 @@ class DBParser(object):
+ for cname in cnames:
+ if len(cname) != 2:
+ self._warn("country '%s' not alpha2" % cname)
+-cname = bytes(cname, 'ascii')
++cname = cname.encode('ascii')
+ if not cname in self._countries:
+ self._countries[cname] = Country(dfs_region,
comments=self._comments)
+ self._current_countries[cname] = self._countries[cname]
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] base-files: indicate initial setup by uci system config option
Adrian Schmutzler [2019-11-08 13:05:19]: > This provides a uci system config setting that will be set only > during initial setup. This can be used by uci-defaults script to > determine whether they are run during initial setup or after a > sysupgrade. I use similar stuff in my config scripts, just differently. I do `set system.@system[-1].firstboot_done='1'` in order to know, that the system was already first time booted. So if the user performs sysupgrade but prefers to keep settings, I don't run uci-default scripts which performs one time setup stuff, like setting hostname, generating unique auth token etc. basically it boils down to `is_firstboot || exit 0` in those one time uci-default scripts. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 335a5b: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 335a5b266fa6e549e2173c6d6d02359f183df84e https://github.com/sdwalker/sdwalker.github.io/commit/335a5b266fa6e549e2173c6d6d02359f183df84e Author: Stephen Walker Date: 2019-11-17 (Sun, 17 Nov 2019) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wifi is broken
Am 16.11.2019 um 17:27 schrieb Daniel Golle: > Hi, > > On Sat, Nov 16, 2019 at 09:17:08AM +0100, e9hack wrote: >> Hi, >> >> this commit >> >> commit 000b7687bc50be5b0f1161f4bf8ceb85c495c395 >> mac80211: restore mac80211_interface_cleanup() >> >> breaks wifi on my tp-link archer C7 router. After update, only the 5G wifi >> will be activated. The 2.4G wifi doesn't start. I try to recover from this >> by shuting down and restart wifi by executing 'wifi down; sleep 30; wifi &'. >> Afterwards, wifi doesn't start anymore. I modify mac80211.sh to get some >> more log entries: > > I've reverted that commit and applied a more sophisticated fix instead. > Please retest and report if that works better. After your fix, both networks does start again. Thanks! Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export
Hi Piotr, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Piotr Dymacz > Sent: Samstag, 16. November 2019 15:51 > To: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Cc: bj...@mork.no; 'Enrico Mioso' ; 'Mathias Kresin' > ; 'Birger Koblitz' > Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of > gpio-export > > Hi Adrian, > > Sorry for a late reply. > > On 06.11.2019 16:47, Adrian Schmutzler wrote: > > Hi, > > > >> Wouldn't it make more sense to spend time now on implementing > >> future-proof solution and switch to it when it's ready? > > > > Obviously, yes. But for the meantime, I'd like to have a less-arbitrary > > status > quo. > > For me, in that case, I would leave decision to the author of support _and_ > reviewer/committer. > > >> I believe the major issue here is that there is no 'in place' > >> replacement for 'gpio-export' (or I'm just not aware of it). > >> > > [...] > >> > >> Are there any other reasons to get rid of 'gpio-export' _now_, other > >> than the fact upstream rejected this approach? > >> > > [...] > >> > >> '03_gpio_switches' doesn't handle inputs. > >> > >> Of course, it has advantages, like the fact it makes the GPIO setup > >> uci-based but on the other hand... it does its job fairly late during > >> bootup. In some cases, you might want to, for example, enable power > >> for 3/4G modem as early as possible, to give it time to register in > >> network. > >> > >> Anyway, under the hood, it's the same approach, export named GPIO > >> using _deprecated_ sysfs. Excluding uci and place in boot time where > >> it happens, the difference is where the GPIOs are defined, DTS vs. > >> user-space scripts. > >> > > > > So, both 03_gpio_switches and gpio-hogs provide less functionality > > than gpio-exports with no striking benefit. From that point of view we > > should actually allow gpio-exports in device support submissions > > again, and actually discourage gpio_hogs for the status quo ... (and > > it would be better to convert hogs to exports and not the other way > > around ...) > > Someone could say that 'gpio-hog' is the accepted solution in upstream and > the 'gpio-export' is the rejected one so we need to get rid of it ASAP. > > Personally, I don't see now any good reason to convert everything back to > 'gpio-export'. I would be just more pragmatic when reviewing and accepting > boards support - if the author thinks that it would be better (look at it from > usability point of view) to have user-space control on a specific GPIO line, I > wouldn't ask him to use 'gpio-hog'. For me, also the uci approach is fine if > there is no need to setup GPIO before the whole boot process finishes. > > Still, in some cases maybe 'fixed-regulator' would fit even better than > discussed solution. IIRC, at least in case of the USB, there is still a way > to have > control on the VBUS if 'fixed-regulator' is used (unload the driver, power > goes off, load it back, power goes on). > > I just don't think it makes sense to look for a consensus now on something > which for sure has to go away/change in, I hope close future. okay, I accept that. I've marked this particular patch with "Rejected" already a week ago I think, but since it is consensus that replacement of gpio-export by gpio-hog reduces functionality, I will also mark the other patches attempting this conversion as "Rejected". Best Adrian > > -- > Cheers, > Piotr > > > > > Best > > > > Adrian > > > > > > ___ > > 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 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] introduce label_mac into hostname and SSID
Hi Adrian, On 17.11.2019 00:23, m...@adrianschmutzler.de wrote: Hi Piotr, Thank you for providing extensive feedback on this topic. -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Piotr Dymacz Sent: Samstag, 16. November 2019 16:32 To: Adrian Schmutzler ; openwrt- de...@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH 0/2] introduce label_mac into hostname and SSID Hi Adrian, On 08.11.2019 12:48, Adrian Schmutzler wrote: > This patchset will introduce the label MAC address into the _default_ > hostname and SSID of OpenWrt devices. Devices installed after these > commits (or upgraded with sysupgrade -n) will have their hostname and > SSID set to OpenWrt-ddeeff where "ddeeff" is the EUI of the label MAC > address aa:bb:cc:dd:ee:ff. As this is something which touches essential system setting (identification), I would really like other team members to join the discussion before it sneaks in again. Especially because this was already merged and reverted later, after short discussion on IRC. From my point of view, I'm only worried about all the consequences we don't know about, so I would prefer to have this one _optional_. With the label MAC address being available already independent of this patch, it's relatively easy for someone building the image to create custom hostname and SSID in a uci-default script, achieving similar effects as in this patchset with about 10 lines of code. That's correct. For that reason, I do not think that providing a _standardized optional_ rename is worth the effort of maintaining it, as the user could get a much more flexible alternative (manual uci-defaults file) with manageable amount of additional work. Agree. In this context, let me point out that for me personally the important feature is having the label MAC address. What I do in this patchset (which isn't even from me originally) is a nice-to-have additional use of this feature, but I don't heavily insist on it. So, if feedback keeps to be mainly negative, I will bury it and still be fine (and will still be able to use the label MAC address in custom scripts). OK. I also think it would be good to document that new system function 'get_mac_label' somewhere in the Wiki. I know that you worked on the topic already: [0]. On the other hand, I'm fine with the SSID change but I see it's not going to be that straightforward to implement. Also, what I'm thinking about here is which one MAC should be used for the SSID name. The 'label' one which is not available on all devices or maybe the 'phy' one? We had this discussion very early when this was still a PR in GitHub, as initially it actually was using the phy addresses. The argument for using the label MAC was on the one hand that the label MAC address is apparent to the user on the case, while a +1/-1 of this number will be (a little bit) confusing. Secondly, only having the label MAC address would assure having the same SSID for more than one WiFi interface (as it's now the case with default 'OpenWrt'). This was explicitly requested by ynezz (as the only committer reviewing this) back then. I believe SSID is probably first thing users change when they setup their device after installing OpenWrt. Given the fact we don't allow Wi-Fi to be enabled by default, this is more a matter of taste for me. > For devices where no label MAC address has been specified, hostname > and SSIDs will use the former default "OpenWrt". And this is probably the biggest issue I have with the whole idea behind 'label_mac'. As I understand the motivation, I don't like the fact it's not specified (and probably would never be) for all devices so we will have here inconsistency (in essential system settings!) and might end up with confusion. Maybe that's something which should be handled by downstream users/projects (and AFAIK, it is already). Yes, I cannot discuss away this drawback, some devices will have OpenWrt_ddeeff and some will have just OpenWrt. I just never felt (and still feel) about that as being a practical problem. And from my personal experience with downstream projects, the SSID most probably gets overwritten with something completely different anyway, only the change in hostname might matter there. So, I have lots of time to wait for further feedback on this, and I most probably will bury it without too bad feelings if negative feedback continues. At the end, this is just meant as an improvement for the uneducated end user, I will have zero benefit for my personal/downstream projects from this (unlike the label MAC address itself, which is extremely helpful). I think we look at the project from slightly different perspectives. I have (still) a feeling that OpenWrt should be considered more as a platform, framework or kind of a 'base' for building something bigger on it. Just not a fully ready, polished distribution with fireworks where everything is already defined for
[OpenWrt-Devel] [PATCH v2] base-files: config_generate: split macaddr with multiple ifaces
From: Sungbo Eo
netifd does not handle network.@device[x].name properly if it
contains multiple ifaces separated by spaces. Due to this, board.d
lan_mac setup does not work if multiple ifaces are set to LAN by
ucidef_set_interface_lan.
To fix this, create a device node for each member iface when
running config_generate instead. Those are named based on the
member ifname:
ucidef_set_interface_lan "eth0 eth1.1"
ucidef_set_interface_macaddr "lan" "yy:yy:yy:yy:yy:01"
will return
config device 'eth0_dev'
option name 'eth0'
option macaddr 'yy:yy:yy:yy:yy:01'
config device 'eth1_1_dev'
option name 'eth1.1'
option macaddr 'yy:yy:yy:yy:yy:01'
ref: https://github.com/openwrt/openwrt/pull/2542
Signed-off-by: Sungbo Eo
[only use new names, extend description, change commit title]
Signed-off-by: Adrian Schmutzler
---
Changes in v2:
- Remove lan_dev/wan_dev, use new names consistently
I plan to also backport this to at least 19.07 and 18.06, as it's
essentially a fix.
---
package/base-files/files/bin/config_generate | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index 3ca035ca8b..2f62912180 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -85,12 +85,16 @@ generate_network() {
set network.$1.proto='none'
EOF
- [ -n "$macaddr" ] && uci -q batch <<-EOF
- delete network.$1_dev
- set network.$1_dev='device'
- set network.$1_dev.name='$ifname'
- set network.$1_dev.macaddr='$macaddr'
- EOF
+ if [ -n "$macaddr" ]; then
+ for name in $ifname; do
+ uci -q batch <<-EOF
+ delete network.${name/./_}_dev
+ set network.${name/./_}_dev='device'
+ set network.${name/./_}_dev.name='$name'
+ set network.${name/./_}_dev.macaddr='$macaddr'
+ EOF
+ done
+ fi
case "$protocol" in
static)
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] base-files: indicate initial setup by uci system config option
Hi Adrian,
On 17.11.2019 00:36, m...@adrianschmutzler.de wrote:
Hi Piotr,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Piotr Dymacz
Sent: Samstag, 16. November 2019 16:50
To: Adrian Schmutzler ; openwrt-
de...@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH 1/2] base-files: indicate initial setup by
uci system config option
Hi Adrian,
On 08.11.2019 13:05, Adrian Schmutzler wrote:
> This provides a uci system config setting that will be set only during
> initial setup. This can be used by uci-defaults script to determine
> whether they are run during initial setup or after a sysupgrade.
>
> Since the setting is removed again after uci-defaults have been
> processed, it won't be recognized by the user on the running device,
> but can be exploited also for downstream setup tasks.
This looks for me like a misuse of uci configuration and some kind of
workaround for a missing feature, maybe in procd/ubus?
Maybe I'm not familiar enough with it, but I currently can't think of a method
indicating a fresh installation with procd/ubus.
I just don't think uci is the right way for this job. It's used for
configuration, not for storing and clearing some flags about system
state. Your way of using uci for that could introduce false positive
results.
I would look at preinit stage, maybe checking if the writable filesystem
(rootfs_data) is created/ready could be used for detecting the 'initial
setup' state (I'm just not sure if that could work across all targets).
Either way, maybe an env variable, like we have for initramfs images
(INITRAMFS set to 1), would be better?
--
Cheers,
Piotr
NAK on this one from me.
Similar to the label MAC hostname/SSID stuff, this was just a nice-to-have
thing for me. I will mark both patches as rejected.
Best
Adrian
--
Cheers,
Piotr
>
> Signed-off-by: Adrian Schmutzler
> ---
> package/base-files/files/bin/config_generate | 1 +
> .../base-files/files/etc/uci-defaults/90_end-initial-setup| 4
> 2 files changed, 5 insertions(+)
> create mode 100644
> package/base-files/files/etc/uci-defaults/90_end-initial-setup
>
> diff --git a/package/base-files/files/bin/config_generate
> b/package/base-files/files/bin/config_generate
> index b473eba9e9..273561229a 100755
> --- a/package/base-files/files/bin/config_generate
> +++ b/package/base-files/files/bin/config_generate
> @@ -243,6 +243,7 @@ generate_static_system() {
>set system.@system[-1].ttylogin='0'
>set system.@system[-1].log_size='64'
>set system.@system[-1].urandom_seed='0'
> + set system.@system[-1].initial_setup='1'
>
>delete system.ntp
>set system.ntp='timeserver'
> diff --git
> a/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> b/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> new file mode 100644
> index 00..779d858d5f
> --- /dev/null
> +++ b/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> @@ -0,0 +1,4 @@
> +uci -q delete system.@system[0].initial_setup uci commit system
> +
> +exit 0
>
___
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
[OpenWrt-Devel] [PATCH 1/2] ar71xx: fix LED setup for TL-WDR4900 v2
LEDs in mach file for TL-WDR4900 v2 are just used as set up for
Archer C5/C7. However, WDR4900 uses blue front LEDs, while C7 uses
green ones. Despite, in base-files WDR4900 is actually set up with
LED labels containing "blue" for the mentioned LEDs.
This patch creates a separate LED struct for WDR4900, so the
LED can be set up correctly. Despite, the wlan5g LED is removed as
it is controlled by ath9k chip for WDR4900 (in contrast to C5/C7).
Note: While front LEDs are blue, USB LEDs (on the back) are green,
so colors seem mixed for the WDR4900 v2.
Signed-off-by: Adrian Schmutzler
---
.../files/arch/mips/ath79/mach-archer-c7.c| 38 ++-
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
index 304a8c7057..d86cc385f5 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
@@ -105,6 +105,34 @@ static struct gpio_led archer_c7_leds_gpio[] __initdata = {
},
};
+static struct gpio_led wdr4900_leds_gpio[] __initdata = {
+ {
+ .name = "tp-link:blue:qss",
+ .gpio = ARCHER_C7_GPIO_LED_QSS,
+ .active_low = 1,
+ },
+ {
+ .name = "tp-link:blue:system",
+ .gpio = ARCHER_C7_GPIO_LED_SYSTEM,
+ .active_low = 1,
+ },
+ {
+ .name = "tp-link:blue:wlan2g",
+ .gpio = ARCHER_C7_GPIO_LED_WLAN2G,
+ .active_low = 1,
+ },
+ {
+ .name = "tp-link:green:usb1",
+ .gpio = ARCHER_C7_GPIO_LED_USB1,
+ .active_low = 1,
+ },
+ {
+ .name = "tp-link:green:usb2",
+ .gpio = ARCHER_C7_GPIO_LED_USB2,
+ .active_low = 1,
+ },
+};
+
static struct gpio_keys_button archer_c7_gpio_keys[] __initdata = {
{
.desc = "Reset button",
@@ -210,8 +238,6 @@ static void __init common_setup(bool pcie_slot)
u8 tmpmac2[ETH_ALEN];
ath79_register_m25p80(_c7_flash_data);
- ath79_register_leds_gpio(-1, ARRAY_SIZE(archer_c7_leds_gpio),
-archer_c7_leds_gpio);
if (pcie_slot) {
ath79_register_wmac(art + ARCHER_C7_WMAC_CALDATA_OFFSET, mac);
@@ -263,6 +289,8 @@ static void __init archer_c5_setup(void)
ath79_register_gpio_keys_polled(-1, ARCHER_C7_KEYS_POLL_INTERVAL,
ARRAY_SIZE(archer_c7_gpio_keys),
archer_c7_gpio_keys);
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(archer_c7_leds_gpio),
+archer_c7_leds_gpio);
common_setup(true);
}
@@ -274,6 +302,8 @@ static void __init archer_c7_setup(void)
ath79_register_gpio_keys_polled(-1, ARCHER_C7_KEYS_POLL_INTERVAL,
ARRAY_SIZE(archer_c7_gpio_keys),
archer_c7_gpio_keys);
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(archer_c7_leds_gpio),
+archer_c7_leds_gpio);
common_setup(true);
}
@@ -285,6 +315,8 @@ static void __init archer_c7_v2_setup(void)
ath79_register_gpio_keys_polled(-1, ARCHER_C7_KEYS_POLL_INTERVAL,
ARRAY_SIZE(archer_c7_v2_gpio_keys),
archer_c7_v2_gpio_keys);
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(archer_c7_leds_gpio),
+archer_c7_leds_gpio);
common_setup(true);
}
@@ -296,6 +328,8 @@ static void __init tl_wdr4900_v2_setup(void)
ath79_register_gpio_keys_polled(-1, ARCHER_C7_KEYS_POLL_INTERVAL,
ARRAY_SIZE(archer_c7_gpio_keys),
archer_c7_gpio_keys);
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(wdr4900_leds_gpio),
+wdr4900_leds_gpio);
common_setup(false);
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ar71xx: fix buttons for TP-Link TL-WDR4900 v2
TP-Link TL-WDR4900 v2 only has one combined WPS/Reset button, so
don't set up an RFKILL for this device.
Signed-off-by: Adrian Schmutzler
---
.../ar71xx/files/arch/mips/ath79/mach-archer-c7.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
index d86cc385f5..53c539f85a 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c
@@ -169,6 +169,17 @@ static struct gpio_keys_button archer_c7_v2_gpio_keys[]
__initdata = {
},
};
+static struct gpio_keys_button wdr4900_gpio_keys[] __initdata = {
+ {
+ .desc = "Reset button",
+ .type = EV_KEY,
+ .code = KEY_WPS_BUTTON,
+ .debounce_interval = ARCHER_C7_KEYS_DEBOUNCE_INTERVAL,
+ .gpio = ARCHER_C7_GPIO_BTN_RESET,
+ .active_low = 1,
+ },
+};
+
static const struct ar8327_led_info archer_c7_leds_ar8327[] = {
AR8327_LED_INFO(PHY0_0, HW, "tp-link:green:wan"),
AR8327_LED_INFO(PHY1_0, HW, "tp-link:green:lan1"),
@@ -326,8 +337,8 @@ MIPS_MACHINE(ATH79_MACH_ARCHER_C7_V2, "ARCHER-C7-V2",
"TP-LINK Archer C7",
static void __init tl_wdr4900_v2_setup(void)
{
ath79_register_gpio_keys_polled(-1, ARCHER_C7_KEYS_POLL_INTERVAL,
- ARRAY_SIZE(archer_c7_gpio_keys),
- archer_c7_gpio_keys);
+ ARRAY_SIZE(wdr4900_gpio_keys),
+ wdr4900_gpio_keys);
ath79_register_leds_gpio(-1, ARRAY_SIZE(wdr4900_leds_gpio),
wdr4900_leds_gpio);
common_setup(false);
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uqmi: add timeout parameter
On 11/16/19 3:59 PM, Piotr Dymacz wrote:
> Hi Zefir,
>
> On 07.11.2019 12:54, Zefir Kurtisi wrote:
>> Working with Quectel EM12 LTE-module, we observe
>> regular stalls of the QMI interface which cause
>> a request issued by uqmi to hang forever.
>>
>> Most reproducibly this happens after the device
>> has been power-cycled and left untouched for a
>> while (~ 60s+). Most of the time the very first
>> QMI request fails, since it is not responded by
>> the module. This is the strace from such a run
>> (from --get-pin-status):
>>
>> open("/dev/cdc-wdm0", O_RDWR|O_EXCL|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 6
>> fcntl64(6, F_GETFL) = 0x10802 (flags
>> O_RDWR|O_NONBLOCK|O_LARGEFILE)
>> fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
>> epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLRDHUP|EPOLLET, {u32=268567076,
>> u64=1153486808202346496}}) = 0
>> write(6, "\1\17\0\0\0\0\0\1\"\0\4\0\1\1\0\2", 16) = 16
>> clock_gettime(CLOCK_MONOTONIC, {tv_sec=95, tv_nsec=583444789}) = 0
>> clock_gettime(CLOCK_MONOTONIC, {tv_sec=95, tv_nsec=583770264}) = 0
>> epoll_pwait(3,
>> [ hang forever ]
>>
>> After killing the blocked uqmi process, the next
>> request works as expected.
>>
>> We don't know whether this is a device FW issue
>> (we use the latest EM12GPAR01A15M4G) or whether
>> the device enters some undocumented power-save
>> mode after idling for some time.
>
> Could you share this firmware version, is that a generic Quectel or a
> customized
> one? I would like to reproduce and debug the problem but the EM12 I have here
> has
> 'EM12GPAR01A_11_M4G'.
>
> Also, what platform do you use this modem with?
>
Hi Piotr,
we use our own products [1], which are built around a PowerPC (8540) based
platform.
The FW we received from Codico [2], Quectel's distributor and support proxy for
Switzerland. We get preview versions on request, therefore I am not sure if it
can
be posted publicly. I'll check for restrictions and provide the FW if able.
Cheers
[1] https://www.neratec.com/products
[2] https://www.codico.com/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
