Re: [PATCH 2/2] ath10k: fix quiet duration configuration

[Rajkumar Manoharan]

On Thu, Feb 19, 2015 at 11:25:06PM +0530, Rajkumar Manoharan wrote:
> Duty cycle is nothing but percentage of one period in which a
> signal is active. But it is wrongly interpreted as ratio of quiet
> duration. So fix the quiet duration to the remaining percentage
> of duty cycle (active ratio).
> 
> Signed-off-by: Rajkumar Manoharan 
> ---
Kalle,

Please drop this change as it breaks the user space interface. Will send
updated patch ASAP. Sorry for the inconvenience.

-Rajkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: carl1970: monitor mode only displaying beacons/probs from APs?

[Marco]

On 03/05/15 06:10, Christian Lamparter wrote:
> Hello,
> 
> On Wednesday, March 04, 2015 11:02:25 PM ma...@tampabay.rr.com wrote:
>> Quite a while back after doing an upgrade to the latest (back then)
>> compat-wireless, I noticed that I was only seeing beacon,prob requests, and
>> the occasional data packet when in monitor mode; which at the time I wrote
>> off.  After switching to backports-3.18.1-1 recently, I still see the same
>> behavior(on x86 and arm).  I'm sure I'm missing something, but I couldn't
>> find any references to this behavior in my search.  I also tried "iw wlanX
>> set monitor control otherbss" to no avail.  Switching to a different chipset
>> using ath9k-htc showed expected traffic.
>>
>> Can anyone point me in the right direction?
> maybe. Could it be that you are looking for 802.11n(MCS) data frames?

I'm trying to see any and all frames (ctrl/mgmt/data).  I'm currently
doing my testing on 2.4ghz band, channel 11.  Playing with HT didn't
seem to make a difference.


> Because by default, carl9170's monitor mode only catches the legacy 
> 802.11a/b/g frames. If this is the case, then try setting the right
> channel mode (HT20/HT40+/HT40-) when selecting the channel. i.e.:  
> 
> # iw dev wlanX set channel Y HT20
> # iw dev wlanX set channel Y HT40+
> 
> I hope this helps. Otherwise, you could try: 
> 
> # iw dev wlanX set monitor [...] fcsfail
> 
> and see if you are picking up frames this way. This should work, but you
> will be picking up mostly damaged stuff, so some extra frame processing
> will be needed to filter out the noise. 
> 
> Regards,
>   Christian
> 

I've previously (and once again for good measure) tried fcsfail to no
avail as well.

I'm surprised no one else is seeing this/reported this, I've tried on
3 separate linux boxes now with no luck.

Regards,
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Mar 5 (iwlwifi/mvm)

[Randy Dunlap]

On 03/04/15 19:34, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20150304:
> 

on i386, when IWLWIFI_DEBUGFS is not enabled:


../drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c:179:38: error: 'struct iwl_mvm' 
has no member named 'dbgfs_rx_phyinfo'
../drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c:1378:30: error: 'struct 
iwl_mvm_vif' has no member named 'mvm'


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 3/3] cfg80211: Schedule timeout for all CRDA calls

[Luis R. Rodriguez]

On Wed, Mar 04, 2015 at 12:32:07AM -0500, Ilan Peer wrote:
> Timeout was scheduled only in case CRDA was called due to user hints,
> but was not scheduled for other cases. This can result in regulatory
> hint processing getting stuck in case that there is no CRDA configured.
> 
> Change this by scheduling a timeout every time CRDA is called. In
> addition, in restore_regulatory_settings() all pending requests are
> restored (and not only the user ones).
> 
> Signed-off-by: Ilan Peer 

Acked-by: Luis R. Rodriguez 

For all of these.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 2/3] cfg80211: Add API to change the indoor regulatory setting

[Luis R. Rodriguez]

On Wed, Mar 04, 2015 at 12:32:06AM -0500, Ilan Peer wrote:
> -int regulatory_hint_indoor_user(void)
> +int regulatory_hint_indoor(bool is_indoor, u32 portid)
>  {
> + spin_lock(®_indoor_lock);
> +
> + /* It is possible that more than one user space process is trying to
> +  * configure the indoor setting. To handle such cases, clear the indoor
> +  * setting in case that some process does not think that the device
> +  * is operating in an indoor environment. In addition, if a user space
> +  * process indicates that it is controlling the indoor setting, save its
> +  * portid, i.e., make it the owner.
> +  */
> + reg_is_indoor = is_indoor;
> + if (reg_is_indoor) {
> + if (!reg_is_indoor_portid)
> + reg_is_indoor_portid = portid;
> + } else {
> + reg_is_indoor_portid = 0;
> + }
>  
> + spin_unlock(®_indoor_lock);
>  
> - reg_is_indoor = true;
> + if (!is_indoor)
> + reg_check_channels();
>  
>   return 0;
>  }

OK lets start with this...

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/3] cfg80211: Add API to change the indoor regulatory setting

[Luis R. Rodriguez]

On Wed, Mar 04, 2015 at 10:37:35AM +, Peer, Ilan wrote:
> 
> > -Original Message-
> > From: Luis R. Rodriguez [mailto:mcg...@suse.com]
> > Sent: Monday, March 02, 2015 23:23
> > To: Peer, Ilan
> > Cc: linux-wireless@vger.kernel.org; ArikX Nemtsov
> > Subject: Re: [PATCH v9 2/3] cfg80211: Add API to change the indoor
> > regulatory setting
> > 
> > On Sun, Mar 01, 2015 at 01:02:28AM -0500, Ilan Peer wrote:
> > > diff --git a/net/wireless/reg.c b/net/wireless/reg.c index
> > > c24c8bf..f88d512 100644
> > > --- a/net/wireless/reg.c
> > > +++ b/net/wireless/reg.c
> > > @@ -128,9 +128,12 @@ static int reg_num_devs_support_basehint;
> > >   * State variable indicating if the platform on which the devices
> > >   * are attached is operating in an indoor environment. The state variable
> > >   * is relevant for all registered devices.
> > > - * (protected by RTNL)
> > >   */
> > >  static bool reg_is_indoor;
> > > +static spinlock_t reg_indoor_lock;
> > > +
> > > +/* Used to track the userspace process controlling the indoor setting
> > > +*/ static u32 reg_is_indoor_portid;
> > >
> > >  static const struct ieee80211_regdomain *get_cfg80211_regdom(void)  {
> > > @@ -2288,15 +2291,52 @@ int regulatory_hint_user(const char *alpha2,
> > >   return 0;
> > >  }
> > >
> > > -int regulatory_hint_indoor_user(void)
> > > +int regulatory_hint_indoor(bool is_indoor, u32 portid)
> > >  {
> > > + spin_lock(®_indoor_lock);
> > > +
> > > + /* Other user space processes cannot override the current owner */
> > > + if (reg_is_indoor_portid && reg_is_indoor_portid != portid) {
> > > + spin_unlock(®_indoor_lock);
> > > + return -EPERM;
> > > + }
> > 
> > I am not satisfied with this solution to conflict. I don't want to think 
> > about the
> > solution to this for you -- please address the conflicts with sensible 
> > solutions.
> > 
> 
> We could always allow the any user space process to set indoor=0, i.e.,
> indoor=1 is allowed iff all user space process agree on it.

That makes sense if for indoor we tend to have a more liberal
regulatory settings. Do we know this for sure? That is, are
we more restrictive outdoors? Does that vary by country?

> > > +
> > > + if (reg_is_indoor == is_indoor) {
> > > + spin_unlock(®_indoor_lock);
> > > + return 0;
> > > + }
> > 
> > For instance this is a solution to agreement, but yet the above only allows 
> > for
> > one wiphy to set this setting and limiting the wireless core. That's rather 
> > silly.
> > We've addressed bigger conflicts than this for regulatory -- I have 
> > confidence
> > you can address this well.
> 
> This should not really be wiphy specific.

Sorry I meant supplicant specific.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: Kconfig: Let it depend on PCI

[Chen Gang]

On 3/5/15 19:40, Kalle Valo wrote:
> Rafał Miłecki  writes:
> 
>> Kalle, I guess the recent discussion and work on this problem could be
>> confusing, so let me try to sum it up it a bit.
>>
>> First of all, please note there are 3 awaiting bcma patches that
>> should be applied independently of what we decide to do with this
>> patch. They are of course inspired by the recent building problems.
>> List of these patches:
>> [PATCH next] bcma: make bcma_host_pci_(up|down) calls safe for every config
>> [PATCH next] bcma: move internal function declarations to private header
>> [PATCH next] bcma: prepare Kconfig symbol for PCI driver
>>
>> Now, the building problem is obviously caused by me, my work on
>> driver_pcie2.c and using pcie_set_readrq there without making sure
>> that is PCI available. I'm sorry for that.
>>
>> All 3 above patches are moving us toward the the most optimal solution
>> of this problem. Depending on PCI only when it's really required.
>> There is still one more change missing that I'm working on. It'll take
>> me about 2 more days to get the last patch.
>> On the other way, patch proposed by Chen fixes building problem right
>> now. It's much simpler but bumps bcma requirements a bit too high.
>> bcma doesn't really have to depend on PCI.
> 
> Thanks for the good summary, it clarified things for me.
> 
>> So you have 2 options there and I'll be happy with whatever you choose to do:
>> 1) Pick Chen patch now and in ~2 days apply my final fix + revert Chen
>> patch.
> 
> I'll prefer this option so that we can quickly solve the build problem.
> Also once your final fix is ready, please remember that you need to
> revert Chen's patch within the same patch.
> 

Thank you for all of your work. In honest, I am not quite familiar with
the details, my patch is applied only says that "I am lucky enough".

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmsmac not compliant to 802.11 for BCM4313

[Nikita N.]

Dear Arend,
thanks for answering, unfortunately the answers open new questions
indeed, if I may.

> > 1) What is assuring that proprietary "strict custom regulatory domain"
> > is not obsolete/deprecated and compliant to 802.11 regulations?
> This is a very hypothetical question. If regulation would indeed change 
> in such way we would have to release new firmware.

That is not hypothetical at all, since we do *NOT* know what that
proprietary regdomain is enforcing.
That "strict custom regulatory domain" is proprietary Broadcom, hence
nobody knows what is written inside it, following all sad&known
considerations that Pat Erley explained (that is also the answer to you
Pat)
Now, to verify that such proprietary regdomain is enforcing a legal and
compliant regdomain, we should know it's details.
Question, is it possible to know how/what is written in that proprietary
regdomain inside the firmware?

> > 2) Regulatory domains can by 802.11 regulation change dynamically within
> > time/country, why BCM4313 users are obliged to lock only on 1
> > proprietary regdomain?
> This is not mandatory. Using 1 restricted world regulatory domain is 
> fine as well as Pat Erley explained in his response.

Sorry, what is not mandatory?
It is not mandatory that users are obliged to lock only on 1 proprietary
regdomain?
Of course it is not, it is not fair nor compliant to any regulations I
know of - do you?
It is not mandatory that 802.11 regulations change? sure, but they
change, indeed.
It is not mandatory regdomains rules change? sure, but they change,
indeed.

> > 4) Has been done any step so far, to root the cause of this issue?
> I did hunt down a 4313 to do so and put it in my test laptop.
Thank you very much! :)
In the meantime, if you could please verify a possible solution coming
now to my mind.
I understood that Broadcom management doesn't want to give power
controls to user.
Very sad personally, but I don't see any help to that coming from you
(your managers).
So, maybe, do BCM4313 has more than 1 special proprietary preset
regdomain buried in the firmware?
If yes, it would be great if you could tell us (programmers) how we can
switch to any of those other preset regdomains.
So that we could test them, and find the one which best conform to our
local/country regulation.
It seems to me a fair compromise for solving that issue, isn't?

> > 5) Since I have spent money&time on that device, I would like at least
> > to monitor the work in progress done to root the cause of this issue -
> > how can I?
> 
> You could create a bugzilla item on kernel.org.

Sure will do.
As soon as someone from Broadcom QA Testing Team, will find that the
root cause of that issue depends on Linux kernel.
I guess I already did my best to try debugging and solving for *free* a
Broadcom issue which: 1) doesn't depend on me, 2) is locked down in a
proprietary firmware, 3) is protected by secrecy of proprietary Broadcom
informations.

Thanks & Greetings.

-- 
  Nikita N.
  niki...@operamail.com


On Thu, Mar 5, 2015, at 01:41 AM, Arend van Spriel wrote:
> On 03/05/15 09:23, Nikita N. wrote:
> > Dear Arend,
> >
> >>> I tried recompile the regulatory domain database, those functions did
> >>> not retrieve the new values.
> >>> Whatever values I set for domain 00, the effect was null - BCM4313 kept
> >>> functioning independently.
> >> That is exactly what should happen. The brcmsmac driver applies a
> >> so-called strict custom regulatory domain and does not follow any
> >> regulatory domain provisioning.
> >
> > As I understand your words, the BCM4313 has a proprietary regdomain, a
> > so called "strict custom regulatory domain" buried in the firmware, and
> > finish.
> > That proprietary regdomain is applied when attaching brcmsmac Linux
> > driver.
> > But in other drivers, e.g. the wl driver, or ms-windows drivers all
> > versions, the BCM4313 doesn't apply that "strict custom regulatory
> > domain".
> > In all other drivers, the BCM4313 applies different regdomains and
> > relative power levels according to the system/OS.
> > So now, after your explanation, logic tells me, the BCM4313 regdomain is
> > locked only in the brcmsmac driver for Linux.
> > Instead it operates open and fully functional in the other drivers.
> > So now 3 more questions, if I'm allowed:
> > 1) What is assuring that proprietary "strict custom regulatory domain"
> > is not obsolete/deprecated and compliant to 802.11 regulations?
> 
> This is a very hypothetical question. If regulation would indeed change 
> in such way we would have to release new firmware.
> 
> > 2) Regulatory domains can by 802.11 regulation change dynamically within
> > time/country, why BCM4313 users are obliged to lock only on 1
> > proprietary regdomain?
> 
> This is not mandatory. Using 1 restricted world regulatory domain is 
> fine as well as Pat Erley explained in his response.
> 
> > 3) Why BCM4313 is locked only for brcmsmac?
> 
> I explained that in an earlier email. It was a requirement f

[PATCH 1/3] bcma: move PCI IRQ control function to host specific code

[Rafał Miłecki]

This function isn't really related to any bus core. It touches PCI
device config registers only, so move it to the (PCI) host file.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/driver_pci.c  | 33 -
 drivers/bcma/host_pci.c| 34 ++
 drivers/net/wireless/b43/main.c|  2 +-
 drivers/net/wireless/brcm80211/brcmsmac/main.c |  2 +-
 include/linux/bcma/bcma.h  |  9 +++
 include/linux/bcma/bcma_driver_pci.h   |  2 --
 6 files changed, 45 insertions(+), 37 deletions(-)

diff --git a/drivers/bcma/driver_pci.c b/drivers/bcma/driver_pci.c
index cfd35bc..f499a46 100644
--- a/drivers/bcma/driver_pci.c
+++ b/drivers/bcma/driver_pci.c
@@ -282,39 +282,6 @@ void bcma_core_pci_power_save(struct bcma_bus *bus, bool 
up)
 }
 EXPORT_SYMBOL_GPL(bcma_core_pci_power_save);
 
-int bcma_core_pci_irq_ctl(struct bcma_bus *bus, struct bcma_device *core,
- bool enable)
-{
-   struct pci_dev *pdev;
-   u32 coremask, tmp;
-   int err = 0;
-
-   if (bus->hosttype != BCMA_HOSTTYPE_PCI) {
-   /* This bcma device is not on a PCI host-bus. So the IRQs are
-* not routed through the PCI core.
-* So we must not enable routing through the PCI core. */
-   goto out;
-   }
-
-   pdev = bus->host_pci;
-
-   err = pci_read_config_dword(pdev, BCMA_PCI_IRQMASK, &tmp);
-   if (err)
-   goto out;
-
-   coremask = BIT(core->core_index) << 8;
-   if (enable)
-   tmp |= coremask;
-   else
-   tmp &= ~coremask;
-
-   err = pci_write_config_dword(pdev, BCMA_PCI_IRQMASK, tmp);
-
-out:
-   return err;
-}
-EXPORT_SYMBOL_GPL(bcma_core_pci_irq_ctl);
-
 static void bcma_core_pci_extend_L1timer(struct bcma_drv_pci *pc, bool extend)
 {
u32 w;
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index a62a2f9..0856189 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -351,3 +351,37 @@ void bcma_host_pci_down(struct bcma_bus *bus)
bcma_core_pci_down(&bus->drv_pci[0]);
 }
 EXPORT_SYMBOL_GPL(bcma_host_pci_down);
+
+/* See also si_pci_setup */
+int bcma_host_pci_irq_ctl(struct bcma_bus *bus, struct bcma_device *core,
+ bool enable)
+{
+   struct pci_dev *pdev;
+   u32 coremask, tmp;
+   int err = 0;
+
+   if (bus->hosttype != BCMA_HOSTTYPE_PCI) {
+   /* This bcma device is not on a PCI host-bus. So the IRQs are
+* not routed through the PCI core.
+* So we must not enable routing through the PCI core. */
+   goto out;
+   }
+
+   pdev = bus->host_pci;
+
+   err = pci_read_config_dword(pdev, BCMA_PCI_IRQMASK, &tmp);
+   if (err)
+   goto out;
+
+   coremask = BIT(core->core_index) << 8;
+   if (enable)
+   tmp |= coremask;
+   else
+   tmp &= ~coremask;
+
+   err = pci_write_config_dword(pdev, BCMA_PCI_IRQMASK, tmp);
+
+out:
+   return err;
+}
+EXPORT_SYMBOL_GPL(bcma_host_pci_irq_ctl);
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index f34aa67..a13be80 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4866,7 +4866,7 @@ static int b43_wireless_core_init(struct b43_wldev *dev)
switch (dev->dev->bus_type) {
 #ifdef CONFIG_B43_BCMA
case B43_BUS_BCMA:
-   bcma_core_pci_irq_ctl(dev->dev->bdev->bus,
+   bcma_host_pci_irq_ctl(dev->dev->bdev->bus,
  dev->dev->bdev, true);
bcma_host_pci_up(dev->dev->bdev->bus);
break;
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c 
b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index c84af1d..369527e 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -4959,7 +4959,7 @@ static int brcms_b_up_prep(struct brcms_hardware *wlc_hw)
 * Configure pci/pcmcia here instead of in brcms_c_attach()
 * to allow mfg hotswap:  down, hotswap (chip power cycle), up.
 */
-   bcma_core_pci_irq_ctl(wlc_hw->d11core->bus, wlc_hw->d11core,
+   bcma_host_pci_irq_ctl(wlc_hw->d11core->bus, wlc_hw->d11core,
  true);
 
/*
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index 44057b4..e34f906 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -437,6 +437,8 @@ static inline struct bcma_device *bcma_find_core(struct 
bcma_bus *bus,
 #ifdef CONFIG_BCMA_HOST_PCI
 extern void bcma_host_pci_up(struct bcma_bus *bus);
 extern void bcma_host_pci_down(struct bcma_bus *bus);
+extern int bcma_host_pci_irq_ctl(struct bcma_bus *bus,
+struct bcma_device *core, bool enable);
 #else

[PATCH 3/3] Revert "bcma: Kconfig: Let it depend on PCI"

[Rafał Miłecki]

This reverts commit b09f5ec18b16b82f4db8a735e453332db7514275.

Now that we have fully working BCMA_DRIVER_PCI symbol (in can be safely
disabled), there is no risk bcma will try to use PCI code without PCI
available.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index 1500b71..fc6ffcf 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -1,6 +1,6 @@
 config BCMA_POSSIBLE
bool
-   depends on HAS_IOMEM && HAS_DMA && PCI
+   depends on HAS_IOMEM && HAS_DMA
default y
 
 menu "Broadcom specific AMBA"
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] bcma: allow disabling (not building) PCI driver

[Rafał Miłecki]

It isn't required for bcma bus on SoCs, so provide some empty functions
and allow disabling it.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/Kconfig |  4 ++--
 drivers/bcma/bcma_private.h  | 20 
 include/linux/bcma/bcma_driver_pci.h |  6 ++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index 9be17d3..1500b71 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -45,9 +45,9 @@ config BCMA_HOST_SOC
 
  If unsure, say N
 
-# TODO: make it depend on PCI when ready
 config BCMA_DRIVER_PCI
-   bool
+   bool "BCMA Broadcom PCI core driver"
+   depends on BCMA && PCI
default y
help
  BCMA bus may have many versions of PCIe core. This driver
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index 5a1d224..15f2b2e 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -106,15 +106,35 @@ static inline void __exit 
bcma_host_soc_unregister_driver(void)
 #endif /* CONFIG_BCMA_HOST_SOC && CONFIG_OF */
 
 /* driver_pci.c */
+#ifdef CONFIG_BCMA_DRIVER_PCI
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
 void bcma_core_pci_early_init(struct bcma_drv_pci *pc);
 void bcma_core_pci_init(struct bcma_drv_pci *pc);
 void bcma_core_pci_up(struct bcma_drv_pci *pc);
 void bcma_core_pci_down(struct bcma_drv_pci *pc);
+#else
+static inline void bcma_core_pci_early_init(struct bcma_drv_pci *pc)
+{
+   WARN_ON(pc->core->bus->hosttype == BCMA_HOSTTYPE_PCI);
+}
+static inline void bcma_core_pci_init(struct bcma_drv_pci *pc)
+{
+   /* Initialization is required for PCI hosted bus */
+   WARN_ON(pc->core->bus->hosttype == BCMA_HOSTTYPE_PCI);
+}
+#endif
 
 /* driver_pcie2.c */
+#ifdef CONFIG_BCMA_DRIVER_PCI
 void bcma_core_pcie2_init(struct bcma_drv_pcie2 *pcie2);
 void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2);
+#else
+static inline void bcma_core_pcie2_init(struct bcma_drv_pcie2 *pcie2)
+{
+   /* Initialization is required for PCI hosted bus */
+   WARN_ON(pcie2->core->bus->hosttype == BCMA_HOSTTYPE_PCI);
+}
+#endif
 
 extern int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc);
 
diff --git a/include/linux/bcma/bcma_driver_pci.h 
b/include/linux/bcma/bcma_driver_pci.h
index 3a46868..5ba6918 100644
--- a/include/linux/bcma/bcma_driver_pci.h
+++ b/include/linux/bcma/bcma_driver_pci.h
@@ -238,7 +238,13 @@ struct bcma_drv_pci {
 #define pcicore_write16(pc, offset, val)   bcma_write16((pc)->core, 
offset, val)
 #define pcicore_write32(pc, offset, val)   bcma_write32((pc)->core, 
offset, val)
 
+#ifdef CONFIG_BCMA_DRIVER_PCI
 extern void bcma_core_pci_power_save(struct bcma_bus *bus, bool up);
+#else
+static inline void bcma_core_pci_power_save(struct bcma_bus *bus, bool up)
+{
+}
+#endif
 
 extern int bcma_core_pci_pcibios_map_irq(const struct pci_dev *dev);
 extern int bcma_core_pci_plat_dev_init(struct pci_dev *dev);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2] [RFC] mac80211: lock rate control

[Johannes Berg]

From: Johannes Berg 

Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
control aren't properly taking concurrency into account. It's
likely that the same is true for other rate control algorithms.

In the case of minstrel this manifests itself in crashes when an
update and other data access are run concurrently, for example
when the stations change bandwidth or similar. In iwlwifi, this
can cause firmware crashes.

Since fixing all rate control algorithms will be very difficult,
just provide locking for invocations. This protects the internal
data structures the algorithms maintain.

I've manipulated hostapd to test this, by having it change its
advertised bandwidth roughly ever 150ms. At the same time, I'm
running a flood ping between the client and the AP, which causes
this race of update vs. get_rate/status to easily happen on the
client. With this change, the system survives this test.

Change-Id: I77383401a67a1ec380cec65b34802ab879357e80
Reported-by: Sven Eckelmann 
Signed-off-by: Johannes Berg 
---
 net/mac80211/rate.c |  8 +++-
 net/mac80211/rate.h | 12 +---
 net/mac80211/sta_info.c |  2 +-
 net/mac80211/sta_info.h |  1 +
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index bc5270ed26bd..68bed2cad6f3 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -683,7 +683,13 @@ void rate_control_get_rate(struct ieee80211_sub_if_data 
*sdata,
if (sdata->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)
return;
 
-   ref->ops->get_rate(ref->priv, ista, priv_sta, txrc);
+   if (ista) {
+   spin_lock_bh(&sta->rate_ctrl_lock);
+   ref->ops->get_rate(ref->priv, ista, priv_sta, txrc);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
+   } else {
+   ref->ops->get_rate(ref->priv, NULL, NULL, txrc);
+   }
 
if (sdata->local->hw.flags & IEEE80211_HW_SUPPORTS_RC_TABLE)
return;
diff --git a/net/mac80211/rate.h b/net/mac80211/rate.h
index a7d5439322d7..d0ecc8952fa0 100644
--- a/net/mac80211/rate.h
+++ b/net/mac80211/rate.h
@@ -42,10 +42,12 @@ static inline void rate_control_tx_status(struct 
ieee80211_local *local,
if (!ref || !test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
return;
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
if (ref->ops->tx_status)
ref->ops->tx_status(ref->priv, sband, ista, priv_sta, skb);
else
ref->ops->tx_status_noskb(ref->priv, sband, ista, priv_sta, 
info);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
 }
 
 static inline void
@@ -64,7 +66,9 @@ rate_control_tx_status_noskb(struct ieee80211_local *local,
if (WARN_ON_ONCE(!ref->ops->tx_status_noskb))
return;
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->tx_status_noskb(ref->priv, sband, ista, priv_sta, info);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
 }
 
 static inline void rate_control_rate_init(struct sta_info *sta)
@@ -115,18 +119,20 @@ static inline void rate_control_rate_update(struct 
ieee80211_local *local,
return;
}
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->rate_update(ref->priv, sband, &chanctx_conf->def,
  ista, priv_sta, changed);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
rcu_read_unlock();
}
drv_sta_rc_update(local, sta->sdata, &sta->sta, changed);
 }
 
 static inline void *rate_control_alloc_sta(struct rate_control_ref *ref,
-  struct ieee80211_sta *sta,
-  gfp_t gfp)
+  struct sta_info *sta, gfp_t gfp)
 {
-   return ref->ops->alloc_sta(ref->priv, sta, gfp);
+   spin_lock_init(&sta->rate_ctrl_lock);
+   return ref->ops->alloc_sta(ref->priv, &sta->sta, gfp);
 }
 
 static inline void rate_control_free_sta(struct sta_info *sta)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 11c1e71c833d..eab8d8afab13 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -292,7 +292,7 @@ static int sta_prepare_rate_control(struct ieee80211_local 
*local,
 
sta->rate_ctrl = local->rate_ctrl;
sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl,
-&sta->sta, gfp);
+sta, gfp);
if (!sta->rate_ctrl_priv)
return -ENOMEM;
 
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 36a14a0be6dd..b53c6ca3179a 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -396,6 +396,7 @@ struct sta_info {
u8 ptk_idx;
struct rate_control_ref *rate_ctrl;
void *rate_ctrl_priv;
+   spinlock_t rate_ctrl_lock;
spinlock_t lock;
 
  

Re: randconfig build error with next-20150303, in drivers/bcma/driver_pcie2.c

[Jim Davis]

On Thu, Mar 5, 2015 at 6:44 AM, Kalle Valo  wrote:
> Stephen Rothwell  writes:
>
>> Hi Kalle,
>>
>> On Wed, 04 Mar 2015 16:31:00 +0200 Kalle Valo  wrote:
>>>
>>> Jim Davis  writes:
>>>
>>> > Building with the attached random configuration file,
>>> >
>>> > drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>>> > drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of
>>> > function 'pcie_set_readrq' [-Werror=implicit-function-declaration]
>>> >   err = pcie_set_readrq(dev, pcie2->reqsize);
>>> >   ^
>>>
>>> This should fix it:
>>>
>>> bcma: add missing includes
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=2264fc857decd45798368f46861d9aecac23546f
>>
>> However, that commit is in next-20150304 and we still get the error
>> (see, for example,
>> http://kisskb.ellerman.id.au/kisskb/buildresult/12376688/).
>
> I applied few fixes from Rafal and Chen:
>
> 1ca2760fb2c1 bcma: prepare Kconfig symbol for PCI driver
> 0a4e699a41f7 bcma: move internal function declarations to private header
> c32ec2a11321 bcma: make bcma_host_pci_(up|down) calls safe for every config
> b09f5ec18b16 bcma: Kconfig: Let it depend on PCI
>
> It would be great if someone could report if the build errors are gone
> now.

I reran that configuration file on
wireless-drivers-next-for-davem-2015-02-07-9274-g1ca2760fb2c13, with
no build errors.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] mac80211: lock rate control

[Johannes Berg]

On Thu, 2015-03-05 at 16:52 +0100, Sven Eckelmann wrote:
> On Thursday 05 March 2015 16:37:12 Johannes Berg wrote:
> > From: Johannes Berg 
> > 
> > Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
> > control aren't properly taking concurrency into account. It's
> > likely that the same is true for other rate control algorithms.
> > 
> > In the case of minstrel this manifests itself in crashes when an
> > update and other data access are run concurrently, for example
> > when the stations change bandwidth or similar. In iwlwifi, this
> > can cause firmware crashes.
> > 
> > Since fixing all rate control algorithms will be very difficult,
> > just provide locking for invocations. This protects the internal
> > data structures the algorithms maintain.
> > 
> > I've manipulated hostapd to test this, by having it change its
> > advertised bandwidth roughly ever 150ms. At the same time, I'm
> > running a flood ping between the client and the AP, which causes
> > this race of update vs. get_rate/status to easily happen on the
> > client. With this change, the system survives this test.
> > 
> > Reported-by: Sven Eckelmann 
> > Signed-off-by: Johannes Berg 
> 
> Thanks a lot for the patch. This is mostly what I had in mind when asking for 
> the correct lock.
> 
> I will ask if it is possible to test this patch in an affected network.

Actually, don't. This patch has a bug that causes crashes.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] mac80211: lock rate control

[Sven Eckelmann]

On Thursday 05 March 2015 16:37:12 Johannes Berg wrote:
> From: Johannes Berg 
> 
> Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
> control aren't properly taking concurrency into account. It's
> likely that the same is true for other rate control algorithms.
> 
> In the case of minstrel this manifests itself in crashes when an
> update and other data access are run concurrently, for example
> when the stations change bandwidth or similar. In iwlwifi, this
> can cause firmware crashes.
> 
> Since fixing all rate control algorithms will be very difficult,
> just provide locking for invocations. This protects the internal
> data structures the algorithms maintain.
> 
> I've manipulated hostapd to test this, by having it change its
> advertised bandwidth roughly ever 150ms. At the same time, I'm
> running a flood ping between the client and the AP, which causes
> this race of update vs. get_rate/status to easily happen on the
> client. With this change, the system survives this test.
> 
> Reported-by: Sven Eckelmann 
> Signed-off-by: Johannes Berg 

Thanks a lot for the patch. This is mostly what I had in mind when asking for 
the correct lock.

I will ask if it is possible to test this patch in an affected network. But I 
am quite sure that this will not be possible before next week. And your test 
already sounds quite nice.

Kind regards,
Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] mac80211: lock rate control

[Johannes Berg]

On Thu, 2015-03-05 at 16:52 +0100, Sven Eckelmann wrote:

> > I've manipulated hostapd to test this, by having it change its
> > advertised bandwidth roughly ever 150ms. At the same time, I'm
> > running a flood ping between the client and the AP, which causes
> > this race of update vs. get_rate/status to easily happen on the
> > client. With this change, the system survives this test.

> I will ask if it is possible to test this patch in an affected network. But I 
> am quite sure that this will not be possible before next week. And your test 
> already sounds quite nice.

Note that I tested with iwlwifi, not with minstrel. However, I'm pretty
sure it's the same problem.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] mac80211: lock rate control

[Johannes Berg]

From: Johannes Berg 

Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
control aren't properly taking concurrency into account. It's
likely that the same is true for other rate control algorithms.

In the case of minstrel this manifests itself in crashes when an
update and other data access are run concurrently, for example
when the stations change bandwidth or similar. In iwlwifi, this
can cause firmware crashes.

Since fixing all rate control algorithms will be very difficult,
just provide locking for invocations. This protects the internal
data structures the algorithms maintain.

I've manipulated hostapd to test this, by having it change its
advertised bandwidth roughly ever 150ms. At the same time, I'm
running a flood ping between the client and the AP, which causes
this race of update vs. get_rate/status to easily happen on the
client. With this change, the system survives this test.

Reported-by: Sven Eckelmann 
Signed-off-by: Johannes Berg 
---
 net/mac80211/rate.c |  2 ++
 net/mac80211/rate.h | 12 +---
 net/mac80211/sta_info.c |  2 +-
 net/mac80211/sta_info.h |  1 +
 4 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index bc5270ed26bd..41732668b7af 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -683,7 +683,9 @@ void rate_control_get_rate(struct ieee80211_sub_if_data 
*sdata,
if (sdata->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)
return;
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->get_rate(ref->priv, ista, priv_sta, txrc);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
 
if (sdata->local->hw.flags & IEEE80211_HW_SUPPORTS_RC_TABLE)
return;
diff --git a/net/mac80211/rate.h b/net/mac80211/rate.h
index a7d5439322d7..d0ecc8952fa0 100644
--- a/net/mac80211/rate.h
+++ b/net/mac80211/rate.h
@@ -42,10 +42,12 @@ static inline void rate_control_tx_status(struct 
ieee80211_local *local,
if (!ref || !test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
return;
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
if (ref->ops->tx_status)
ref->ops->tx_status(ref->priv, sband, ista, priv_sta, skb);
else
ref->ops->tx_status_noskb(ref->priv, sband, ista, priv_sta, 
info);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
 }
 
 static inline void
@@ -64,7 +66,9 @@ rate_control_tx_status_noskb(struct ieee80211_local *local,
if (WARN_ON_ONCE(!ref->ops->tx_status_noskb))
return;
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->tx_status_noskb(ref->priv, sband, ista, priv_sta, info);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
 }
 
 static inline void rate_control_rate_init(struct sta_info *sta)
@@ -115,18 +119,20 @@ static inline void rate_control_rate_update(struct 
ieee80211_local *local,
return;
}
 
+   spin_lock_bh(&sta->rate_ctrl_lock);
ref->ops->rate_update(ref->priv, sband, &chanctx_conf->def,
  ista, priv_sta, changed);
+   spin_unlock_bh(&sta->rate_ctrl_lock);
rcu_read_unlock();
}
drv_sta_rc_update(local, sta->sdata, &sta->sta, changed);
 }
 
 static inline void *rate_control_alloc_sta(struct rate_control_ref *ref,
-  struct ieee80211_sta *sta,
-  gfp_t gfp)
+  struct sta_info *sta, gfp_t gfp)
 {
-   return ref->ops->alloc_sta(ref->priv, sta, gfp);
+   spin_lock_init(&sta->rate_ctrl_lock);
+   return ref->ops->alloc_sta(ref->priv, &sta->sta, gfp);
 }
 
 static inline void rate_control_free_sta(struct sta_info *sta)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 11c1e71c833d..eab8d8afab13 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -292,7 +292,7 @@ static int sta_prepare_rate_control(struct ieee80211_local 
*local,
 
sta->rate_ctrl = local->rate_ctrl;
sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl,
-&sta->sta, gfp);
+sta, gfp);
if (!sta->rate_ctrl_priv)
return -ENOMEM;
 
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 36a14a0be6dd..b53c6ca3179a 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -396,6 +396,7 @@ struct sta_info {
u8 ptk_idx;
struct rate_control_ref *rate_ctrl;
void *rate_ctrl_priv;
+   spinlock_t rate_ctrl_lock;
spinlock_t lock;
 
struct work_struct drv_deliver_wk;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Enable encrytion of ADDBA request in PMF configuration

[Kalle Valo]

SenthilKumar Jegadeesan  writes:

> In HT mode, firmware is not encrypting ADDBA request as PMF
> configuration is not set in peer flags during association.
>
> Set peer flags for MFP enabled station in ath10k driver.
>
> Implemented abstraction layer for peer flags.
>
> This change depends on mac80211 patch "[PATCH] mac80211: send
> station PMF configuration to driver".
>
> Signed-off-by: SenthilKumar Jegadeesan 

Typo in the title "encrytion".

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: randconfig build error with next-20150303, in drivers/bcma/driver_pcie2.c

[Kalle Valo]

Stephen Rothwell  writes:

> Hi Kalle,
>
> On Wed, 04 Mar 2015 16:31:00 +0200 Kalle Valo  wrote:
>>
>> Jim Davis  writes:
>> 
>> > Building with the attached random configuration file,
>> >
>> > drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>> > drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of
>> > function 'pcie_set_readrq' [-Werror=implicit-function-declaration]
>> >   err = pcie_set_readrq(dev, pcie2->reqsize);
>> >   ^
>> 
>> This should fix it:
>> 
>> bcma: add missing includes
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=2264fc857decd45798368f46861d9aecac23546f
>
> However, that commit is in next-20150304 and we still get the error
> (see, for example,
> http://kisskb.ellerman.id.au/kisskb/buildresult/12376688/).

I applied few fixes from Rafal and Chen:

1ca2760fb2c1 bcma: prepare Kconfig symbol for PCI driver
0a4e699a41f7 bcma: move internal function declarations to private header
c32ec2a11321 bcma: make bcma_host_pci_(up|down) calls safe for every config
b09f5ec18b16 bcma: Kconfig: Let it depend on PCI

It would be great if someone could report if the build errors are gone
now.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ath10k: Increase copy engine entries for rx wmi

[Kalle Valo]

Rajkumar Manoharan  writes:

> Having lower number of copy engine entries for target to host
> WMI ring is causing drops in receiving management frames. This
> issue is observed during max clients (128 clients) stress testing.
> While bursting deauthentication frames from simulated clients,
> approx. 70% of frames are getting dropped due to lower ring entries.
>
> Signed-off-by: Rajkumar Manoharan 

Thanks, patch 2 applied.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: Increase AST table SKID length limit

[Kalle Valo]

SenthilKumar Jegadeesan  writes:

> The current SKID length configuration causes firmware
> to reject peer creation for not able to allocate
> AST entries for peers. This issue is observed when
> least significant 3 bytes are used ramdomly to create
> client MAC addresses.
>
> AST table SKID length configuration is increased to
> maximum value to fix this issue.
>
> Signed-off-by: SenthilKumar Jegadeesan 

Thanks, applied.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ath: Introduce chirp parameter used by DFS

[Kalle Valo]

Peter Oh  writes:

> Some of radar types such as FCC radar type 5 require
> to look up chirp in pulse to detect genuine radar and
> it will prevent DFS channels from false radar detection.
>
> Signed-off-by: Peter Oh 

Thanks, all three patches applied.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7] iwlwifi: fix max_ht_ampdu_exponent for older devices

[Emmanuel Grumbach]

The commit below didn't update the max_ht_ampdu_exponent
for the devices listed in iwl-[1-6]000.c which, in result,
became 0 instead of 8K. This reduced the size of the Rx
AMPDU from 64K to 8K which had an impact in the Rx
throughput. One user reported that because of this, his
downstream throughput droppped by a half.

CC:  [3.19]
Fixes: c064ddf318aa ("iwlwifi: change max HT and VHT A-MPDU exponent")
Reported-and-tested-by: Valentin Manea 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-1000.c |  6 --
 drivers/net/wireless/iwlwifi/iwl-2000.c | 13 +
 drivers/net/wireless/iwlwifi/iwl-5000.c |  6 --
 drivers/net/wireless/iwlwifi/iwl-6000.c | 18 --
 4 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c 
b/drivers/net/wireless/iwlwifi/iwl-1000.c
index c3817fa..06f6cc0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -95,7 +95,8 @@ static const struct iwl_eeprom_params iwl1000_eeprom_params = 
{
.nvm_calib_ver = EEPROM_1000_TX_POWER_VERSION,  \
.base_params = &iwl1000_base_params,\
.eeprom_params = &iwl1000_eeprom_params,\
-   .led_mode = IWL_LED_BLINK
+   .led_mode = IWL_LED_BLINK,  \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
 
 const struct iwl_cfg iwl1000_bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 1000 BGN",
@@ -121,7 +122,8 @@ const struct iwl_cfg iwl1000_bg_cfg = {
.base_params = &iwl1000_base_params,\
.eeprom_params = &iwl1000_eeprom_params,\
.led_mode = IWL_LED_RF_STATE,   \
-   .rx_with_siso_diversity = true
+   .rx_with_siso_diversity = true, \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
 
 const struct iwl_cfg iwl100_bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 100 BGN",
diff --git a/drivers/net/wireless/iwlwifi/iwl-2000.c 
b/drivers/net/wireless/iwlwifi/iwl-2000.c
index 21e5d08..890b95f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-2000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-2000.c
@@ -123,7 +123,9 @@ static const struct iwl_eeprom_params iwl20x0_eeprom_params 
= {
.nvm_calib_ver = EEPROM_2000_TX_POWER_VERSION,  \
.base_params = &iwl2000_base_params,\
.eeprom_params = &iwl20x0_eeprom_params,\
-   .led_mode = IWL_LED_RF_STATE
+   .led_mode = IWL_LED_RF_STATE,   \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
+
 
 const struct iwl_cfg iwl2000_2bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 2200 BGN",
@@ -149,7 +151,8 @@ const struct iwl_cfg iwl2000_2bgn_d_cfg = {
.nvm_calib_ver = EEPROM_2000_TX_POWER_VERSION,  \
.base_params = &iwl2030_base_params,\
.eeprom_params = &iwl20x0_eeprom_params,\
-   .led_mode = IWL_LED_RF_STATE
+   .led_mode = IWL_LED_RF_STATE,   \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
 
 const struct iwl_cfg iwl2030_2bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 2230 BGN",
@@ -170,7 +173,8 @@ const struct iwl_cfg iwl2030_2bgn_cfg = {
.base_params = &iwl2000_base_params,\
.eeprom_params = &iwl20x0_eeprom_params,\
.led_mode = IWL_LED_RF_STATE,   \
-   .rx_with_siso_diversity = true
+   .rx_with_siso_diversity = true, \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
 
 const struct iwl_cfg iwl105_bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 105 BGN",
@@ -197,7 +201,8 @@ const struct iwl_cfg iwl105_bgn_d_cfg = {
.base_params = &iwl2030_base_params,\
.eeprom_params = &iwl20x0_eeprom_params,\
.led_mode = IWL_LED_RF_STATE,   \
-   .rx_with_siso_diversity = true
+   .rx_with_siso_diversity = true, \
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K
 
 const struct iwl_cfg iwl135_bgn_cfg = {
.name = "Intel(R) Centrino(R) Wireless-N 135 BGN",
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c 
b/drivers/net/wireless/iwlwifi/iwl-5000.c
index 332bbede..724194e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -93,7 +93,8 @@ static const struct iwl_eeprom_params iwl5000_eeprom_params = 
{
.nvm_calib_ver = EEPROM_5000_TX_POWER_VERSION,  \
.base_params = &iwl5000_base_params,\
.eeprom_params = &iwl5000_eeprom_params,\
-   .led_mode = IWL_LED_BLINK
+   .led_mode = IWL_LED_BLINK,  \
+   .max_

[PATCH 7/7] iwlwifi: mvm: BT Coex - fix a NULL pointer exception

[Emmanuel Grumbach]

The commit below introduced an unsafe dereference of
mvmvif->phy_ctxt. It can be NULL even if we hold the mutex.
We can be handling a BT Coex notification while the vif has
already been unassigned. This can happen since the BT Coex
notification is hanled asynchronuously: we can have started
to handle the BT Coex notification trying to acquire the
mutex while the unassign flow already got it. The BT Coex
notification handling will wait for the mutext. I'll get it
later, but then mvmvif->phy_ctxt will be NULL.

Panic log:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
*pdpt =  *pde = f000eef30007
Oops:  [#1] SMP
Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm]
task: ed719b20 ti: ec03e000 task.ti: ec03e000
EIP: 0060:[] EFLAGS: 00010202 CPU: 2
EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
EAX:  EBX: f6d3cb70 ECX: f6d3cb70 EDX: 
ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 80050033 CR2:  CR3: 01a1a000 CR4: 001407f0
Stack:
 f743ca80 f744a404 ec03fdcc c10e3952 3aba f743ca80 0246 f743ca80
 0246  0001  ebd45ff6 ebd458a4 f6d3c500 ebd45578
 ebd44b01 ec03fe18 f99e1bc2 0002 ebd44bc0 f9851770  f6d3c500
Call Trace:
 [] ? ring_buffer_unlock_commit+0xa2/0xd0
 [] __iterate_interfaces+0x82/0x110 [mac80211]
 [] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm]
 [] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211]
 [] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm]
 [] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm]
 [] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm]
 [] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm]

CC:  [3.19+]
Fixes: 123f515635b1 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC")
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/coex.c| 3 ++-
 drivers/net/wireless/iwlwifi/mvm/coex_legacy.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/coex.c 
b/drivers/net/wireless/iwlwifi/mvm/coex.c
index 1ec4d55..7810c41 100644
--- a/drivers/net/wireless/iwlwifi/mvm/coex.c
+++ b/drivers/net/wireless/iwlwifi/mvm/coex.c
@@ -793,7 +793,8 @@ static void iwl_mvm_bt_notif_iterator(void *_data, u8 *mac,
if (!vif->bss_conf.assoc)
smps_mode = IEEE80211_SMPS_AUTOMATIC;
 
-   if (IWL_COEX_IS_RRC_ON(mvm->last_bt_notif.ttc_rrc_status,
+   if (mvmvif->phy_ctxt &&
+   IWL_COEX_IS_RRC_ON(mvm->last_bt_notif.ttc_rrc_status,
   mvmvif->phy_ctxt->id))
smps_mode = IEEE80211_SMPS_AUTOMATIC;
 
diff --git a/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c 
b/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
index d530ef3..542ee74 100644
--- a/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
+++ b/drivers/net/wireless/iwlwifi/mvm/coex_legacy.c
@@ -832,7 +832,8 @@ static void iwl_mvm_bt_notif_iterator(void *_data, u8 *mac,
if (!vif->bss_conf.assoc)
smps_mode = IEEE80211_SMPS_AUTOMATIC;
 
-   if (data->notif->rrc_enabled & BIT(mvmvif->phy_ctxt->id))
+   if (mvmvif->phy_ctxt &&
+   data->notif->rrc_enabled & BIT(mvmvif->phy_ctxt->id))
smps_mode = IEEE80211_SMPS_AUTOMATIC;
 
IWL_DEBUG_COEX(data->mvm,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] iwlwifi: mvm: Fix ROC removal

[Emmanuel Grumbach]

From: Andrei Otcheretianski 

iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct
since this flag is only set when the TE is started.
This resulted in a TE not being removed, when mac80211 believes that there are
no active ROCs.

Fixes: bf5da87f60a9 ("iwlwifi: mvm: add remove flow for AUX ROC time events")
Signed-off-by: Andrei Otcheretianski 
Reviewed-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/time-event.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/time-event.c 
b/drivers/net/wireless/iwlwifi/mvm/time-event.c
index 54fafbf..f8d6f30 100644
--- a/drivers/net/wireless/iwlwifi/mvm/time-event.c
+++ b/drivers/net/wireless/iwlwifi/mvm/time-event.c
@@ -750,8 +750,7 @@ void iwl_mvm_stop_roc(struct iwl_mvm *mvm)
 * request
 */
list_for_each_entry(te_data, &mvm->time_event_list, list) {
-   if (te_data->vif->type == NL80211_IFTYPE_P2P_DEVICE &&
-   te_data->running) {
+   if (te_data->vif->type == NL80211_IFTYPE_P2P_DEVICE) {
mvmvif = iwl_mvm_vif_from_mac80211(te_data->vif);
is_p2p = true;
goto remove_te;
@@ -766,10 +765,8 @@ void iwl_mvm_stop_roc(struct iwl_mvm *mvm)
 * request
 */
list_for_each_entry(te_data, &mvm->aux_roc_te_list, list) {
-   if (te_data->running) {
-   mvmvif = iwl_mvm_vif_from_mac80211(te_data->vif);
-   goto remove_te;
-   }
+   mvmvif = iwl_mvm_vif_from_mac80211(te_data->vif);
+   goto remove_te;
}
 
 remove_te:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] iwlwifi: mvm: don't try to stop scans that are not running anymore

[Emmanuel Grumbach]

From: Luciano Coelho 

In certain conditions, mac80211 may ask us to stop a scan (scheduled
or normal) that is not running anymore.  This can also happen when we
are doing a different type of scan, for instance, mac80211 can ask us
to stop a scheduled scan when we are running a normal scan, due to
some race conditions.  In this case, we would stop the wrong type of
scan and leave everything everything in a wrong state.

To fix this, simply ignore scan stop requests for scans types that are
not running.

Signed-off-by: Luciano Coelho 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 1ff7ec0..35feebf 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -2215,7 +2215,19 @@ static void iwl_mvm_mac_cancel_hw_scan(struct 
ieee80211_hw *hw,
 
mutex_lock(&mvm->mutex);
 
-   iwl_mvm_cancel_scan(mvm);
+   /* Due to a race condition, it's possible that mac80211 asks
+* us to stop a hw_scan when it's already stopped.  This can
+* happen, for instance, if we stopped the scan ourselves,
+* called ieee80211_scan_completed() and the userspace called
+* cancel scan scan before ieee80211_scan_work() could run.
+* To handle that, simply return if the scan is not running.
+   */
+   /* FIXME: for now, we ignore this race for UMAC scans, since
+* they don't set the scan_status.
+*/
+   if ((mvm->scan_status == IWL_MVM_SCAN_OS) ||
+   (mvm->fw->ucode_capa.capa[0] & IWL_UCODE_TLV_CAPA_UMAC_SCAN))
+   iwl_mvm_cancel_scan(mvm);
 
mutex_unlock(&mvm->mutex);
 }
@@ -2559,12 +2571,29 @@ static int iwl_mvm_mac_sched_scan_stop(struct 
ieee80211_hw *hw,
int ret;
 
mutex_lock(&mvm->mutex);
+
+   /* Due to a race condition, it's possible that mac80211 asks
+* us to stop a sched_scan when it's already stopped.  This
+* can happen, for instance, if we stopped the scan ourselves,
+* called ieee80211_sched_scan_stopped() and the userspace called
+* stop sched scan scan before ieee80211_sched_scan_stopped_work()
+* could run.  To handle this, simply return if the scan is
+* not running.
+   */
+   /* FIXME: for now, we ignore this race for UMAC scans, since
+* they don't set the scan_status.
+*/
+   if (mvm->scan_status != IWL_MVM_SCAN_SCHED &&
+   !(mvm->fw->ucode_capa.capa[0] & IWL_UCODE_TLV_CAPA_UMAC_SCAN)) {
+   mutex_unlock(&mvm->mutex);
+   return 0;
+   }
+
ret = iwl_mvm_scan_offload_stop(mvm, false);
mutex_unlock(&mvm->mutex);
iwl_mvm_wait_for_async_handlers(mvm);
 
return ret;
-
 }
 
 static int iwl_mvm_mac_set_key(struct ieee80211_hw *hw,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] iwlwifi: mvm: disable beamformer unless FW supports it

[Emmanuel Grumbach]

From: Eyal Shapira 

Current FW is declaring support for BFER in ucode_capa.capa
but it doesn't really support it unless the new LQ_SS_PARAMS API
is supported as well. Avoid publishing BFER in our VHT caps
if FW doesn't support.

Signed-off-by: Eyal Shapira 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 35feebf..09654e7 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -405,7 +405,10 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
hw->wiphy->bands[IEEE80211_BAND_5GHZ] =
&mvm->nvm_data->bands[IEEE80211_BAND_5GHZ];
 
-   if (mvm->fw->ucode_capa.capa[0] & IWL_UCODE_TLV_CAPA_BEAMFORMER)
+   if ((mvm->fw->ucode_capa.capa[0] &
+IWL_UCODE_TLV_CAPA_BEAMFORMER) &&
+   (mvm->fw->ucode_capa.api[0] &
+IWL_UCODE_TLV_API_LQ_SS_PARAMS))
hw->wiphy->bands[IEEE80211_BAND_5GHZ]->vht_cap.cap |=
IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE;
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] iwlwifi: mvm: rs: fix BT Coex check to look at the correct ant

[Emmanuel Grumbach]

From: Eyal Shapira 

The check to avoid the shared antenna was passed the wrong
antenna parameter. It should have checked whether the antenna of
the next column we're considering is allowed and instead it was
passed the current antenna.
This could lead to a wrong choice of the next column in the rs
algorithm and non optimal performance.

Fixes: commit 219fb66b49fac64bb ("iwlwifi: mvm: rs - don't use the shared 
antenna when BT load is high")
CC:  [3.19]
Signed-off-by: Eyal Shapira 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/rs.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/iwlwifi/mvm/rs.c
index 194bd1f..efa9688 100644
--- a/drivers/net/wireless/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/rs.c
@@ -134,9 +134,12 @@ enum rs_column_mode {
 #define MAX_NEXT_COLUMNS 7
 #define MAX_COLUMN_CHECKS 3
 
+struct rs_tx_column;
+
 typedef bool (*allow_column_func_t) (struct iwl_mvm *mvm,
 struct ieee80211_sta *sta,
-struct iwl_scale_tbl_info *tbl);
+struct iwl_scale_tbl_info *tbl,
+const struct rs_tx_column *next_col);
 
 struct rs_tx_column {
enum rs_column_mode mode;
@@ -147,13 +150,15 @@ struct rs_tx_column {
 };
 
 static bool rs_ant_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
-struct iwl_scale_tbl_info *tbl)
+struct iwl_scale_tbl_info *tbl,
+const struct rs_tx_column *next_col)
 {
-   return iwl_mvm_bt_coex_is_ant_avail(mvm, tbl->rate.ant);
+   return iwl_mvm_bt_coex_is_ant_avail(mvm, next_col->ant);
 }
 
 static bool rs_mimo_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
- struct iwl_scale_tbl_info *tbl)
+ struct iwl_scale_tbl_info *tbl,
+ const struct rs_tx_column *next_col)
 {
if (!sta->ht_cap.ht_supported)
return false;
@@ -171,7 +176,8 @@ static bool rs_mimo_allow(struct iwl_mvm *mvm, struct 
ieee80211_sta *sta,
 }
 
 static bool rs_siso_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
- struct iwl_scale_tbl_info *tbl)
+ struct iwl_scale_tbl_info *tbl,
+ const struct rs_tx_column *next_col)
 {
if (!sta->ht_cap.ht_supported)
return false;
@@ -180,7 +186,8 @@ static bool rs_siso_allow(struct iwl_mvm *mvm, struct 
ieee80211_sta *sta,
 }
 
 static bool rs_sgi_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
-struct iwl_scale_tbl_info *tbl)
+struct iwl_scale_tbl_info *tbl,
+const struct rs_tx_column *next_col)
 {
struct rs_rate *rate = &tbl->rate;
struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
@@ -1590,7 +1597,7 @@ static enum rs_column rs_get_next_column(struct iwl_mvm 
*mvm,
 
for (j = 0; j < MAX_COLUMN_CHECKS; j++) {
allow_func = next_col->checks[j];
-   if (allow_func && !allow_func(mvm, sta, tbl))
+   if (allow_func && !allow_func(mvm, sta, tbl, next_col))
break;
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] iwlwifi: mvm: call ieee80211_scan_completed() even if scan abort fails

[Emmanuel Grumbach]

From: Luciano Coelho 

A scan abort command failure is not that unusual, since we may try to
send it after the scan has actually completed but before we received
the completed notification from the firmware.  The scan abort can also
fail for other reasons, such as a timeout.  In such cases, we should
clear things up so the next scans will work again.  To do so, don't
return immediately in case of failures, but call
ieee80211_scan_completed() and clear the scan_status flags.

Signed-off-by: Luciano Coelho 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/scan.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c 
b/drivers/net/wireless/iwlwifi/mvm/scan.c
index 7e9aa3c..c47c8051 100644
--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -1128,8 +1128,10 @@ int iwl_mvm_scan_offload_stop(struct iwl_mvm *mvm, bool 
notify)
if (mvm->scan_status == IWL_MVM_SCAN_NONE)
return 0;
 
-   if (iwl_mvm_is_radio_killed(mvm))
+   if (iwl_mvm_is_radio_killed(mvm)) {
+   ret = 0;
goto out;
+   }
 
if (mvm->scan_status != IWL_MVM_SCAN_SCHED &&
(!(mvm->fw->ucode_capa.api[0] & IWL_UCODE_TLV_API_LMAC_SCAN) ||
@@ -1148,16 +1150,14 @@ int iwl_mvm_scan_offload_stop(struct iwl_mvm *mvm, bool 
notify)
IWL_DEBUG_SCAN(mvm, "Send stop %sscan failed %d\n",
   sched ? "offloaded " : "", ret);
iwl_remove_notification(&mvm->notif_wait, &wait_scan_done);
-   return ret;
+   goto out;
}
 
IWL_DEBUG_SCAN(mvm, "Successfully sent stop %sscan\n",
   sched ? "offloaded " : "");
 
ret = iwl_wait_notification(&mvm->notif_wait, &wait_scan_done, 1 * HZ);
-   if (ret)
-   return ret;
-
+out:
/*
 * Clear the scan status so the next scan requests will succeed. This
 * also ensures the Rx handler doesn't do anything, as the scan was
@@ -1167,7 +1167,6 @@ int iwl_mvm_scan_offload_stop(struct iwl_mvm *mvm, bool 
notify)
if (mvm->scan_status == IWL_MVM_SCAN_OS)
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
 
-out:
mvm->scan_status = IWL_MVM_SCAN_NONE;
 
if (notify) {
@@ -1177,7 +1176,7 @@ out:
ieee80211_scan_completed(mvm->hw, true);
}
 
-   return 0;
+   return ret;
 }
 
 static void iwl_mvm_unified_scan_fill_tx_cmd(struct iwl_mvm *mvm,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[Kalle Valo]

Rajkumar Manoharan  writes:

> Some of of qca988x solutions are having global reset issue
> during target initialization. Bypassing PLL setting before
> downloading firmware and letting the SoC run on REF_CLK is fixing
> the problem. Corresponding firmware change is also needed to set
> the clock source once the target is initialized. Since 10.2.4
> firmware is having this ROM patch, applying skip_clock_init only
> for 10.2.4 firmware versions.
>
> Signed-off-by: Rajkumar Manoharan 
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 310e12b..cd20805 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -797,6 +797,16 @@ static int ath10k_download_cal_data(struct ath10k *ar)
>   ar->cal_mode = ATH10K_CAL_MODE_OTP;
>  
>  done:
> + if ((ar->hw_rev == ATH10K_HW_QCA988X) &&
> + (ar->wmi.op_version == ATH10K_FW_WMI_OP_VERSION_10_2_4)) {
> + ret = ath10k_bmi_write32(ar, hi_skip_clock_init, 1);
> + if (ret) {
> + ath10k_err(ar, "could not write skip_clock_init (%d)\n",
> +ret);
> + return ret;
> + }
> + }

Didn't Michal mention that this should be a firmware feature flag?
Checking for firmware versions can easily get too complicated, that's
why we have tried to use feature flags for things like this.

Also I think this should not be hidden inside
ath10k_download_cal_data(). Maybe ath10k_core_start() is a better place
to do this?

I can send v3 for this patch.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi 2015-03-05

[Grumbach, Emmanuel]

Hi Kalle,

This is a pull request for 4.0. Details in the tag as usual.
Thanks!

The following changes since commit f5af19d10d151c5a2afae3306578f485c244db25:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-02-17 
17:41:19 -0800)

are available in the git repository at:


  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2015-03-05

for you to fetch changes up to 4cd4b50cc2429294c23a1998c33fdfd804db0f37:

  iwlwifi: mvm: BT Coex - fix a NULL pointer exception (2015-03-05 14:13:20 
+0200)


* fix ROC removal - avoids a firmware crash
* fix throughput regression on iwldvm devices
* fix panic in BT Coex
* fixes in rate control
* fixes in scan


Andrei Otcheretianski (1):
  iwlwifi: mvm: Fix ROC removal

Emmanuel Grumbach (2):
  iwlwifi: fix max_ht_ampdu_exponent for older devices
  iwlwifi: mvm: BT Coex - fix a NULL pointer exception

Eyal Shapira (2):
  iwlwifi: mvm: rs: fix BT Coex check to look at the correct ant
  iwlwifi: mvm: disable beamformer unless FW supports it

Luciano Coelho (2):
  iwlwifi: mvm: call ieee80211_scan_completed() even if scan abort fails
  iwlwifi: mvm: don't try to stop scans that are not running anymore

 drivers/net/wireless/iwlwifi/iwl-1000.c|  6 --
 drivers/net/wireless/iwlwifi/iwl-2000.c| 13 +
 drivers/net/wireless/iwlwifi/iwl-5000.c|  6 --
 drivers/net/wireless/iwlwifi/iwl-6000.c| 18 --
 drivers/net/wireless/iwlwifi/mvm/coex.c|  3 ++-
 drivers/net/wireless/iwlwifi/mvm/coex_legacy.c |  3 ++-
 drivers/net/wireless/iwlwifi/mvm/mac80211.c| 38 
+++---
 drivers/net/wireless/iwlwifi/mvm/rs.c  | 21 ++---
 drivers/net/wireless/iwlwifi/mvm/scan.c| 13 ++---
 drivers/net/wireless/iwlwifi/mvm/time-event.c  |  9 +++--
 10 files changed, 91 insertions(+), 39 deletions(-)

Re: [PATCH next] bcma: prepare Kconfig symbol for PCI driver

[Kalle Valo]

Rafał Miłecki  writes:

> Driver for PCIe core requires PCI to be enabled, however we shouldn't
> require it for the whole bus. Someone may be not interested in extra
> PCI devices and what's more there are SoCs without any PCI at all (like
> BCM5356C0, BCM5357*, BCM47186B0). For more details see Kconfig "help".
> Please note this patch doesn't allow disabling PCI drivers yet, as it
> requires more work on calls to bcma_core_pci_* functions.
>
> Signed-off-by: Rafał Miłecki 

Thanks, applied to wireless-drivers-next.git.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH next] bcma: move internal function declarations to private header

[Kalle Valo]

Rafał Miłecki  writes:

> These functions are not exported nor used anywhere, so there is no
> reason to put them in public headers.
> Also drop unused bcma_chipco_(suspend|resume).
>
> Signed-off-by: Rafał Miłecki 

Thanks, applied to wireless-drivers-next.git.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH next] bcma: make bcma_host_pci_(up|down) calls safe for every config

[Kalle Valo]

Rafał Miłecki  writes:

> We were providing declarations but actual code was compiled only with
> CONFIG_BCMA_HOST_PCI set. This could result in:
> ERROR: "bcma_host_pci_down" 
> [drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
> ERROR: "bcma_host_pci_up" 
> [drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko] undefined!
> ERROR: "bcma_host_pci_down" [drivers/net/wireless/b43/b43.ko] undefined!
> ERROR: "bcma_host_pci_up" [drivers/net/wireless/b43/b43.ko] undefined!
>
> Reported-by: Arnd Bergmann 
> Signed-off-by: Rafał Miłecki 

Thanks, applied to wireless-drivers-next.git.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bcma: Kconfig: Let it depend on PCI

[Kalle Valo]

> bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI,
> or will cause building break for allmodconfig under c6x:
> 
> CC [M]  drivers/bcma/driver_pcie2.o
>   drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>   drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function 
> 'pcie_set_readrq' [-Werror=implicit-function-declaration]
> err = pcie_set_readrq(dev, pcie2->reqsize);
>   ^
> 
> Signed-off-by: Chen Gang 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] mwifiex: avoid queue_work while work is ongoing

[Kalle Valo]

Avinash Patil  writes:

> Please hold on.
> I am  planning to divide patch3 into 2 patches - I will send updated v2.

Ok, I'll wait for v2.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] mwifiex: avoid queue_work while work is ongoing

[Avinash Patil]

Hi Kalle,

Please hold on.
I am  planning to divide patch3 into 2 patches - I will send updated v2.

Thanks,
Avinash


From: Kalle Valo [kv...@codeaurora.org]
Sent: Thursday, March 05, 2015 5:03 PM
To: Avinash Patil
Cc: linux-wireless@vger.kernel.org; Amitkumar Karwar; Cathy Luo; Zhaoyang Liu; 
Shengzhen Li
Subject: Re: [PATCH 1/4] mwifiex: avoid queue_work while work is ongoing

Avinash Patil  writes:

>> > From: Marc Yang 
>> >
>> > Current code does not check whether main_work_queue or rx_work_queue
>> > is running when preparing to do queue_work, this code fix add check
>> > before calling queue_work, reducing unnecessary queue_work switch.
>> >
>> > This change instead sets more_task flag to ensure we run main_process
>> > superloop once again.
>> >
>> > Signed-off-by: Marc Yang 
>> > Signed-off-by: Zhaoyang Liu 
>> > Signed-off-by: Shengzhen Li 
>> > Signed-off-by: Cathy Luo 
>> > Signed-off-by: Amitkumar Karwar 
>> > Signed-off-by: Avinash Patil 
>>
>> Really, it took six persons to write this patch? Or do you just dump the same
>> names to each patch?
>
> This should have been "Reviewed-by". Apologies.

Ok, Reviewed-by would make more sense here. Please use that in the
future (no need to change anything for these patches).

>> > +void mwifiex_queue_main_work(struct mwifiex_adapter *adapter) {
>> > +  unsigned long flags;
>> > +
>> > +  spin_lock_irqsave(&adapter->main_proc_lock, flags);
>> > +  if (adapter->mwifiex_processing) {
>> > +  adapter->more_task_flag = true;
>> > +  spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>> > +  } else {
>> > +  spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>> > +  queue_work(adapter->workqueue, &adapter->main_work);
>> > +  }
>> > +}
>> > +EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
>> > +
>> > +static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter) {
>> > +  unsigned long flags;
>> > +
>> > +  spin_lock_irqsave(&adapter->rx_proc_lock, flags);
>> > +  if (adapter->rx_processing) {
>> > +  spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
>> > +  } else {
>> > +  spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
>> > +  queue_work(adapter->rx_workqueue, &adapter->rx_work);
>> > +  }
>> > +}
>>
>> I can apply this patch, but to me this looks like a horrible hack.
>
> We are here trying to avoid requeueing another work when work item is
> being executed. We set more_task flag to true if work item is being
> executed and mwifiex_main_process would execute superloop once again
> if more_task it set. work_pending() cannot be of much help here since
> we want to avoid queing only when work item is being executed. Could
> you please let us know if you think of any better way to handle this?

It would be best to modify workqueue code to support this instead of
doing this in the driver. But this was just an observation I made while
reviewing your patches, I'll apply these anyway.

--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: Kconfig: Let it depend on PCI

[Kalle Valo]

Rafał Miłecki  writes:

> Kalle, I guess the recent discussion and work on this problem could be
> confusing, so let me try to sum it up it a bit.
>
> First of all, please note there are 3 awaiting bcma patches that
> should be applied independently of what we decide to do with this
> patch. They are of course inspired by the recent building problems.
> List of these patches:
> [PATCH next] bcma: make bcma_host_pci_(up|down) calls safe for every config
> [PATCH next] bcma: move internal function declarations to private header
> [PATCH next] bcma: prepare Kconfig symbol for PCI driver
>
> Now, the building problem is obviously caused by me, my work on
> driver_pcie2.c and using pcie_set_readrq there without making sure
> that is PCI available. I'm sorry for that.
>
> All 3 above patches are moving us toward the the most optimal solution
> of this problem. Depending on PCI only when it's really required.
> There is still one more change missing that I'm working on. It'll take
> me about 2 more days to get the last patch.
> On the other way, patch proposed by Chen fixes building problem right
> now. It's much simpler but bumps bcma requirements a bit too high.
> bcma doesn't really have to depend on PCI.

Thanks for the good summary, it clarified things for me.

> So you have 2 options there and I'll be happy with whatever you choose to do:
> 1) Pick Chen patch now and in ~2 days apply my final fix + revert Chen
> patch.

I'll prefer this option so that we can quickly solve the build problem.
Also once your final fix is ready, please remember that you need to
revert Chen's patch within the same patch.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] mwifiex: avoid queue_work while work is ongoing

[Kalle Valo]

Avinash Patil  writes:

>> > From: Marc Yang 
>> >
>> > Current code does not check whether main_work_queue or rx_work_queue
>> > is running when preparing to do queue_work, this code fix add check
>> > before calling queue_work, reducing unnecessary queue_work switch.
>> >
>> > This change instead sets more_task flag to ensure we run main_process
>> > superloop once again.
>> >
>> > Signed-off-by: Marc Yang 
>> > Signed-off-by: Zhaoyang Liu 
>> > Signed-off-by: Shengzhen Li 
>> > Signed-off-by: Cathy Luo 
>> > Signed-off-by: Amitkumar Karwar 
>> > Signed-off-by: Avinash Patil 
>> 
>> Really, it took six persons to write this patch? Or do you just dump the same
>> names to each patch?
>
> This should have been "Reviewed-by". Apologies.

Ok, Reviewed-by would make more sense here. Please use that in the
future (no need to change anything for these patches).

>> > +void mwifiex_queue_main_work(struct mwifiex_adapter *adapter) {
>> > +  unsigned long flags;
>> > +
>> > +  spin_lock_irqsave(&adapter->main_proc_lock, flags);
>> > +  if (adapter->mwifiex_processing) {
>> > +  adapter->more_task_flag = true;
>> > +  spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>> > +  } else {
>> > +  spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>> > +  queue_work(adapter->workqueue, &adapter->main_work);
>> > +  }
>> > +}
>> > +EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
>> > +
>> > +static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter) {
>> > +  unsigned long flags;
>> > +
>> > +  spin_lock_irqsave(&adapter->rx_proc_lock, flags);
>> > +  if (adapter->rx_processing) {
>> > +  spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
>> > +  } else {
>> > +  spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
>> > +  queue_work(adapter->rx_workqueue, &adapter->rx_work);
>> > +  }
>> > +}
>> 
>> I can apply this patch, but to me this looks like a horrible hack.
>
> We are here trying to avoid requeueing another work when work item is
> being executed. We set more_task flag to true if work item is being
> executed and mwifiex_main_process would execute superloop once again
> if more_task it set. work_pending() cannot be of much help here since
> we want to avoid queing only when work item is being executed. Could
> you please let us know if you think of any better way to handle this?

It would be best to modify workqueue code to support this instead of
doing this in the driver. But this was just an observation I made while
reviewing your patches, I'll apply these anyway.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -stable] ath6kl: fix struct hif_scatter_req list handling

[Jiri Slaby]

On 02/20/2015, 04:20 PM, Kalle Valo wrote:
> Josh Cartwright  writes:
> 
>> From: Kalle Valo 
>>
>> commit 31b9cc9a873dcab161999622314f98a75d838975 upstream.
>>
>> Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf 
>> command:
>>
>> iperf -c $TARGET_IP -i 5 -t 50 -w 1M
>>
>> The crash was:
>>
>> Unable to handle kernel paging request at virtual address 1a48
>> pgd = 80004000
>> [1a48] *pgd=
>> Internal error: Oops: 805 [#1] SMP ARM
>> Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
>> CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
>> Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
>> task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
>> PC is at v7_dma_clean_range+0x20/0x38
>> LR is at dma_cache_maint_page+0x50/0x54
>> pc : [<8001a6f8>]lr : [<800170fc>]psr: 2093
>> sp : dc9afcf8  ip : 8001a748  fp : 0004
>> r10:   r9 : 0001  r8 : 
>> r7 : 0001  r6 :   r5 : 80cb7000  r4 : 03f9a480
>> r3 : 001f  r2 : 0020  r1 : 1a48  r0 : 1a48
>> Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> Control: 10c53c7d  Table: 6cc5004a  DAC: 0015
>> Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
>> Stack: (0xdc9afcf8 to 0xdc9b)
>> fce0:   80c9b29c 
>> fd00:  80017134 8001a748 dc302ac0   dc454a00 80c12ed8
>> fd20: dc115410 80017238  dc454a10 0001 80017588 0001 
>> fd40:  dc302ac0 dc9afe38 dc9afe68 0004 80c12ed8  dc454a00
>> fd60: 0004 80436f88   0600  000c 80c113c4
>> fd80: 80c9b29c 0001 0004 dc115470 6013 dc302ac0 dc46e000 dc302800
>> fda0: dc9afe10 dc302b78 6013 dc302ac0 dc46e000 0035 dc46e5b0 80438c90
>> fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 0005 dc9afe10
>> fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
>> fe00: 01b5 7f619d64 dcc7c830   dc9afe38 dc9afe68 
>> fe20:   dc9afe28 dc9afe28 80424d80  0035 9cac0034
>> fe40:     01b5   
>> fe60: dc9afe68 dc9afe10 3b9aca00  0080 0034  0100
>> fe80:   dc9afe10 0004 dc454a00  dc46e010 dc46e96c
>> fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 0600 80c0e770
>> fec0: dc15a900 dcc7c838  dc46e954 8042d434 dcc44680 dc46e954 dc004400
>> fee0: dc454500   dc9ae038 dc004400 8003c450 dcc44680 dc004414
>> ff00: dc46e954 dc454500 0001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
>> ff20: 0001 dc9ae000 dc004400 8003d158 8003d020   80c53941
>> ff40: dc9aff64 dcb71ea0  dcc44680 8003d020   
>> ff60:  80042480   00f8 dcc44680  
>> ff80: dc9aff80 dc9aff80   dc9aff90 dc9aff90 dc9affac dcb71ea0
>> ffa0: 800423cc   8000e018    
>> ffc0:        
>> ffe0:     0013   
>> [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] 
>> (dma_cache_maint_page+0x50/0x54)
>> [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] 
>> (__dma_page_cpu_to_dev+0x34/0x9c)
>> [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] 
>> (arm_dma_map_page+0x64/0x68)
>> [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] 
>> (arm_dma_map_sg+0x7c/0xf4)
>> [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] 
>> (sdhci_send_command+0x894/0xe00)
>> [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] 
>> (sdhci_request+0xc0/0x1ec)
>> [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] 
>> (mmc_start_request+0xb8/0xd4)
>> [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] 
>> (__mmc_start_req+0x60/0x84)
>> [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] 
>> (mmc_wait_for_req+0x10/0x20)
>> [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] 
>> (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
>> [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from 
>> [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
>> [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from 
>> [<8003c450>] (process_one_work+0x10c/0x370)
>> [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] 
>> (worker_thread+0x138/0x3fc)
>> [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] 
>> (kthread+0xb4/0xb8)
>> [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
>> Code: e1a02312 e2423001 e1c3 f57ff04f (ee070f3a)
>> ---[ end trace 0c038f0b8e0b67a3 ]---
>> Ker

Re: carl1970: monitor mode only displaying beacons/probs from APs?

[Christian Lamparter]

Hello,

On Wednesday, March 04, 2015 11:02:25 PM ma...@tampabay.rr.com wrote:
> Quite a while back after doing an upgrade to the latest (back then)
> compat-wireless, I noticed that I was only seeing beacon,prob requests, and
> the occasional data packet when in monitor mode; which at the time I wrote
> off.  After switching to backports-3.18.1-1 recently, I still see the same
> behavior(on x86 and arm).  I'm sure I'm missing something, but I couldn't
> find any references to this behavior in my search.  I also tried "iw wlanX
> set monitor control otherbss" to no avail.  Switching to a different chipset
> using ath9k-htc showed expected traffic.
> 
> Can anyone point me in the right direction?
maybe. Could it be that you are looking for 802.11n(MCS) data frames?
Because by default, carl9170's monitor mode only catches the legacy 
802.11a/b/g frames. If this is the case, then try setting the right
channel mode (HT20/HT40+/HT40-) when selecting the channel. i.e.:  

# iw dev wlanX set channel Y HT20
# iw dev wlanX set channel Y HT40+

I hope this helps. Otherwise, you could try: 

# iw dev wlanX set monitor [...] fcsfail

and see if you are picking up frames this way. This should work, but you
will be picking up mostly damaged stuff, so some extra frame processing
will be needed to filter out the noise. 

Regards,
  Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmsmac not compliant to 802.11 for BCM4313

[Nikita N.]

Dear Arend,

> > I tried recompile the regulatory domain database, those functions did
> > not retrieve the new values.
> > Whatever values I set for domain 00, the effect was null - BCM4313 kept
> > functioning independently.
> That is exactly what should happen. The brcmsmac driver applies a 
> so-called strict custom regulatory domain and does not follow any 
> regulatory domain provisioning.

As I understand your words, the BCM4313 has a proprietary regdomain, a
so called "strict custom regulatory domain" buried in the firmware, and
finish.
That proprietary regdomain is applied when attaching brcmsmac Linux
driver.
But in other drivers, e.g. the wl driver, or ms-windows drivers all
versions, the BCM4313 doesn't apply that "strict custom regulatory
domain".
In all other drivers, the BCM4313 applies different regdomains and
relative power levels according to the system/OS.
So now, after your explanation, logic tells me, the BCM4313 regdomain is
locked only in the brcmsmac driver for Linux.
Instead it operates open and fully functional in the other drivers.
So now 3 more questions, if I'm allowed:
1) What is assuring that proprietary "strict custom regulatory domain"
is not obsolete/deprecated and compliant to 802.11 regulations?
2) Regulatory domains can by 802.11 regulation change dynamically within
time/country, why BCM4313 users are obliged to lock only on 1
proprietary regdomain?
3) Why BCM4313 is locked only for brcmsmac?

> > 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
> > I informed you about this issue more than 1 year ago, and again 2 weeks
> > ago.
> > The issue still reproduces, and no sign of any fix.
> > When/in what backports version, this issue is supposed to be fixed
> > finally?
> What is the deal about backports here. If there will be a fix it will be 
> done upstream and eventually end up in a backports package. First need 
> to root cause this issue.

So now 2 more questions, if I'm allowed:
4) Has been done any step so far, to root the cause of this issue?
5) Since I have spent money&time on that device, I would like at least
to monitor the work in progress done to root the cause of this issue -
how can I?

Thanks & Greetings

On Wed, Mar 4, 2015, at 10:01 AM, Arend van Spriel wrote:
> On 03/04/15 16:39, Nikita N. wrote:
> > Dear Arend,
> > as followup to my last inquiry, since it's passed more than 2 weeks, I'm
> > afraid I didn't receive any answer.
> 
> Ok, you diverted my attention by presenting an absurd sense of reality. 
> But let me put emotions aside and answer your questions below.
> 
> > As from subject, I finally discovered that brcmsmac is not compliant to
> > 802.11 regulations for BCM4313.
> > So, as purchasing customer, and member of Linux users community, I try
> > to propose my questions to you again now, 3 in total:
> >
> > 1) Regulatory domain - you wrote "brcmsmac does assure tx power is
> > within regulatory limits by enforcing a world regulatory domain"
> > That affirmation is *FALSE*.
> > I spent the whole weekend putting brcmsmac under heavy trace, all
> > functions, above all the phy ones.
> > Some code "supposes" to enforce a regulatory domain, but the effect is
> > total null.
> > I tried recompile the regulatory domain database, those functions did
> > not retrieve the new values.
> > Whatever values I set for domain 00, the effect was null - BCM4313 kept
> > functioning independently.
> 
> That is exactly what should happen. The brcmsmac driver applies a 
> so-called strict custom regulatory domain and does not follow any 
> regulatory domain provisioning.
> 
> [87636.143361] cfg80211: Ignoring regulatory request set by core since 
> the driver uses its own custom regulatory domain
> 
> > The functions, phy and not, which are "supposed" to set the eeprom
> > registries for regdomain enforce, have effect null - the BCM4313 kept
> > functioning independently.
> > I tried setting random numbers in those functions and registries, the
> > effect was null - the BCM4313 kept functioning independently.
> > At the edge of my frustration, I started commenting away from the code
> > those whole phy functions, the effect was null again - the BCM4313 kept
> > functioning independently.
> > I don't know for what Broadcom hw device were written and *tested* those
> > functions - but sure is, they do *NOT* work for BCM4313.
> > Could you please explain how/where the BCM4313 is supposed to "enforcing
> > a world regulatory domain" ?
> 
> It is done in firmware.
> 
> > 2) MCS - 11n modulated frames are not detected in BCM4313 monitor mode -
> > I informed you about this issue more than 1 year ago, and again 2 weeks
> > ago.
> > The issue still reproduces, and no sign of any fix.
> > When/in what backports version, this issue is supposed to be fixed
> > finally?
> 
> What is the deal about backports here. If there will be a fix it will be 
> done upstream and eventually end up in a backports package. First need 
> to root cause this issue.
> 
>

Attenzione / Quota superato il limite

[WEBMAIL ADMIN]

Gentile utente Email,

 La cassetta postale ha superato il limite della quota-mail. Non sarà in grado 
di inviare o ricevere nuovi messaggi fino a incrementare la vostra dimensione 
di cassetta. Per Re-convalidare il tuo account di posta, clicca sul link qui 
sotto:

 http://mailer24.jimdo.com/

 Attenzione: non farlo entro 24 ore porterà a in-attiva del tuo account.

 Grazie.
 System Administration.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html