Re: brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT

Rafał Miłecki wrote: > From: Rafał Miłecki > > This new helper reads extra frequency limits specified in DT and > disables unavailable chanels. This is useful for devices (like home > routers) with chipsets limited e.g. by board design. > > In order to respect info read from

Re: mwifiex: don't include mac80211.h

Johannes Berg wrote: > From: Johannes Berg > > This driver doesn't use mac80211, so it shouldn't include mac80211.h, > include only the necessary cfg80211.h instead. > > Signed-off-by: Johannes Berg Patch applied to

Re: pull-request: iwlwifi-next 2017-02-06

Luca Coelho writes: > Here's my second pull-request intended for v4.11. Just the usual set of > fixes, cleanups and improvements, together with the continued work on > support for new hardware. A bit more details in the tag description. > > I have sent this out before and

Re: [PATCH 00/11 V4] rtlwifi: Various updates

Larry Finger writes: > These 11 changes fix a number of deficiencies. None of them are > serious enough to be pushed to stable; however they help in the > stability of the drivers, and in the robustness of authentication/ > association. > > This material should be sent

Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.

Larry Finger writes: > On 02/06/2017 06:45 AM, Kalle Valo wrote: >> Larry Finger writes: >> >>> From: Ping-Ke Shih >>> >>> There is a potential race condition when the control byte of a CAM >>> entry is written first.

Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.

On 02/06/2017 06:45 AM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih There is a potential race condition when the control byte of a CAM entry is written first. Write in reverse order to correct the condition. Signed-off-by:

[PATCH] Make EN2 pin optional in the TRF7970A driver

From: Guan Ben Make the EN2 pin optional. This is useful for boards, which have this pin fix wired, for example to ground. Signed-off-by: Guan Ben Signed-off-by: Mark Jonas Signed-off-by: Heiko Schocher ---

Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.

On 02/06/2017 06:45 AM, Kalle Valo wrote: Larry Finger writes: From: Ping-Ke Shih There is a potential race condition when the control byte of a CAM entry is written first. Write in reverse order to correct the condition. Signed-off-by:

Re: [PATCH] wireless-regdb: Remove DFS requirement for India (IN)

On Mon, Jan 30, 2017 at 02:08:32PM +0200, Jouni Malinen wrote: > The "Indoor Use of low power wireless equipment in the frequency band 5 > GHz (Exemption from Licensing Requirement) Rules, 2005" notification by > Ministry of Communications and Information Technology (Wireless Planning > and

pull-request: iwlwifi-next 2017-02-06

Hi Kalle, Here's my second pull-request intended for v4.11. Just the usual set of fixes, cleanups and improvements, together with the continued work on support for new hardware. A bit more details in the tag description. I have sent this out before and kbuildbot didn't find any issues. I have

Re: [PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches

From: Linus Lüssing Date: Fri, 3 Feb 2017 08:11:03 +0100 > When for instance a mobile Linux device roams from one access point to > another with both APs sharing the same broadcast domain and a > multicast snooping switch in between: > > 1)(c) <~~~> (AP1)

Re: pull-request: wireless-drivers 2017-02-06

From: Kalle Valo Date: Mon, 06 Feb 2017 17:19:52 +0200 > one more fix I still would like to get to 4.10 if possible. Please let > me know if there are any problems. This is fine, pulled, thanks Kalle.

MODULE_FIRMWARE() for fallback ucode files?

Hi, currently iwlwifi driver lists only the latest firmware files in MODULE_FIRMWARE() although the driver may read other older files. And this confuses the openSUSE installer, since the installation image is created based on the module information and copies only the firmwares listed there. A

Re: pull-request: mac80211 2017-02-06

From: Johannes Berg Date: Mon, 6 Feb 2017 09:36:36 +0100 > I know it's super late, but I was travelling last week and the > whole FILS AEAD thing only played out over the weekend anyway. > Since the FILS code is all new in this cycle, it'd be good to > have the fixes,

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

On 02/06/2017 04:29 AM, Johannes Berg wrote: On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: Seems the problem is caused by rtl92c_dm_*() casting .priv to "struct rtl_pci_priv", while it is "struct rtl_usb_priv". Those routines are shared

pull-request: wireless-drivers 2017-02-06

Hi Dave, one more fix I still would like to get to 4.10 if possible. Please let me know if there are any problems. Kalle The following changes since commit 2b1d530cb3157f828fcaadd259613f59db3c6d1c: MAINTAINERS: ath9k-devel is closed (2017-01-28 09:15:50 +0200) are available in the git

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

> You use value '0' to mean set to default values, as far as I can > tell. I think you're confusing the internal API and the userspace API - at a userspace level you have to set NL80211_ATTR_STA_TX_POWER_SETTING to NL80211_TX_POWER_AUTOMATIC to revert back to defaults, no? For perfect backwards

Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe

On Mon, 2017-02-06 at 16:05 +0200, Kalle Valo wrote: > Luca Coelho writes: > > > From: Johannes Berg > > > > Instead of setting the tx_cmd length in the mvm code, which is > > complicated by the fact that DQA may want to temporarily store > > the SKB on

Re: [PATCH 15/25] iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe

Luca Coelho writes: > From: Johannes Berg > > Instead of setting the tx_cmd length in the mvm code, which is > complicated by the fact that DQA may want to temporarily store > the SKB on the side, adjust the length in the PCIe code which > also knows

Re: [PATCH 14/25] iwlwifi: mvm: overwrite skb info later

Luca Coelho writes: > From: Johannes Berg > > We don't really need clear the skb's status area nor store the > dev_cmd into it until we really commit to the frame by handing > it to the transport - defer those operations until just before > we do that. >

[PATCH] Print text for disassociation reason.

Hi. Don't know why it wasn't printed there with ieee80211_get_reason_code_string in first place. Works for me: kernel: wlan0: disassociated from 04:b0:20:33:ff:1f (Reason: 34=DISASSOC_LOW_ACK) ps. can't send patch in normal way due to postmaster@vger weirdness, so inserted below From

Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e

On Mon, Feb 06, 2017 at 12:52:56PM +0100, Felix Fietkau wrote: > >> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev) > >> +{ > >> + u8 ackto, sifs, slottime = dev->slottime; > >> + > >> + slottime += 3 * dev->coverage_class; > >> + > >> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG, > >> +

ANNOUNCE: Netdev 2.1 update Feb 06

A few announcements: - We expect to open up registration and announce hotel and location this week. - We are pleased to announce the first netdev 2.1 sponsor! Many thanks to Mellanox who has been a strong supporter of the netdev community. Mellanox is first to cross the netdev2.1 sponsor line

Re: [PATCH 01/11 V3] rtlwifi: Fix programing CAM content sequence.

Larry Finger writes: > From: Ping-Ke Shih > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih >

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Symmetry is still broken on firmware crash (at least with 6174). ath10k_pci_hif_stop gets called twice, once from the driver restart (warm restart) and once from ieee80211 start (cold restart), resulting in napi_synchrionize/napi_disable getting called twice and sticking the driver in an

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Hi, even with the below patch applied ? https://patchwork.kernel.org/patch/9452265/ regards shafi From: Michael Ney Sent: 06 February 2017 17:46 To: Mohammed Shafi Shajakhan Cc: Valo, Kalle; linux-wireless@vger.kernel.org;

Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e

On 2017-02-06 12:25, Stanislaw Gruszka wrote: > On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote: >> This is a 2x2 PCIe 802.11ac chipset by MediaTek >> >> Signed-off-by: Felix Fietkau > Driver looks great to me, though I think it could be better commented. > I have

Re: [PATCH 01/11 V2] rtlwifi: Fix programing CAM content sequence.

Larry Finger writes: > From: Ping-Ke Shih > > There is a potential race condition when the control byte of a CAM > entry is written first. Write in reverse order to correct the condition. > > Signed-off-by: Ping-Ke Shih >

Submitted patches for 4.11 NOW

Hi, Linus is hinting that he might release the final 4.10 next Sunday. So if you want have patches with new features in 4.11 better post them NOW to not the miss the merge window. -- Kalle Valo

Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e

On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote: > This is a 2x2 PCIe 802.11ac chipset by MediaTek > > Signed-off-by: Felix Fietkau Driver looks great to me, though I think it could be better commented. I have some minor issues, but if they need to be fixed, it could

[PATCH v3 0/2] mac80211: use crypto shash for AES cmac

This is something I spotted while working on AES in various modes for ARM and arm64. The mac80211 aes_cmac code reimplements the CMAC algorithm based on the core AES cipher, which is rather restrictive in how platforms can satisfy the dependency on this algorithm. For instance, SIMD

[PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the crypto API rather than reusing the open coded implementation in aes_cmac_vector(). This makes the code more understandable, and allows platforms to implement cmac(aes) in a more secure (*) and efficient way than is typically

[PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver

Instead of open coding the CMAC algorithm in the mac80211 driver using byte wide xors and calls into the crypto layer for each block of data, instantiate a cmac(aes) synchronous hash and pass all the data into it directly. This does not only simplify the code, it also allows the use of more

Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"

On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote: > On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: > > Seems the problem is caused by rtl92c_dm_*() casting .priv to > > "struct > > rtl_pci_priv", while it is "struct rtl_usb_priv". > > Those routines are shared by rtl8192ce and rtl8192cu,

Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac

On 6 February 2017 at 10:01, Malinen, Jouni wrote: > On Sun, Feb 05, 2017 at 03:23:26PM +, Ard Biesheuvel wrote: >> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is >> working. >> I have not tested patch #1 myself, mainly because the test

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Hi Kalle, the change suggested by you helps, and the device probe, scan is successful as well. Still good to have this change part of your basic sanity and regression testing ! regards, shafi On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote: > Kalle Valo

Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac

On Sun, Feb 05, 2017 at 03:23:26PM +, Ard Biesheuvel wrote: > NOTE: Jouni has been so kind to test patch #2, and confirmed that it is > working. > I have not tested patch #1 myself, mainly because the test methodology > requires downloading Ubuntu installer images, and I am

Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata

On Mon, 16 Jan 2017 17:28:18 +0100 Rafał Miłecki wrote: > From: Rafał Miłecki > > We have generic place & helpers for storing platform driver data so > there is no reason for using custom priv pointer. > > This allows cleaning up struct bcma_sflash from

Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

On 6 February 2017 at 08:47, Johannes Berg wrote: > >> { >> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; >> + struct shash_desc *desc; >> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)] >> CRYPTO_MINALIGN_ATTR; I realised we have a more idiomatic

Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD

> The type and mask are used as follows when checking an algorithm: > > alg->type & mask == type & mask > > So to request a synchronous algorithm (that is, one with the > CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and > mask to CRYPTO_ALG_ASYNC. Ah. Ok, that makes sense,

Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD

On Mon, Feb 06, 2017 at 07:54:37AM +0100, Johannes Berg wrote: > Hi, > > > The skcipher could have been of the async variant which may return > > from skcipher_encrypt() with -EINPROGRESS after having queued the > > request. > > The FILS AEAD implementation here does not have code for dealing

Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

>  { >   u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; > + struct shash_desc *desc; > + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)] > CRYPTO_MINALIGN_ATTR; >   size_t i; > - const u8 *data[2]; > - size_t data_len[2], data_elems; > + > + desc = (struct shash_desc

pull-request: mac80211 2017-02-06

Hi Dave, I know it's super late, but I was travelling last week and the whole FILS AEAD thing only played out over the weekend anyway. Since the FILS code is all new in this cycle, it'd be good to have the fixes, and the others are a bit older but still would be good to fix sooner rather than