Re: [PATCH v6] brcmfmac: add CLM download support

[Kalle Valo]

Chung-Hsien Hsu  writes:

> On Fri, Nov 03, 2017 at 03:40:45PM +0200, Kalle Valo wrote:
>> Chung-Hsien Hsu  writes:
>> 
>> > On Fri, Nov 03, 2017 at 10:20:07AM +0100, Arend van Spriel wrote:
>> >> On 03-11-17 09:27, Chung-Hsien Hsu wrote:
>> >> >On Thu, Oct 05, 2017 at 03:31:18PM +0800, Wright Feng wrote:
>> >> >>From: Chung-Hsien Hsu 
>> >> >>
>> >> >>The firmware for brcmfmac devices includes information regarding
>> >> >>regulatory constraints. For certain devices this information is kept
>> >> >>separately in a binary form that needs to be downloaded to the device.
>> >> >>This patch adds support to download this so-called CLM blob file. It
>> >> >>uses the same naming scheme as the other firmware files with extension
>> >> >>of .clm_blob.
>> >> >>
>> >> >>The CLM blob file is optional. If the file does not exist, the download
>> >> >>process will be bypassed. It will not affect the driver loading.
>> >> >>
>> >> >>Signed-off-by: Chung-Hsien Hsu 
>> >> >>---
>> >> >>v2: Revise commit message to describe in more detail
>> >> >>v3: Add error handling in brcmf_c_get_clm_name function
>> >> >>v4: Correct the length of dload_buf in brcmf_c_download function
>> >> >>v5: Remove unnecessary cast and alignment
>> >> >>v6: Add debug log for the case of no CLM file present
>> >> >>---
>> >> >>  .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  10 ++
>> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 162 
>> >> >> +
>> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/core.c|   2 +
>> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/core.h|   2 +
>> >> >>  .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  31 
>> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/pcie.c|  19 +++
>> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  19 +++
>> >> >>  .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  18 +++
>> >> >>  8 files changed, 263 insertions(+)
>> >> >
>> >> >Any comments or feedback about this? I'm hoping to have it in v4.15.
>> 
>> This might not necessary make it to v4.15, it depends if Linus releases
>> the final v4.14 on Sunday or not.
>
> Since the final v4.14 was not released last Sunday, is it possible to get 
> this to v4.15?

Thanks for reminding, apparently I had forgotten to change the state of
the patch from Deferred to New. But unfortunately the patch failed to
apply so you need to rebase and submit v7.

-- 
Kalle Valo

Re: [PATCH v6] brcmfmac: add CLM download support

[Kalle Valo]

Wright Feng  writes:

> From: Chung-Hsien Hsu 
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
>
> Signed-off-by: Chung-Hsien Hsu 

[...]

> + err = brcmf_fil_iovar_data_get(ifp, "clmver", buf, sizeof(buf));
> + if (err) {
> + if (err == -23) {

No magic numbers, please. Is this supposed to be -ENFILE?

-- 
Kalle Valo

Re: [v6] brcmfmac: add CLM download support

[Kalle Valo]

Wright Feng  wrote:

> From: Chung-Hsien Hsu 
> 
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
> 
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
> 
> Signed-off-by: Chung-Hsien Hsu 
> Reviewed-by: Arend van Spriel 

Didn't apply:

error: Failed to merge in the changes.
Applying: brcmfmac: add CLM download support
Using index info to reconstruct a base tree...
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
M   drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
CONFLICT (content): Merge conflict in 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
Patch failed at 0001 brcmfmac: add CLM download support
The copy of the patch that failed is found in: .git/rebase-apply/patch

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/patch/9986493/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2] ath9k: add MSI support

[Daniel Drake]

Hi Russell,

> On new Intel platforms like ApolloLake, legacy interrupt mechanism
> (INTx) is not supported

Could you please share the background on what you are claiming here.
I have multiple ApolloLake laptops here with many legacy interrupts
being used in /proc/interrupts.

I do see this ath9k problem on multiple Acer ApolloLake laptops, however
I also have an Asus E402NA ApolloLake laptop on hand where the exact same
ath9k miniPCIe card is working fine with legacy interrupts.

> With module paremeter "use_msi=1", ath9k driver would try to
> use MSI instead of INTx.

In the previous patch review it was suggested that MSI should become
the default - not a quirk or parameter.
https://lkml.org/lkml/2017/9/26/64


I have tested your patch on Acer Aspire ES1-432. It does not work -
I still can't connect to wifi.
/proc/interrupts shows that no MSI interrupts are delivered, the
counters are 0.

lspci -vv shows:
Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+
Address: fee0f00c  Data: 4142
Masking: 000e  Pending: 

So MSI is enabled and the vector number is 0x42 (decimal 66).
However my kernel log is now totally spammed with:
  do_IRQ: 0.64 No irq handler for vector

My assumption here is that the ath9k hardware implementation of
MSI is buggy, and it is therefore corrupting the MSI vector number
by zeroing out the lower 2 bits (e.g. 66 -> 64).

It would be very useful if Qualcomm could confirm if this behaviour
is really true and if it could potentially be fixed with a new ath9k
firmware version.

For more info please see:
   https://marc.info/?l=linux-pci=150238260826803=2
   https://marc.info/?t=15063128321=1=2
   https://marc.info/?l=linux-pci=150831581725596=2

Thanks
Daniel


> diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
> b/drivers/net/wireless/ath/ath9k/hw.c
> index 8c5c2dd8fa7f..cd0f023ccf77 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -922,6 +922,7 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw 
> *ah,
>   AR_IMR_RXERR |
>   AR_IMR_RXORN |
>   AR_IMR_BCNMISC;
> + u32 msi_cfg = 0;
>  
>   if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
>   AR_SREV_9561(ah))
> @@ -929,22 +930,30 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw 
> *ah,
>  
>   if (AR_SREV_9300_20_OR_LATER(ah)) {
>   imr_reg |= AR_IMR_RXOK_HP;
> - if (ah->config.rx_intr_mitigation)
> + if (ah->config.rx_intr_mitigation) {
>   imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
> + } else {
>   imr_reg |= AR_IMR_RXOK_LP;
> -
> + msi_cfg |= AR_INTCFG_MSI_RXOK;
> + }
>   } else {
> - if (ah->config.rx_intr_mitigation)
> + if (ah->config.rx_intr_mitigation) {
>   imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
> + } else {
>   imr_reg |= AR_IMR_RXOK;
> + msi_cfg |= AR_INTCFG_MSI_RXOK;
> + }
>   }
>  
> - if (ah->config.tx_intr_mitigation)
> + if (ah->config.tx_intr_mitigation) {
>   imr_reg |= AR_IMR_TXINTM | AR_IMR_TXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_TXINTM | AR_INTCFG_MSI_TXMINTR;
> + } else {
>   imr_reg |= AR_IMR_TXOK;
> + msi_cfg |= AR_INTCFG_MSI_TXOK;
> + }
>  
>   ENABLE_REGWRITE_BUFFER(ah);
>  
> @@ -952,6 +961,16 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw 
> *ah,
>   ah->imrs2_reg |= AR_IMR_S2_GTT;
>   REG_WRITE(ah, AR_IMR_S2, ah->imrs2_reg);
>  
> + if (ah->msi_enabled) {
> + ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
> + ah->msi_reg |= AR_PCIE_MSI_HW_DBI_WR_EN;
> + ah->msi_reg &= AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
> + REG_WRITE(ah, AR_INTCFG, msi_cfg);
> + ath_dbg(ath9k_hw_common(ah), ANY,
> + "value of AR_INTCFG=0x%X, msi_cfg=0x%X\n",
> + REG_READ(ah, AR_INTCFG), msi_cfg);
> + }
> +
>   if (!AR_SREV_9100(ah)) {
>   REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0x);
>   REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
> diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
> b/drivers/net/wireless/ath/ath9k/hw.h
> index 4ac70827d142..0d6c07c77372 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.h
> +++ b/drivers/net/wireless/ath/ath9k/hw.h
> @@ -977,6 +977,9 @@ struct ath_hw {
>   bool tpc_enabled;
>   u8 tx_power[Ar5416RateSize];
>   u8 tx_power_stbc[Ar5416RateSize];
> + bool msi_enabled;
> + u32 msi_mask;
> + u32 msi_reg;
>  };

Re: [PATCH v6] brcmfmac: add CLM download support

[Chung-Hsien Hsu]

On Fri, Nov 03, 2017 at 03:40:45PM +0200, Kalle Valo wrote:
> Chung-Hsien Hsu  writes:
> 
> > On Fri, Nov 03, 2017 at 10:20:07AM +0100, Arend van Spriel wrote:
> >> On 03-11-17 09:27, Chung-Hsien Hsu wrote:
> >> >On Thu, Oct 05, 2017 at 03:31:18PM +0800, Wright Feng wrote:
> >> >>From: Chung-Hsien Hsu 
> >> >>
> >> >>The firmware for brcmfmac devices includes information regarding
> >> >>regulatory constraints. For certain devices this information is kept
> >> >>separately in a binary form that needs to be downloaded to the device.
> >> >>This patch adds support to download this so-called CLM blob file. It
> >> >>uses the same naming scheme as the other firmware files with extension
> >> >>of .clm_blob.
> >> >>
> >> >>The CLM blob file is optional. If the file does not exist, the download
> >> >>process will be bypassed. It will not affect the driver loading.
> >> >>
> >> >>Signed-off-by: Chung-Hsien Hsu 
> >> >>---
> >> >>v2: Revise commit message to describe in more detail
> >> >>v3: Add error handling in brcmf_c_get_clm_name function
> >> >>v4: Correct the length of dload_buf in brcmf_c_download function
> >> >>v5: Remove unnecessary cast and alignment
> >> >>v6: Add debug log for the case of no CLM file present
> >> >>---
> >> >>  .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  10 ++
> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 162 
> >> >> +
> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/core.c|   2 +
> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/core.h|   2 +
> >> >>  .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  31 
> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/pcie.c|  19 +++
> >> >>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  19 +++
> >> >>  .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  18 +++
> >> >>  8 files changed, 263 insertions(+)
> >> >
> >> >Any comments or feedback about this? I'm hoping to have it in v4.15.
> 
> This might not necessary make it to v4.15, it depends if Linus releases
> the final v4.14 on Sunday or not.

Since the final v4.14 was not released last Sunday, is it possible to get this 
to v4.15?

> 
> >> Sorry for not following up. The change log for v6 made me wonder if
> >> all my comments on v5 were addressed. I just checked and it looks
> >> fine to me. Kalle has set this patch to Deferred state in patchwork
> >> maybe awaiting my response.
> 
> Yup, I was waiting your comments.
> 
> >> I already gave my "Reviewed-by:" on v5 so you may add that for v6,
> >> but I am sure Kalle can do that.
> >> 
> >> Regards,
> >> Arend
> >
> > Hi Arend,
> >
> > Thanks for the confirmation and quick reply. How can I know the state of
> > a patch, e.g., a patch is set to Deferred state?
> 
> I have documented this in the wiki:
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
> 
> > Could you please help to add Arend's "Reviewed-by:" on v6? Or should I
> > add it and resend v6?
> 
> Sure, I can add it. No need to resend.
> 
> And actually Arend should be able to add the tag automatically by
> replying to the patch with his tag, patchwork would then pick it up and
> add it when I apply the patch. To my knowledge patchwork supports
> Acked-by, Reviewed-by and Tested-by tags.

Thanks for the info.

Regards,
Chung-Hsien

> 
> -- 
> Kalle Valo

Re: rsi: rsi_91x_ps: remove redundant code in str_psstate

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> "INVALID_STATE" is already being returned in the default case and this
> code cannot be reached.
> 
> Addresses-Coverity-ID: 1398384
> Signed-off-by: Gustavo A. R. Silva 

Patch applied to wireless-drivers-next.git, thanks.

4775ae7afec6 rsi: rsi_91x_ps: remove redundant code in str_psstate

-- 
https://patchwork.kernel.org/patch/10044571/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rt2x00: use monotonic timestamps for frame dump

[Kalle Valo]

Arnd Bergmann  wrote:

> rt2x00 uses the deprecated do_gettimeofday() function to get a timestamp
> for its debugfs "dump" file interface.
> 
> The timestamp is using an unsigned 32-bit value, so we could make it
> work until 2106 by using ktime_get_real_ts64(), but it seems better to
> use monotonic times, as we normally want for timestamps.
> 
> Since this is an interface change, I'm incrementing the
> DUMP_HEADER_VERSION number, so user space can figure out whether the
> timestamps are monotonic or not. Most likely the tools won't care either
> way.
> 
> Generally speaking, ABI version numbers and in particular changing them
> is a bad idea. However since this is in debugfs, we don't put any
> API stability rules on the interface according to
> Documentation/filesystems/debugfs.txt, and we can take the easy way
> out here; anyone using the frame dump feature can probably work out
> the differences here.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

f87eba996bac rt2x00: use monotonic timestamps for frame dump

-- 
https://patchwork.kernel.org/patch/10043531/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Toke Høiland-Jørgensen]

Rajkumar Manoharan  writes:

> Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed
> this change as temp one and planned to revert it once it is fixed in
> stack or in driver.
>
> I thought Eric change in fq_codel is meant only for fatty udp flows.
> Forgive my ignorance.

It is, mostly. There's a separate possible issue with TCP performance
that we're looking into, but that is unrelated to TXQs.

-Toke

Re: rt2x00usb: mark device removed when get ENOENT usb error

[Kalle Valo]

Stanislaw Gruszka  wrote:

> ENOENT usb error mean "specified interface or endpoint does not exist or
> is not enabled". Mark device not present when we encounter this error
> similar like we do with ENODEV error.
> 
> Otherwise we can have infinite loop in rt2x00usb_work_rxdone(), because
> we remove and put again RX entries to the queue infinitely.
> 
> We can have similar situation when submit urb will fail all the time
> with other error, so we need consider to limit number of entries
> processed by rxdone work. But for now, since the patch fixes
> reproducible soft lockup issue on single processor systems
> and taken ENOENT error meaning, let apply this fix.
> 
> Patch adds additional ENOENT check not only in rx kick routine, but
> also on other places where we check for ENODEV error.
> 
> Reported-by: Richard Genoud 
> Debugged-by: Richard Genoud 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka 
> Tested-by: Richard Genoud 

Patch applied to wireless-drivers-next.git, thanks.

bfa62a52cad9 rt2x00usb: mark device removed when get ENOENT usb error

-- 
https://patchwork.kernel.org/patch/10050781/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [V2,1/9] qtnfmac: use per-band HT/VHT info from wireless device

[Kalle Valo]

Igor Mitsyanko  wrote:

> From: Igor Mitsyanko 
> 
> HT/VHT capabilities must be reported per each band supported by a radio,
> not for all bands on a radio. Furthermore, driver better not assume
> any capabilities and just use whetever is reported by device itself.
> 
> To support this, convert "get channels" command into "get band info"
> command. Difference is that it may also carry HT/VHT capabilities along
> with channels information.
> 
> While at it, also add "num_bitrates" field to "get band info" command,
> for future use.
> 
> Signed-off-by: Igor Mitsyanko 

9 patches applied to wireless-drivers-next.git, thanks.

e294cbfda056 qtnfmac: use per-band HT/VHT info from wireless device
d42df85f7d85 qtnfmac: initialize HT/VHT caps "can override" masks
d1398b5b34cc qtnfmac: get rid of PHYMODE capabilities flags
18b7470f92df qtnfmac: extend "IE set" TLV to include frame type info
5face518d446 qtnfmac: SCAN results: retreive frame type information from "IE 
set" TLV
4d1f0fabdc45 qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage
17011da0b8f0 qtnfmac: configure and start AP interface with a single command
a3945f43761c qtnfmac: include HTCAP and VHTCAP into config AP command
c9889671736c qtnfmac: pass all CONNECT cmd params to wireless card for 
processing

-- 
https://patchwork.kernel.org/patch/10033509/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [V2,1/7] brcmfmac: handle FWHALT mailbox indication

[Kalle Valo]

Arend Van Spriel  wrote:

> From: Arend Van Spriel 
> 
> The firmware uses a mailbox to communicate to the host what is going
> on. In the driver we validate the bit received. Various people seen
> the following message:
> 
>  brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
> 
> Bit 4 is cause of this message, but this actually indicates the firmware
> has halted. Handle this bit by giving a more meaningful error message.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Franky Lin 
> Signed-off-by: Arend van Spriel 

7 patches applied to wireless-drivers-next.git, thanks.

2fd3877b5bb7 brcmfmac: handle FWHALT mailbox indication
6c219b008815 brcmfmac: disable packet filtering in promiscuous mode
8c6efda22f5f brcmfmac: cleanup brcmf_cfg80211_escan() function
df2d8388bc96 brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
588378f15cff brcmfmac: get rid of brcmf_cfg80211_escan() function
bbf35414cd23 brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
bd99a3013bdc brcmfmac: move configuration of probe request IEs

-- 
https://patchwork.kernel.org/patch/10048525/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Rajkumar Manoharan]

> >
> > The issue that seems to point to has been fixed a while ago; I'll send
> > and updated patch with a better commit message (also forgot to cc the
> > ath10k list, I see).
> >
> > -Toke
> 
> Hmm. I remember that thread. I thought we'd basically resolved that issue (45%
> of the time spent in fq_codel_drop under udp flood), back then, with eric 
> adding
> the batch drop fix to fq_codel itself:
> 
> See commit: https://osdn.net/projects/android-
> x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca
> 
> which fixed up the problem beautifully:
> 
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
> 
> So if we've been carrying this darn patch for the ath10k vs something that 
> we'd
> actually fixed elsewhere in the stack, for over a year, sigh.
>
Dave,

Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed this
change as temp one and planned to revert it once it is fixed in stack or in 
driver.

I thought Eric change in fq_codel is meant only for fatty udp flows. Forgive my 
ignorance.

-Rajkumar

Re: ath9k disconnects in 4.13 with reason=4 locally_generated=1

[Daniel Drake]

On Fri, Nov 3, 2017 at 5:51 PM, Jouni Malinen  wrote:
> On Fri, Nov 03, 2017 at 10:57:11AM +0800, Daniel Drake wrote:
>> Endless OS recently upgraded from Linux 4.11 to Linux 4.13, and we now
>> have a few reports of issues with ath9k wireless becoming unusable.
>>
>> In the logs we can see that it authenticates, associates and completes
>> the WPA 4 way handshake, before then being disconnected with:
>>
>>  wlp2s0: CTRL-EVENT-DISCONNECTED bssid=74:26:ac:68:2f:c0 reason=4
>> locally_generated=1
>
> reason=4 is WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY. I'd expect the most
> likely source of this to be one of the mac80211 code paths in mlme.c
> where disconnection is triggered if the current AP become unreachable.
> Getting a debug log from mac80211 might help in figuring out what is
> causing this (there seem to be number of mlme_dbg() calls before most,
> but not necessarily all, places where
> WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY is used).

We got the log, it is coming from ieee80211_sta_work()

else if (ieee80211_hw_check(>hw, REPORTS_TX_ACK_STATUS)) {
sdata_info(sdata,t
 "Failed to send nullfunc to AP %pM after %dms,
disconnecting\n",
 bssid, probe_wait_ms);
ieee80211_sta_connection_lost(sdata, bssid,
WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY, false);

I looked again at changes between 4.12 and 4.13 and still no idea how
4.13 causes this problem :(

Daniel

Re: [PATCH V2 1/9] qtnfmac: use per-band HT/VHT info from wireless device

[Kalle Valo]

igor.mitsyanko...@quantenna.com writes:

> From: Igor Mitsyanko 
>
> HT/VHT capabilities must be reported per each band supported by a radio,
> not for all bands on a radio. Furthermore, driver better not assume
> any capabilities and just use whetever is reported by device itself.
>
> To support this, convert "get channels" command into "get band info"
> command. Difference is that it may also carry HT/VHT capabilities along
> with channels information.
>
> While at it, also add "num_bitrates" field to "get band info" command,
> for future use.
>
> Signed-off-by: Igor Mitsyanko 

[...]

> @@ -1241,13 +1273,32 @@ qtnf_cmd_resp_fill_channels_info(struct 
> ieee80211_supported_band *band,
>chan->hw_value, chan->flags, chan->max_power,
>chan->max_reg_power);
>   break;
> + case WLAN_EID_HT_CAPABILITY:
> + if (unlikely(tlv_dlen !=
> +  sizeof(struct ieee80211_ht_cap))) {
> + pr_err("bad HTCAP TLV len %zu\n", tlv_dlen);
> + goto error_ret;
> + }
> +
> + qtnf_cmd_resp_band_fill_htcap(tlv->val, >ht_cap);
> + break;
> + case WLAN_EID_VHT_CAPABILITY:
> + if (unlikely(tlv_dlen !=
> +  sizeof(struct ieee80211_vht_cap))) {
> + pr_err("bad VHTCAP TLV len %zu\n", tlv_dlen);
> + goto error_ret;
> + }
> +
> + qtnf_cmd_resp_band_fill_vhtcap(tlv->val,
> +>vht_cap);
> + break;

I'm having a hard time to believe that this in hotpath so the use of
unlikely() is not really making any sense to me. No need to resend
because of this, just looks strange and makes the code harder to read.

-- 
Kalle Valo

Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Kalle Valo]

Adding ath10k list to get this discussion to the list archive.

Dave Taht  writes:

> On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen  wrote:
>> Rajkumar Manoharan  writes:
>>
 Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
 mac80211 TXQs for some devices because of a theoretical throughput
 regression. We have not seen this regression for a while now, so it should 
 be
 safe to re-enable TXQs.

 Signed-off-by: Toke Høiland-Jørgensen 
 ---
 This has been in LEDE trunk for a couple of months now with good results.

>>> Toke,
>>>
>>> Good to know that the performance drop is not seen with the chips that does 
>>> not
>>> have push-pull support. The issue was originally reported with ap152 + 
>>> qca988x
>>> by community [1]. Hope this combination is also considered in LEDE.
>>
>> Ah, was that the original bug report? Thank you, I have not been able to
>> find that anywhere!
>>
>> The issue that seems to point to has been fixed a while ago; I'll send
>> and updated patch with a better commit message (also forgot to cc the
>> ath10k list, I see).
>>
>> -Toke
>
> Hmm. I remember that thread. I thought we'd basically resolved that
> issue (45% of the time spent in fq_codel_drop under udp flood),
> back then, with eric adding the batch drop fix to fq_codel itself:
>
> See commit: 
> https://osdn.net/projects/android-x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca
>
> which fixed up the problem beautifully:
>
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
>
> So if we've been carrying this darn patch for the ath10k vs something
> that we'd actually fixed elsewhere in the stack, for over a year,
> sigh.

-- 
Kalle Valo

[PATCH v2] ath10k: Re-enable TXQs for all devices

[Toke Høiland-Jørgensen]

Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
mac80211 TXQs for some devices because of a theoretical throughput
regression. The original regression report[1] was related to fq_codel
qdisc drop performance, which was fixed in
9d18562a227874289fda8ca5d117d8f503f1dcca. Since then, we have not seen
the TXQ-related regression, so it should be safe to re-enable TXQs.

[1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html

Signed-off-by: Toke Høiland-Jørgensen 
---
This has been in LEDE trunk for a couple of months now with good
results.

Changes since v1:
- Update commit message to refer to original report and the fix for it.
- Add ath10k list to cc

 drivers/net/wireless/ath/ath10k/mac.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..ca596ecd2d64 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8329,15 +8329,6 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
}
 
-   /* Current wake_tx_queue implementation imposes a significant
-* performance penalty in some setups. The tx scheduling code needs
-* more work anyway so disable the wake_tx_queue unless firmware
-* supports the pull-push mechanism.
-*/
-   if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
- ar->running_fw->fw_file.fw_features))
-   ar->ops->wake_tx_queue = NULL;
-
ret = ath10k_mac_init_rd(ar);
if (ret) {
ath10k_err(ar, "failed to derive regdom: %d\n", ret);
-- 
2.15.0

ath10k targaddrs issue

[Ben Greear]

While poking around in the firmware, I noticed what appears to be
an ath10k driver issue, which came in with this commit below.

commit 01d6fd6965eaf8d4b3aab681d30e77c53a834162
Author: Erik Stromdahl 
Date:   Wed Apr 26 12:17:55 2017 +0300

ath10k: various sdio related definitions

Debug masks for SDIO HIF layer.
Address definitions for SDIO/mbox based chipsets.
Augmented struct host_interest with more members.

Signed-off-by: Erik Stromdahl 
Signed-off-by: Kalle Valo 

...

diff --git a/drivers/net/wireless/ath/ath10k/targaddrs.h 
b/drivers/net/wireless/ath/ath10k/targaddrs.h
index cbac9e42..8bded5d 100644
--- a/drivers/net/wireless/ath/ath10k/targaddrs.h
+++ b/drivers/net/wireless/ath/ath10k/targaddrs.h
@@ -205,6 +205,24 @@ struct host_interest {
 */
/* Bit 1 - unused */
u32 hi_fw_swap; /* 0x104 */
+
+   /* global arenas pointer address, used by host driver debug */
+   u32 hi_dynamic_mem_arenas_addr; /* 0x108 */
+
+   /* allocated bytes of DRAM use by allocated */
+   u32 hi_dynamic_mem_allocated;   /* 0x10C */
+
+   /* remaining bytes of DRAM */
+   u32 hi_dynamic_mem_remaining;   /* 0x110 */
+
+   /* memory track count, configured by host */
+   u32 hi_dynamic_mem_track_max;   /* 0x114 */
+
+   /* minidump buffer */
+   u32 hi_minidump;/* 0x118 */
+
+   /* bdata's sig and key addr */
+   u32 hi_bd_sig_key;  /* 0x11c */
 } __packed;


Those variables above may be correct for some firmware, but they are not
correct for at least some versions of 10.4, which have this instead:

...
A_UINT32   hi_fw_swap;   /* 0x104 */

/* host side need to support tx/rx data packet swap */
A_UINT32   hi_txrx_dataswap;   /* 0x108 */  

/* enable allocram statistics gathering (set to an integer, which
 * is the number of tracking records that allocram will allocate).
 */
A_UINT32   hi_allocram_track_max; /* 0x108 
*/
}

I guess this may not be an issue as long as zero'd values are sent to the
10.4 nics, but it is confusing at best.

Eric, where did you get these values from?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Dave Taht]

On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen  wrote:
> Rajkumar Manoharan  writes:
>
>>> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
>>> mac80211 TXQs for some devices because of a theoretical throughput
>>> regression. We have not seen this regression for a while now, so it should 
>>> be
>>> safe to re-enable TXQs.
>>>
>>> Signed-off-by: Toke Høiland-Jørgensen 
>>> ---
>>> This has been in LEDE trunk for a couple of months now with good results.
>>>
>> Toke,
>>
>> Good to know that the performance drop is not seen with the chips that does 
>> not
>> have push-pull support. The issue was originally reported with ap152 + 
>> qca988x
>> by community [1]. Hope this combination is also considered in LEDE.
>
> Ah, was that the original bug report? Thank you, I have not been able to
> find that anywhere!
>
> The issue that seems to point to has been fixed a while ago; I'll send
> and updated patch with a better commit message (also forgot to cc the
> ath10k list, I see).
>
> -Toke

Hmm. I remember that thread. I thought we'd basically resolved that
issue (45% of the time spent in fq_codel_drop under udp flood),
back then, with eric adding the batch drop fix to fq_codel itself:

See commit: 
https://osdn.net/projects/android-x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca

which fixed up the problem beautifully:

https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html

So if we've been carrying this darn patch for the ath10k vs something
that we'd actually fixed elsewhere in the stack, for over a year,
sigh.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

RE: [PATCH] ath10k: Re-enable TXQs for all devices

[Toke Høiland-Jørgensen]

Rajkumar Manoharan  writes:

>> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
>> mac80211 TXQs for some devices because of a theoretical throughput
>> regression. We have not seen this regression for a while now, so it should be
>> safe to re-enable TXQs.
>> 
>> Signed-off-by: Toke Høiland-Jørgensen 
>> ---
>> This has been in LEDE trunk for a couple of months now with good results.
>>
> Toke,
>  
> Good to know that the performance drop is not seen with the chips that does 
> not
> have push-pull support. The issue was originally reported with ap152 + qca988x
> by community [1]. Hope this combination is also considered in LEDE.

Ah, was that the original bug report? Thank you, I have not been able to
find that anywhere!

The issue that seems to point to has been fixed a while ago; I'll send
and updated patch with a better commit message (also forgot to cc the
ath10k list, I see).

-Toke

[PATCH v2 0/6] wl1251: Fix MAC address for Nokia N900

[Pali Rohár]

This patch series fix processing MAC address for wl1251 chip found in Nokia 
N900.

Changes since v1:
* Added Acked-by for Pavel Machek
* Fixed grammar
* Magic numbers for NVS offsets are replaced by defines
* Check for validity of mac address NVS data is moved into function
* Changed order of patches as Pavel requested

Pali Rohár (6):
  wl1251: Update wl->nvs_len after wl->nvs is valid
  wl1251: Generate random MAC address only if driver does not have
valid
  wl1251: Parse and use MAC address from supplied NVS data
  wl1251: Set generated MAC address back to NVS data
  firmware: Add request_firmware_prefer_user() function
  wl1251: Use request_firmware_prefer_user() for loading NVS
calibration data

 drivers/base/firmware_class.c  |   45 +-
 drivers/net/wireless/ti/wl1251/Kconfig |1 +
 drivers/net/wireless/ti/wl1251/main.c  |  104 ++--
 include/linux/firmware.h   |9 +++
 4 files changed, 138 insertions(+), 21 deletions(-)

-- 
1.7.9.5

[PATCH v2 2/6] wl1251: Generate random MAC address only if driver does not have valid

[Pali Rohár]

Before this patch, driver generated random MAC address every time it was
initialized. After that random MAC address could be overwritten with fixed
one, if provided.

This patch changes order. First it tries to read fixed MAC address and if
it fails then driver generates random MAC address.

Signed-off-by: Pali Rohár 
Acked-by: Pavel Machek 
---
 drivers/net/wireless/ti/wl1251/main.c |   27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index 8929bb3..9106c20 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1492,7 +1492,24 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
wl->hw->queues = 4;
 
if (wl->use_eeprom)
-   wl1251_read_eeprom_mac(wl);
+   ret = wl1251_read_eeprom_mac(wl);
+   else
+   ret = -EINVAL;
+
+   if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
+   ret = -EINVAL;
+
+   if (ret < 0) {
+   /*
+* In case our MAC address is not correctly set,
+* we use a random but Nokia MAC.
+*/
+   static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
+   memcpy(wl->mac_addr, nokia_oui, 3);
+   get_random_bytes(wl->mac_addr + 3, 3);
+   wl1251_warning("MAC address in eeprom or nvs data is not 
valid");
+   wl1251_warning("Setting random MAC address: %pM", wl->mac_addr);
+   }
 
ret = wl1251_register_hw(wl);
if (ret)
@@ -1513,7 +1530,6 @@ struct ieee80211_hw *wl1251_alloc_hw(void)
struct ieee80211_hw *hw;
struct wl1251 *wl;
int i;
-   static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
 
hw = ieee80211_alloc_hw(sizeof(*wl), _ops);
if (!hw) {
@@ -1563,13 +1579,6 @@ struct ieee80211_hw *wl1251_alloc_hw(void)
INIT_WORK(>irq_work, wl1251_irq_work);
INIT_WORK(>tx_work, wl1251_tx_work);
 
-   /*
-* In case our MAC address is not correctly set,
-* we use a random but Nokia MAC.
-*/
-   memcpy(wl->mac_addr, nokia_oui, 3);
-   get_random_bytes(wl->mac_addr + 3, 3);
-
wl->state = WL1251_STATE_OFF;
mutex_init(>mutex);
spin_lock_init(>wl_lock);
-- 
1.7.9.5

[PATCH v2 1/6] wl1251: Update wl->nvs_len after wl->nvs is valid

[Pali Rohár]

If kmemdup fails, then wl->nvs_len will contain invalid non-zero size.

Signed-off-by: Pali Rohár 
Acked-by: Pavel Machek 
---
 drivers/net/wireless/ti/wl1251/main.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index 9915d83..8929bb3 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -122,8 +122,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
goto out;
}
 
-   wl->nvs_len = fw->size;
-   wl->nvs = kmemdup(fw->data, wl->nvs_len, GFP_KERNEL);
+   wl->nvs = kmemdup(fw->data, fw->size, GFP_KERNEL);
 
if (!wl->nvs) {
wl1251_error("could not allocate memory for the nvs file");
@@ -131,6 +130,8 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
goto out;
}
 
+   wl->nvs_len = fw->size;
+
ret = 0;
 
 out:
-- 
1.7.9.5

[PATCH v2 5/6] firmware: Add request_firmware_prefer_user() function

[Pali Rohár]

This function works pretty much like request_firmware(), but it prefer
usermode helper. If usermode helper fails then it fallback to direct
access. Useful for dynamic or model specific firmware data.

Signed-off-by: Pali Rohár 
---
 drivers/base/firmware_class.c |   45 +++--
 include/linux/firmware.h  |9 +
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4b57cf5..c3a9fe5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -195,6 +195,11 @@ static int __fw_state_check(struct fw_state *fw_st, enum 
fw_status status)
 #endif
 #define FW_OPT_NO_WARN (1U << 3)
 #define FW_OPT_NOCACHE (1U << 4)
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+#define FW_OPT_PREFER_USER (1U << 5)
+#else
+#define FW_OPT_PREFER_USER 0
+#endif
 
 struct firmware_cache {
/* firmware_buf instance will be added into the below list */
@@ -1214,13 +1219,26 @@ static void fw_abort_batch_reqs(struct firmware *fw)
if (ret <= 0) /* error or already assigned */
goto out;
 
-   ret = fw_get_filesystem_firmware(device, fw->priv);
+   if (opt_flags & FW_OPT_PREFER_USER) {
+   ret = fw_load_from_user_helper(fw, name, device, opt_flags, 
timeout);
+   if (ret && !(opt_flags & FW_OPT_NO_WARN)) {
+   dev_warn(device,
+"User helper firmware load for %s failed with 
error %d\n",
+name, ret);
+   dev_warn(device, "Falling back to direct firmware 
load\n");
+   }
+   } else {
+   ret = -EINVAL;
+   }
+
+   if (ret)
+   ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
if (!(opt_flags & FW_OPT_NO_WARN))
dev_warn(device,
 "Direct firmware load for %s failed with error 
%d\n",
 name, ret);
-   if (opt_flags & FW_OPT_USERHELPER) {
+   if ((opt_flags & FW_OPT_USERHELPER) && !(opt_flags & 
FW_OPT_PREFER_USER)) {
dev_warn(device, "Falling back to user helper\n");
ret = fw_load_from_user_helper(fw, name, device,
   opt_flags);
@@ -1329,6 +1347,29 @@ int request_firmware_direct(const struct firmware 
**firmware_p,
 EXPORT_SYMBOL(request_firmware_into_buf);
 
 /**
+ * request_firmware_prefer_user: - prefer usermode helper for loading firmware
+ * @firmware_p: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function works pretty much like request_firmware(), but it prefer
+ * usermode helper. If usermode helper fails then it fallback to direct access.
+ * Useful for dynamic or model specific firmware data.
+ **/
+int request_firmware_prefer_user(const struct firmware **firmware_p,
+   const char *name, struct device *device)
+{
+   int ret;
+
+   __module_get(THIS_MODULE);
+   ret = _request_firmware(firmware_p, name, device, NULL, 0,
+   FW_OPT_UEVENT | FW_OPT_PREFER_USER);
+   module_put(THIS_MODULE);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
+
+/**
  * release_firmware: - release the resource associated with a firmware image
  * @fw: firmware resource to release
  **/
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index d450808..8584528 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -48,6 +48,8 @@ int request_firmware_nowait(
void (*cont)(const struct firmware *fw, void *context));
 int request_firmware_direct(const struct firmware **fw, const char *name,
struct device *device);
+int request_firmware_prefer_user(const struct firmware **fw, const char *name,
+struct device *device);
 int request_firmware_into_buf(const struct firmware **firmware_p,
const char *name, struct device *device, void *buf, size_t size);
 
@@ -78,6 +80,13 @@ static inline int request_firmware_direct(const struct 
firmware **fw,
return -EINVAL;
 }
 
+static inline int request_firmware_prefer_user(const struct firmware **fw,
+  const char *name,
+  struct device *device)
+{
+   return -EINVAL;
+}
+
 static inline int request_firmware_into_buf(const struct firmware **firmware_p,
const char *name, struct device *device, void *buf, size_t size)
 {
-- 
1.7.9.5

[PATCH v2 4/6] wl1251: Set generated MAC address back to NVS data

[Pali Rohár]

In case there is no valid MAC address kernel generates random one. This
patch propagate this generated MAC address back to NVS data which will be
uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
uses.

This should not change any functionality, but it is better to tell wl1251
correct mac address since beginning of chip usage.

Signed-off-by: Pali Rohár 
---
 drivers/net/wireless/ti/wl1251/main.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index d497ba5..1f423be 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1481,6 +1481,21 @@ static int wl1251_read_nvs_mac(struct wl1251 *wl)
return 0;
 }
 
+static int wl1251_write_nvs_mac(struct wl1251 *wl)
+{
+   int i, ret;
+
+   ret = wl1251_check_nvs_mac(wl);
+   if (ret)
+   return ret;
+
+   /* MAC is stored in reverse order */
+   for (i = 0; i < ETH_ALEN; i++)
+   wl->nvs[NVS_OFF_MAC_DATA + i] = wl->mac_addr[ETH_ALEN - i - 1];
+
+   return 0;
+}
+
 static int wl1251_register_hw(struct wl1251 *wl)
 {
int ret;
@@ -1546,6 +1561,8 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
memcpy(wl->mac_addr, nokia_oui, 3);
get_random_bytes(wl->mac_addr + 3, 3);
+   if (!wl->use_eeprom)
+   wl1251_write_nvs_mac(wl);
wl1251_warning("MAC address in eeprom or nvs data is not 
valid");
wl1251_warning("Setting random MAC address: %pM", wl->mac_addr);
}
-- 
1.7.9.5

[PATCH v2 6/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Pali Rohár]

NVS calibration data for wl1251 are model specific. Every one device with
wl1251 chip has different and calibrated in factory.

Not all wl1251 chips have own EEPROM where are calibration data stored. And
in that case there is no "standard" place. Every device has stored them on
different place (some in rootfs file, some in dedicated nand partition,
some in another proprietary structure).

Kernel wl1251 driver cannot support every one different storage decided by
device manufacture so it will use request_firmware_prefer_user() call for
loading NVS calibration data and userspace helper will be responsible to
prepare correct data.

In case userspace helper fails request_firmware_prefer_user() still try to
load data file directly from VFS as fallback mechanism.

On Nokia N900 device, which has wl1251 chip, NVS calibration data are
stored in CAL nand partition. CAL is proprietary Nokia key/value format for
nand devices.

With this patch it is finally possible to load correct model specific NVS
calibration data for Nokia N900.

Userspace tool for reading NVS calibration data on Nokia N900 is available
in git repository at: https://github.com/community-ssu/wl1251-cal

Signed-off-by: Pali Rohár 
---
 drivers/net/wireless/ti/wl1251/Kconfig |1 +
 drivers/net/wireless/ti/wl1251/main.c  |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wl1251/Kconfig 
b/drivers/net/wireless/ti/wl1251/Kconfig
index 7142ccf..affe154 100644
--- a/drivers/net/wireless/ti/wl1251/Kconfig
+++ b/drivers/net/wireless/ti/wl1251/Kconfig
@@ -2,6 +2,7 @@ config WL1251
tristate "TI wl1251 driver support"
depends on MAC80211
select FW_LOADER
+   select FW_LOADER_USER_HELPER
select CRC7
---help---
  This will enable TI wl1251 driver support. The drivers make
diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index 1f423be..e9d232c 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -108,7 +108,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
struct device *dev = wiphy_dev(wl->hw->wiphy);
int ret;
 
-   ret = request_firmware(, WL1251_NVS_NAME, dev);
+   ret = request_firmware_prefer_user(, WL1251_NVS_NAME, dev);
 
if (ret < 0) {
wl1251_error("could not get nvs file: %d", ret);
-- 
1.7.9.5

Re: [PATCH 0/4] neard: Add support for deactivating tags

[Samuel Ortiz]

On Thu, Jun 15, 2017 at 08:57:24PM -0700, Mark Greer wrote:
> This series adds the ability for client apps to deactivate a currently
> active tag.  Once deactivated, the client can either poll again to
> reactivate the tag or power the adapter off to save power.  These
> changes will not work until the Linux kernel commits submitted under
> the subject, "NFC: Add deactivate target functionality" are committed.
> Those commits can be viewed here:
> 
>   https://lists.01.org/pipermail/linux-nfc/2017-June/004415.html
> 
> The commits are based on the commits submitted previously under the
> subject, "[PATCH 00/23] neard: Support TI Std & Pro tags, fixups, etc."
> which can be viewed here:
> 
>   https://lists.01.org/pipermail/linux-nfc/2017-June/004392.html
> 
> For convenience, these commits are available in the 'submit/deactivate_tag-v1'
> branch of this repo on github:
> 
>   https://github.com/animalcreek/neard.git
> 
> Mark Greer (4):
>   adapter: Make adapter_start_poll() global
>   adapter: Add call indicating whether constant poll is enabled
>   tag: Add Tag deactivate support
>   test: Add option to deactivate tag
All 4 patches applied, thanks.

Cheers,
Samuel.

[PATCH v2 3/6] wl1251: Parse and use MAC address from supplied NVS data

[Pali Rohár]

This patch implements parsing MAC address from NVS data which are sent to
wl1251 chip. Calibration NVS data could contain valid MAC address and it
will be used instead of randomly generated one.

This patch also moves code for requesting NVS data from userspace to driver
initialization code to make sure that NVS data will be there at time when
permanent MAC address is needed.

Calibration NVS data for wl1251 are device specific. Every device with
wl1251 chip should have been calibrated in factory and needs to provide own
calibration data.

Default example file wl1251-nvs.bin, found in linux-firmware repository,
contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
invalid as it is not real device specific address, just example one.

Format of calibration NVS data can be found at:
http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt

Signed-off-by: Pali Rohár 
---
 drivers/net/wireless/ti/wl1251/main.c |   55 -
 1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index 9106c20..d497ba5 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -203,13 +203,6 @@ static int wl1251_chip_wakeup(struct wl1251 *wl)
goto out;
}
 
-   if (wl->nvs == NULL && !wl->use_eeprom) {
-   /* No NVS from netlink, try to get it from the filesystem */
-   ret = wl1251_fetch_nvs(wl);
-   if (ret < 0)
-   goto out;
-   }
-
 out:
return ret;
 }
@@ -1448,6 +1441,46 @@ static int wl1251_read_eeprom_mac(struct wl1251 *wl)
return 0;
 }
 
+#define NVS_OFF_MAC_LEN 0x19
+#define NVS_OFF_MAC_ADDR_LO 0x1a
+#define NVS_OFF_MAC_ADDR_HI 0x1b
+#define NVS_OFF_MAC_DATA 0x1c
+
+static int wl1251_check_nvs_mac(struct wl1251 *wl)
+{
+   if (wl->nvs_len < 0x24)
+   return -ENODATA;
+
+   /* length is 2 and data address is 0x546c (ANDed with 0xfffe) */
+   if (wl->nvs[NVS_OFF_MAC_LEN] != 2 ||
+   wl->nvs[NVS_OFF_MAC_ADDR_LO] != 0x6d ||
+   wl->nvs[NVS_OFF_MAC_ADDR_HI] != 0x54)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int wl1251_read_nvs_mac(struct wl1251 *wl)
+{
+   u8 mac[ETH_ALEN];
+   int i, ret;
+
+   ret = wl1251_check_nvs_mac(wl);
+   if (ret)
+   return ret;
+
+   /* MAC is stored in reverse order */
+   for (i = 0; i < ETH_ALEN; i++)
+   mac[i] = wl->nvs[NVS_OFF_MAC_DATA + ETH_ALEN - i - 1];
+
+   /* 00:00:20:07:03:09 is in example file wl1251-nvs.bin, so invalid */
+   if (ether_addr_equal_unaligned(mac, "\x00\x00\x20\x07\x03\x09"))
+   return -EINVAL;
+
+   memcpy(wl->mac_addr, mac, ETH_ALEN);
+   return 0;
+}
+
 static int wl1251_register_hw(struct wl1251 *wl)
 {
int ret;
@@ -1491,10 +1524,16 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
 
wl->hw->queues = 4;
 
+   if (wl->nvs == NULL && !wl->use_eeprom) {
+   ret = wl1251_fetch_nvs(wl);
+   if (ret < 0)
+   goto out;
+   }
+
if (wl->use_eeprom)
ret = wl1251_read_eeprom_mac(wl);
else
-   ret = -EINVAL;
+   ret = wl1251_read_nvs_mac(wl);
 
if (ret == 0 && !is_valid_ether_addr(wl->mac_addr))
ret = -EINVAL;
-- 
1.7.9.5

Re: [PATCH 00/23] neard: Support TI Std & Pro tags, fixups, etc.

[Samuel Ortiz]

Hi Mark,

On Thu, Jun 15, 2017 at 11:24:53AM -0700, Mark Greer wrote:
> This is an assortment of commits that make some fixups, do some general
> tightening of NDEF data checking, add support for TI Standard and Pro
> Type 5 tags, and stop issuing the Read Multiple Blocks command when
> formatting a Type 5 tag.  The reasoning for each change is in the
> individual commit descriptions.
> 
> For convenience, a branch with these commits is available in the
> submit/updates-v1 branch here:
> 
>   https://github.com/animalcreek/neard.git
Applied, thanks.

Cheers,
Samuel.

Re: [PATCH 0/2] NFC: Add deactivate target functionality

[Samuel Ortiz]

Hi Mark,

On Thu, Jun 15, 2017 at 08:34:20PM -0700, Mark Greer wrote:
> There is currently no way for userspace to deactivate an active target.
> Since the target is active, the adapter cannot be powered down which
> wastes wastes power when the target has been read and isn't needed
> anymore (but remains within range).  To solve this, add a way to
> deactivate a currently active target which will then allow the adapter
> to be powered down.
> 
> To be fully operational, this requires companion patches for neard.
> Those patches will be submitted shortly.
> 
> Mark Greer (2):
>   NFC: digital: Abort cmd when deactivating target
>   NFC: Add NFC_CMD_DEACTIVATE_TARGET support
Both patches applied to nfc-next, thanks.

Cheers,
Samuel.

RE: [PATCH] ath10k: Re-enable TXQs for all devices

[Rajkumar Manoharan]

> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
> mac80211 TXQs for some devices because of a theoretical throughput
> regression. We have not seen this regression for a while now, so it should be
> safe to re-enable TXQs.
> 
> Signed-off-by: Toke Høiland-Jørgensen 
> ---
> This has been in LEDE trunk for a couple of months now with good results.
>
Toke,
 
Good to know that the performance drop is not seen with the chips that does not
have push-pull support. The issue was originally reported with ap152 + qca988x
by community [1]. Hope this combination is also considered in LEDE.

-Rajkumar

[1] - http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html

Re: [PATCH] rt2x00usb: mark device removed when get ENOENT usb error

[Richard Genoud]

On 09/11/2017 11:59, Stanislaw Gruszka wrote:
> ENOENT usb error mean "specified interface or endpoint does not exist or
> is not enabled". Mark device not present when we encounter this error
> similar like we do with ENODEV error.
> 
> Otherwise we can have infinite loop in rt2x00usb_work_rxdone(), because
> we remove and put again RX entries to the queue infinitely.
> 
> We can have similar situation when submit urb will fail all the time
> with other error, so we need consider to limit number of entries
> processed by rxdone work. But for now, since the patch fixes
> reproducible soft lockup issue on single processor systems
> and taken ENOENT error meaning, let apply this fix.
> 
> Patch adds additional ENOENT check not only in rx kick routine, but
> also on other places where we check for ENODEV error.
> 
> Reported-by: Richard Genoud 
> Debugged-by: Richard Genoud 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka 

Tested-by: Richard Genoud 
(on 4.14-rc8)

This is working like a charm now !

Thanks !!

Richard.

> ---
>  drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c 
> b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> index e2f4f5778267..086aad22743d 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> @@ -57,7 +57,7 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
>   if (status >= 0)
>   return 0;
>  
> - if (status == -ENODEV) {
> + if (status == -ENODEV || status == -ENOENT) {
>   /* Device has disappeared. */
>   clear_bit(DEVICE_STATE_PRESENT, >flags);
>   break;
> @@ -321,7 +321,7 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry 
> *entry, void *data)
>  
>   status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
>   if (status) {
> - if (status == -ENODEV)
> + if (status == -ENODEV || status == -ENOENT)
>   clear_bit(DEVICE_STATE_PRESENT, >flags);
>   set_bit(ENTRY_DATA_IO_FAILED, >flags);
>   rt2x00lib_dmadone(entry);
> @@ -410,7 +410,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry 
> *entry, void *data)
>  
>   status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
>   if (status) {
> - if (status == -ENODEV)
> + if (status == -ENODEV || status == -ENOENT)
>   clear_bit(DEVICE_STATE_PRESENT, >flags);
>   set_bit(ENTRY_DATA_IO_FAILED, >flags);
>   rt2x00lib_dmadone(entry);
> 

[PATCH] cfg80211: cleanup signal strength units notation

[Sergey Matyukevich]

Both cfg80211_rx_mgmt and cfg80211_report_obss_beacon functions send
reports to userspace using NL80211_ATTR_RX_SIGNAL_DBM attribute w/o
any processing of their input signal values. Which means that in
order to match userspace tools expectations, input signal values
for those functions are supposed to be in dBm units.

This patch cleans up comments, variable names, and trace reports
for those functions, replacing confusing 'mBm' by 'dBm'.

Signed-off-by: Sergey Matyukevich 
---
 include/net/cfg80211.h |  4 ++--
 net/wireless/mlme.c|  6 +++---
 net/wireless/trace.h   | 12 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8b8118a7fadb..54321759aa44 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5576,7 +5576,7 @@ void cfg80211_conn_failed(struct net_device *dev, const 
u8 *mac_addr,
  * cfg80211_rx_mgmt - notification of received, unprocessed management frame
  * @wdev: wireless device receiving the frame
  * @freq: Frequency on which the frame was received in MHz
- * @sig_dbm: signal strength in mBm, or 0 if unknown
+ * @sig_dbm: signal strength in dBm, or 0 if unknown
  * @buf: Management frame (header + body)
  * @len: length of the frame data
  * @flags: flags, as defined in enum nl80211_rxmgmt_flags
@@ -5755,7 +5755,7 @@ void cfg80211_probe_status(struct net_device *dev, const 
u8 *addr,
  * @frame: the frame
  * @len: length of the frame
  * @freq: frequency the frame was received on
- * @sig_dbm: signal strength in mBm, or 0 if unknown
+ * @sig_dbm: signal strength in dBm, or 0 if unknown
  *
  * Use this function to report to userspace when a beacon was
  * received. It is not useful to call this when there is no
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index e7c64a8dce54..bbb9907bfa86 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -692,7 +692,7 @@ int cfg80211_mlme_mgmt_tx(struct cfg80211_registered_device 
*rdev,
return rdev_mgmt_tx(rdev, wdev, params, cookie);
 }
 
-bool cfg80211_rx_mgmt(struct wireless_dev *wdev, int freq, int sig_mbm,
+bool cfg80211_rx_mgmt(struct wireless_dev *wdev, int freq, int sig_dbm,
  const u8 *buf, size_t len, u32 flags)
 {
struct wiphy *wiphy = wdev->wiphy;
@@ -708,7 +708,7 @@ bool cfg80211_rx_mgmt(struct wireless_dev *wdev, int freq, 
int sig_mbm,
cpu_to_le16(IEEE80211_FCTL_FTYPE | IEEE80211_FCTL_STYPE);
u16 stype;
 
-   trace_cfg80211_rx_mgmt(wdev, freq, sig_mbm);
+   trace_cfg80211_rx_mgmt(wdev, freq, sig_dbm);
stype = (le16_to_cpu(mgmt->frame_control) & IEEE80211_FCTL_STYPE) >> 4;
 
if (!(stypes->rx & BIT(stype))) {
@@ -735,7 +735,7 @@ bool cfg80211_rx_mgmt(struct wireless_dev *wdev, int freq, 
int sig_mbm,
 
/* Indicate the received Action frame to user space */
if (nl80211_send_mgmt(rdev, wdev, reg->nlportid,
- freq, sig_mbm,
+ freq, sig_dbm,
  buf, len, flags, GFP_ATOMIC))
continue;
 
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index f3353fe5b35b..bcfedd39e7a3 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2544,20 +2544,20 @@ DEFINE_EVENT(cfg80211_netdev_mac_evt, cfg80211_del_sta,
 );
 
 TRACE_EVENT(cfg80211_rx_mgmt,
-   TP_PROTO(struct wireless_dev *wdev, int freq, int sig_mbm),
-   TP_ARGS(wdev, freq, sig_mbm),
+   TP_PROTO(struct wireless_dev *wdev, int freq, int sig_dbm),
+   TP_ARGS(wdev, freq, sig_dbm),
TP_STRUCT__entry(
WDEV_ENTRY
__field(int, freq)
-   __field(int, sig_mbm)
+   __field(int, sig_dbm)
),
TP_fast_assign(
WDEV_ASSIGN;
__entry->freq = freq;
-   __entry->sig_mbm = sig_mbm;
+   __entry->sig_dbm = sig_dbm;
),
-   TP_printk(WDEV_PR_FMT ", freq: %d, sig mbm: %d",
- WDEV_PR_ARG, __entry->freq, __entry->sig_mbm)
+   TP_printk(WDEV_PR_FMT ", freq: %d, sig dbm: %d",
+ WDEV_PR_ARG, __entry->freq, __entry->sig_dbm)
 );
 
 TRACE_EVENT(cfg80211_mgmt_tx_status,
-- 
2.11.0

[PATCH] rt2x00usb: mark device removed when get ENOENT usb error

[Stanislaw Gruszka]

ENOENT usb error mean "specified interface or endpoint does not exist or
is not enabled". Mark device not present when we encounter this error
similar like we do with ENODEV error.

Otherwise we can have infinite loop in rt2x00usb_work_rxdone(), because
we remove and put again RX entries to the queue infinitely.

We can have similar situation when submit urb will fail all the time
with other error, so we need consider to limit number of entries
processed by rxdone work. But for now, since the patch fixes
reproducible soft lockup issue on single processor systems
and taken ENOENT error meaning, let apply this fix.

Patch adds additional ENOENT check not only in rx kick routine, but
also on other places where we check for ENODEV error.

Reported-by: Richard Genoud 
Debugged-by: Richard Genoud 
Cc: sta...@vger.kernel.org
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e2f4f5778267..086aad22743d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -57,7 +57,7 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
if (status >= 0)
return 0;
 
-   if (status == -ENODEV) {
+   if (status == -ENODEV || status == -ENOENT) {
/* Device has disappeared. */
clear_bit(DEVICE_STATE_PRESENT, >flags);
break;
@@ -321,7 +321,7 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry 
*entry, void *data)
 
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   if (status == -ENODEV)
+   if (status == -ENODEV || status == -ENOENT)
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
@@ -410,7 +410,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry 
*entry, void *data)
 
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   if (status == -ENODEV)
+   if (status == -ENODEV || status == -ENOENT)
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
rt2x00lib_dmadone(entry);
-- 
2.7.5

Re: Soft lockup in rt2x00usb_work_rxdone()

[Stanislaw Gruszka]

On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> (maybe if there was more than one CPU on the board, I could do
> something, but that's not the case)

I reproduced the problem with nosmp option. I think we need
to check also for ENOENT error (not only for ENODEV).
Will post the fix in a second.

Thanks for reporting and debugging
Stanislaw 

[RFC PATCH 1/2] nl80211: implement NL80211_CMD_GET_BEACON command

[Sergey Matyukevich]

From: Vasily Ulyanov 

Implement nl80211_get_beacon callback which returns current beacon
configuration. The actual data is saved on .start_ap and .set_beacon calls.

Signed-off-by: Vasily Ulyanov 
---
 include/net/cfg80211.h   |   3 +
 include/uapi/linux/nl80211.h |   5 +-
 net/wireless/nl80211.c   | 220 +++
 3 files changed, 227 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8b8118a7fadb..31d39e066274 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4002,6 +4002,8 @@ struct cfg80211_cqm_config;
  * the user-set channel definition.
  * @preset_chandef: (private) Used by the internal configuration code to
  * track the channel to be used for AP later
+ * @beacon: (private) Used by the internal configuration code to track
+ * the user-set effective beacon data.
  * @bssid: (private) Used by the internal configuration code
  * @ssid: (private) Used by the internal configuration code
  * @ssid_len: (private) Used by the internal configuration code
@@ -4078,6 +4080,7 @@ struct wireless_dev {
struct cfg80211_internal_bss *current_bss; /* associated / joined */
struct cfg80211_chan_def preset_chandef;
struct cfg80211_chan_def chandef;
+   struct cfg80211_beacon_data beacon;
 
bool ibss_fixed;
bool ibss_dfs_possible;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index f882fe1f9709..e9e163bbe11a 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -279,7 +279,10 @@
  * @NL80211_CMD_DEL_KEY: delete a key identified by %NL80211_ATTR_KEY_IDX
  * or %NL80211_ATTR_MAC.
  *
- * @NL80211_CMD_GET_BEACON: (not used)
+ * @NL80211_CMD_GET_BEACON: Get beacon attributes on an access point interface.
+ * %NL80211_ATTR_BEACON_HEAD, %NL80211_ATTR_BEACON_TAIL, %NL80211_ATTR_IE,
+ * %NL80211_ATTR_IE_PROBE_RESP, NL80211_ATTR_IE_ASSOC_RESP,
+ * %NL80211_ATTR_PROBE_RESP will be returned if present.
  * @NL80211_CMD_SET_BEACON: change the beacon on an access point interface
  * using the %NL80211_ATTR_BEACON_HEAD and %NL80211_ATTR_BEACON_TAIL
  * attributes. For drivers that generate the beacon and probe responses
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fce2cbe6a193..f03f9989efbc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3784,6 +3784,172 @@ static int nl80211_parse_beacon(struct nlattr *attrs[],
return 0;
 }
 
+static size_t nl80211_beacon_size(struct cfg80211_beacon_data *bcn)
+{
+   size_t size = bcn->head_len + bcn->tail_len +
+ bcn->beacon_ies_len +
+ bcn->proberesp_ies_len +
+ bcn->assocresp_ies_len +
+ bcn->probe_resp_len;
+
+   return size;
+}
+
+static void nl80211_free_beacon(struct cfg80211_beacon_data *bcn)
+{
+#define free_and_null(member) \
+   do { \
+   kfree(bcn->member); \
+   bcn->member = NULL; \
+   bcn->member ## _len = 0; \
+   } while (0)
+
+   free_and_null(head);
+   free_and_null(tail);
+   free_and_null(beacon_ies);
+   free_and_null(proberesp_ies);
+   free_and_null(assocresp_ies);
+   free_and_null(probe_resp);
+
+#undef free_and_null
+}
+
+static int nl80211_dup_beacon(struct cfg80211_beacon_data *dst,
+ struct cfg80211_beacon_data *src)
+{
+   memset(dst, 0, sizeof(*dst));
+
+#define check_and_dup(member) \
+   do { \
+   if (src->member && (src->member ## _len > 0)) { \
+   dst->member = kmemdup(src->member, \
+ src->member ## _len, \
+ GFP_KERNEL); \
+   if (!dst->member) \
+   goto dup_failure; \
+   dst->member ## _len = src->member ## _len; \
+   } \
+   } while (0)
+
+   check_and_dup(head);
+   check_and_dup(tail);
+   check_and_dup(beacon_ies);
+   check_and_dup(proberesp_ies);
+   check_and_dup(assocresp_ies);
+   check_and_dup(probe_resp);
+
+#undef dup_and_check
+
+   return 0;
+
+dup_failure:
+   nl80211_free_beacon(dst);
+   return -ENOMEM;
+}
+
+static int nl80211_merge_beacons(struct cfg80211_beacon_data *dst,
+struct cfg80211_beacon_data *old,
+struct cfg80211_beacon_data *new)
+{
+   memset(dst, 0, sizeof(*dst));
+
+#define check_and_merge(member) \
+   do { \
+   if (new->member && (new->member ## _len > 0)) { \
+   dst->member = kmemdup(new->member, \
+ new->member ## _len, \
+ GFP_KERNEL); \
+   if 

[RFC PATCH 2/2] nl80211: implement beacon change notifier

[Sergey Matyukevich]

From: Vasily Ulyanov 

Notify user-space listeners about beacon data change.

Signed-off-by: Vasily Ulyanov 
---
 net/wireless/nl80211.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f03f9989efbc..98e52e5ffc13 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3950,6 +3950,26 @@ static int nl80211_send_beacon(struct sk_buff *msg, u32 
portid,
return -EMSGSIZE;
 }
 
+static void nl80211_notify_beacon_change(struct net_device *dev,
+enum nl80211_commands cmd,
+struct cfg80211_beacon_data *bcn)
+{
+   struct wiphy *wiphy = dev->ieee80211_ptr->wiphy;
+   struct sk_buff *msg;
+
+   msg = nlmsg_new(nl80211_beacon_size(bcn), GFP_KERNEL);
+   if (!msg)
+   return;
+
+   if (nl80211_send_beacon(msg, cmd, 0, 0, 0, bcn) < 0) {
+   nlmsg_free(msg);
+   return;
+   }
+
+   genlmsg_multicast_netns(_fam, wiphy_net(wiphy), msg, 0,
+   NL80211_MCGRP_MLME, GFP_KERNEL);
+}
+
 static void nl80211_check_ap_rate_selectors(struct cfg80211_ap_settings 
*params,
const u8 *rates)
 {
@@ -4250,6 +4270,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct 
genl_info *info)
wdev->ssid_len = params.ssid_len;
memcpy(wdev->ssid, params.ssid, wdev->ssid_len);
nl80211_assign_beacon(>beacon, _bcn);
+   nl80211_notify_beacon_change(dev, NL80211_CMD_START_AP,
+>beacon);
}
wdev_unlock(wdev);
 
@@ -4317,8 +4339,11 @@ static int nl80211_set_beacon(struct sk_buff *skb, 
struct genl_info *info)
 
wdev_lock(wdev);
err = rdev_change_beacon(rdev, dev, );
-   if (!err)
+   if (!err) {
nl80211_assign_beacon(>beacon, _bcn);
+   nl80211_notify_beacon_change(dev, NL80211_CMD_SET_BEACON,
+>beacon);
+   }
wdev_unlock(wdev);
 
if (err)
-- 
2.11.0