Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, 2016-01-28 at 14:04 -0800, Linus Torvalds wrote: >  > Well, it "makes a difference" in the sense that the warning goes > away. > But it doesn't make things work. In fact, it might be making things > worse. Heh, ok. > Because with that patch, the wireless still authenticates and >

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, 2016-01-28 at 11:01 -0800, Linus Torvalds wrote: >  > I used to have the basic original UniFi UAP. I've replaced them with > the newer "AC Lite" version: > > https://www.ubnt.com/unifi/unifi-ap-ac-lite/ > > so it's a fairly big jump from a 2.4GHz-only network to a dual-band > one. >

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote: > .. except now I upgraded the nearest access point, and now wireless > on that machine no longer works. Can you describe the upgrade a bit more, just for background? > Or rather, it actually *does* work in the sense that it >

Re: [PATCH v3 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

Hi, Is there anything I should do about these patches? I see you marked them as "deferred" in patchwork, but I don't really know how you're using that state. johannes

[PATCH 2/2] cfg80211/wext: fix message ordering

From: Johannes Berg <johannes.b...@intel.com> Since cfg80211 frequently takes actions from its netdev notifier call, wireless extensions messages could still be ordered badly since the wext netdev notifier, since wext is built into the kernel, runs before the cfg80211 netdev notifier. For e

[PATCH 1/2] wext: fix message delay/ordering

From: Johannes Berg <johannes.b...@intel.com> Beniamino reported that he was getting an RTM_NEWLINK message for a given interface, after the RTM_DELLINK for it. It turns out that the message is a wireless extensions message, which was sent because the interface had been con

pull-request: mac80211 2016-01-26

mac80211: clear local->sched_scan_req properly on reconfig mac80211: handle sched_scan_stopped vs. hw restart race Emmanuel Grumbach (1): mac80211: fix PS-Poll handling Helmut Schaa (1): mac80211: Don't buffer non-bufferable MMPDUs Johannes Berg (4): mac80211: recal

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: >  > seems to work fine. I wish we could instantiate this from device-tree > so we can finially get rid of this file. That'd be nice - anyone want to propose rfkill DT bindings? :) johannes

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

ather take the entire series through your tree to get it into one place for Marc? In which case, you have my Acked-by: Johannes Berg <johan...@sipsolutions.net> for the other 3 patches. Let me know which you prefer. johannes

Re: net/rfkill: WARNING in rfkill_fop_read

On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING message in rfkill_fop_read: > > [ cut here ] > WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663 > __might_sleep+0x138/0x1a0() > do not call blocking ops when

Re: [PATCH] net:mac80211:mesh_plink: remove redundant sta_info check

On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote: > Remove unnecessory "if" statement and club it with previos "if" > block. > Applied. johannes

Re: [PATCH 0/8] General RFKill improvements

Hi, On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote: > This series contains a few general improvements to the RFKill code, > found while > I was writing the rfkill-all / airplane mode LED trigger. All were > points where > I had to read twice or do some other kind of extra effort

[PATCH v2] net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28

CONFIG_ARM is safe for them. Signed-off-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/fec.h | 8 +++- drivers/net/ethernet/freescale/fec_main.c | 3 +-- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec.h b/d

[PATCH] net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28

From: Johannes Berg <johannes.b...@intel.com> As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28 is wrong if some other ARM platform uses this device - the operation of the driver would depend on an unrelated ARM platform that might or might not be set for multi-platform k

Re: [PATCH v2] net: fec: make driver endian-safe

On Mon, 2016-01-25 at 10:52 +1000, Greg Ungerer wrote: >  > I tested this on a ColdFire (5208) target that uses this driver. > Simple testing showed it working with no problems. The ColdFire > SoC processors use a version of the FEC hardware module, and they > always run big-endian. > Great,

[PATCH v2] net: fec: make driver endian-safe

not clear that the ifdef there really is correct and shouldn't just be #ifdef CONFIG_ARM, but I also can't test on anything but the i.MX6 HummingBoard where this gets it working with a BE kernel. Signed-off-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/Ma

Re: [PATCH v2] net: fec: make driver endian-safe

On Sun, 2016-01-24 at 17:49 +0100, Arnd Bergmann wrote: > I'd argue that the "(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)" > is definitely wrong, because if we ever get another ARM platform > that uses this driver, it may or may not work depending on whether > the ARCH_MXC is also set, and

[PATCH] net: fec: make driver endian-safe

-by: Johannes Berg <johan...@sipsolutions.net> --- drivers/net/ethernet/freescale/Makefile | 2 + drivers/net/ethernet/freescale/fec.h | 39 ++--- drivers/net/ethernet/freescale/fec_main.c | 130 -- 3 files changed, 99 insertions(+), 72 deletions(-) diff

Re: net: fec: make driver endian-safe

On Sat, 2016-01-23 at 23:09 +0100, Johannes Berg wrote: >  > +/* buffer endianness appears to be a mess ... ARM is usually LE but > can be BE */ > +#if defined(CONFIG_ARM) && defined(CONFIG_CPU_BIG_ENDIAN) Just realized that this is, of course, completely wrong. If the ARM

[PATCH] Bluetooth: avoid rebuilding hci_sock all the time

From: Johannes Berg <johannes.b...@intel.com> Instead, allow using string formatting with send_monitor_note() and access init_utsname(). Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- net/bluetooth/hci_sock.c | 28 ++-- 1 file changed, 18 inser

Re: [PATCH] net/rfkill: Create "airplane mode" LED trigger

On Tue, 2016-01-05 at 22:55 -0800, Marcel Holtmann wrote: >  > so I am not convinced the kernel should have the concept of airplane > mode at all. [snip long story] This is true, but that doesn't mean the patch is bad, just the naming could be different. I think the patch could name this

[PATCH v2] Bluetooth: avoid rebuilding hci_sock all the time

From: Johannes Berg <johannes.b...@intel.com> Instead, allow using string formatting with send_monitor_note() and access init_utsname(). Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- net/bluetooth/hci_sock.c | 28 ++-- 1 file changed, 18 inser

pull-request: mac80211-next 2015-12-18

Dave Young (1):   wireless: change cfg80211 regulatory domain info as debug messages Johannes Berg (4):   mac80211: recalculate SW ROC only when needed   mac80211: fix remain-on-channel cancellation   cfg80211: remove CFG80211_REG_DEBUG   regulatory: fix world

Re: pull-request: mac80211 2015-12-15

On Wed, 2015-12-16 at 18:34 -0500, David Miller wrote: >  > Something about your text encoding kept this from ending up > in patchwork for some reason. > Hm. I don't see anything special with this, seems to just be plain text 8bit transfer encoding. Do you want me to watch out for things

Re: [PATCH 1/1] mac80211: improve the contiguous mask checking

On Thu, 2015-12-17 at 22:59 +0800, Zeng Zhaoxiu wrote: > If the result of adding the first set bit to the mask is power of 2, > the mask must be contiguous. "mask & -mask" can get the first set bit > of mask gracefully. > - if (__ffs64(mask) + hweight64(mask) != fls64(mask)) > { > +

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

On Thu, 2015-12-17 at 11:19 +0800, Dave Young wrote: >  > Cool, has the fix been in mainline or somewhere else? > https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=a87da0cbc42949cefc8282c39ab4cb8c460bd6ea johannes -- To unsubscribe from this list: send the line "unsubscribe

pull-request: mac80211 2015-12-15

am (myself) Eyal Shapira (1):   mac80211: handle width changes from opmode notification IE in beacon Johannes Berg (4):   rfkill: copy the name into the rfkill struct   mac80211: run scan completed work on reconfig failure   mac80211: reprogram in inter

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

On Mon, 2015-11-23 at 09:37 +0800, Dave Young wrote: > Seems there're a lot of other wireless messages. Should we refactor > them as well? I still did not get chance to see where is the code. > (My wireless driver being used is iwlwifi) Most are probably from net/mac80211/. > # dmesg|grep

Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage

On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote: > [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 > suspicious rcu_dereference_protected() usage! > Funny, Laura Abbott also reported this bug earlier today :) I've sent out a fix, you can see it here:

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote: > cfg80211 module prints a lot of messages like below. Actually > printing once is acceptable but sometimes it will print again and > again, it looks very annoying. It is better to change these detail > messages to debugging only. > Despite

[PATCH] iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

From: Johannes Berg <johannes.b...@intel.com> Properly protect the RCU dereference in iwl_mvm_get_key_sta_id() when coming from iwl_mvm_update_tkip_key() which cannot hold the mvm->mutex by moving the call into the RCU critical section. Modify the check to use rcu_dereference_check()

Re: Suspicious RCU from iwlwifi driver

Hi Laura, >   drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 suspicious > rcu_dereference_protected() usage! > If I revert 9513c5e18a0dc55a1fc9c890715098ba2315830b > (iwlwifi: mvm: Avoid dereferencing sta if it was already flushed) > The warning goes away. Known issue? Thanks for the report

Re: [PATCH v4 2/3] mac80211: Prevent build failure with CONFIG_UBSAN=y

On Thu, 2015-12-03 at 18:50 +0300, Andrey Ryabinin wrote: > With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in > net/mac80211/debugfs.c starts to trigger: > BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (void > *)0x1); > > It seems, that compiler instrumentation causes some

pull-request: mac80211 2015-12-02

update tx power on a non-running sdata Gregory Greenman (1):   mac80211: always set the buf_size in AddBA req to 64 Johannes Berg (3):   mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE   mac80211: mesh: fix call_rcu() usage   mac80211: fix off-channel mgmt-tx uniniti

Re: [PATCH] mac80211_hwsim: missing NULL check

On Mon, 2015-11-30 at 12:46 +0530, Rahul Jain wrote: > From: Amit Khatri > > txrate variable might be NULL and passing inside function > without NULL check. Applied. However, this comes with a big BUT. I seems to always be rewriting your static checker patches, or

Re: pull-request: mac80211 2015-11-26

Hi, > > A small set of fixes for 4.4: >  * remove NL80211_FEATURE_FULL_AP_CLIENT_STATE again, it >    was broken and needs more work, we'll enable it for 4.5 >  * fix call_rcu() induced use-after-reset/free in mesh >    (that was

pull-request: mac80211 2015-11-26

Gregory Greenman (1):   mac80211: always set the buf_size in AddBA req to 64 Johannes Berg (2):   mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE   mac80211: mesh: fix call_rcu() usage  include/net/mac80211.h  | 6 --  net/mac80211/agg-tx.c   | 3 ++-  net

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

On Sun, 2015-11-15 at 19:25 +0100, Stefan Lippers-Hollmann wrote: > Hi > > On 2015-11-15, Dave Young wrote: > > cfg80211 module prints a lot of messages like below. Actually > > printing once is acceptable but sometimes it will print again and > > again, it looks very annoying. It is better to

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

> So maybe add some wrapper that does a pr_info then > a pr_debug for the second and subsequent uses like: > That seems like a bad idea - one might be tricked into think that one saw the current data, but the actually current data is later hidden. johannes -- To unsubscribe from this list:

[PATCH v3 4/4] ipv6: add option to drop unsolicited neighbor advertisements

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be NA proxies that use knowledge of the network to correctly answer requests. To prevent unsolicitd advertisements on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v3 2/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v3 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv4 unicast packets encapsulated in link-layer multi- or

[PATCH v3 3/4] ipv6: add option to drop unicast encapsulated in L2 multicast

From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv6 unicast packets encapsulated in link-layer multi- or

Re: [PATCH v2 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

On Wed, 2015-11-04 at 22:59 +0200, Julian Anastasov wrote: >  > Patches 1 and 3 look correct to me, > > Reviewed-by: Julian Anastasov Thanks for checking! > If the patches are lost in the merge window you > can also consider one minor optimization, see below...

[PATCH v2 2/4] ipv6: add option to drop unicast encapsulated in L2 multicast

From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv6 unicast packets encapsulated in link-layer multi- or

[PATCH v2 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

From: Johannes Berg <johannes.b...@intel.com> In order to solve a problem with 802.11, the so-called hole-196 attack, add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if enabled, causes the stack to drop IPv4 unicast packets encapsulated in link-layer multi- or

[PATCH v2 3/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v2 4/4] ipv6: add option to drop unsolicited neighbor advertisements

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be NA proxies that use knowledge of the network to correctly answer requests. To prevent unsolicitd advertisements on the shared medium from being a problem, on such deployments wireless needs t

Re: [PATCH 3/4] ipv4: add option to drop gratuitous ARP packets

On Sat, 2015-04-11 at 13:59 +0300, Julian Anastasov wrote: >  > May be only arptable_filter can help here to > protect ARP? > Finally reviving an ancient thread ... I checked, butI don't see a way to match tip==sip. You can match on each, but not against each other. johannes -- To

pull-request: mac80211 2015-11-03

of disabling WMM janusz.dzied...@tieto.com (1): mac80211: fix divide by zero when NOA update Johannes Berg (4): cfg80211/mac80211: clarify RSSI CQM reporting requirements mac80211: make enable_qos parameter to ieee80211_set_wmm_default() mac80211: treat bad WMM parameters more

pull-request: mac80211-next 2015-10-21

scheduled scan if multiple scan plans are set Dmitry Shmidt (1): nl80211: allow BSS data to include CLOCK_BOOTTIME timestamp Felix Fietkau (1): mac80211: add missing struct ieee80211_txq tid field initialization Johannes Berg (25): Merge remote-tracking branch 'net-next/master

pull-request: mac80211 2015-10-13

Hi, There are just two small fixes, but I didn't really want to wait since I have nothing else pending. Let me know if there's any problem. johannes The following changes since commit babc305e21ea3811d98b67437299360904ac1b6a: mac80211: reset CQM history upon reconfiguration (2015-09-22

Re: [PATCH] cfg80211: drop unlikely behind WARN_ON()

The subject is entirely wrong - this is not a cfg80211 patch. johannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

pull-request: mac80211-next 2015-10-05

net/wireless: enable wiphy device to suspend/resume asynchronously Helmut Schaa (2): mac80211: Split sending tx'ed frames to monitor interfaces into its own function mac80211: Copy tx'ed beacons to monitor mode Johannes Berg (13): wireless: make __freq_reg_info static nl80

Re: Rate limiting AP bandwidth change messages in ieee80211_config_bw?

> For what purpose? Or rather, when a user sees this in their dmesg, > what are they supposed to do about it? I think the idea isn't that the user would do something, but more that in case of performance issues, or perhaps driver/device bugs handling the changes, or similar you'd have an

Re: Rate limiting AP bandwidth change messages in ieee80211_config_bw?

> > I'm not sure ratelimiting it would even work - it's not *that* high > frequency? Not really sure though. > > I think we can do either, it's not such a terribly important message as > far as I can tell. > Seems like Emmanuel would like to see the message stay in some form - perhaps we

Re: Rate limiting AP bandwidth change messages in ieee80211_config_bw?

On Wed, 2015-09-30 at 13:02 -0400, Josh Boyer wrote: > Hi Johannes, > > We've seen a handful of reports that seem to have verbose output from > the ieee80211_config_bw function in net/mac80211/mlme.c. It looks > similar to this: > > [ 66.578652] wlp3s0: AP xx:xx:xx:xx:xx changed bandwidth,

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote: > Signed-off-by: Viresh Kumar > --- > V3->V4: > - Create a local variable instead of changing type of global_lock > (Rafael) Err, surely that wasn't what Rafael meant, since it's clearly impossible to use a

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

> Rafael wrote: > > Actually, what about adding a local u32 variable, say val, here and > > doing > > > > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 > > > *)_ec->gpe)) > > > goto error; > > > if (!debugfs_create_bool("use_global_lock", 0444, > > > dev_dir, > > > -

Re: [PATCH 18/19] mac80211: make ieee80211_new_mesh_header return unsigned

On Thu, 2015-09-24 at 16:00 +0200, Andrzej Hajda wrote: > The function returns always non-negative values. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. > You should at least compile your patches. johannes -- To

pull-request: mac80211 2015-09-23

Johannes Berg (1): mac80211: fix VHT MCS mask array overrun Sara Sharon (1): mac80211: reset CQM history upon reconfiguration net/mac80211/cfg.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send

Re: [PATCH v2] net/wireless: enable wiphy device to suspend/resume asynchronously

On Sat, 2015-09-19 at 10:40 +0800, Fu, Zhonghui wrote: > Now, PM core supports asynchronous suspend/resume mode for devices > during system suspend/resume, and the power state transition of one > device may be completed in separate kernel thread. PM core ensures > all power state transition timing

Re: [PATCH] iwlwifi: mvm: fix tof.h header guard

On Sat, 2015-09-12 at 12:04 +0200, Nicolas Iooss wrote: > Commit ce7929186a39 ("iwlwifi: mvm: add basic Time of Flight > (802.11mc > FTM) support") created drivers/net/wireless/iwlwifi/mvm/tof.h with a > broken header guard: > > #ifndef __tof > #define __tof_h__ > > ... > >

Re: [PATCH] net/mac80211/rate.c: fix wrong sizeof()

On Wed, 2015-09-09 at 21:56 +0100, Sergei Trofimovich wrote: > From: Sergei Trofimovich > > Noticed by gcc-5.2.0: > > net/mac80211/rate.c: In function 'rate_control_cap_mask': > net/mac80211/rate.c:719:25: warning: 'sizeof' on array function > parameter 'mcs_mask'

Re: [PATCH] cfg80211: regulatory: restore proper user alpha2

On Wed, 2015-09-02 at 19:00 +0200, Maciej S. Szmigiero wrote: > restore_regulatory_settings() should restore alpha2 > as computed in restore_alpha2(), not raw user_alpha2 to > behave as described in the comment just above that code. > > This fixes endless loop of calling CRDA for "00" and "97" >

Re: [PATCH] mac80211: Do not use sizeof() on pointer type

On Wed, 2015-08-26 at 12:22 +0200, Thierry Reding wrote: > From: Thierry Reding > > The rate_control_cap_mask() function takes a parameter mcs_mask, > which > GCC will take to be u8 * even though it was declared with a fixed > size. > This causes the following warning: > >

pull-request: mac80211 2015-09-04

traffic exists Johannes Berg (1): mac80211: reject software RSSI CQM with beacon filtering João Paulo Rechi Vita (1): rfkill: Copy "all" global state to other types Maciej S. Szmigiero (1): cfg80211: regulatory: restore proper user alpha2 Thierry Reding (1): ma

Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously

On Mon, 2015-08-24 at 11:45 +0800, Fu, Zhonghui wrote: On 2015/8/17 16:46, Arend van Spriel wrote: + Rafael On 08/17/2015 09:29 AM, Johannes Berg wrote: On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote: The suspend/resume timing of wiphy device and related devices

Re: [PATCH] lib/Makefile: remove CONFIG_AVERAGE build rule

On Fri, 2015-08-21 at 10:05 +, Valentin Rothberg wrote: The Kconfig option AVERAGE and its implementation has been removed by commit f4e774f55fe0 (average: remove out-of-line implementation). Remove the dead build rule in lib/Makefile. D'oh, sorry about that. Reviewed-by: Johannes Berg

[PATCH 1/4] virtio_net: use DECLARE_EWMA

From: Johannes Berg johannes.b...@intel.com Instead of using the out-of-line EWMA calculation, use DECLARE_EWMA() to create static inlines. On x86/64 this results in no change in code size for me, but reduces the struct receive_queue size by the two unsigned long values that store the parameters

Re: [PATCH 1/4] virtio_net: use DECLARE_EWMA

Sorry, forgot to Cc Michael and the virt list - patch reproduced below in full. johannes From 22500fbcf722748fe3471b2e4c6156db47aade15 Mon Sep 17 00:00:00 2001 From: Johannes Berg johannes.b...@intel.com Date: Wed, 19 Aug 2015 09:25:18 +0200 Subject: [PATCH] virtio_net: use DECLARE_EWMA Instead

[PATCH 4/4] average: remove out-of-line implementation

From: Johannes Berg johannes.b...@intel.com Since all users are now converted to the inline implementation, remove the out-of-line implementation entirely. Signed-off-by: Johannes Berg johannes.b...@intel.com --- include/linux/average.h | 24 --- lib/Kconfig | 10

[PATCH 3/4] rt2x00: use DECLARE_EWMA

From: Johannes Berg johannes.b...@intel.com Instead of using the out-of-line EWMA calculation, use DECLARE_EWMA() to create static inlines. On x86/64 this results in code that's one byte larger (for me), but reduces struct link_ant and struct link size by the two unsigned long values that store

[PATCH 0/4] average: convert users to inline implementation

Since there's very little benefit of the out-of-line implementation (a single byte of .text in one driver as far as I've seen), convert all drivers to the inline implementation, saving memory, and remove the out-of-line implementation. Perhaps the easiest would be for Dave to take all of these

[PATCH 2/4] ath5k: use DECLARE_EWMA

From: Johannes Berg johannes.b...@intel.com This reduces code size slightly (at least on x86/64) while also removing memory consumption by two unsigned long values for each ath5k device. Signed-off-by: Johannes Berg johannes.b...@intel.com --- drivers/net/wireless/ath/ath5k/Kconfig | 1

Re: [PATCH 15/21] net: mac80211_hwsim: convert to using IFF_NO_QUEUE

On Tue, 2015-08-18 at 10:30 +0200, Phil Sutter wrote: Signed-off-by: Phil Sutter p...@nwl.cc Cc: Johannes Berg johan...@sipsolutions.net --- drivers/net/wireless/mac80211_hwsim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mac80211_hwsim.c b

Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously

On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote: The suspend/resume timing of wiphy device and related devices will be ensured by their parent/child relationship. So, enabling wiphy device to suspend/resume asynchronously does not change any dependency. It can only take advantage

pull-request: mac80211 2015-08-14

Hi Dave, I'm back from vacation, and found a single bugfix waiting. It's in this pull request, but I'm not quite up to speed as to what's happening with the release. If it goes in, great; if not I've already tagged it with Cc stable anyway. Thanks, johannes The following changes since commit

Re: [PATCH 1/2] average: provide macro to create static EWMA

On Thu, 2015-08-13 at 17:26 -0700, David Miller wrote: From: Johannes Berg johan...@sipsolutions.net Date: Thu, 13 Aug 2015 11:11:48 +0200 From: Johannes Berg johannes.b...@intel.com Having the EWMA parameters stored in the runtime struct imposes memory requirements for the constant

Re: GCOV_PROFILE_ALL breaks BUILD_BUG_ON(!is_power_of_2(8))

On Fri, 2015-08-14 at 11:00 +0200, Michal Kubecek wrote: but should I have expected this? It might have something to do with the fact that is_power_of_2() being an inline function, perhaps with this compiler option it translates to something that can't be used in the context

GCOV_PROFILE_ALL breaks BUILD_BUG_ON(!is_power_of_2(8))

+linux-kernel +#define DECLARE_EWMA(name, _factor, _weight) \ + struct ewma_##name { \ +unsigned long internal; \ + };

pull-request: mac80211-next 2015-08-14

BIT position for TDLS WIDE extended cap Geert Uytterhoeven (1): rfkill: Allow compile test of GPIO consumers if !GPIOLIB Jesse Jones (2): mac80211: mesh: don't invalidate SN on discovery failure mac80211: mac80211: Check SN for deactivated mpaths Johannes Berg (26): mac80211

[PATCH 2/2] mac80211: use DECLARE_EWMA

From: Johannes Berg johannes.b...@intel.com Instead of using the out-of-line average calculation, use the new DECLARE_EWMA() macro to declare a signal EWMA, and use that. This actually *reduces* the code size slightly (on x86-64) while also reducing the station info size by 80 bytes. Signed-off

Re: [PATCH v2 11/11] net: rfkill: Allow compile test of GPIO consumers if !GPIOLIB

On Sun, 2015-08-02 at 11:09 +0200, Geert Uytterhoeven wrote: The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the

[PATCH 1/2] average: provide macro to create static EWMA

From: Johannes Berg johannes.b...@intel.com Having the EWMA parameters stored in the runtime struct imposes memory requirements for the constant values that could just be inlined in the code. This particularly makes sense if there are a lot of such structs, for example in mac80211 in the station

Re: [PATCH 2/5] net: rfkill: add rfkill_find_type function

On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote: +static const char *rfkill_types[NUM_RFKILL_TYPES] = { + [RFKILL_TYPE_WLAN] = wlan, + [RFKILL_TYPE_BLUETOOTH] = bluetooth, + [RFKILL_TYPE_UWB] = ultrawideband, + [RFKILL_TYPE_WIMAX] = wimax, +

Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously

On Thu, 2015-07-30 at 08:55 +0300, Emmanuel Grumbach wrote: On Thu, Jul 30, 2015 at 8:18 AM, Fu, Zhonghui zhonghui...@linux.intel.com wrote: Enable wiphy device to suspend/resume asynchronously. This can improve system suspend/resume speed. How will that impact the timing with

Re: [PATCH] mac80211: fix invalid read in minstrel_sort_best_tp_rates()

On Tue, 2015-07-28 at 10:30 +0200, Adrien Schildknecht wrote: At the last iteration of the loop, j may equal zero and thus tp_list[j - 1] causes an invalid read. Changed the logic of the loop so that j - 1 is always = 0. Signed-off-by: Adrien Schildknecht adrien+...@schischi.me Applied, I

Re: [PATCH] mac80211_hwsim: unregister genetlink family properly

On Fri, 2015-08-07 at 16:54 +0800, Su Kang Yin wrote: During hwsim_init_netlink(), we should call genl_unregister_family() if failed on netlink_register_notifier() since the genetlink is already registered. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe netdev

Re: [GIT] Networking

On Mon, 2015-07-20 at 18:11 +0800, Xiong Zhou wrote: Hi On Wed, Jun 24, 2015 at 9:39 PM, David Miller da...@davemloft.net wrote: 1) Add TX fast path in mac80211, from Johannes Berg. [snip far far far FAR too big quote] was there any content whatsoever in your email? johannes

Re: [PATCH] net: wireless: reduce log level of CRDA related messages

On Thu, 2015-07-09 at 15:35 +0200, Thomas Petazzoni wrote: With a basic Linux userspace, the messages Calling CRDA to update world regulatory domain appears 10 times after boot every second or so, followed by a final Exceeded CRDA call max attempts. Not calling CRDA. For those of us not having

Re: [PATCH] mac80211: Deinline rate_control_rate_init, rate_control_rate_update

On Wed, 2015-07-15 at 14:56 +0200, Denys Vlasenko wrote: With this .config: http://busybox.net/~vda/kernel_config, after deinlining these functions have sizes and callsite counts as follows: rate_control_rate_init: 554 bytes, 8 calls rate_control_rate_update: 1596 bytes, 5 calls Total

Re: pull-request: mac80211 2015-07-17

On Fri, 2015-07-17 at 15:31 +0200, Johannes Berg wrote: Hi Dave, We've accumulated some wireless fixes, please pull. Arik's fix is a bit bigger than I might like, but it fixes a real locking issue and we didn't really see a good way to make a smaller version. Let me know if there's any

pull-request: mac80211 2015-07-17

): mac80211: wowlan: enable powersave if suspend while ps-polling Johannes Berg (1): mac80211: shut down interfaces before destroying interface list Michal Kazior (1): mac80211: don't clear all tx flags when requeing Thomas Petazzoni (1): wireless: regulatory: reduce log level

Re: [PATCH] rfkill-gpio: Add support for the Realtek 8723 BT

On Tue, 2015-07-14 at 08:20 -0500, Larry Finger wrote: On 07/13/2015 05:11 PM, Bastien Nocera wrote: http://thread.gmane.org/gmane.linux.kernel.wireless.general/127706/ focu s=127896 Signed-off-by: Bastien Nocera had...@hadess.net Bastien, The subject of this patch needs a bit

[PATCH] mac80211: fix locking in update_vlan_tailroom_need_count()

From: Johannes Berg johannes.b...@intel.com Unfortunately, Michal's change to fix AP_VLAN crypto tailroom caused a locking issue that was reported by lockdep, but only in a few cases - the issue was a classic ABBA deadlock caused by taking the mtx after the key_mtx, where normally they're taken

writing timestamps to outgoing packets

Hi, For MA-USB (media-agnostic USB, but specifically we're working on doing it over 802.11 wifi) there's a need to write a timestamp to outgoing packets at a specific offset inside the packet. Unfortunately, it's not that we have to write the timestamp of the previous packet or similar which

pull-request: mac80211-next 2015-06-10

Chun-Yeow Yeoh (1): mac80211: fix the beacon csa counter for mesh and ibss Jakub Kicinski (1): mac80211: remove obsolete sentence from documentation Johannes Berg (9): mac80211: act upon and report deauth while associating mac80211: move TX PN to public part of key struct

Re: pull-request: mac80211-next 2015-06-10

On Wed, 2015-06-10 at 15:09 +0200, Johannes Berg wrote: The following changes since commit c3eee1fb1d308564ada5f7ea57bc51efc6130b37: Merge tag 'batman-adv-for-davem' of git://git.open-mesh.org/linux-merge (2015-06-09 20:23:52 -0700) are available in the git repository at: git

[PATCH 4.1] cfg80211: wext: clear sinfo struct before calling driver

From: Johannes Berg johannes.b...@intel.com Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause

<    3   4   5   6   7   8   9   10   11   12   >