Re: [RFC 0/7] netlink: Add allocation flag to netlink_unicast()

From: Masashi Honma Date: Wed, 6 Jul 2016 09:28:29 +0900 > Though currently such a use case was not found, to solve potential > issue we will add an allocation flag to netlink_unicast(). We don't solve potential issues, we solve real issues. There is no reason to add

[RFC 5/7] net: Add allocation flag to rtnl_unicast()

Signed-off-by: Masashi Honma --- include/linux/rtnetlink.h | 3 ++- net/core/net_namespace.c | 2 +- net/core/rtnetlink.c | 10 ++ net/dcb/dcbnl.c | 2 +- net/decnet/dn_route.c | 3 ++- net/ipv4/devinet.c| 2 +- net/ipv4/ipmr.c

[RFC 4/7] infiniband: Add allocation flag to ibnl_unicast()

Signed-off-by: Masashi Honma --- drivers/infiniband/core/iwpm_msg.c | 6 +++--- drivers/infiniband/core/iwpm_util.c | 5 +++-- drivers/infiniband/core/iwpm_util.h | 1 + drivers/infiniband/core/netlink.c | 4 ++-- include/rdma/rdma_netlink.h | 3 ++- 5 files

[RFC 2/7] netfilter: Add allocation flag to nfnetlink_unicast()

Signed-off-by: Masashi Honma --- include/linux/netfilter/nfnetlink.h | 2 +- net/netfilter/nfnetlink.c | 4 ++-- net/netfilter/nfnetlink_log.c | 4 ++-- net/netfilter/nfnetlink_queue.c | 3 ++- 4 files changed, 7 insertions(+), 6 deletions(-) diff

[RFC 6/7] genetlink: Add allocation flag to genlmsg_unicast()

Signed-off-by: Masashi Honma --- drivers/net/gtp.c | 3 ++- drivers/net/team/team.c | 5 +++-- drivers/net/wireless/mac80211_hwsim.c | 2 +- fs/dlm/netlink.c | 2 +- include/net/genetlink.h | 8 +---

[RFC 7/7] genetlink: Add allocation flag to genlmsg_reply()

Add allocation flag to genlmsg_reply() and remove netlink_unicast() temporal functionality for stepwise modification. Signed-off-by: Masashi Honma --- drivers/block/drbd/drbd_nl.c | 2 +- drivers/net/wireless/mac80211_hwsim.c | 2 +- include/net/genetlink.h

[RFC 3/7] netlink: Add allocation flag to nlmsg_unicast()

Signed-off-by: Masashi Honma --- crypto/crypto_user.c | 3 ++- drivers/infiniband/core/netlink.c | 2 +- include/net/genetlink.h | 2 +- include/net/netlink.h | 6 -- net/core/rtnetlink.c | 2 +-

[RFC 1/7] netlink: Add allocation flag to netlink_unicast()

Though netlink_broadcast() has allocation flag which can specify memory allocation type (ex. GFP_KERNEL/GFP_ATOMIC), netlink_unicast() does not have it. This can cause "BUG: sleeping function called from invalid context at" with CONFIG_DEBUG_ATOMIC_SLEEP enabled kernel when calling

[RFC 0/7] netlink: Add allocation flag to netlink_unicast()

Though netlink_broadcast() has allocation flag which can specify memory allocation type (ex. GFP_KERNEL/GFP_ATOMIC), netlink_unicast() does not have it. This can cause "BUG: sleeping function called from invalid context at" with CONFIG_DEBUG_ATOMIC_SLEEP enabled kernel when calling

Re: ath9k-htc on OHCI -> bogus usb xfer

Am 05.07.2016 um 19:31 schrieb Alexey Brodkin: > Hi Oleksij, > > On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote: >> Hi, >> >> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin: >>> >>> Hello, >>> >>> Looks like this is another manifestation of already seen problem with >>> ath9k-htc >>> and

Re: ath9k-htc on OHCI -> bogus usb xfer

Hi Oleksij, On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote: > Hi, > > Am 05.07.2016 um 14:20 schrieb Alexey Brodkin: > > > > Hello, > > > > Looks like this is another manifestation of already seen problem with > > ath9k-htc > > and OHCI controller. > > > > I'm trying to get USB

Re: ath9k-htc on OHCI -> bogus usb xfer

Hi, Am 05.07.2016 um 14:20 schrieb Alexey Brodkin: > Hello, > > Looks like this is another manifestation of already seen problem with > ath9k-htc > and OHCI controller. > > I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our > development board (this is Synopsys AXS103)

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

On 06/30/2016 03:25 AM, Valo, Kalle wrote: Ben Greear writes: Is there a better way than posting to the ath10k mailing list? There are quite a few more of my patches that are stuck in pending or ignored state. If you could review some of them and add them to your

[PATCH v3 02/10] rtlwifi: rtl8192ce: Convert driver to use common hardware info routine

The driver for RTL8192CE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 06/10] rtlwifi: rtl8723ae: Convert driver to use common hardware info routine

The driver for RTL8723AE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 08/10] rtlwifi: rtl8821ae: Convert driver to use common hardware info routine

The driver for RTL8821AE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 10/10] rtlwifi: rtl8723ae: Clean up the hardware info routine

This driver contains some complicated if ... else if ... else constructions. These are replaced by switch statements to improve readability. Signed-off-by: Larry Finger --- V2 - Changes suggested by Joe Perches were incorporated V3 - Missing break statments are added.

[PATCH v3 09/10] rtlwifi: rtl8192de: Convert driver to use common hardware info routine

The driver for RTL8192DE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 07/10] rtlwifi: rtl8723be: Convert driver to use common hardware info routine

The driver for RTL8723BE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 05/10] rtlwifi: rtl8192ee: Convert driver to use common hardware info routine

The driver for RTL8192EE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH 00/10 V3] rtlwifi: Various clean-ups for the hwinfo routines

The rtlwifi family of drivers use similar routines to extract hardware information from EFUSE. This set of patches create a common routine to extract this data, and converts most of the drivers to use this routine. In addition, a complicated set of if ... else if ... else statements are present

[PATCH v3 03/10] rtlwifi: rtl8192cu: Convert driver to use common hardware info routine

The driver for RTL8192CU chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

[PATCH v3 01/10] rtlwifi: Create common routine to get hardware info

All of the rtlwifi family of drivers have a similar routine that acquires the hardware info from efuse and initializes a number of variables in the driver's private area. A common routine is created for all drivers to use. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger

[PATCH v3 04/10] rtlwifi: rtl8188ee: Convert driver to use common hardware info routine

The driver for RTL8188EE chips is converted to use the common routine for getting the hardware information. Reported-by: Arnd Bergmann Signed-off-by: Larry Finger Cc: Arnd Bergmann --- V2 - Fixes bug found after V1 was submitted. V3 - No

4.8 merge window closing

Hi, Linus released 4.7-rc6 last Sunday but didn't give any hints how close the real release is, but nevertheless the merge window for 4.8 is getting quite close so if there's anything you want to have in wireless-drivers-next for 4.8 better send them NOW. Especially as I won't have that much time

Re: [1/6] rtlwifi: Remove unused parameter from rtl_ps_set_rf_state()

Larry Finger wrote: > Commit 4b9d8d67b44a ("rtlwifi: rtl8192cu: Remove unused parameter") reworked > this routine. Those changes were later reverted by commit d3feae41a347 > ("rtlwifi: Update power-save routines for 062814 driver"). > > There were two changes in commit

Re: mwifiex: disable MSIx interrupt for 8997 chipset

Amitkumar Karwar wrote: > From: Shengzhen Li > > Sometimes MSIx interrupts are received out of order on multi-core > system. This creates a problem when there is a race between data > packet and SLEEP event from firmware. We will disable MSIx interrupt >

Re: [PATCH v2] nl80211: Add info to scan results to support beacon report

On Tue, 2016-07-05 at 17:10 +0300, Luca Coelho wrote: > From: Avraham Stern > > Beacon report radio measurement requires reporting observed BSSs > on the channels specified in the beacon request. If the measurement > mode is set to passive or active, it requires actually

[PATCH v2] nl80211: Add info to scan results to support beacon report

From: Avraham Stern Beacon report radio measurement requires reporting observed BSSs on the channels specified in the beacon request. If the measurement mode is set to passive or active, it requires actually performing a scan (passive or active, accordingly), and

Re: [PATCH 3/4] rtl8xxxu: Mark 0x20f4:0x648b as tested

jes.soren...@redhat.com writes: > From: Jes Sorensen > > Successfully tested by Jocelyn Mayer > > Reported-by: J. Mayer > Signed-off-by: Jes Sorensen > --- > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9

Re: [PATCH 4/4] rtl8xxxu: Mark 0x2001:0x3308 as tested

jes.soren...@redhat.com writes: > From: Jes Sorensen > > D-Link DWA-121 is reported as working. > > Reported-by: Stefano Bravi > Signed-off-by: Jes Sorensen > --- >

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

On Monday, July 4, 2016 8:36:05 PM CEST Arend van Spriel wrote: > On 04-07-16 16:54, Arnd Bergmann wrote: > > On Monday, July 4, 2016 11:08:38 AM CEST Arend Van Spriel wrote: > > > > In drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c I already see > > over a dozen different chips being

Re: [v2, 1/3] mwifiex: add a cfg80211 .get_tx_power operation callback

Javier Martinez Canillas wrote: > The mwifiex driver implements a cfg80211 .set_tx_power operation handler > but doesn't have the inverse .get_tx_power callback. > > This not only has the effect that the Tx power can't be reported to user > space tools such as iwconfig

Re: [PATCH 4/7] nl80211: Add info to scan results to support beacon report

On Tue, 2016-07-05 at 15:23 +0300, Luca Coelho wrote: > From: Avraham Stern > > Beacon report radio measurement requires reporting observed BSSs > on the channels specified in the beacon request. If the measurement > mode is set to passive or active, it requires actually

Re: mwifiex: fix unconditional error return in .add_virtual_intf callback

Javier Martinez Canillas wrote: > The commit 7311ea850079 ("mwifiex: fix AP start problem for newly added > interface") attempted to fix an issue when a new AP interface is added. > > But the patch didn't check the return value of the functions doing the > firmware calls

Re: [PATCH 4/7] nl80211: Add info to scan results to support beacon report

Hi, [auto build test ERROR on mac80211-next/master] [also build test ERROR on next-20160705] [cannot apply to v4.7-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Luca-Coelho/mac80211

Re: [PATCHv4 wl-drv-next 0/2] register-field manipulation macros

Jakub Kicinski writes: > This set moves to a global header file macros which I find > very useful and worth popularising. The basic problem is > that since C bitfields are not very dependable accessing > subfields of registers becomes slightly inconvenient. > It is

Re: [PATCH 4/7] nl80211: Add info to scan results to support beacon report

Hi, [auto build test WARNING on mac80211-next/master] [also build test WARNING on next-20160705] [cannot apply to v4.7-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Luca-Coelho/mac80211

Re: [PATCH] mwifiex: fix unconditional error return in .add_virtual_intf callback

Hello Kalle, On 07/05/2016 09:09 AM, Kalle Valo wrote: > Javier Martinez Canillas writes: > >> The commit 7311ea850079 ("mwifiex: fix AP start problem for newly added >> interface") attempted to fix an issue when a new AP interface is added. >> >> But the patch didn't

Re: [PATCHv4 wl-drv-next 2/2] mt7601u: use linux/bitfield.h

Jakub Kicinski writes: > Use the newly added linux/bitfield.h. > > Signed-off-by: Jakub Kicinski [...] > +#define MT76_SET FIELD_PUT > +#define MT76_GET FIELD_GET This define is useless now, I would just remove it entirely.

Re: [PATCH] mwifiex: fix unconditional error return in .add_virtual_intf callback

Javier Martinez Canillas writes: > The commit 7311ea850079 ("mwifiex: fix AP start problem for newly added > interface") attempted to fix an issue when a new AP interface is added. > > But the patch didn't check the return value of the functions doing the > firmware calls

Re: pull-request: iwlwifi-next 2016-07-01

Luca Coelho writes: > Here are some patches intended for 4.8.  I have a lot more patches > pending in our internal tree, but I decided to take smaller steps > because it's easier to find a few hours to push a few patches than it > is to find many hours to send all pending

Re: [PATCH 1/2] cfg80211: Add support to set tx power for a station associated

On 2016-06-28 16:18, Johannes Berg wrote: On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote: This patch adds support to set transmit power setting type and transmit power level attributes to NL80211_CMD_SET_STATION in order to facilitate adjusting the transmit power level of a

[PATCH 2/7] mac80211_hwsim: Add radar bandwidths to the P2P Device combination

From: Ilan Peer Add radar_detect_widths to the interface combination that allows concurrent P2P Device dedicated interface and AP interfaces, to enable testing of radar detection when P2P Device interface is used. Clear the radar_detect_widths in case of multi channel

[PATCH 4/7] nl80211: Add info to scan results to support beacon report

From: Avraham Stern Beacon report radio measurement requires reporting observed BSSs on the channels specified in the beacon request. If the measurement mode is set to passive or active, it requires actually performing a scan (passive or active, accordingly), and

[PATCH 6/7] mac80211: report failure to start (partial) scan as scan abort

From: Johannes Berg Rather than reporting the scan as having completed, report it as being aborted. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho --- net/mac80211/scan.c | 5 +++-- 1 file changed, 3

[PATCH 5/7] mac80211: Add support for beacon report radio measurement

From: Avraham Stern Add the following to support beacon report radio measurement with the measurement mode field set to passive or active: 1. Propagate the required scan duration to the device 2. Report the scan start time (in terms of TSF) 3. Report each BSS's detection

[PATCH 7/7] mac80211: parse wide bandwidth channel switch IE with workaround

From: Johannes Berg Continuing the workaround implemented in commit 23665aaf9170 ("mac80211: Interoperability workaround for 80+80 and 160 MHz channels") use the same code to parse the Wide Bandwidth Channel Switch element by converting to VHT Operation element since the

[PATCH 3/7] cfg80211: handle failed skb allocation

From: Gregory Greenman Handle the case when dev_alloc_skb returns NULL. Signed-off-by: Gregory Greenman Signed-off-by: Luca Coelho --- net/wireless/util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/7] nl80211: Add API to support VHT MU-MIMO air sniffer

From: Aviya Erenfeld add API to support VHT MU-MIMO air sniffer. in MU-MIMO there are parallel frames on the air while the HW has only one RX. add the capability to sniff one of the MU-MIMO parallel frames by giving the sniffer additional information so it'll know which

[PATCH 0/7] mac80211/cfg80211: a bunch of patches from our internal tree

From: Luca Coelho Hi Johannes, These are some cfg80211/mac80211 patches that were pending upstreaming in our internal tree (I think you know about them ;). Please let me know if everything is okay. There is a couple of checkpatch >80 chars line warnings, which I

ath9k-htc on OHCI -> bogus usb xfer

Hello, Looks like this is another manifestation of already seen problem with ath9k-htc and OHCI controller. I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our development board (this is Synopsys AXS103) and seeing a picture very similar to what was discussed here 

[PATCHv4 wl-drv-next 2/2] mt7601u: use linux/bitfield.h

Use the newly added linux/bitfield.h. Signed-off-by: Jakub Kicinski --- drivers/net/wireless/mediatek/mt7601u/dma.h | 2 - drivers/net/wireless/mediatek/mt7601u/mt7601u.h | 5 +- drivers/net/wireless/mediatek/mt7601u/util.h| 77 -

[PATCHv4 wl-drv-next 1/2] add basic register-field manipulation macros

Common approach to accessing register fields is to define structures or sets of macros containing mask and shift pair. Operations on the register are then performed as follows: field = (reg >> shift) & mask; reg &= ~(mask << shift); reg |= (field & mask) << shift; Defining shift and mask

[PATCHv4 wl-drv-next 0/2] register-field manipulation macros

Hi! This set moves to a global header file macros which I find very useful and worth popularising. The basic problem is that since C bitfields are not very dependable accessing subfields of registers becomes slightly inconvenient. It is nice to have the necessary mask and shift operations

Re: [PATCHv3 wl-drv-next 1/2] add basic register-field manipulation macros

On Tue, 5 Jul 2016 10:56:13 +, David Laight wrote: > From: Jakub Kicinski > > Sent: 01 July 2016 22:27 > > > > C bitfields are problematic and best avoided. Developers > > interacting with hardware registers find themselves searching > > for easy-to-use alternatives. Common approach is to

RE: [PATCHv3 wl-drv-next 1/2] add basic register-field manipulation macros

From: Jakub Kicinski > Sent: 01 July 2016 22:27 > > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and shift

[PATCH] nl80211: Move ACL parsing later to avoid a possible memory leak

No support for pbss results in a memory leak for the acl_data (if parse_acl_data succeeds). Fix this by moving the ACL parsing later. Fixes: 34d505193bd10 ("cfg80211: basic support for PBSS network type") Signed-off-by: Purushottam Kushwaha --- net/wireless/nl80211.c