* Re: [PATCH v2 6/6] [media] Only descend into directory when CONFIG_MEDIA_SUPPORT is set
From: Arnd Bergmann @ 2017-01-05 23:12 UTC (permalink / raw)
To: Andrew F. Davis
Cc: linuxppc-dev, Russell King, Miguel Ojeda Sandonis, Wolfram Sang,
Richard Purdie, Benjamin Herrenschmidt, Mauro Carvalho Chehab,
Ulf Hansson, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Ingo Molnar, linux-pwm, linux-wireless,
linux-kernel, linux-media
In-Reply-To: <f29ea3de-efb1-a406-db3e-b048e677f3a8@ti.com>
On Thursday, January 5, 2017 4:35:33 PM CET Andrew F. Davis wrote:
> On 01/05/2017 03:42 PM, Arnd Bergmann wrote:
> > On Thursday, January 5, 2017 3:01:58 PM CET Andrew F. Davis wrote:
> >> @@ -109,7 +109,8 @@ obj-$(CONFIG_SERIO) += input/serio/
> >> obj-$(CONFIG_GAMEPORT) += input/gameport/
> >> obj-$(CONFIG_INPUT) += input/
> >> obj-$(CONFIG_RTC_LIB) += rtc/
> >> -obj-y += i2c/ media/
> >> +obj-y += i2c/
> >> +obj-$(CONFIG_MEDIA_SUPPORT) += media/
> >> obj-$(CONFIG_PPS) += pps/
> >> obj-y += ptp/
> >> obj-$(CONFIG_W1) += w1/
> >>
> >
> > This one seems wrong: if CONFIG_MEDIA_SUPPORT=m, but some I2C drivers
> > inside of drivers/media/ are built-in, we will fail to enter the directory,
> > see drivers/media/Makefile.
>
> Not sure if I see this, it looks like everything in drivers/media/
> depends on CONFIG_MEDIA_SUPPORT (directly or indirectly). If
> CONFIG_MEDIA_SUPPORT is =m then all dependents should be locked out of
> being built-in.
>
> Any bool symbol that controls compilation of source that depends on a
> tristate symbol is broken and should be fixed anyway.
I don't think it's this easy, we have a couple of cases where that doesn't
work. I have not looked at the media example in detail, but at least it
looks intentional.
Note that drivers/media is rather creative with expressing dependencies.
Arnd
^ permalink raw reply
* [PATCH v4] rfkill: Add rfkill-any LED trigger
From: Michał Kępień @ 2017-01-06 6:07 UTC (permalink / raw)
To: Johannes Berg, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
which may be useful on laptops with a single "radio LED" and multiple
radio transmitters. The trigger is meant to turn a LED on whenever
there is at least one radio transmitter active and turn it off
otherwise.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
Changes from v3:
- Revert introducing a new bitfield and instead defer LED event firing
to a work queue to prevent conditional locking and ensure the
trigger can really be used from any context. This also voids the
need to take rfkill_global_mutex before calling rfkill_set_block()
in rfkill_resume().
Changes from v2:
- Handle the global mutex properly when rfkill_set_{hw,sw}_state() or
rfkill_set_states() is called from within an rfkill callback. v2
always tried to lock the global mutex in such a case, which led to a
deadlock when an rfkill driver called one of the above functions
from its query or set_block callback. This is solved by defining a
new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the above
callbacks are invoked and cleared afterwards; the functions listed
above use this bitfield to tell rfkill_any_led_trigger_event()
whether the global mutex is currently held or not.
RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as setting
it before invoking the query callback would cause any calls to
rfkill_set_sw_state() made from within that callback to work on
RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change the
way rfkill_set_block() behaves.
- As rfkill_any_led_trigger_event() now takes a boolean argument which
tells it whether the global mutex was already taken by the caller,
all calls to __rfkill_any_led_trigger_event() outside
rfkill_any_led_trigger_event() have been replaced with calls to
rfkill_any_led_trigger_event(true).
Changes from v1:
- take rfkill_global_mutex before calling rfkill_set_block() in
rfkill_resume(); the need for doing this was previously obviated by
908209c ("rfkill: don't impose global states on resume"), but given
that __rfkill_any_led_trigger_event() is called from
rfkill_set_block() unconditionally, each caller of the latter needs
to take care of locking rfkill_global_mutex,
- declare __rfkill_any_led_trigger_event() even when
CONFIG_RFKILL_LEDS=n to prevent implicit declaration errors,
- remove the #ifdef surrounding rfkill_any_led_trigger_{,un}register()
calls to prevent compilation warnings about functions and a label
being defined but not used,
- move the rfkill_any_led_trigger_register() call in rfkill_init()
before the rfkill_handler_init() call to avoid the need to call
rfkill_handler_exit() from rfkill_init() and thus prevent a section
mismatch.
net/rfkill/core.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index afa4f71b4c7b..2064c3a35ef8 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,50 @@ static void rfkill_led_trigger_unregister(struct rfkill *rfkill)
{
led_trigger_unregister(&rfkill->led_trigger);
}
+
+static struct led_trigger rfkill_any_led_trigger;
+static struct work_struct rfkill_any_work;
+
+static void rfkill_any_led_trigger_worker(struct work_struct *work)
+{
+ enum led_brightness brightness = LED_OFF;
+ struct rfkill *rfkill;
+
+ mutex_lock(&rfkill_global_mutex);
+ list_for_each_entry(rfkill, &rfkill_list, node) {
+ if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+ brightness = LED_FULL;
+ break;
+ }
+ }
+ mutex_unlock(&rfkill_global_mutex);
+
+ led_trigger_event(&rfkill_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+ schedule_work(&rfkill_any_work);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+ rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+ INIT_WORK(&rfkill_any_work, rfkill_any_led_trigger_worker);
+ rfkill_any_led_trigger.name = "rfkill-any";
+ rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+ return led_trigger_register(&rfkill_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+ led_trigger_unregister(&rfkill_any_led_trigger);
+ cancel_work_sync(&rfkill_any_work);
+}
#else
static void rfkill_led_trigger_event(struct rfkill *rfkill)
{
@@ -189,6 +233,19 @@ static inline int rfkill_led_trigger_register(struct rfkill *rfkill)
static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
{
}
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+ return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
#endif /* CONFIG_RFKILL_LEDS */
static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
@@ -297,6 +354,7 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
spin_unlock_irqrestore(&rfkill->lock, flags);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
if (prev != curr)
rfkill_event(rfkill);
@@ -477,6 +535,7 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
spin_unlock_irqrestore(&rfkill->lock, flags);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
if (rfkill->registered && prev != blocked)
schedule_work(&rfkill->uevent_work);
@@ -520,6 +579,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
schedule_work(&rfkill->uevent_work);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
return blocked;
}
@@ -569,6 +629,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
schedule_work(&rfkill->uevent_work);
rfkill_led_trigger_event(rfkill);
+ rfkill_any_led_trigger_event();
}
}
EXPORT_SYMBOL(rfkill_set_states);
@@ -985,6 +1046,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
#endif
}
+ rfkill_any_led_trigger_event();
rfkill_send_events(rfkill, RFKILL_OP_ADD);
mutex_unlock(&rfkill_global_mutex);
@@ -1017,6 +1079,7 @@ void rfkill_unregister(struct rfkill *rfkill)
mutex_lock(&rfkill_global_mutex);
rfkill_send_events(rfkill, RFKILL_OP_DEL);
list_del_init(&rfkill->node);
+ rfkill_any_led_trigger_event();
mutex_unlock(&rfkill_global_mutex);
rfkill_led_trigger_unregister(rfkill);
@@ -1269,6 +1332,10 @@ static int __init rfkill_init(void)
if (error)
goto error_misc;
+ error = rfkill_any_led_trigger_register();
+ if (error)
+ goto error_led_trigger;
+
#ifdef CONFIG_RFKILL_INPUT
error = rfkill_handler_init();
if (error)
@@ -1279,8 +1346,10 @@ static int __init rfkill_init(void)
#ifdef CONFIG_RFKILL_INPUT
error_input:
- misc_deregister(&rfkill_miscdev);
+ rfkill_any_led_trigger_unregister();
#endif
+error_led_trigger:
+ misc_deregister(&rfkill_miscdev);
error_misc:
class_unregister(&rfkill_class);
error_class:
@@ -1293,6 +1362,7 @@ static void __exit rfkill_exit(void)
#ifdef CONFIG_RFKILL_INPUT
rfkill_handler_exit();
#endif
+ rfkill_any_led_trigger_unregister();
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
}
--
2.11.0
^ permalink raw reply related
* Re: [ath9k-devel] 802.11k, 802.11v and 802.11r support in QCA9592-AR1B
From: Sven Eckelmann @ 2017-01-06 8:45 UTC (permalink / raw)
To: ath9k-devel, sandeep suresh
Cc: QCA Ath9k Development, Adrian Chadd, Linux Wireless List,
freebsd-wireless@freebsd.org
In-Reply-To: <587211005.1320200.1483690502965@mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On Freitag, 6. Januar 2017 08:15:02 CET sandeep suresh wrote:
> Dear Experts,We are using QCA9592-AR1B ( WPEA-252NI ) in one of our products and it supports 802.11bgn. There is a requirement to support the following standards:-802.11k802.11v and802.11r.Do we have the driver patches to support these standards? Please let me know how to go about this.Thanks & regardsSandeep Suresh.
Most of the stuff you ask here is already part of the current hostapd and has
nearly nothing to do with ath9k.
There are some things in 802.11v which would require driver support but I am
guessing that you are not actually requiring these parts of the kitchen sink
802.11 amendment. Your list of amendments look more like you want to support
some features to allow better roaming for Apple (and similar) devices.
Spoiler: They also don't support most of WNM (regardless of what Cisco tells
you).
The other thing which comes to my mind which is driver specific in 802.11v
would be BSS Max idle period management - but this is supported by mac80211
since ages.
I would recommend to get in contact with the hostapd people for more details.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: make ndo_get_stats64 a void function
From: kbuild test robot @ 2017-01-06 8:51 UTC (permalink / raw)
To: Stephen Hemminger
Cc: kbuild-all, davem, devel, dev, Stephen Hemminger, linux-rdma,
netdev, linux-wireless, linux-kernel, virtualization, oss-drivers,
linux-ppp, devel
In-Reply-To: <20170105173136.2817-1-sthemmin@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 4047 bytes --]
Hi Stephen,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Hemminger/net-make-ndo_get_stats64-a-void-function/20170106-160123
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net/ethernet/broadcom/bnx2.c: In function 'bnx2_get_stats64':
>> drivers/net/ethernet/broadcom/bnx2.c:6830:10: warning: 'return' with a value, in function returning void
return net_stats;
^~~~~~~~~
drivers/net/ethernet/broadcom/bnx2.c:6825:1: note: declared here
bnx2_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *net_stats)
^~~~~~~~~~~~~~~~
vim +/return +6830 drivers/net/ethernet/broadcom/bnx2.c
5d07bf26 drivers/net/bnx2.c Eric Dumazet 2010-07-08 6814 (((u64) (ctr##_hi) << 32) + (u64) (ctr##_lo))
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6815
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6816 #define GET_64BIT_NET_STATS(ctr) \
354fcd77 drivers/net/bnx2.c Michael Chan 2010-01-17 6817 GET_64BIT_NET_STATS64(bp->stats_blk->ctr) + \
354fcd77 drivers/net/bnx2.c Michael Chan 2010-01-17 6818 GET_64BIT_NET_STATS64(bp->temp_stats_blk->ctr)
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6819
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6820 #define GET_32BIT_NET_STATS(ctr) \
354fcd77 drivers/net/bnx2.c Michael Chan 2010-01-17 6821 (unsigned long) (bp->stats_blk->ctr + \
354fcd77 drivers/net/bnx2.c Michael Chan 2010-01-17 6822 bp->temp_stats_blk->ctr)
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6823
1e665d95 drivers/net/ethernet/broadcom/bnx2.c Stephen Hemminger 2017-01-05 6824 static void
5d07bf26 drivers/net/bnx2.c Eric Dumazet 2010-07-08 6825 bnx2_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *net_stats)
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6826 {
972ec0d4 drivers/net/bnx2.c Michael Chan 2006-01-23 6827 struct bnx2 *bp = netdev_priv(dev);
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6828
5d07bf26 drivers/net/bnx2.c Eric Dumazet 2010-07-08 6829 if (bp->stats_blk == NULL)
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 @6830 return net_stats;
5d07bf26 drivers/net/bnx2.c Eric Dumazet 2010-07-08 6831
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6832 net_stats->rx_packets =
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6833 GET_64BIT_NET_STATS(stat_IfHCInUcastPkts) +
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6834 GET_64BIT_NET_STATS(stat_IfHCInMulticastPkts) +
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6835 GET_64BIT_NET_STATS(stat_IfHCInBroadcastPkts);
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6836
b6016b76 drivers/net/bnx2.c Michael Chan 2005-05-26 6837 net_stats->tx_packets =
a4743058 drivers/net/bnx2.c Michael Chan 2010-01-17 6838 GET_64BIT_NET_STATS(stat_IfHCOutUcastPkts) +
:::::: The code at line 6830 was first introduced by commit
:::::: b6016b767397258b58163494a869f8f1199e6897 [BNX2]: New Broadcom gigabit network driver.
:::::: TO: Michael Chan <mchan@broadcom.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28924 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: make ndo_get_stats64 a void function
From: kbuild test robot @ 2017-01-06 9:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: kbuild-all, davem, devel, dev, Stephen Hemminger, linux-rdma,
netdev, linux-wireless, linux-kernel, virtualization, oss-drivers,
linux-ppp, devel
In-Reply-To: <20170105173136.2817-1-sthemmin@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]
Hi Stephen,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Hemminger/net-make-ndo_get_stats64-a-void-function/20170106-160123
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
drivers/net/macsec.c: In function 'macsec_get_stats64':
>> drivers/net/macsec.c:2897:3: warning: 'return' with a value, in function returning void
return s;
^
vim +/return +2897 drivers/net/macsec.c
c09440f7 Sabrina Dubroca 2016-03-11 2881 unsigned int extra = macsec->secy.icv_len + macsec_extra_len(true);
c09440f7 Sabrina Dubroca 2016-03-11 2882
c09440f7 Sabrina Dubroca 2016-03-11 2883 if (macsec->real_dev->mtu - extra < new_mtu)
c09440f7 Sabrina Dubroca 2016-03-11 2884 return -ERANGE;
c09440f7 Sabrina Dubroca 2016-03-11 2885
c09440f7 Sabrina Dubroca 2016-03-11 2886 dev->mtu = new_mtu;
c09440f7 Sabrina Dubroca 2016-03-11 2887
c09440f7 Sabrina Dubroca 2016-03-11 2888 return 0;
c09440f7 Sabrina Dubroca 2016-03-11 2889 }
c09440f7 Sabrina Dubroca 2016-03-11 2890
1e665d95 Stephen Hemminger 2017-01-05 2891 static void macsec_get_stats64(struct net_device *dev,
c09440f7 Sabrina Dubroca 2016-03-11 2892 struct rtnl_link_stats64 *s)
c09440f7 Sabrina Dubroca 2016-03-11 2893 {
c09440f7 Sabrina Dubroca 2016-03-11 2894 int cpu;
c09440f7 Sabrina Dubroca 2016-03-11 2895
c09440f7 Sabrina Dubroca 2016-03-11 2896 if (!dev->tstats)
c09440f7 Sabrina Dubroca 2016-03-11 @2897 return s;
c09440f7 Sabrina Dubroca 2016-03-11 2898
c09440f7 Sabrina Dubroca 2016-03-11 2899 for_each_possible_cpu(cpu) {
c09440f7 Sabrina Dubroca 2016-03-11 2900 struct pcpu_sw_netstats *stats;
c09440f7 Sabrina Dubroca 2016-03-11 2901 struct pcpu_sw_netstats tmp;
c09440f7 Sabrina Dubroca 2016-03-11 2902 int start;
c09440f7 Sabrina Dubroca 2016-03-11 2903
c09440f7 Sabrina Dubroca 2016-03-11 2904 stats = per_cpu_ptr(dev->tstats, cpu);
c09440f7 Sabrina Dubroca 2016-03-11 2905 do {
:::::: The code at line 2897 was first introduced by commit
:::::: c09440f7dcb304002dfced8c0fea289eb25f2da0 macsec: introduce IEEE 802.1AE driver
:::::: TO: Sabrina Dubroca <sd@queasysnail.net>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48149 bytes --]
^ permalink raw reply
* Re: [PATCH v4] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-06 12:22 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20170106060747.6162-1-kernel@kempniu.pl>
On Fri, 2017-01-06 at 07:07 +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-
> any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least one radio transmitter active and turn it off
> otherwise.
>
> Signed-off-by: Michał Kępień <kernel@kempniu.pl>
> ---
> Changes from v3:
>
> - Revert introducing a new bitfield and instead defer LED event
> firing
> to a work queue to prevent conditional locking and ensure the
> trigger can really be used from any context. This also voids the
> need to take rfkill_global_mutex before calling
> rfkill_set_block()
> in rfkill_resume().
Looks better, but
> +static struct work_struct rfkill_any_work;
At least on module exit you need to cancel this work.
johannes
^ permalink raw reply
* pull-request: mac80211 2017-01-06
From: Johannes Berg @ 2017-01-06 12:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's another fix for something I noticed while reviewing the code in
a new suggested patch that added another netlink socket destroy path.
Since the new patch would otherwise cause conflicts, it might be good
to pull net or Linus's next RC containing it into net-next, if you can.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 35f432a03e41d3bf08c51ede917f94e2288fbe8c:
mac80211: initialize fast-xmit 'info' later (2017-01-02 11:28:25 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-01-06
for you to fetch changes up to 753aacfd2e95df6a0caf23c03dc309020765bea9:
nl80211: fix sched scan netlink socket owner destruction (2017-01-05 10:59:53 +0100)
----------------------------------------------------------------
Another single fix, to correctly handle destruction of a
single netlink socket having ownership of multiple objects
(scheduled scan requests and interfaces.)
----------------------------------------------------------------
Johannes Berg (1):
nl80211: fix sched scan netlink socket owner destruction
net/wireless/nl80211.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-06 12:47 UTC (permalink / raw)
To: Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <20170102193214.31723-1-linus.luessing@c0d3.blue>
On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote:
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to a unicast one accordingly.
How does this compare and/or relate to the multicast-to-unicast feature
we were going to add to the wifi stack, particularly mac80211? Do we
perhaps not need that feature at all, if bridging will have it?
I suppose that the feature there could apply also to locally generated
traffic when the AP interface isn't in a bridge, but I think I could
live with requiring the AP to be put into a bridge to achieve a similar
configuration?
Additionally, on an unrelated note, this seems to apply generically to
all kinds of frames, losing information by replacing the address.
Shouldn't it have similar limitations as the wifi stack feature has
then, like only applying to ARP, IPv4, IPv6 and not general protocols?
Also, it should probably come with the same caveat as we documented for
the wifi feature:
Note that this may break certain expectations of the receiver,
such as the ability to drop unicast IP packets received within
multicast L2 frames, or the ability to not send ICMP destination
unreachable messages for packets received in L2 multicast (which
is required, but the receiver can't tell the difference if this
new option is enabled.)
I'll hold off sending my tree in until we see that we really need both
features, or decide that we want the wifi feature *instead* of the
bridge feature.
johannes
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Johannes Berg @ 2017-01-06 12:59 UTC (permalink / raw)
To: Rob Herring
Cc: Rafał Miłecki, linux-wireless, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree@vger.kernel.org, Rafał Miłecki
In-Reply-To: <CAL_JsqKYpTZFRJpPR1V9MmA-JW5ntoKzbkjwnYBp9HMWLObG3A@mail.gmail.com>
On Thu, 2017-01-05 at 10:34 -0600, Rob Herring wrote:
> On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes@sipsolutions.
> net> wrote:
> >
> > > Acked-by: Rob Herring <robh@kernel.org>
> >
> > Do I take that to mean that we'll merge it through the subsystem
> > tree,
> > and not go through some common DT tree?
>
> Yes, that's generally the case when bindings are in a series with
> driver changes.
Alright, thanks.
I've applied patches 1-3, patch 4 obviously still needs work (and
probably won't go through my tree anyway.)
Note that I made some documentation fixes in patch 3, Rafał, please
check.
johannes
^ permalink raw reply
* [PATCH 8/9] rt2x00: do not flush empty queue
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
index 3cc1384..ecc9631 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mac.c
@@ -743,7 +743,8 @@ void rt2x00mac_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return;
tx_queue_for_each(rt2x00dev, queue)
- rt2x00queue_flush_queue(queue, drop);
+ if (!rt2x00queue_empty(queue))
+ rt2x00queue_flush_queue(queue, drop);
}
EXPORT_SYMBOL_GPL(rt2x00mac_flush);
--
2.7.4
^ permalink raw reply related
* [PATCH 9/9] rt2800: set max_psdu to 3 on usb devices
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
All Ralink USB devices I have, including old ones, work well with
max_psdu = 3 (64kB tx AMPDUs).
Fix indent on the way.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 6cac311..de7a564 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4743,15 +4743,16 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, MAX_LEN_CFG, ®);
rt2x00_set_field32(®, MAX_LEN_CFG_MAX_MPDU, AGGREGATION_SIZE);
- if (rt2x00_rt_rev_gte(rt2x00dev, RT2872, REV_RT2872E) ||
- rt2x00_rt(rt2x00dev, RT2883) ||
- rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070E)) {
+ if (rt2x00_is_usb(rt2x00dev)) {
+ drv_data->max_psdu = 3;
+ } else if (rt2x00_rt_rev_gte(rt2x00dev, RT2872, REV_RT2872E) ||
+ rt2x00_rt(rt2x00dev, RT2883) ||
+ rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070E)) {
drv_data->max_psdu = 2;
- rt2x00_set_field32(®, MAX_LEN_CFG_MAX_PSDU, 2);
} else {
drv_data->max_psdu = 1;
- rt2x00_set_field32(®, MAX_LEN_CFG_MAX_PSDU, 1);
}
+ rt2x00_set_field32(®, MAX_LEN_CFG_MAX_PSDU, drv_data->max_psdu);
rt2x00_set_field32(®, MAX_LEN_CFG_MIN_PSDU, 10);
rt2x00_set_field32(®, MAX_LEN_CFG_MIN_MPDU, 10);
rt2800_register_write(rt2x00dev, MAX_LEN_CFG, reg);
--
2.7.4
^ permalink raw reply related
* [PATCH 7/9] rt2800usb: mark tx failure on timeout
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
If we do not get TX status in reasonable time, we most likely fail to
send frame hence mark it as so.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 400f074..205a7b8 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -602,10 +602,9 @@ static void rt2800usb_txdone_nostatus(struct rt2x00_dev *rt2x00dev)
!test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
break;
- if (test_bit(ENTRY_DATA_IO_FAILED, &entry->flags))
+ if (test_bit(ENTRY_DATA_IO_FAILED, &entry->flags) ||
+ rt2800usb_entry_txstatus_timeout(entry))
rt2x00lib_txdone_noinfo(entry, TXDONE_FAILURE);
- else if (rt2800usb_entry_txstatus_timeout(entry))
- rt2x00lib_txdone_noinfo(entry, TXDONE_UNKNOWN);
else
break;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 6/9] rt2800: fallback from mcs8 to mcs7
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
If we do not fallback to lower rate, we are unable to calculate
correctly number of retries in TX status code.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 1f4a120..6cac311 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4968,7 +4968,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, HT_FBK_CFG0, reg);
rt2800_register_read(rt2x00dev, HT_FBK_CFG1, ®);
- rt2x00_set_field32(®, HT_FBK_CFG1_HTMCS8FBK, 8);
+ rt2x00_set_field32(®, HT_FBK_CFG1_HTMCS8FBK, 7);
rt2x00_set_field32(®, HT_FBK_CFG1_HTMCS9FBK, 8);
rt2x00_set_field32(®, HT_FBK_CFG1_HTMCS10FBK, 9);
rt2x00_set_field32(®, HT_FBK_CFG1_HTMCS11FBK, 10);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/9] rt2800usb: remove watchdog
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
On rt2800usb, if we do not get TX status from HW, we assume frames were
posted and after entry->last_action timeout, we forcibly provide TX
status to mac80211. So it's not possible to detect hardware TX hung
based on the timeout. Additionally TXRQ_PCNT tells on number of frames
in the Packet Buffer (buffer between bus interface and chip MAC
subsystem), which can be non zero on normal conditions. To check HW hung
we will need provide some different mechanism, for now remove watchdog
as current implementation is wrong and not useful.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 42 --------------------------
1 file changed, 42 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index f38c440..8ec22c0 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -436,47 +436,6 @@ static int rt2800usb_set_device_state(struct rt2x00_dev *rt2x00dev,
}
/*
- * Watchdog handlers
- */
-static void rt2800usb_watchdog(struct rt2x00_dev *rt2x00dev)
-{
- unsigned int i;
- u32 reg;
-
- rt2x00usb_register_read(rt2x00dev, TXRXQ_PCNT, ®);
- if (rt2x00_get_field32(reg, TXRXQ_PCNT_TX0Q)) {
- rt2x00_warn(rt2x00dev, "TX HW queue 0 timed out, invoke forced kick\n");
-
- rt2x00usb_register_write(rt2x00dev, PBF_CFG, 0xf40012);
-
- for (i = 0; i < 10; i++) {
- udelay(10);
- if (!rt2x00_get_field32(reg, TXRXQ_PCNT_TX0Q))
- break;
- }
-
- rt2x00usb_register_write(rt2x00dev, PBF_CFG, 0xf40006);
- }
-
- rt2x00usb_register_read(rt2x00dev, TXRXQ_PCNT, ®);
- if (rt2x00_get_field32(reg, TXRXQ_PCNT_TX1Q)) {
- rt2x00_warn(rt2x00dev, "TX HW queue 1 timed out, invoke forced kick\n");
-
- rt2x00usb_register_write(rt2x00dev, PBF_CFG, 0xf4000a);
-
- for (i = 0; i < 10; i++) {
- udelay(10);
- if (!rt2x00_get_field32(reg, TXRXQ_PCNT_TX1Q))
- break;
- }
-
- rt2x00usb_register_write(rt2x00dev, PBF_CFG, 0xf40006);
- }
-
- rt2x00usb_watchdog(rt2x00dev);
-}
-
-/*
* TX descriptor initialization
*/
static __le32 *rt2800usb_get_txwi(struct queue_entry *entry)
@@ -877,7 +836,6 @@ static const struct rt2x00lib_ops rt2800usb_rt2x00_ops = {
.link_tuner = rt2800_link_tuner,
.gain_calibration = rt2800_gain_calibration,
.vco_calibration = rt2800_vco_calibration,
- .watchdog = rt2800usb_watchdog,
.start_queue = rt2800usb_start_queue,
.kick_queue = rt2x00usb_kick_queue,
.stop_queue = rt2800usb_stop_queue,
--
2.7.4
^ permalink raw reply related
* [PATCH 5/9] rt2800: tune TX_RTS_CFG config
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
Enable RTS frame retry fall-back and limit number of RTS retries to 7
what is default number of retries for small frames. As RTS/CTS is used
for TXOP protection, those settings prevent posting lots of RTS
frames when remote station do not response with CTS at the moment. After
sending 7 RTS's the HW will start back-off mechanism and after it will
start posing RTS again to get access to the medium.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 4833ec6..1f4a120 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4902,10 +4902,10 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, TXOP_HLDR_ET, reg);
rt2800_register_read(rt2x00dev, TX_RTS_CFG, ®);
- rt2x00_set_field32(®, TX_RTS_CFG_AUTO_RTS_RETRY_LIMIT, 32);
+ rt2x00_set_field32(®, TX_RTS_CFG_AUTO_RTS_RETRY_LIMIT, 7);
rt2x00_set_field32(®, TX_RTS_CFG_RTS_THRES,
IEEE80211_MAX_RTS_THRESHOLD);
- rt2x00_set_field32(®, TX_RTS_CFG_RTS_FBK_EN, 0);
+ rt2x00_set_field32(®, TX_RTS_CFG_RTS_FBK_EN, 1);
rt2800_register_write(rt2x00dev, TX_RTS_CFG, reg);
rt2800_register_write(rt2x00dev, EXP_ACK_TIME, 0x002400ca);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/9] rt2800: change default retry settings
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
We do not have option to set per frame retry count. We have only global
TX_RTY_CFG registers which specify the number or retries. Set setting
of that register to value that correspond rate control algorithm number
of frame post (number of retries + 1), which is 3 for aggregated frames.
This should help with big amount of retries on bad conditions, hence
mitigate buffer-bloat like problems.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 5436cdb..4833ec6 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4769,8 +4769,8 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, PBF_MAX_PCNT, 0x1f3fbf9f);
rt2800_register_read(rt2x00dev, TX_RTY_CFG, ®);
- rt2x00_set_field32(®, TX_RTY_CFG_SHORT_RTY_LIMIT, 15);
- rt2x00_set_field32(®, TX_RTY_CFG_LONG_RTY_LIMIT, 31);
+ rt2x00_set_field32(®, TX_RTY_CFG_SHORT_RTY_LIMIT, 2);
+ rt2x00_set_field32(®, TX_RTY_CFG_LONG_RTY_LIMIT, 2);
rt2x00_set_field32(®, TX_RTY_CFG_LONG_RTY_THRE, 2000);
rt2x00_set_field32(®, TX_RTY_CFG_NON_AGG_RTY_MODE, 0);
rt2x00_set_field32(®, TX_RTY_CFG_AGG_RTY_MODE, 0);
@@ -7514,6 +7514,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
rt2x00dev->hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
/*
+ * Change default retry settings to values corresponding more closely
+ * to rate[0].count setting of minstrel rate control algorithm.
+ */
+ rt2x00dev->hw->wiphy->retry_short = 2;
+ rt2x00dev->hw->wiphy->retry_long = 2;
+
+ /*
* Initialize all hw fields.
*/
ieee80211_hw_set(rt2x00dev->hw, REPORTS_TX_ACK_STATUS);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/9] rt2x00: save conf settings before reset tuner
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
Reset tuner use curr_band value, make sure it is updated.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00config.c | 32 +++++++++++------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00config.c b/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
index 6a1f508..3505074 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00config.c
@@ -249,6 +249,22 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
*/
rt2x00dev->ops->lib->config(rt2x00dev, &libconf, ieee80211_flags);
+ if (conf->flags & IEEE80211_CONF_PS)
+ set_bit(CONFIG_POWERSAVING, &rt2x00dev->flags);
+ else
+ clear_bit(CONFIG_POWERSAVING, &rt2x00dev->flags);
+
+ if (conf->flags & IEEE80211_CONF_MONITOR)
+ set_bit(CONFIG_MONITORING, &rt2x00dev->flags);
+ else
+ clear_bit(CONFIG_MONITORING, &rt2x00dev->flags);
+
+ rt2x00dev->curr_band = conf->chandef.chan->band;
+ rt2x00dev->curr_freq = conf->chandef.chan->center_freq;
+ rt2x00dev->tx_power = conf->power_level;
+ rt2x00dev->short_retry = conf->short_frame_max_tx_count;
+ rt2x00dev->long_retry = conf->long_frame_max_tx_count;
+
/*
* Some configuration changes affect the link quality
* which means we need to reset the link tuner.
@@ -271,20 +287,4 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
&rt2x00dev->autowakeup_work,
autowake_timeout - 15);
}
-
- if (conf->flags & IEEE80211_CONF_PS)
- set_bit(CONFIG_POWERSAVING, &rt2x00dev->flags);
- else
- clear_bit(CONFIG_POWERSAVING, &rt2x00dev->flags);
-
- if (conf->flags & IEEE80211_CONF_MONITOR)
- set_bit(CONFIG_MONITORING, &rt2x00dev->flags);
- else
- clear_bit(CONFIG_MONITORING, &rt2x00dev->flags);
-
- rt2x00dev->curr_band = conf->chandef.chan->band;
- rt2x00dev->curr_freq = conf->chandef.chan->center_freq;
- rt2x00dev->tx_power = conf->power_level;
- rt2x00dev->short_retry = conf->short_frame_max_tx_count;
- rt2x00dev->long_retry = conf->long_frame_max_tx_count;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/9] rt2800: increase TX timeout
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-1-git-send-email-sgruszka@redhat.com>
When medium is busy or frames have to be resend, it takes time to send
the frames and get TX status from hardware. For some really bad medium
conditions it can take seconds. Patch change TX status timeout to give
HW more time to provide it, however 500ms is not enough for bad
conditions. In the future this timeout should be removed and replaced
with proper watchdog mechanism.
Increase flush timeout accordingly as well.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 8ec22c0..400f074 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -123,7 +123,7 @@ static inline bool rt2800usb_entry_txstatus_timeout(struct queue_entry *entry)
if (!test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
return false;
- tout = time_after(jiffies, entry->last_action + msecs_to_jiffies(100));
+ tout = time_after(jiffies, entry->last_action + msecs_to_jiffies(500));
if (unlikely(tout))
rt2x00_dbg(entry->queue->rt2x00dev,
"TX status timeout for entry %d in queue %d\n",
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c
index f0178fd..da38d25 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c
@@ -101,7 +101,7 @@ void rt2x00mmio_flush_queue(struct data_queue *queue, bool drop)
unsigned int i;
for (i = 0; !rt2x00queue_empty(queue) && i < 10; i++)
- msleep(10);
+ msleep(50);
}
EXPORT_SYMBOL_GPL(rt2x00mmio_flush_queue);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 6005e14..838ca58 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -517,7 +517,7 @@ void rt2x00usb_flush_queue(struct data_queue *queue, bool drop)
* Wait for a little while to give the driver
* the oppurtunity to recover itself.
*/
- msleep(10);
+ msleep(50);
}
}
EXPORT_SYMBOL_GPL(rt2x00usb_flush_queue);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/9] rt2800 patches 06.01.2017
From: Stanislaw Gruszka @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
Random fixes for rt2800 driver.
Stanislaw Gruszka (9):
rt2800usb: remove watchdog
rt2800: increase TX timeout
rt2x00: save conf settings before reset tuner
rt2800: change default retry settings
rt2800: tune TX_RTS_CFG config
rt2800: fallback from mcs8 to mcs7
rt2800usb: mark tx failure on timeout
rt2x00: do not flush empty queue
rt2800: set max_psdu to 3 on usb devices
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 28 ++++++++-----
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 49 ++---------------------
drivers/net/wireless/ralink/rt2x00/rt2x00config.c | 32 +++++++--------
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 3 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
6 files changed, 41 insertions(+), 75 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-06 13:52 UTC (permalink / raw)
To: Johannes Berg, Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Michael Braun
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On 2017-01-06 13:47, Johannes Berg wrote:
> On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote:
>> Implements an optional, per bridge port flag and feature to deliver
>> multicast packets to any host on the according port via unicast
>> individually. This is done by copying the packet per host and
>> changing the multicast destination MAC to a unicast one accordingly.
>
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
>
>
> I'll hold off sending my tree in until we see that we really need both
> features, or decide that we want the wifi feature *instead* of the
> bridge feature.
The bridge layer can use IGMP snooping to ensure that the multicast
stream is only transmitted to clients that are actually a member of the
group. Can the mac80211 feature do the same?
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-06 13:54 UTC (permalink / raw)
To: Felix Fietkau, Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Michael Braun
In-Reply-To: <8836daaa-9638-4502-d079-fd428595f822@nbd.name>
> The bridge layer can use IGMP snooping to ensure that the multicast
> stream is only transmitted to clients that are actually a member of
> the group. Can the mac80211 feature do the same?
No, it'll convert the packet for all clients that are behind that
netdev. But that's an argument for dropping the mac80211 feature, which
hasn't been merged upstream yet, no?
johannes
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-06 13:54 UTC (permalink / raw)
To: Johannes Berg, Linus Lüssing, netdev
Cc: David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Michael Braun
In-Reply-To: <1483710841.12677.1.camel@sipsolutions.net>
On 2017-01-06 14:54, Johannes Berg wrote:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that are behind that
> netdev. But that's an argument for dropping the mac80211 feature, which
> hasn't been merged upstream yet, no?
Right.
- Felix
^ permalink raw reply
* Re: [PATCH 2/9] rt2800: increase TX timeout
From: Felix Fietkau @ 2017-01-06 15:15 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-3-git-send-email-sgruszka@redhat.com>
On 2017-01-06 14:05, Stanislaw Gruszka wrote:
> When medium is busy or frames have to be resend, it takes time to send
> the frames and get TX status from hardware. For some really bad medium
> conditions it can take seconds. Patch change TX status timeout to give
> HW more time to provide it, however 500ms is not enough for bad
> conditions. In the future this timeout should be removed and replaced
> with proper watchdog mechanism.
>
> Increase flush timeout accordingly as well.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
By the way, to make tx status reporting more robust, I would suggest
mapping tx fifo status to skb only for frames where
IEEE80211_TX_CTL_REQ_TX_STATUS is set. For all other frames, set PID=0
and return the status using ieee80211_tx_status_noskb.
I did the same in mt76 and it works quite well.
- Felix
^ permalink raw reply
* [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool
From: Rahul Krishnan @ 2017-01-06 15:20 UTC (permalink / raw)
To: m; +Cc: linux-wireless, linux-kernel
This patch removes unnecessary return statement using spatch.
Signed-off-by: Rahul Krishnan <mrahul.krishnan@gmail.com>
---
drivers/ssb/main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index d1a7507..ae3b7fe 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -1,4 +1,4 @@
-/*
+ patch /home/rahul/git/kernels/staging/drivers//*
* Sonics Silicon Backplane
* Subsystem core
*
@@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm)
default:
SSB_WARN_ON(1);
}
- size = (1 << (size + 1));
-
- return size;
+ return (1 << (size + 1));
}
EXPORT_SYMBOL(ssb_admatch_size);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/9] rt2800: increase TX timeout
From: Stanislaw Gruszka @ 2017-01-06 15:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <ce1a213e-19fe-83fa-e037-a5fefa88284e@nbd.name>
On Fri, Jan 06, 2017 at 04:15:40PM +0100, Felix Fietkau wrote:
> On 2017-01-06 14:05, Stanislaw Gruszka wrote:
> > When medium is busy or frames have to be resend, it takes time to send
> > the frames and get TX status from hardware. For some really bad medium
> > conditions it can take seconds. Patch change TX status timeout to give
> > HW more time to provide it, however 500ms is not enough for bad
> > conditions. In the future this timeout should be removed and replaced
> > with proper watchdog mechanism.
> >
> > Increase flush timeout accordingly as well.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> By the way, to make tx status reporting more robust, I would suggest
> mapping tx fifo status to skb only for frames where
> IEEE80211_TX_CTL_REQ_TX_STATUS is set. For all other frames, set PID=0
> and return the status using ieee80211_tx_status_noskb.
> I did the same in mt76 and it works quite well.
Good idea, thanks!
Stanislaw
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox