Re: iwlwifi firmware load broken in current -git

[Bjorn Helgaas]

On Fri, Sep 15, 2017 at 01:55:57PM -0600, Jens Axboe wrote:
> On 09/15/2017 01:51 PM, Luca Coelho wrote:
> > On Fri, 2017-09-15 at 13:48 -0600, Jens Axboe wrote:
> >> On 09/15/2017 01:38 PM, Linus Torvalds wrote:
> >>> On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
> >
> > In any case, your patch introduces a regression on systems. Please get
> > it reverted now, and then you can come up with a new approach to fix the
> > double enable of the upstream bridge.
> 
>  Who's sending in the revert? I can certainly do it if no one else does,
>  but it needs to be done.
> 
>  I'm not seeing any patches coming out of Srinath to fix up the
>  situation, so we should revert the broken patch until a better solution
>  exists.
> >>>
> >>> Hmm. I don't have the history here (apparently it never made lkml, for
> >>> example), so I don't even know which commit you're talking about.
> >>>
> >>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
> >>> Avoid race while enabling upstream bridges"), is that correct?
> >>
> >> Yes, Luca says that Bjorn already sent in the revert request, I just
> >> didn't see it since I wasn't CC'ed on it. So looks like we're all
> >> good, provided that makes it into -rc1. 40f11adc7cd9 is the broken
> >> commit.
> > 
> > Strange... AFAICT you *were* CCed on it.  And so was everyone else in
> > the original thread (+LKML)...
> 
> Hmm, never showed up here. Very odd!

Sorry, I think this is probably because I'm an idiot and sent it from
an @google.com account and it got rejected because the DMARC check
failed.

Bjorn

[GIT PULL] PCI fixes for v4.14

[Bjorn Helgaas]

PCI fix:

  - revert an attempt to fix a race while enabling upstream bridges because
it broke iwlwifi firmware loading


The following changes since commit 711aab1dbb324d321e3d84368a435a78908c7bce:

  vfs: constify path argument to kernel_read_file_from_path (2017-09-14 
20:18:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.14-fixes-1

for you to fetch changes up to 0f50a49e3008597abed0fff052d487f77db89093:

  Revert "PCI: Avoid race while enabling upstream bridges" (2017-09-15 01:33:51 
-0500)


pci-v4.14-fixes-1


Bjorn Helgaas (1):
  Revert "PCI: Avoid race while enabling upstream bridges"

 drivers/pci/pci.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

Re: iwlwifi firmware load broken in current -git

[Jens Axboe]

On 09/15/2017 01:51 PM, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 12:43 PM, Luca Coelho  wrote:
>> On Fri, 2017-09-15 at 12:38 -0700, Linus Torvalds wrote:
>>>
>>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
>>> Avoid race while enabling upstream bridges"), is that correct?
>>
>> Yes, that's the one.  And Bjorn already sent a revert:
>>
>> https://lkml.org/lkml/2017/9/15/46
> 
> Well, he may have sent a revert to lkml, but not to me. I'm assuming
> it's in his tree and I'll get a pull request. Hopefully soon, so that
> it makes rc.

That was my hope, and why I emailed again today on the topic.

> Jens, you were actually cc'd on that revert according to the email
> headers, so check your spam-box.

Yeah, Luca says so too. Which is making me a little worried on behalf
of my email, since it's not sitting in spam.

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

[Jens Axboe]

On 09/15/2017 01:51 PM, Luca Coelho wrote:
> On Fri, 2017-09-15 at 13:48 -0600, Jens Axboe wrote:
>> On 09/15/2017 01:38 PM, Linus Torvalds wrote:
>>> On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
>
> In any case, your patch introduces a regression on systems. Please get
> it reverted now, and then you can come up with a new approach to fix the
> double enable of the upstream bridge.

 Who's sending in the revert? I can certainly do it if no one else does,
 but it needs to be done.

 I'm not seeing any patches coming out of Srinath to fix up the
 situation, so we should revert the broken patch until a better solution
 exists.
>>>
>>> Hmm. I don't have the history here (apparently it never made lkml, for
>>> example), so I don't even know which commit you're talking about.
>>>
>>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
>>> Avoid race while enabling upstream bridges"), is that correct?
>>
>> Yes, Luca says that Bjorn already sent in the revert request, I just
>> didn't see it since I wasn't CC'ed on it. So looks like we're all
>> good, provided that makes it into -rc1. 40f11adc7cd9 is the broken
>> commit.
> 
> Strange... AFAICT you *were* CCed on it.  And so was everyone else in
> the original thread (+LKML)...

Hmm, never showed up here. Very odd!

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

[Linus Torvalds]

On Fri, Sep 15, 2017 at 12:43 PM, Luca Coelho  wrote:
> On Fri, 2017-09-15 at 12:38 -0700, Linus Torvalds wrote:
>>
>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
>> Avoid race while enabling upstream bridges"), is that correct?
>
> Yes, that's the one.  And Bjorn already sent a revert:
>
> https://lkml.org/lkml/2017/9/15/46

Well, he may have sent a revert to lkml, but not to me. I'm assuming
it's in his tree and I'll get a pull request. Hopefully soon, so that
it makes rc.

Jens, you were actually cc'd on that revert according to the email
headers, so check your spam-box.

 Linus

Re: iwlwifi firmware load broken in current -git

[Luca Coelho]

On Fri, 2017-09-15 at 13:48 -0600, Jens Axboe wrote:
> On 09/15/2017 01:38 PM, Linus Torvalds wrote:
> > On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
> > > > 
> > > > In any case, your patch introduces a regression on systems. Please get
> > > > it reverted now, and then you can come up with a new approach to fix the
> > > > double enable of the upstream bridge.
> > > 
> > > Who's sending in the revert? I can certainly do it if no one else does,
> > > but it needs to be done.
> > > 
> > > I'm not seeing any patches coming out of Srinath to fix up the
> > > situation, so we should revert the broken patch until a better solution
> > > exists.
> > 
> > Hmm. I don't have the history here (apparently it never made lkml, for
> > example), so I don't even know which commit you're talking about.
> > 
> > From some of the context it looks like commit 40f11adc7cd9 ("PCI:
> > Avoid race while enabling upstream bridges"), is that correct?
> 
> Yes, Luca says that Bjorn already sent in the revert request, I just
> didn't see it since I wasn't CC'ed on it. So looks like we're all
> good, provided that makes it into -rc1. 40f11adc7cd9 is the broken
> commit.

Strange... AFAICT you *were* CCed on it.  And so was everyone else in
the original thread (+LKML)...

--
Luca.

Re: iwlwifi firmware load broken in current -git

[Jens Axboe]

On 09/15/2017 01:38 PM, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
>>>
>>> In any case, your patch introduces a regression on systems. Please get
>>> it reverted now, and then you can come up with a new approach to fix the
>>> double enable of the upstream bridge.
>>
>> Who's sending in the revert? I can certainly do it if no one else does,
>> but it needs to be done.
>>
>> I'm not seeing any patches coming out of Srinath to fix up the
>> situation, so we should revert the broken patch until a better solution
>> exists.
> 
> Hmm. I don't have the history here (apparently it never made lkml, for
> example), so I don't even know which commit you're talking about.
> 
> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
> Avoid race while enabling upstream bridges"), is that correct?

Yes, Luca says that Bjorn already sent in the revert request, I just
didn't see it since I wasn't CC'ed on it. So looks like we're all
good, provided that makes it into -rc1. 40f11adc7cd9 is the broken
commit.

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

[Jens Axboe]

On 09/15/2017 01:36 PM, Luca Coelho wrote:
> On Fri, 2017-09-15 at 13:32 -0600, Jens Axboe wrote:
>> On 09/14/2017 02:36 PM, Jens Axboe wrote:
>>> On 09/14/2017 02:04 PM, Srinath Mannam wrote:
 Hi Jens Axboe,


 On Thu, Sep 14, 2017 at 11:14 PM, Jens Axboe  wrote:
> On 09/14/2017 11:35 AM, Jens Axboe wrote:
>> On 09/14/2017 11:28 AM, Srinath Mannam wrote:
>>> Hi Bjorn,
>>>
>>> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe  wrote:

 On 09/14/2017 11:11 AM, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe  wrote:
>> On 09/12/2017 02:04 PM, Johannes Berg wrote:
>>> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
>>>
 CC'ing the guilty part and Bjorn. I'm assuming it's the
 pci_is_enabled() check, since the rest of the patch shouldn't have
 functional changes.
>>>
>>> and pci_enable_bridge() already checks if it's already enabled, but
>>> still enables mastering in that case if it isn't:
>>>
>>> static void pci_enable_bridge(struct pci_dev *dev)
>>> {
>>> [...]
>>> if (pci_is_enabled(dev)) {
>>> if (!dev->is_busmaster)
>>> pci_set_master(dev);
>>> return;
>>> }
>>>
>>> so I guess due to the new check we end up with mastering disabled, 
>>> and
>>> thus the firmware can't load since that's a DMA thing?
>>
>> Bjorn/Srinath, any input here? This is a regression that prevents 
>> wifi
>> from working on a pretty standard laptop. It'd suck to have this be 
>> in
>> -rc1. Seems like the trivial fix would be:
>>
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b0002daa50f3..ffbe11dbdd61 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct 
>> pci_dev *dev, unsigned long flags)
>> return 0;   /* already enabled */
>>
>> bridge = pci_upstream_bridge(dev);
>> -   if (bridge && !pci_is_enabled(bridge))
>> +   if (bridge)
>>>
>>> With this change and keeping "mutex_lock(_bridge_mutex);" in
>>> pci_enable_bridge functoin will causes a nexted lock.
>>
>> Took a look, and looks like you are right. That code looks like a mess,
>> fwiw.
>>
>> I'd strongly suggest that the bad commit is reverted until a proper
>> solution is found, since the simple one-liner could potentially
>> introduce a deadlock with your patch applied.
>
> BTW, your patch looks pretty bad too, introducing a random mutex
> deep on code that can be recursive. Why isn't this check in
> pci_enable_device_flags() enough to prevent double-enable of
> an upstream bridge?
>
> if (atomic_inc_return(>enable_cnt) > 1)
> return 0;   /* already enabled */
>

 This check only to verify device enable not for the bus master check.
 But device enable function calls the bridge enable if it has the bridge.
 Bridge enable function enables both device and bus master.

 Here the issue might be because, bridge of endpoint has already set
 device enable without set bus master in some other context. which is
 wrong.
 because all bridges should enable with bridge_enable function only.
 So we see the problem In this context, because "if (bridge &&
 !pci_is_enabled(bridge))" check stops bridge enable which intern stops
 bus master.
 pci_enable_bridge function always makes sure that both device and bus
 master are enabled in any case. If pci_enable_bridge function is not
 called means, that bridge is already has device enable flag set. which
 is not from pci_enable_bridge function.
>>>
>>> In any case, your patch introduces a regression on systems. Please get
>>> it reverted now, and then you can come up with a new approach to fix the
>>> double enable of the upstream bridge.
>>
>> Who's sending in the revert? I can certainly do it if no one else does,
>> but it needs to be done.
>>
>> I'm not seeing any patches coming out of Srinath to fix up the
>> situation, so we should revert the broken patch until a better solution
>> exists.
> 
> Bjorn already sent it:
> 
> https://lkml.org/lkml/2017/9/15/46

Huh ok, I would have thought the various folks in this discussion would
have been CC'ed on that. But good to know, that takes care of my
concern.

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

[Luca Coelho]

On Fri, 2017-09-15 at 12:38 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
> > > 
> > > In any case, your patch introduces a regression on systems. Please get
> > > it reverted now, and then you can come up with a new approach to fix the
> > > double enable of the upstream bridge.
> > 
> > Who's sending in the revert? I can certainly do it if no one else does,
> > but it needs to be done.
> > 
> > I'm not seeing any patches coming out of Srinath to fix up the
> > situation, so we should revert the broken patch until a better solution
> > exists.
> 
> Hmm. I don't have the history here (apparently it never made lkml, for
> example), so I don't even know which commit you're talking about.
> 
> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
> Avoid race while enabling upstream bridges"), is that correct?

Yes, that's the one.  And Bjorn already sent a revert:

https://lkml.org/lkml/2017/9/15/46

--
Luca.

Re: iwlwifi firmware load broken in current -git

[Linus Torvalds]

On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
>>
>> In any case, your patch introduces a regression on systems. Please get
>> it reverted now, and then you can come up with a new approach to fix the
>> double enable of the upstream bridge.
>
> Who's sending in the revert? I can certainly do it if no one else does,
> but it needs to be done.
>
> I'm not seeing any patches coming out of Srinath to fix up the
> situation, so we should revert the broken patch until a better solution
> exists.

Hmm. I don't have the history here (apparently it never made lkml, for
example), so I don't even know which commit you're talking about.

>From some of the context it looks like commit 40f11adc7cd9 ("PCI:
Avoid race while enabling upstream bridges"), is that correct?

   Linus

Re: iwlwifi firmware load broken in current -git

[Luca Coelho]

On Fri, 2017-09-15 at 13:32 -0600, Jens Axboe wrote:
> On 09/14/2017 02:36 PM, Jens Axboe wrote:
> > On 09/14/2017 02:04 PM, Srinath Mannam wrote:
> > > Hi Jens Axboe,
> > > 
> > > 
> > > On Thu, Sep 14, 2017 at 11:14 PM, Jens Axboe  wrote:
> > > > On 09/14/2017 11:35 AM, Jens Axboe wrote:
> > > > > On 09/14/2017 11:28 AM, Srinath Mannam wrote:
> > > > > > Hi Bjorn,
> > > > > > 
> > > > > > On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe  
> > > > > > wrote:
> > > > > > > 
> > > > > > > On 09/14/2017 11:11 AM, Bjorn Helgaas wrote:
> > > > > > > > [+cc linux-pci]
> > > > > > > > 
> > > > > > > > On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe  
> > > > > > > > wrote:
> > > > > > > > > On 09/12/2017 02:04 PM, Johannes Berg wrote:
> > > > > > > > > > On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
> > > > > > > > > > 
> > > > > > > > > > > CC'ing the guilty part and Bjorn. I'm assuming it's the
> > > > > > > > > > > pci_is_enabled() check, since the rest of the patch 
> > > > > > > > > > > shouldn't have
> > > > > > > > > > > functional changes.
> > > > > > > > > > 
> > > > > > > > > > and pci_enable_bridge() already checks if it's already 
> > > > > > > > > > enabled, but
> > > > > > > > > > still enables mastering in that case if it isn't:
> > > > > > > > > > 
> > > > > > > > > > static void pci_enable_bridge(struct pci_dev *dev)
> > > > > > > > > > {
> > > > > > > > > > [...]
> > > > > > > > > > if (pci_is_enabled(dev)) {
> > > > > > > > > > if (!dev->is_busmaster)
> > > > > > > > > > pci_set_master(dev);
> > > > > > > > > > return;
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > so I guess due to the new check we end up with mastering 
> > > > > > > > > > disabled, and
> > > > > > > > > > thus the firmware can't load since that's a DMA thing?
> > > > > > > > > 
> > > > > > > > > Bjorn/Srinath, any input here? This is a regression that 
> > > > > > > > > prevents wifi
> > > > > > > > > from working on a pretty standard laptop. It'd suck to have 
> > > > > > > > > this be in
> > > > > > > > > -rc1. Seems like the trivial fix would be:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > > > > > > index b0002daa50f3..ffbe11dbdd61 100644
> > > > > > > > > --- a/drivers/pci/pci.c
> > > > > > > > > +++ b/drivers/pci/pci.c
> > > > > > > > > @@ -1394,7 +1394,7 @@ static int 
> > > > > > > > > pci_enable_device_flags(struct pci_dev *dev, unsigned long 
> > > > > > > > > flags)
> > > > > > > > > return 0;   /* already enabled */
> > > > > > > > > 
> > > > > > > > > bridge = pci_upstream_bridge(dev);
> > > > > > > > > -   if (bridge && !pci_is_enabled(bridge))
> > > > > > > > > +   if (bridge)
> > > > > > 
> > > > > > With this change and keeping "mutex_lock(_bridge_mutex);" in
> > > > > > pci_enable_bridge functoin will causes a nexted lock.
> > > > > 
> > > > > Took a look, and looks like you are right. That code looks like a 
> > > > > mess,
> > > > > fwiw.
> > > > > 
> > > > > I'd strongly suggest that the bad commit is reverted until a proper
> > > > > solution is found, since the simple one-liner could potentially
> > > > > introduce a deadlock with your patch applied.
> > > > 
> > > > BTW, your patch looks pretty bad too, introducing a random mutex
> > > > deep on code that can be recursive. Why isn't this check in
> > > > pci_enable_device_flags() enough to prevent double-enable of
> > > > an upstream bridge?
> > > > 
> > > > if (atomic_inc_return(>enable_cnt) > 1)
> > > > return 0;   /* already enabled */
> > > > 
> > > 
> > > This check only to verify device enable not for the bus master check.
> > > But device enable function calls the bridge enable if it has the bridge.
> > > Bridge enable function enables both device and bus master.
> > > 
> > > Here the issue might be because, bridge of endpoint has already set
> > > device enable without set bus master in some other context. which is
> > > wrong.
> > > because all bridges should enable with bridge_enable function only.
> > > So we see the problem In this context, because "if (bridge &&
> > > !pci_is_enabled(bridge))" check stops bridge enable which intern stops
> > > bus master.
> > > pci_enable_bridge function always makes sure that both device and bus
> > > master are enabled in any case. If pci_enable_bridge function is not
> > > called means, that bridge is already has device enable flag set. which
> > > is not from pci_enable_bridge function.
> > 
> > In any case, your patch introduces a regression on systems. Please get
> > it reverted now, and then you can come up with a new approach to fix the
> > double enable of the upstream bridge.
> 
> Who's sending in the revert? I can certainly do it if no one else does,
> but it needs to be done.
> 
> I'm not seeing any patches coming out of 

Re: iwlwifi firmware load broken in current -git

[Jens Axboe]

On 09/14/2017 02:36 PM, Jens Axboe wrote:
> On 09/14/2017 02:04 PM, Srinath Mannam wrote:
>> Hi Jens Axboe,
>>
>>
>> On Thu, Sep 14, 2017 at 11:14 PM, Jens Axboe  wrote:
>>> On 09/14/2017 11:35 AM, Jens Axboe wrote:
 On 09/14/2017 11:28 AM, Srinath Mannam wrote:
> Hi Bjorn,
>
> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe  wrote:
>>
>> On 09/14/2017 11:11 AM, Bjorn Helgaas wrote:
>>> [+cc linux-pci]
>>>
>>> On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe  wrote:
 On 09/12/2017 02:04 PM, Johannes Berg wrote:
> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
>
>> CC'ing the guilty part and Bjorn. I'm assuming it's the
>> pci_is_enabled() check, since the rest of the patch shouldn't have
>> functional changes.
>
> and pci_enable_bridge() already checks if it's already enabled, but
> still enables mastering in that case if it isn't:
>
> static void pci_enable_bridge(struct pci_dev *dev)
> {
> [...]
> if (pci_is_enabled(dev)) {
> if (!dev->is_busmaster)
> pci_set_master(dev);
> return;
> }
>
> so I guess due to the new check we end up with mastering disabled, and
> thus the firmware can't load since that's a DMA thing?

 Bjorn/Srinath, any input here? This is a regression that prevents wifi
 from working on a pretty standard laptop. It'd suck to have this be in
 -rc1. Seems like the trivial fix would be:


 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
 index b0002daa50f3..ffbe11dbdd61 100644
 --- a/drivers/pci/pci.c
 +++ b/drivers/pci/pci.c
 @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct 
 pci_dev *dev, unsigned long flags)
 return 0;   /* already enabled */

 bridge = pci_upstream_bridge(dev);
 -   if (bridge && !pci_is_enabled(bridge))
 +   if (bridge)
> With this change and keeping "mutex_lock(_bridge_mutex);" in
> pci_enable_bridge functoin will causes a nexted lock.

 Took a look, and looks like you are right. That code looks like a mess,
 fwiw.

 I'd strongly suggest that the bad commit is reverted until a proper
 solution is found, since the simple one-liner could potentially
 introduce a deadlock with your patch applied.
>>>
>>> BTW, your patch looks pretty bad too, introducing a random mutex
>>> deep on code that can be recursive. Why isn't this check in
>>> pci_enable_device_flags() enough to prevent double-enable of
>>> an upstream bridge?
>>>
>>> if (atomic_inc_return(>enable_cnt) > 1)
>>> return 0;   /* already enabled */
>>>
>> This check only to verify device enable not for the bus master check.
>> But device enable function calls the bridge enable if it has the bridge.
>> Bridge enable function enables both device and bus master.
>>
>> Here the issue might be because, bridge of endpoint has already set
>> device enable without set bus master in some other context. which is
>> wrong.
>> because all bridges should enable with bridge_enable function only.
>> So we see the problem In this context, because "if (bridge &&
>> !pci_is_enabled(bridge))" check stops bridge enable which intern stops
>> bus master.
>> pci_enable_bridge function always makes sure that both device and bus
>> master are enabled in any case. If pci_enable_bridge function is not
>> called means, that bridge is already has device enable flag set. which
>> is not from pci_enable_bridge function.
> 
> In any case, your patch introduces a regression on systems. Please get
> it reverted now, and then you can come up with a new approach to fix the
> double enable of the upstream bridge.

Who's sending in the revert? I can certainly do it if no one else does,
but it needs to be done.

I'm not seeing any patches coming out of Srinath to fix up the
situation, so we should revert the broken patch until a better solution
exists.

-- 
Jens Axboe

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/15/2017 12:12 PM, Zwindl wrote:

Thanks for your patient and advice, I'll keep that in mind.
I do want help, and I got 1 day to build the system, but I can't recall how to 
compile it, The last time I compile kernel is 2013, so, maybe I'll ask you so 
many stupid questions during the build time.

ZWindL


Building a new kernel is not difficult. In an average week, I make at least 10 
new kernels. Many of them are done on slow machines that take many hours. At 
least, your i5 CPU should do it in less that one hour.


Step 1: Download the kernel sources using

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

If your system complains that the git command is unknown, then you will need to 
install it with your package manager (pacman?).


Step 2: "cd  linux" and copy the latest /boot/config-. to the linux source 
directory as ".config". Edit .config, find the line that says
"# CONFIG_LOCALVERSION_AUTO is not set", and change the line to read 
"CONFIG_LOCALVERSION_AUTO=y".


Step 3: Build and install the latest version using

make -j9
sudo make modules_install install

You will need to answer some configuration questions at the start of the first 
make line. Answer with the default value, i.e. just use an ENTER. When the build 
is complete, reboot. Grub should show an entry for something like 
v4.13-12084-ged43e4d190d0. The numbers after the 4.13 will likely be different, 
but the form will match. Check that the new kernel still has the fault. If not, 
it has been fixed and we do not need to find it.


It the problem is still in the latest version of the kernel, then we start the 
bisection with the following:


git bisect start
git bisect bad v4.13
git bisect good v4.12

At this point, git will report the number of revisions to test, the likely 
number of tries, and the SHA hash for the new kernel. Record the first 7 digits 
of the hash, and repeat the make commands above. After the build is complete, 
reboot into the kernel with the hash in the version name and test. Then enter 
the command "git bisect xxx", where xxx is good or bad depending on the test. A 
new trial will be generated by bisecting the appropriate half of the commits. 
Record its hash and redo the build. Repeat until git tells you the bad commit.


This process will generate a number of kernels that will take quite a bit of 
disk space. If you run short, you can delete kernels that have already been 
tested from /boot. You should also delete the corresponding modules from 
/lib/modules.


Good luck,

Larry

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/15/2017 05:10 AM, Zwindl wrote:



 Original Message 
Subject: Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13
Local Time: 14 September 2017 6:05 PM
UTC Time: 14 September 2017 18:05
From: larry.fin...@lwfinger.net
To: Zwindl , linux-wireless@vger.kernel.org 

chaoming...@realsil.com.cn , kv...@codeaurora.org 
, pks...@realtek.com , 
johannes.b...@intel.com , gre...@linuxfoundation.org 
, net...@vger.kernel.org , 
linux-ker...@vger.kernel.org 


On 09/14/2017 08:30 AM, Zwindl wrote:
> Dear developers:
> I"m using Arch Linux with testing enabled, the current kernel version and
> details are
> `Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64
> GNU/Linux`.
> The wireless card can"t work properly from the kernel 4.13. Here"s the log(in
> attachment) when NetworkManager trying to connect my wifi which is named as
> "TP", my mac addr hided as xx:xx:xx:xx:xx.
> What should I provide to help to debug?
> ZWindL.

The BUG-ON arises in __intel_map_single() due to dir (for direction of DMA)
equal to DMA_NONE (3). When rtl8192ee calls pci_map_single(), it uses
PCI_DMA_TODEVICE (1). I followed the calling sequence through the entire chain,
and none of the routines made any changes to "dir", other that changing the type
from int to enum dma_data_direction. That would not have changed a 1 to a 3.

I built a 4.13.2 system. The problem does not happen here. At this point, the
system has been up for about two hours. I did discover a small memory leak
associated with firmware loading, but that should not have caused the problem.
Nonetheless, I will be sending a patch to fix that problem.

I will continue testing, although I doubt that the problem will happen here.

How long had your system been up when the problem occurred? Your dmesg fragment
did not show any times. What kernels have you tried besides 4.13.2?

Larry

Oh, sorry, the original log is from `journalctl`.
Here's the `dmesg` prints(error.txt). I can't determine which part is related, 
so I paste all of it. I've tried 4.12.X(no issue), 4.13.1(issue), 4.13.2(issue).

ZWindL


The output of dmesg is a lot more instructive than that of journalctl. I now 
know exactly the location that triggered the WARNING. I still do not understand 
it. In fact, it is likely a regression in kernel 4.13 that does not affect my 
Toshiba laptop, nor a Lenovo machine I have, but does affect your Lenovo laptop.


Is it possible for you to install the mainline source from vger.kernel.org using 
git and bisect the issue? It will take quite a bit of time, but it is likely the 
only way to find the offending change. If you are willing to try this, I will 
send you reasonably complete instructions.


By the way, it is usually better to load the dmesg output into a pastebin site 
and post the link. Sending the entire file to a list makes a lot of people 
receive a lot of data for which they have no interest.


Larry

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 09:27 -0500, Denis Kenzior wrote:

> > > However, you're not answering my question...
> > 
> > Which was?
> 
> So if we issue CMD_CONNECT with a PREV_BSSID, does/should OPERSTATE 
> still stay UP?

It's difficult to do, but from a higher-layer POV I'd argue that it
should? I'd basically argue that it's no different from 802.1X
reauthentication, and the operstate docs say:

-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
 fails

> > We had intended to have NL80211_CMD_ROAM to make that decision
> > once,
> > but never really used it for that... I think it could be
> > implemented
> > but I don't really know how well drivers were to support it.
> 
> I think it would be nice.  Worst case a driver won't implement it,
> but we can use FT on those that do.

I have no idea how you'd ask them to do FT or just normal reassoc? I
guess they don't really care as long as the supplicant is in the host.

johannes

Re: rtlwifi/rtl8188ee baseband config explanation request

[Larry Finger]

On 09/15/2017 01:26 AM, Farhan Khan wrote:

Thank you for your prompt response.

I am trying to write a FreeBSD port of this driver. The structures of
the two drivers are significantly different, so it is not a trivial
exercise.

The FreeBSD driver also has a similar block of code that writes over an
array of data using an array of registers, and this should be easy to
re-create. But I do not see the equivalent of phy_config_bb_with_pghdr()
anywhere. I do not know if I need to maintain the order for any reason.

I attempted to reach out to Realtek through multiple mediums but did not
receive any replies. Ultimately, I may end up re-playing the same bits
without understanding what is happening.


You should have stated your purpose at the start.

Those sections are loading data for the firmware to use. As you probably are not 
writing your own firmware, and not doing your own calibration, then you should 
just copy all the code that touches the data in the file table.c. The firmware 
does not care whether the host is Linux or FreeBSD. It still has to do that same 
operations on the radio, and this is the data it needs.


As I said in my initial response, I think the PHY register data needs to be 
written before the AGC data as the latter is being written into a buffer that is 
not directly accessible from the host, which means some previous step has set up 
that transfer. As we do not know what that was, you likely need to do everything 
in the same order.


Larry

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,


And AFAIK the kernel generates a disconnected event as soon as we
send a CMD_AUTHENTICATE, so not sure how you envision 'your'
preauthentication working...


That's what I was trying to say - it doesn't. A few years ago we tried
to support that but it's not really possible to do well.


Okay, *now* I'm with you :)




However, you're not answering my question...


Which was?


So if we issue CMD_CONNECT with a PREV_BSSID, does/should OPERSTATE 
still stay UP?



One can use regular roaming on a full mac but not FT.


We had intended to have NL80211_CMD_ROAM to make that decision once,
but never really used it for that... I think it could be implemented
but I don't really know how well drivers were to support it.


I think it would be nice.  Worst case a driver won't implement it, but 
we can use FT on those that do.


Regards,
-Denis

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 08:50 -0500, Denis Kenzior wrote:

> > I thought you meant sending an 802.11 auth frame to the new AP
> > before breaking the connection to the old AP.
> > 
> 
> I mean 802.11-2012 Section 11.5.9.2 type preauthentication.

Yeha, OK.

> And AFAIK the kernel generates a disconnected event as soon as we
> send a CMD_AUTHENTICATE, so not sure how you envision 'your'
> preauthentication working...

That's what I was trying to say - it doesn't. A few years ago we tried
to support that but it's not really possible to do well.

> However, you're not answering my question...

Which was?

> > Well, with full MAC devices you should let the device decide on the
> > BSS?
> > 
> 
> Why? So we can deal with the various ways a vendor firmware can
> screw up?  Besides, you have an asymmetry in the kernel API. 

:)

> One can use regular roaming on a full mac but not FT.

We had intended to have NL80211_CMD_ROAM to make that decision once,
but never really used it for that... I think it could be implemented
but I don't really know how well drivers were to support it.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/15/2017 08:29 AM, Johannes Berg wrote:

On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:


E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
issue a CMD_CONNECT to AP2?


That's not something you can do with full-MAC cards?


Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So
we should get these just like regular PAE frames.  But forget
pre-authentication, one can still force a roam between BSSes within
the same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's
what the docs say ;)


Oh, you meant that kind of pre-authentication :-)

I thought you meant sending an 802.11 auth frame to the new AP before
breaking the connection to the old AP.



I mean 802.11-2012 Section 11.5.9.2 type preauthentication.

And AFAIK the kernel generates a disconnected event as soon as we send a 
CMD_AUTHENTICATE, so not sure how you envision 'your' preauthentication 
working...


However, you're not answering my question...


And even mac80211 doesn't really support pre-authentication (unless
you mean over-the-DS)




There's only one kind of preauthentication? Are you confusing this
with FT?


No, see above.


We use FT-over-Air just fine on mac80211 and on real hardware.  We
even have an autotest for this based on mac80211_hwsim.  FT-over-DS
should work as well.

Full macs don't support FT due to lack of
CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?


Well, with full MAC devices you should let the device decide on the
BSS?



Why? So we can deal with the various ways a vendor firmware can screw 
up?  Besides, you have an asymmetry in the kernel API.  One can use 
regular roaming on a full mac but not FT.


Regards,
-Denis

Re: [PATCH] Revert "PCI: Avoid race while enabling upstream bridges"

[Konstantin Khlebnikov]

On 15.09.2017 10:23, Bjorn Helgaas wrote:

This reverts commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9.

Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
gen4:

   iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed 
with error -2
   iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed 
with error -2
   iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed 
with error -2
   iwlwifi :04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
   iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
   ...
   iwlwifi :04:00.0: Failed to load firmware chunk!
   iwlwifi :04:00.0: Could not load the [0] uCode section
   iwlwifi :04:00.0: Failed to start INIT ucode: -110
   iwlwifi :04:00.0: Failed to run INIT ucode: -110

He bisected it to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream
bridges").  Revert that commit to fix the regression.


I've found this too. Bug in fast-path: reverting last hunk is enough
http://lkml.kernel.org/r/150547971091.977464.16294045866179907260.stgit@buzz



Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6...@kernel.dk
Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
Signed-off-by: Bjorn Helgaas 
CC: Srinath Mannam 
CC: Jens Axboe 
CC: Luca Coelho 
CC: Johannes Berg 
CC: Emmanuel Grumbach 
---
  drivers/pci/pci.c |   13 ++---
  1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0002daa50f3..6078dfc11b11 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -52,7 +52,6 @@ static void pci_pme_list_scan(struct work_struct *work);
  static LIST_HEAD(pci_pme_list);
  static DEFINE_MUTEX(pci_pme_list_mutex);
  static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan);
-static DEFINE_MUTEX(pci_bridge_mutex);
  
  struct pci_pme_device {

struct list_head list;
@@ -1351,16 +1350,10 @@ static void pci_enable_bridge(struct pci_dev *dev)
if (bridge)
pci_enable_bridge(bridge);
  
-	/*

-* Hold pci_bridge_mutex to prevent a race when enabling two
-* devices below the bridge simultaneously.  The race may cause a
-* PCI_COMMAND_MEMORY update to be lost (see changelog).
-*/
-   mutex_lock(_bridge_mutex);
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
-   goto end;
+   return;
}
  
  	retval = pci_enable_device(dev);

@@ -1368,8 +1361,6 @@ static void pci_enable_bridge(struct pci_dev *dev)
dev_err(>dev, "Error enabling bridge (%d), continuing\n",
retval);
pci_set_master(dev);
-end:
-   mutex_unlock(_bridge_mutex);
  }
  
  static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)

@@ -1394,7 +1385,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
return 0;   /* already enabled */
  
  	bridge = pci_upstream_bridge(dev);

-   if (bridge && !pci_is_enabled(bridge))
+   if (bridge)
pci_enable_bridge(bridge);
  
  	/* only skip sriov related */

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Fri, 2017-09-15 at 07:50 -0500, Denis Kenzior wrote:

> > > E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and
> > > issue a CMD_CONNECT to AP2?
> > 
> > That's not something you can do with full-MAC cards?
> 
> Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So
> we should get these just like regular PAE frames.  But forget 
> pre-authentication, one can still force a roam between BSSes within
> the same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's
> what the docs say ;)

Oh, you meant that kind of pre-authentication :-)

I thought you meant sending an 802.11 auth frame to the new AP before
breaking the connection to the old AP.

> > And even mac80211 doesn't really support pre-authentication (unless
> > you mean over-the-DS)

> 
> There's only one kind of preauthentication? Are you confusing this
> with FT?

No, see above.

> We use FT-over-Air just fine on mac80211 and on real hardware.  We 
> even have an autotest for this based on mac80211_hwsim.  FT-over-DS 
> should work as well.
> 
> Full macs don't support FT due to lack of 
> CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?

Well, with full MAC devices you should let the device decide on the
BSS?

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Denis Kenzior]

Hi Johannes,

On 09/15/2017 02:19 AM, Johannes Berg wrote:

On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:


If you want roaming to keep oper state UP in all cases, then
yes.  Does this work on full mac cards as well?


I don't see why not.


E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue
a CMD_CONNECT to AP2?


That's not something you can do with full-MAC cards?


Err, why not?  Pre-Authentication runs over a 0x88c7 protocol.  So we 
should get these just like regular PAE frames.  But forget 
pre-authentication, one can still force a roam between BSSes within the 
same ESS by specifying NL80211_ATTR_PREV_BSSID.  At least that's what 
the docs say ;)




And even mac80211 doesn't really support pre-authentication (unless you
mean over-the-DS)



There's only one kind of preauthentication?  Are you confusing this with 
FT?  We use FT-over-Air just fine on mac80211 and on real hardware.  We 
even have an autotest for this based on mac80211_hwsim.  FT-over-DS 
should work as well.


Full macs don't support FT due to lack of 
CMD_ASSOCIATE/CMD_AUTHENTICATE.  Can we fix that btw?


Regards,
-Denis

[PATCH 03/10] iwlwifi: fix wrong struct for a000 device

[Luca Coelho]

From: Oren Givon 

The PCI ID (0x2720, 0x0070) was set with the config struct
iwla000_2ax_cfg_hr instead of iwla000_2ac_cfg_hr_cdb.

Fixes: 175b87c69253 ("iwlwifi: add the new a000_2ax series")
Signed-off-by: Oren Givon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 858765fed8f8..3416c6155996 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -576,7 +576,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x2720, 0x, iwla000_2ax_cfg_hr)},
{IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
{IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
{IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
 #endif /* CONFIG_IWLMVM */
 
-- 
2.14.1

[PATCH 00/10] iwlwifi: updates intended for v4.15 2017-09-15

[Luca Coelho]

From: Luca Coelho 

Hi,

Here's my first set of patches intended for 4.15.  Nothing major here,
these are the changes:

* Cleanups: - remove an unused value that we read from the NVM;
- remove link quality measurement code that was never used;
* One FW command API update;
* A fix and an addition for PCI devices for the A000 family;
* Tiny refactor of ref/unref code used by runtime-PM;
* Some debugging improvements;
* Implementation of a more flexible way to define command queue sizes;

As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.

Please review.

Cheers,
Luca.


Chaya Rachel Ivgi (1):
  iwlwifi: remove redundant reading from NVM file

David Spinadel (1):
  iwlwifi: mvm: Add new quota command API

Emmanuel Grumbach (2):
  iwlwifi: mvm: remove support for Link Quality Measurements
  iwlwifi: mvm: support firmware debug trigger on frame reorder timeout

Ilan Peer (1):
  iwlwifi: Add few debug prints to the WRT dump flow

Liad Kaufman (1):
  iwlwifi: mvm: add dbgfs entry for fw info

Luca Coelho (1):
  iwlwifi: trans: move ref/unref code to the common part of the
transport

Oren Givon (2):
  iwlwifi: fix wrong struct for a000 device
  iwlwifi: add a new a000 device

Shahar S Matityahu (1):
  iwlwifi: pcie: dynamic Tx command queue size

 drivers/net/wireless/intel/iwlwifi/cfg/a000.c  |  3 +-
 .../net/wireless/intel/iwlwifi/fw/api/binding.h| 41 -
 .../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h| 67 ---
 drivers/net/wireless/intel/iwlwifi/fw/dbg.c| 15 
 drivers/net/wireless/intel/iwlwifi/fw/file.h   |  3 +
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|  3 +
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c |  7 --
 drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 16 
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 14 +---
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 16 ++--
 .../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c   | 76 -
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c   | 32 
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 38 +
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   | 45 +++---
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |  2 -
 drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 59 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |  5 ++
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 96 ++
 .../net/wireless/intel/iwlwifi/pcie/ctxt-info.c|  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  |  3 +-
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h |  3 +
 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c  |  8 +-
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c   | 23 +-
 24 files changed, 255 insertions(+), 323 deletions(-)

-- 
2.14.1

[PATCH 08/10] iwlwifi: Add few debug prints to the WRT dump flow

[Luca Coelho]

From: Ilan Peer 

This would enable to better catch timing issues with
cases that WRT dump takes too much time.

Signed-off-by: Ilan Peer 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c 
b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index 6afc7a799892..f7eab03937f2 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -93,6 +93,8 @@ static void iwl_read_radio_regs(struct iwl_fw_runtime *fwrt,
unsigned long flags;
int i;
 
+   IWL_DEBUG_INFO(fwrt, "WRT radio registers dump\n");
+
if (!iwl_trans_grab_nic_access(fwrt->trans, ))
return;
 
@@ -233,6 +235,8 @@ static void iwl_fw_dump_fifos(struct iwl_fw_runtime *fwrt,
unsigned long flags;
int i, j;
 
+   IWL_DEBUG_INFO(fwrt, "WRT FIFO dump\n");
+
if (!iwl_trans_grab_nic_access(fwrt->trans, ))
return;
 
@@ -476,6 +480,8 @@ static void iwl_dump_prph(struct iwl_trans *trans,
unsigned long flags;
u32 i;
 
+   IWL_DEBUG_INFO(trans, "WRT PRPH dump\n");
+
if (!iwl_trans_grab_nic_access(trans, ))
return;
 
@@ -559,6 +565,8 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
bool monitor_dump_only = false;
int i;
 
+   IWL_DEBUG_INFO(fwrt, "WRT dump start\n");
+
/* there's no point in fw dump if the bus is dead */
if (test_bit(STATUS_TRANS_DEAD, >trans->status)) {
IWL_ERR(fwrt, "Skip fw error dump since bus is dead\n");
@@ -816,6 +824,9 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
dump_mem->type = fw_dbg_mem[i].data_type;
dump_mem->offset = cpu_to_le32(ofs);
 
+   IWL_DEBUG_INFO(fwrt, "WRT memory dump. Type=%u\n",
+  dump_mem->type);
+
switch (dump_mem->type & cpu_to_le32(FW_DBG_MEM_TYPE_MASK)) {
case cpu_to_le32(FW_DBG_MEM_TYPE_REGULAR):
iwl_trans_read_mem_bytes(fwrt->trans, ofs,
@@ -841,6 +852,7 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
}
 
if (smem_len) {
+   IWL_DEBUG_INFO(fwrt, "WRT SMEM dump\n");
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_MEM);
dump_data->len = cpu_to_le32(smem_len + sizeof(*dump_mem));
dump_mem = (void *)dump_data->data;
@@ -853,6 +865,7 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
}
 
if (sram2_len) {
+   IWL_DEBUG_INFO(fwrt, "WRT SRAM dump\n");
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_MEM);
dump_data->len = cpu_to_le32(sram2_len + sizeof(*dump_mem));
dump_mem = (void *)dump_data->data;
@@ -868,6 +881,7 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
if (!fwrt->trans->cfg->gen2 &&
fwrt->fw->img[fwrt->cur_fw_img].paging_mem_size &&
fwrt->fw_paging_db[0].fw_paging_block) {
+   IWL_DEBUG_INFO(fwrt, "WRT paging dump\n");
for (i = 1; i < fwrt->num_of_paging_blk + 1; i++) {
struct iwl_fw_error_dump_paging *paging;
struct page *pages =
@@ -930,6 +944,7 @@ void iwl_fw_error_dump(struct iwl_fw_runtime *fwrt)
iwl_fw_free_dump_desc(fwrt);
fwrt->dump.trig = NULL;
clear_bit(IWL_FWRT_STATUS_DUMPING, >status);
+   IWL_DEBUG_INFO(fwrt, "WRT dump done\n");
 }
 IWL_EXPORT_SYMBOL(iwl_fw_error_dump);
 
-- 
2.14.1

[PATCH 10/10] iwlwifi: remove redundant reading from NVM file

[Luca Coelho]

From: Chaya Rachel Ivgi 

The driver reads xtal_calib from NVM file, but actually never uses it.
This is only used in dvm driver.

Signed-off-by: Chaya Rachel Ivgi 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index 3014beef4873..4574a126c1ae 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -89,10 +89,6 @@ enum wkp_nvm_offsets {
SKU = 2,
N_HW_ADDRS = 3,
NVM_CHANNELS = 0x1E0 - NVM_SW_SECTION,
-
-   /* NVM calibration section offset (in words) definitions */
-   NVM_CALIB_SECTION = 0x2B8,
-   XTAL_CALIB = 0x316 - NVM_CALIB_SECTION
 };
 
 enum ext_nvm_offsets {
@@ -748,9 +744,6 @@ iwl_parse_nvm_data(struct iwl_trans *trans, const struct 
iwl_cfg *cfg,
kfree(data);
return NULL;
}
-   /* in family 8000 Xtal calibration values moved to OTP */
-   data->xtal_calib[0] = *(nvm_calib + XTAL_CALIB);
-   data->xtal_calib[1] = *(nvm_calib + XTAL_CALIB + 1);
lar_enabled = true;
ch_section = _sw[NVM_CHANNELS];
} else {
-- 
2.14.1

[PATCH 07/10] iwlwifi: mvm: support firmware debug trigger on frame reorder timeout

[Luca Coelho]

From: Emmanuel Grumbach 

The trigger that collects data when a frame is released
because of the timer of the reordering buffer was not
implemented for 9000 devices.
Fix this.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 28 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  |  6 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c |  5 
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c  |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c| 25 
 5 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 8b4584541272..d7530474c1d3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -4186,31 +4186,6 @@ static void iwl_mvm_event_bar_rx_callback(struct iwl_mvm 
*mvm,
event->u.ba.ssn);
 }
 
-static void
-iwl_mvm_event_frame_timeout_callback(struct iwl_mvm *mvm,
-struct ieee80211_vif *vif,
-const struct ieee80211_event *event)
-{
-   struct iwl_fw_dbg_trigger_tlv *trig;
-   struct iwl_fw_dbg_trigger_ba *ba_trig;
-
-   if (!iwl_fw_dbg_trigger_enabled(mvm->fw, FW_DBG_TRIGGER_BA))
-   return;
-
-   trig = iwl_fw_dbg_get_trigger(mvm->fw, FW_DBG_TRIGGER_BA);
-   ba_trig = (void *)trig->data;
-   if (!iwl_fw_dbg_trigger_check_stop(>fwrt,
-  ieee80211_vif_to_wdev(vif), trig))
-   return;
-
-   if (!(le16_to_cpu(ba_trig->frame_timeout) & BIT(event->u.ba.tid)))
-   return;
-
-   iwl_fw_dbg_collect_trig(>fwrt, trig,
-   "Frame from %pM timed out, tid %d",
-   event->u.ba.sta->addr, event->u.ba.tid);
-}
-
 static void iwl_mvm_mac_event_callback(struct ieee80211_hw *hw,
   struct ieee80211_vif *vif,
   const struct ieee80211_event *event)
@@ -4225,7 +4200,8 @@ static void iwl_mvm_mac_event_callback(struct 
ieee80211_hw *hw,
iwl_mvm_event_bar_rx_callback(mvm, vif, event);
break;
case BA_FRAME_TIMEOUT:
-   iwl_mvm_event_frame_timeout_callback(mvm, vif, event);
+   iwl_mvm_event_frame_timeout_callback(mvm, vif, event->u.ba.sta,
+event->u.ba.tid);
break;
default:
break;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h 
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index ec2cf248990b..e8be5104b909 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -586,6 +586,7 @@ enum iwl_mvm_tdls_cs_state {
  * @queue: queue of this reorder buffer
  * @last_amsdu: track last ASMDU SN for duplication detection
  * @last_sub_index: track ASMDU sub frame index for duplication detection
+ * @tid: the tid
  * @entries: list of skbs stored
  * @reorder_time: time the packet was stored in the reorder buffer
  * @reorder_timer: timer for frames are in the reorder buffer. For AMSDU
@@ -603,6 +604,7 @@ struct iwl_mvm_reorder_buffer {
int queue;
u16 last_amsdu;
u8 last_sub_index;
+   u8 tid;
struct sk_buff_head entries[IEEE80211_MAX_AMPDU_BUF];
unsigned long reorder_time[IEEE80211_MAX_AMPDU_BUF];
struct timer_list reorder_timer;
@@ -1839,6 +1841,10 @@ unsigned int iwl_mvm_get_wd_timeout(struct iwl_mvm *mvm,
bool tdls, bool cmd_q);
 void iwl_mvm_connection_loss(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
 const char *errmsg);
+void iwl_mvm_event_frame_timeout_callback(struct iwl_mvm *mvm,
+ struct ieee80211_vif *vif,
+ const struct ieee80211_sta *sta,
+ u16 tid);
 
 int iwl_mvm_sar_select_profile(struct iwl_mvm *mvm, int prof_a, int prof_b);
 int iwl_mvm_get_sar_geo_profile(struct iwl_mvm *mvm);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 67ffd9774712..a0b406e68d55 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -492,13 +492,18 @@ void iwl_mvm_reorder_timer_expired(unsigned long data)
 
if (expired) {
struct ieee80211_sta *sta;
+   struct iwl_mvm_sta *mvmsta;
 
rcu_read_lock();
sta = rcu_dereference(buf->mvm->fw_id_to_mac_id[buf->sta_id]);
+   mvmsta = 

[PATCH 09/10] iwlwifi: pcie: dynamic Tx command queue size

[Luca Coelho]

From: Shahar S Matityahu 

Devices in the A000 family can use a different size for the command queue.
To allow this, make the command queue size configurable and set the size
for A000 devices to 32.

Signed-off-by: Shahar S Matityahu 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/cfg/a000.c  |  3 ++-
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|  3 +++
 .../net/wireless/intel/iwlwifi/pcie/ctxt-info.c|  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h |  3 +++
 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c  |  8 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c   | 23 --
 6 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c 
b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
index 76ba1f8bc72f..ed8bccd228f8 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
@@ -134,7 +134,8 @@ static const struct iwl_ht_params iwl_a000_ht_params = {
.rf_id = true,  \
.gen2 = true,   \
.ext_nvm = true,\
-   .dbgc_supported = true
+   .dbgc_supported = true, \
+   .tx_cmd_queue_size = 32
 
 const struct iwl_cfg iwla000_2ac_cfg_hr = {
.name = "Intel(R) Dual Band Wireless AC a000",
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-config.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
index 3e057b539d5b..b9f3b350fe34 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
@@ -321,6 +321,8 @@ struct iwl_pwr_tx_backoff {
  * @gen2: a000 and on transport operation
  * @cdb: CDB support
  * @ext_nvm: extended NVM format
+ * @tx_cmd_queue_size: size of the cmd queue. If zero, use the same value as
+ * the regular queues
  *
  * We enable the driver to be backward compatible wrt. hardware features.
  * API differences in uCode shouldn't be handled here but through TLVs
@@ -371,6 +373,7 @@ struct iwl_cfg {
cdb:1,
ext_nvm:1,
dbgc_supported:1;
+   u16 tx_cmd_queue_size;
u8 valid_tx_ant;
u8 valid_rx_ant;
u8 non_shared_ant;
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c
index 3fc4343581ee..5ef216f3a60b 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c
@@ -244,7 +244,7 @@ int iwl_pcie_ctxt_info_init(struct iwl_trans *trans,
ctxt_info->hcmd_cfg.cmd_queue_addr =
cpu_to_le64(trans_pcie->txq[trans_pcie->cmd_queue]->dma_addr);
ctxt_info->hcmd_cfg.cmd_queue_size =
-   TFD_QUEUE_CB_SIZE(TFD_CMD_SLOTS);
+   TFD_QUEUE_CB_SIZE(trans_pcie->tx_cmd_queue_size);
 
/* allocate ucode sections in dram and set addresses */
ret = iwl_pcie_ctxt_info_init_fw_sec(trans, fw, ctxt_info);
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h 
b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index 79020cf8c79c..5647182e1b46 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -383,6 +383,7 @@ struct iwl_self_init_dram {
  * @hw_init_mask: initial unmasked hw causes
  * @fh_mask: current unmasked fh causes
  * @hw_mask: current unmasked hw causes
+ * @tx_cmd_queue_size: the size of the tx command queue
  */
 struct iwl_trans_pcie {
struct iwl_rxq *rxq;
@@ -463,6 +464,7 @@ struct iwl_trans_pcie {
u32 fh_mask;
u32 hw_mask;
cpumask_t affinity_mask[IWL_MAX_RX_HW_QUEUES];
+   u16 tx_cmd_queue_size;
 };
 
 static inline struct iwl_trans_pcie *
@@ -534,6 +536,7 @@ void iwl_pcie_hcmd_complete(struct iwl_trans *trans,
 void iwl_trans_pcie_reclaim(struct iwl_trans *trans, int txq_id, int ssn,
struct sk_buff_head *skbs);
 void iwl_trans_pcie_tx_reset(struct iwl_trans *trans);
+void iwl_pcie_set_tx_cmd_queue_size(struct iwl_trans *trans);
 
 static inline u16 iwl_pcie_tfd_tb_get_len(struct iwl_trans *trans, void *_tfd,
  u8 idx)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
index d74613fcb756..79e4c73a9709 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
@@ -1160,6 +1160,8 @@ int iwl_pcie_gen2_tx_init(struct iwl_trans *trans)
struct iwl_txq *cmd_queue;
int txq_id = trans_pcie->cmd_queue, ret;
 
+   iwl_pcie_set_tx_cmd_queue_size(trans);
+
/* alloc and init the command queue */

[PATCH 05/10] iwlwifi: mvm: Add new quota command API

[Luca Coelho]

From: David Spinadel 

New quota command adds a field indicating low latency
direction per quota.

A TLV API bit was added to indicate the new API.

Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
---
 .../net/wireless/intel/iwlwifi/fw/api/binding.h| 41 +--
 drivers/net/wireless/intel/iwlwifi/fw/file.h   |  3 ++
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 16 +++---
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   | 27 ++
 drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 59 +-
 5 files changed, 113 insertions(+), 33 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/binding.h 
b/drivers/net/wireless/intel/iwlwifi/fw/api/binding.h
index d2717fafdf5b..570f19026c91 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/binding.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/binding.h
@@ -116,14 +116,14 @@ struct iwl_binding_cmd {
 #define IWL_MVM_MAX_QUOTA 128
 
 /**
- * struct iwl_time_quota_data - configuration of time quota per binding
+ * struct iwl_time_quota_data_v1 - configuration of time quota per binding
  * @id_and_color: ID and color of the relevant Binding,
  *  iwl_ctxt_id_and_color
  * @quota: absolute time quota in TU. The scheduler will try to divide the
  * remainig quota (after Time Events) according to this quota.
  * @max_duration: max uninterrupted context duration in TU
  */
-struct iwl_time_quota_data {
+struct iwl_time_quota_data_v1 {
__le32 id_and_color;
__le32 quota;
__le32 max_duration;
@@ -137,8 +137,43 @@ struct iwl_time_quota_data {
  * essentially zero.
  * On CDB the fourth one is a regular binding.
  */
+struct iwl_time_quota_cmd_v1 {
+   struct iwl_time_quota_data_v1 quotas[MAX_BINDINGS];
+} __packed; /* TIME_QUOTA_ALLOCATION_CMD_API_S_VER_1 */
+
+enum iwl_quota_low_latency {
+   IWL_QUOTA_LOW_LATENCY_NONE = 0,
+   IWL_QUOTA_LOW_LATENCY_TX = BIT(0),
+   IWL_QUOTA_LOW_LATENCY_RX = BIT(1),
+   IWL_QUOTA_LOW_LATENCY_TX_RX =
+   IWL_QUOTA_LOW_LATENCY_TX | IWL_QUOTA_LOW_LATENCY_RX,
+};
+
+/**
+ * struct iwl_time_quota_data - configuration of time quota per binding
+ * @id_and_color: ID and color of the relevant Binding.
+ * @quota: absolute time quota in TU. The scheduler will try to divide the
+ * remainig quota (after Time Events) according to this quota.
+ * @max_duration: max uninterrupted context duration in TU
+ * @low_latency: low latency status,  iwl_quota_low_latency
+ */
+struct iwl_time_quota_data {
+   __le32 id_and_color;
+   __le32 quota;
+   __le32 max_duration;
+   __le32 low_latency;
+} __packed; /* TIME_QUOTA_DATA_API_S_VER_2 */
+
+/**
+ * struct iwl_time_quota_cmd - configuration of time quota between bindings
+ * ( TIME_QUOTA_CMD = 0x2c )
+ * Note: on non-CDB the fourth one is the auxilary mac and is essentially zero.
+ * On CDB the fourth one is a regular binding.
+ *
+ * @quotas: allocations per binding
+ */
 struct iwl_time_quota_cmd {
struct iwl_time_quota_data quotas[MAX_BINDINGS];
-} __packed; /* TIME_QUOTA_ALLOCATION_CMD_API_S_VER_1 */
+} __packed; /* TIME_QUOTA_ALLOCATION_CMD_API_S_VER_2 */
 
 #endif /* __iwl_fw_api_binding_h__ */
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h 
b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 887f6d8fc8a7..7d794ad53e4b 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -248,6 +248,8 @@ typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
  * @IWL_UCODE_TLV_API_NEW_RX_STATS: should new RX STATISTICS API be used
  * @IWL_UCODE_TLV_API_ATS_COEX_EXTERNAL: the coex notification is enlared to
  * include information about ACL time sharing.
+ * @IWL_UCODE_TLV_API_QUOTA_LOW_LATENCY: Quota command includes a field
+ * indicating low latency direction.
  *
  * @NUM_IWL_UCODE_TLV_API: number of bits used
  */
@@ -265,6 +267,7 @@ enum iwl_ucode_tlv_api {
IWL_UCODE_TLV_API_NEW_BEACON_TEMPLATE   = (__force 
iwl_ucode_tlv_api_t)34,
IWL_UCODE_TLV_API_NEW_RX_STATS  = (__force 
iwl_ucode_tlv_api_t)35,
IWL_UCODE_TLV_API_COEX_ATS_EXTERNAL = (__force 
iwl_ucode_tlv_api_t)37,
+   IWL_UCODE_TLV_API_QUOTA_LOW_LATENCY = (__force 
iwl_ucode_tlv_api_t)38,
 
NUM_IWL_UCODE_TLV_API
 #ifdef __CHECKER__
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 5de19ea10575..c5ea3fad8002 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -664,6 +664,7 @@ static int iwl_mvm_d3_reprogram(struct iwl_mvm *mvm, struct 
ieee80211_vif *vif,
int ret, i;
struct iwl_binding_cmd binding_cmd = {};
struct iwl_time_quota_cmd quota_cmd = {};
+   struct iwl_time_quota_data *quota;
u32 status;
int size;
 
@@ -745,17 

[PATCH 06/10] iwlwifi: mvm: remove support for Link Quality Measurements

[Luca Coelho]

From: Emmanuel Grumbach 

This was never used by any product. Remove it.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 .../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h| 67 ---
 .../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c   | 76 --
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 10 ---
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   | 12 
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |  2 -
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 71 
 6 files changed, 238 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h 
b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
index 39c89e85fd2f..ec42c84e5df2 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
@@ -67,79 +67,12 @@
  * enum iwl_mac_conf_subcmd_ids - mac configuration command IDs
  */
 enum iwl_mac_conf_subcmd_ids {
-   /**
-* @LINK_QUALITY_MEASUREMENT_CMD:  iwl_link_qual_msrmnt_cmd
-*/
-   LINK_QUALITY_MEASUREMENT_CMD = 0x1,
-
-   /**
-* @LINK_QUALITY_MEASUREMENT_COMPLETE_NOTIF:
-*  iwl_link_qual_msrmnt_notif
-*/
-   LINK_QUALITY_MEASUREMENT_COMPLETE_NOTIF = 0xFE,
-
/**
 * @CHANNEL_SWITCH_NOA_NOTIF:  iwl_channel_switch_noa_notif
 */
CHANNEL_SWITCH_NOA_NOTIF = 0xFF,
 };
 
-#define LQM_NUMBER_OF_STATIONS_IN_REPORT 16
-
-enum iwl_lqm_cmd_operatrions {
-   LQM_CMD_OPERATION_START_MEASUREMENT = 0x01,
-   LQM_CMD_OPERATION_STOP_MEASUREMENT = 0x02,
-};
-
-enum iwl_lqm_status {
-   LQM_STATUS_SUCCESS = 0,
-   LQM_STATUS_TIMEOUT = 1,
-   LQM_STATUS_ABORT = 2,
-};
-
-/**
- * struct iwl_link_qual_msrmnt_cmd - Link Quality Measurement command
- * @cmd_operation: command operation to be performed (start or stop)
- * as defined above.
- * @mac_id: MAC ID the measurement applies to.
- * @measurement_time: time of the total measurement to be performed, in uSec.
- * @timeout: maximum time allowed until a response is sent, in uSec.
- */
-struct iwl_link_qual_msrmnt_cmd {
-   __le32 cmd_operation;
-   __le32 mac_id;
-   __le32 measurement_time;
-   __le32 timeout;
-} __packed /* LQM_CMD_API_S_VER_1 */;
-
-/**
- * struct iwl_link_qual_msrmnt_notif - Link Quality Measurement notification
- *
- * @frequent_stations_air_time: an array containing the total air time
- * (in uSec) used by the most frequently transmitting stations.
- * @number_of_stations: the number of uniqe stations included in the array
- * (a number between 0 to 16)
- * @total_air_time_other_stations: the total air time (uSec) used by all the
- * stations which are not included in the above report.
- * @time_in_measurement_window: the total time in uSec in which a measurement
- * took place.
- * @tx_frame_dropped: the number of TX frames dropped due to retry limit during
- * measurement
- * @mac_id: MAC ID the measurement applies to.
- * @status: return status. may be one of the LQM_STATUS_* defined above.
- * @reserved: reserved.
- */
-struct iwl_link_qual_msrmnt_notif {
-   __le32 frequent_stations_air_time[LQM_NUMBER_OF_STATIONS_IN_REPORT];
-   __le32 number_of_stations;
-   __le32 total_air_time_other_stations;
-   __le32 time_in_measurement_window;
-   __le32 tx_frame_dropped;
-   __le32 mac_id;
-   __le32 status;
-   u8 reserved[12];
-} __packed; /* LQM_MEASUREMENT_COMPLETE_NTF_API_S_VER1 */
-
 /**
  * struct iwl_channel_switch_noa_notif - Channel switch NOA notification
  *
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
index 71a01df96f8b..4228fac77f41 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
@@ -1455,80 +1455,6 @@ static const char * const chanwidths[] = {
[NL80211_CHAN_WIDTH_160] = "vht160",
 };
 
-static bool iwl_mvm_lqm_notif_wait(struct iwl_notif_wait_data *notif_wait,
-  struct iwl_rx_packet *pkt, void *data)
-{
-   struct ieee80211_vif *vif = data;
-   struct iwl_mvm *mvm =
-   container_of(notif_wait, struct iwl_mvm, notif_wait);
-   struct iwl_link_qual_msrmnt_notif *report = (void *)pkt->data;
-   u32 num_of_stations = le32_to_cpu(report->number_of_stations);
-   int i;
-
-   IWL_INFO(mvm, "LQM report:\n");
-   IWL_INFO(mvm, "\tstatus: %d\n", report->status);
-   IWL_INFO(mvm, "\tmacID: %d\n", le32_to_cpu(report->mac_id));
-   IWL_INFO(mvm, "\ttx_frame_dropped: %d\n",
-le32_to_cpu(report->tx_frame_dropped));
-   IWL_INFO(mvm, "\ttime_in_measurement_window: %d us\n",
-le32_to_cpu(report->time_in_measurement_window));
-   IWL_INFO(mvm, 

[PATCH 04/10] iwlwifi: add a new a000 device

[Luca Coelho]

From: Oren Givon 

Add a new a000 device with PCI ID (0x2720, 0x0030).

Signed-off-by: Oren Givon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 3416c6155996..e0966f656376 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -577,6 +577,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
{IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
{IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)},
{IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
 #endif /* CONFIG_IWLMVM */
 
-- 
2.14.1

[PATCH 02/10] iwlwifi: trans: move ref/unref code to the common part of the transport

[Luca Coelho]

From: Luca Coelho 

De-inline iwl_trans_ref/unref and move it to common transport code
in preparation for more common code to come to these functions.

Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 16 
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 14 ++
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-trans.c
index 784bdd0ed233..7e9c924e1220 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.c
@@ -6,6 +6,7 @@
  * GPL LICENSE SUMMARY
  *
  * Copyright(c) 2015 Intel Mobile Communications GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of version 2 of the GNU General Public License as
@@ -31,6 +32,7 @@
  * BSD LICENSE
  *
  * Copyright(c) 2015 Intel Mobile Communications GmbH
+ * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -205,3 +207,17 @@ int iwl_cmd_groups_verify_sorted(const struct 
iwl_trans_config *trans)
return 0;
 }
 IWL_EXPORT_SYMBOL(iwl_cmd_groups_verify_sorted);
+
+void iwl_trans_ref(struct iwl_trans *trans)
+{
+   if (trans->ops->ref)
+   trans->ops->ref(trans);
+}
+IWL_EXPORT_SYMBOL(iwl_trans_ref);
+
+void iwl_trans_unref(struct iwl_trans *trans)
+{
+   if (trans->ops->unref)
+   trans->ops->unref(trans);
+}
+IWL_EXPORT_SYMBOL(iwl_trans_unref);
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index e90abbfba718..91ec077900f6 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@ -875,18 +875,6 @@ static inline int iwl_trans_d3_resume(struct iwl_trans 
*trans,
return trans->ops->d3_resume(trans, status, test, reset);
 }
 
-static inline void iwl_trans_ref(struct iwl_trans *trans)
-{
-   if (trans->ops->ref)
-   trans->ops->ref(trans);
-}
-
-static inline void iwl_trans_unref(struct iwl_trans *trans)
-{
-   if (trans->ops->unref)
-   trans->ops->unref(trans);
-}
-
 static inline int iwl_trans_suspend(struct iwl_trans *trans)
 {
if (!trans->ops->suspend)
@@ -1191,6 +1179,8 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,
  const struct iwl_cfg *cfg,
  const struct iwl_trans_ops *ops);
 void iwl_trans_free(struct iwl_trans *trans);
+void iwl_trans_ref(struct iwl_trans *trans);
+void iwl_trans_unref(struct iwl_trans *trans);
 
 /*
 * driver (transport) register/unregister functions
-- 
2.14.1

[PATCH 01/10] iwlwifi: mvm: add dbgfs entry for fw info

[Luca Coelho]

From: Liad Kaufman 

Add a dbgfs entry for an easy way during runtime to
check what FW file was loaded, and get some general
FW-related data.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
index e97904c2c4d4..2ff594f11259 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
@@ -660,6 +660,36 @@ iwl_dbgfs_bt_force_ant_write(struct iwl_mvm *mvm, char 
*buf,
return ret ?: count;
 }
 
+static ssize_t iwl_dbgfs_fw_ver_read(struct file *file, char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct iwl_mvm *mvm = file->private_data;
+   char *buff, *pos, *endpos;
+   static const size_t bufsz = 1024;
+   int ret;
+
+   buff = kmalloc(bufsz, GFP_KERNEL);
+   if (!buff)
+   return -ENOMEM;
+
+   pos = buff;
+   endpos = pos + bufsz;
+
+   pos += scnprintf(pos, endpos - pos, "FW prefix: %s\n",
+mvm->trans->cfg->fw_name_pre);
+   pos += scnprintf(pos, endpos - pos, "FW: %s\n",
+mvm->fwrt.fw->human_readable);
+   pos += scnprintf(pos, endpos - pos, "Device: %s\n",
+mvm->fwrt.trans->cfg->name);
+   pos += scnprintf(pos, endpos - pos, "Bus: %s\n",
+mvm->fwrt.dev->bus->name);
+
+   ret = simple_read_from_buffer(user_buf, count, ppos, buff, pos - buff);
+   kfree(buff);
+
+   return ret;
+}
+
 #define PRINT_STATS_LE32(_struct, _memb)   \
 pos += scnprintf(buf + pos, bufsz - pos,   \
  fmt_table, #_memb,\
@@ -1662,6 +1692,7 @@ MVM_DEBUGFS_READ_FILE_OPS(bt_cmd);
 MVM_DEBUGFS_READ_WRITE_FILE_OPS(disable_power_off, 64);
 MVM_DEBUGFS_READ_FILE_OPS(fw_rx_stats);
 MVM_DEBUGFS_READ_FILE_OPS(drv_rx_stats);
+MVM_DEBUGFS_READ_FILE_OPS(fw_ver);
 MVM_DEBUGFS_WRITE_FILE_OPS(fw_restart, 10);
 MVM_DEBUGFS_WRITE_FILE_OPS(fw_nmi, 10);
 MVM_DEBUGFS_WRITE_FILE_OPS(bt_tx_prio, 10);
@@ -1843,6 +1874,7 @@ int iwl_mvm_dbgfs_register(struct iwl_mvm *mvm, struct 
dentry *dbgfs_dir)
MVM_DEBUGFS_ADD_FILE(bt_cmd, dbgfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(disable_power_off, mvm->debugfs_dir,
 S_IRUSR | S_IWUSR);
+   MVM_DEBUGFS_ADD_FILE(fw_ver, mvm->debugfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(fw_rx_stats, mvm->debugfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(drv_rx_stats, mvm->debugfs_dir, S_IRUSR);
MVM_DEBUGFS_ADD_FILE(fw_restart, mvm->debugfs_dir, S_IWUSR);
-- 
2.14.1

[PATCH 2/2] qtnfmac: abort scans on wireless interface changes

[Sergey Matyukevich]

Abort active scans when wireless interface configuration is changed.
The usecases include wireless interface mode change, interface down,
AP stop, virtual interface removal.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 9 ++---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.h | 3 +++
 drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
 drivers/net/wireless/quantenna/qtnfmac/event.c| 2 --
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 856fa6e8327e..a450bc6bc774 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -115,6 +115,8 @@ int qtnf_del_virtual_intf(struct wiphy *wiphy, struct 
wireless_dev *wdev)
 
vif = qtnf_netdev_get_priv(wdev->netdev);
 
+   qtnf_scan_done(vif->mac, true);
+
if (qtnf_cmd_send_del_intf(vif))
pr_err("VIF%u.%u: failed to delete VIF\n", vif->mac->macid,
   vif->vifid);
@@ -335,6 +337,8 @@ static int qtnf_stop_ap(struct wiphy *wiphy, struct 
net_device *dev)
struct qtnf_vif *vif = qtnf_netdev_get_priv(dev);
int ret;
 
+   qtnf_scan_done(vif->mac, true);
+
ret = qtnf_cmd_send_stop_ap(vif);
if (ret) {
pr_err("VIF%u.%u: failed to stop AP operation in FW\n",
@@ -570,8 +574,6 @@ qtnf_del_station(struct wiphy *wiphy, struct net_device 
*dev,
!qtnf_sta_list_lookup(>sta_list, params->mac))
return 0;
 
-   qtnf_scan_done(vif->mac, true);
-
ret = qtnf_cmd_send_del_sta(vif, params);
if (ret)
pr_err("VIF%u.%u: failed to delete STA %pM\n",
@@ -1134,8 +1136,9 @@ void qtnf_virtual_intf_cleanup(struct net_device *ndev)
}
 
vif->sta_state = QTNF_STA_DISCONNECTED;
-   qtnf_scan_done(mac, true);
}
+
+   qtnf_scan_done(mac, true);
 }
 
 void qtnf_cfg80211_vif_reset(struct qtnf_vif *vif)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.h 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.h
index 6a4af52522b8..66db26613b1f 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.h
@@ -34,6 +34,9 @@ static inline void qtnf_scan_done(struct qtnf_wmac *mac, bool 
aborted)
.aborted = aborted,
};
 
+   if (timer_pending(>scan_timeout))
+   del_timer_sync(>scan_timeout);
+
mutex_lock(>mac_lock);
 
if (mac->scan_req) {
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c 
b/drivers/net/wireless/quantenna/qtnfmac/core.c
index 5e60180482d1..7f83bedc0b88 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -68,9 +68,9 @@ static int qtnf_netdev_open(struct net_device *ndev)
  */
 static int qtnf_netdev_close(struct net_device *ndev)
 {
-   netif_carrier_off(ndev);
qtnf_virtual_intf_cleanup(ndev);
qtnf_netdev_updown(ndev, 0);
+   netif_carrier_off(ndev);
return 0;
 }
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/event.c 
b/drivers/net/wireless/quantenna/qtnfmac/event.c
index 0fc2814eafad..43d2e7fd6e02 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/event.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/event.c
@@ -345,8 +345,6 @@ qtnf_event_handle_scan_complete(struct qtnf_wmac *mac,
return -EINVAL;
}
 
-   if (timer_pending(>scan_timeout))
-   del_timer_sync(>scan_timeout);
qtnf_scan_done(mac, le32_to_cpu(status->flags) & QLINK_SCAN_ABORTED);
 
return 0;
-- 
2.11.0

[PATCH 1/2] qtnfmac: lock access to h/w in tx path

[Sergey Matyukevich]

Fix tx path regression. Lock should be held when queuing packets
to h/w fifos in order to properly handle configurations with
multiple enabled interfaces.

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c  | 9 -
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 502e72b7cdcc..69131965a298 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -661,14 +661,18 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct 
sk_buff *skb)
struct qtnf_pcie_bus_priv *priv = (void *)get_bus_priv(bus);
dma_addr_t txbd_paddr, skb_paddr;
struct qtnf_tx_bd *txbd;
+   unsigned long flags;
int len, i;
u32 info;
int ret = 0;
 
+   spin_lock_irqsave(>tx0_lock, flags);
+
if (!qtnf_tx_queue_ready(priv)) {
if (skb->dev)
netif_stop_queue(skb->dev);
 
+   spin_unlock_irqrestore(>tx0_lock, flags);
return NETDEV_TX_BUSY;
}
 
@@ -717,8 +721,10 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct 
sk_buff *skb)
dev_kfree_skb_any(skb);
}
 
-   qtnf_pcie_data_tx_reclaim(priv);
priv->tx_done_count++;
+   spin_unlock_irqrestore(>tx0_lock, flags);
+
+   qtnf_pcie_data_tx_reclaim(priv);
 
return NETDEV_TX_OK;
 }
@@ -1247,6 +1253,7 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
strcpy(bus->fwname, QTN_PCI_PEARL_FW_NAME);
init_completion(>request_firmware_complete);
mutex_init(>bus_lock);
+   spin_lock_init(_priv->tx0_lock);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->tx_reclaim_lock);
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
index e76a23716ee0..86ac1ccedb52 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
@@ -34,6 +34,8 @@ struct qtnf_pcie_bus_priv {
 
/* lock for tx reclaim operations */
spinlock_t tx_reclaim_lock;
+   /* lock for tx0 operations */
+   spinlock_t tx0_lock;
u8 msi_enabled;
int mps;
 
-- 
2.11.0

[PATCH 0/2] qtnfmac: misc fixes intended for 4.14

[Sergey Matyukevich]

Hello Kalle, Igor, and all

Here are two patches intended for 4.14. The first patch fixes tx path
regression. Lock should be held when queuing packets to h/w fifos in order to
properly handle configurations with two enabled interfaces or multiple enabled
mbss. The second patch fixes scan issues addressing a review comment
from K.Valo regarding pending active scans upon device removal.

Regards,
Sergey

Sergey Matyukevich (2):

qtnfmac: lock access to h/w in tx path
qtnfmac: abort scans on wireless interface changes

cfg80211.c|9 ++---
cfg80211.h|3 +++
core.c|2 +-
event.c   |2 --
pearl/pcie.c  |9 -
pearl/pcie_bus_priv.h |2 ++
6 files changed, 20 insertions(+), 7 deletions(-)

pull-request: iwlwifi 2017-09-15

[Luca Coelho]

Hi Kalle,

Here is the first set of fixes for 4.14.  More details in the tag
description.

I have sent this out before and kbuildbot didn't find any issues. 
Please let me know if there are any issues.

Cheers,
Luca.


The following changes since commit 2eabc84d2f8e4f36d3719eeb6a330e10c46c8da7:

  iwlwifi: mvm: only send LEDS_CMD when the FW supports it (2017-09-07 19:40:09 
+0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2017-09-15

for you to fetch changes up to 5f90472c00ddf1e64c2865f71cced297bd5f80a2:

  iwlwifi: mvm: fix reorder buffer for 9000 devices (2017-09-08 11:52:51 +0300)


First set of fixes for 4.14

* A couple of bugzilla bugs related to multicast handling;
* Two fixes for WoWLAN bugs that were causing queue hangs and
  re-initialization problems;
* Two fixes for potential uninitialized variable use reported by Dan
  Carpenter in relation to a recently introduced patch;
* A fix for buffer reordering in the newly supported 9000 device
  family;
* Fix a race when starting aggregation;
* Small fix for a recent patch to wake mac80211 queues;
* Send non-bufferable management frames in the generic queue so they
  are not sent on queues that are under power-save;


Avraham Stern (2):
  iwlwifi: mvm: send all non-bufferable frames on the probe queue
  iwlwifi: mvm: wake the correct mac80211 queue

David Spinadel (1):
  iwlwifi: mvm: Flush non STA TX queues

Luca Coelho (4):
  iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD
  iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses
  iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()
  iwlwifi: mvm: set status before calling iwl_mvm_send_cmd_status()

Matt Chen (1):
  iwlwifi: mvm: fix wowlan resume failed to load INIT ucode

Naftali Goldstein (1):
  iwlwifi: mvm: change state when queueing agg start work

Sara Sharon (1):
  iwlwifi: mvm: fix reorder buffer for 9000 devices

 drivers/net/wireless/intel/iwlwifi/mvm/d3.c   |  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 62 
+++---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c   |  3 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c |  7 ---
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c |  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c  |  8 +---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.h  |  2 ++
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c   |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c   | 10 +-
 9 files changed, 80 insertions(+), 17 deletions(-)

signature.asc
Description: This is a digitally signed message part

[TDLS PATCH V1 5/5] ath10k: Avoid to set WEP key for TDLS peer

[yintang]

From: Yingying Tang 

TDLS peer do not need WEP key. Setting WEP key will lead
to TDLS setup failure. Add fix to avoid setting WEP key
for TDLS peer.

Signed-off-by: Yingying Tang 
---
 drivers/net/wireless/ath/ath10k/mac.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index f6702cb..d2530f7 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5841,6 +5841,10 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
ath10k_warn(ar, "Peer %pM disappeared!\n", peer_addr);
spin_unlock_bh(>data_lock);
 
+   if (sta && sta->tdls)
+   ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_AUTHORIZE, 1);
+
 exit:
mutex_unlock(>conf_mutex);
return ret;
-- 
1.7.9.5

[TDLS PATCH V1 4/5] ath10k: Avoid to set WEP key for TDLS peer

[yintang]

From: Yingying Tang 

TDLS peer do not need WEP key. Setting WEP key will lead
to TDLS setup failure. Add fix to avoid setting WEP key
for TDLS peer.

Signed-off-by: Yingying Tang 
---
 drivers/net/wireless/ath/ath10k/mac.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 399f9ba..f6702cb 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2966,7 +2966,7 @@ static int ath10k_station_assoc(struct ath10k *ar,
}
 
/* Plumb cached keys only for static WEP */
-   if (arvif->def_wep_key_idx != -1) {
+   if ((arvif->def_wep_key_idx != -1) && (!sta->tdls)) {
ret = ath10k_install_peer_wep_keys(arvif, sta->addr);
if (ret) {
ath10k_warn(ar, "failed to install peer wep 
keys for vdev %i: %d\n",
-- 
1.7.9.5

[TDLS PATCH V1 3/5] ath10k: Enable TDLS peer inactivity detection

[yintang]

From: Yingying Tang 

Enable TDLS peer inactivity detetion feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS link inactivity detecting.
Set related parameters in TDLS WMI command to enable this feature.

Signed-off-by: Yingying Tang 
---
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |   52 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.h |   23 +
 drivers/net/wireless/ath/ath10k/wmi.h |1 +
 3 files changed, 76 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index f60b46e..63bb2c4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -412,6 +412,49 @@ static int ath10k_wmi_tlv_event_tx_pause(struct ath10k *ar,
return 0;
 }
 
+void ath10k_wmi_event_tdls_peer(struct ath10k *ar, struct sk_buff *skb)
+{
+   struct ieee80211_sta *station;
+   const struct wmi_tlv_tdls_peer_event *ev;
+   const void **tb;
+   struct ath10k_vif *arvif;
+
+   tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+   if (IS_ERR(tb)) {
+   ath10k_warn(ar, "tdls peer failed to parse tlv");
+   return;
+   }
+   ev = tb[WMI_TLV_TAG_STRUCT_TDLS_PEER_EVENT];
+   if (!ev) {
+   kfree(tb);
+   ath10k_warn(ar, "tdls peer NULL event");
+   return;
+   }
+
+   switch (ev->peer_reason) {
+   case WMI_TDLS_TEARDOWN_REASON_TX:
+   case WMI_TDLS_TEARDOWN_REASON_RSSI:
+   case WMI_TDLS_TEARDOWN_REASON_PTR_TIMEOUT:
+   station = ieee80211_find_sta_by_ifaddr(ar->hw,
+  ev->peer_macaddr.addr,
+  NULL);
+   if (!station) {
+   ath10k_warn(ar, "did not find station from tdls peer 
event");
+   kfree(tb);
+   return;
+   }
+   arvif = ath10k_get_arvif(ar, ev->vdev_id);
+   ieee80211_tdls_oper_request(
+   arvif->vif, station->addr,
+   NL80211_TDLS_TEARDOWN,
+   WLAN_REASON_TDLS_TEARDOWN_UNREACHABLE,
+   GFP_ATOMIC
+   );
+   break;
+   }
+   kfree(tb);
+}
+
 /***/
 /* TLV ops */
 /***/
@@ -552,6 +595,9 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct 
sk_buff *skb)
case WMI_TLV_TX_PAUSE_EVENTID:
ath10k_wmi_tlv_event_tx_pause(ar, skb);
break;
+   case WMI_TLV_TDLS_PEER_EVENTID:
+   ath10k_wmi_event_tdls_peer(ar, skb);
+   break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
@@ -2750,6 +2796,12 @@ static void *ath10k_wmi_tlv_put_wmm(void *ptr,
if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
options |=  WMI_TLV_TDLS_BUFFER_STA_EN;
 
+   /* WMI_TDLS_ENABLE_ACTIVE_EXTERNAL_CONTROL means firm will handle TDLS
+* link inactivity detecting logic.
+*/
+   if (state == WMI_TDLS_ENABLE_ACTIVE)
+   state = WMI_TDLS_ENABLE_ACTIVE_EXTERNAL_CONTROL;
+
len = sizeof(*tlv) + sizeof(*cmd);
skb = ath10k_wmi_alloc_skb(ar, len);
if (!skb)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 22cf011..00d68c5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1641,6 +1641,29 @@ struct wmi_tlv_tx_pause_ev {
__le32 tid_map;
 } __packed;
 
+struct wmi_tlv_tdls_peer_event {
+   struct wmi_mac_addrpeer_macaddr;
+   __le32 peer_status;
+   __le32 peer_reason;
+   __le32 vdev_id;
+} __packed;
+
+enum wmi_tdls_peer_reason {
+   WMI_TDLS_TEARDOWN_REASON_TX,
+   WMI_TDLS_TEARDOWN_REASON_RSSI,
+   WMI_TDLS_TEARDOWN_REASON_SCAN,
+   WMI_TDLS_DISCONNECTED_REASON_PEER_DELETE,
+   WMI_TDLS_TEARDOWN_REASON_PTR_TIMEOUT,
+   WMI_TDLS_TEARDOWN_REASON_BAD_PTR,
+   WMI_TDLS_TEARDOWN_REASON_NO_RESPONSE,
+   WMI_TDLS_ENTER_BUF_STA,
+   WMI_TDLS_EXIT_BUF_STA,
+   WMI_TDLS_ENTER_BT_BUSY_MODE,
+   WMI_TDLS_EXIT_BT_BUSY_MODE,
+   WMI_TDLS_SCAN_STARTED_EVENT,
+   WMI_TDLS_SCAN_COMPLETED_EVENT,
+};
+
 void ath10k_wmi_tlv_attach(struct ath10k *ar);
 
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 7a3606d..74a6c78 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6720,6 +6720,7 @@ enum wmi_tdls_state {
WMI_TDLS_DISABLE,
WMI_TDLS_ENABLE_PASSIVE,
WMI_TDLS_ENABLE_ACTIVE,

[TDLS PATCH V1 2/5] ath10k: Enable TDLS peer buffer STA feature

[yintang]

From: Yingying Tang 

Enable TDLS peer buffer STA feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA,
it reports this capability through wmi service map in wmi service ready
event. Set related parameter in TDLS WMI command to enable this feature.

Signed-off-by: Yingying Tang 
---
 drivers/net/wireless/ath/ath10k/mac.c |3 +++
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5683f1a..399f9ba 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8204,6 +8204,9 @@ int ath10k_mac_register(struct ath10k *ar)
ieee80211_hw_set(ar->hw, TDLS_WIDER_BW);
}
 
+   if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
+   ar->hw->wiphy->flags |= WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA;
+
ar->hw->wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
ar->hw->wiphy->flags |= WIPHY_FLAG_HAS_CHANNEL_SWITCH;
ar->hw->wiphy->max_remain_on_channel_duration = 5000;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 7616c1c..f60b46e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2747,6 +2747,9 @@ static void *ath10k_wmi_tlv_put_wmm(void *ptr,
 */
u32 options = 0;
 
+   if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
+   options |=  WMI_TLV_TDLS_BUFFER_STA_EN;
+
len = sizeof(*tlv) + sizeof(*cmd);
skb = ath10k_wmi_alloc_skb(ar, len);
if (!skb)
-- 
1.7.9.5

[TDLS PATCH V1 1/5] mac80211: Enable TDLS peer buffer STA feature

[yintang]

From: Yingying Tang 

Enable TDLS peer buffer STA feature.
Set extended capability bit to enable buffer STA when driver
support it.

Signed-off-by: Yingying Tang 
---
 include/net/cfg80211.h |3 +++
 net/mac80211/tdls.c|5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f12fa52..edefc25 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3249,6 +3249,8 @@ struct cfg80211_ops {
  * beaconing mode (AP, IBSS, Mesh, ...).
  * @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key installation
  * before connection.
+ * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_ST: Device support buffer STA when TDLS is
+ * established.
  */
 enum wiphy_flags {
/* use hole at 0 */
@@ -3275,6 +3277,7 @@ enum wiphy_flags {
WIPHY_FLAG_SUPPORTS_5_10_MHZ= BIT(22),
WIPHY_FLAG_HAS_CHANNEL_SWITCH   = BIT(23),
WIPHY_FLAG_HAS_STATIC_WEP   = BIT(24),
+   WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA  = BIT(25),
 };
 
 /**
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index 91093d4..f99e379 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -49,6 +49,8 @@ static void ieee80211_tdls_add_ext_capab(struct 
ieee80211_sub_if_data *sdata,
  !ifmgd->tdls_wider_bw_prohibited;
struct ieee80211_supported_band *sband = ieee80211_get_sband(sdata);
bool vht = sband && sband->vht_cap.vht_supported;
+   bool buffer_sta =
+   local->hw.wiphy->flags & WIPHY_FLAG_SUPPORT_TDLS_BUFFER_STA;
u8 *pos = skb_put(skb, 10);
 
*pos++ = WLAN_EID_EXT_CAPABILITY;
@@ -56,7 +58,8 @@ static void ieee80211_tdls_add_ext_capab(struct 
ieee80211_sub_if_data *sdata,
*pos++ = 0x0;
*pos++ = 0x0;
*pos++ = 0x0;
-   *pos++ = chan_switch ? WLAN_EXT_CAPA4_TDLS_CHAN_SWITCH : 0;
+   *pos++ = (chan_switch ? WLAN_EXT_CAPA4_TDLS_CHAN_SWITCH : 0) |
+(buffer_sta ? WLAN_EXT_CAPA4_TDLS_BUFFER_STA : 0);
*pos++ = WLAN_EXT_CAPA5_TDLS_ENABLED;
*pos++ = 0;
*pos++ = 0;
-- 
1.7.9.5

[TDLS PATCH V1 0/5] Add TDLS feature for ath10k

[yintang]

From: Yingying Tang 

This patchset is for Rome PCIE chip, it will not affect other hardware

Yingying Tang (5):
  mac80211: Enable TDLS peer buffer STA feature
  ath10k: Enable TDLS peer buffer STA feature
  ath10k: Enable TDLS peer inactivity detection
  ath10k: Avoid to set WEP key for TDLS peer
  ath10k: Avoid to set WEP key for TDLS peer

 drivers/net/wireless/ath/ath10k/mac.c |9 -
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |   55 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.h |   23 
 drivers/net/wireless/ath/ath10k/wmi.h |1 +
 include/net/cfg80211.h|3 ++
 net/mac80211/tdls.c   |5 ++-
 6 files changed, 94 insertions(+), 2 deletions(-)

-- 
1.7.9.5

Re: What makes USB WiFi so difficult in Linux and may I help out?

[Oleksij Rempel]

Hi,

it is not related to your HW, but may help:
https://github.com/qca/open-ath9k-htc-firmware/wiki/Troubleshooting-and-bug-reporting
https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues

Am 15.09.2017 um 10:48 schrieb Ernst Wegner:
> Dear list!
> 
> I recently suffer from attempts to use some USB WiFi sticks to connect
> to a wireless network using Linux. I tried that with a number of
> distros, but found that there seem to be kind of the same problems all
> the way from Linux 2.6.x to 4.x. Most USB WiFi sticks don't work
> reliably.
> 
> As I am a developer also (and very interested in these things) I would
> be willing to help debugging drivers and possibly fix them. But I
> don't really know where to start searching. So some hints would be
> very welcome.
> 
> Currently I try to get this one here to work:
> 
> Bus 001 Device 006: ID 148f:5370 Ralink Technology, Corp. RT5370
> Wireless Adapter
> 
> I am on Debian 9 with a pretty recent kernel:
> 
> Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
> x86_64 GNU/Linux
> 
> I was able to get this stick to work kind of. Actually, it drops the
> connection every couple of minutes, without any error messages in
> dmesg or syslog, actually. But I was able to reach that state only
> after applying some tweaks like disabling hardware encrypt, i.e.
> 
> options rt2800usb nohwcrypt=y
> 
> and
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> So any pointers would be welcome.
> 
> I am not afraid to dig into the code of the driver and recompile.
> 
> I could also possibly add or enable some debugging code so I will get
> some more debugging output to see what actually happens when I loose
> the connection, i.e. if this is an external event, a special kind of
> package, overload, ...
> 
> And finally: This isn't the only USB Wifi stick which has serious
> problems with Linux. The Internet is full of this including drivers
> for some sticks which don't work at all and don't go anywhere for
> month. Obviously it's not the sticks to blame, as they all work fine
> on Windows. So what's the underlying story here which I am missing?
> 
> Regards,
> Torsten
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [RFC 4/4] cfg80211: implement regdb signature checking

[Johannes Berg]

On Fri, 2017-09-15 at 12:18 +0200, Johannes Berg wrote:
> 
> +config CFG80211_REQUIRE_SIGNED_REGDB
> + bool "require regdb signature" if
> CFG80211_CERTIFICATION_ONUS
> + default y
> + select SYSTEM_DATA_VERIFICATION

Note that this will not be easy to backport, however, the code only
needs relatively self-contained functionality, namely this:

> +   builtin_regdb_keys =
> +   keyring_alloc(".builtin_regdb_keys",
> + KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> + ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
> + KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH),
> + KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);

> +   key = key_create_or_update(make_key_ref(builtin_regdb_keys, 
> 1),
> +  "asymmetric",
> +  NULL,
> +  p,
> +  plen,
> +  ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
> +  KEY_USR_VIEW | KEY_USR_READ),
> +  KEY_ALLOC_NOT_IN_QUOTA |
> +  KEY_ALLOC_BUILT_IN |
> +  KEY_ALLOC_BYPASS_RESTRICTION);

> +   if (verify_pkcs7_signature(db->data, db->size, sig->data, sig->size,
> +  builtin_regdb_keys,
> +  VERIFYING_UNSPECIFIED_SIGNATURE, NULL, 
> NULL))

so I'm hoping it won't be too difficult, since we don't really need the
ability to manipulate keyrings etc.

johannes

[RFC 4/4] cfg80211: implement regdb signature checking

[Johannes Berg]

From: Johannes Berg 

Currently CRDA implements the signature checking, and the previous
commits added the ability to load the whole regulatory database
into the kernel.

However, we really can't lose the signature checking, so implement
it in the kernel by loading a detached signature (regulatory.db.p7s)
and check it against built-in keys.

TODO
 - add a Kconfig option to specify extra keys, rather than requiring
   them to be dropped into the right directory
 - should anything be able to modify the keyring? I guess not?
 - add Seth's key, obviously

Signed-off-by: Johannes Berg 
---
 net/wireless/Kconfig |  10 
 net/wireless/Makefile|  10 
 net/wireless/certs/none.x509 |   0
 net/wireless/reg.c   | 109 +++
 net/wireless/reg.h   |   6 +++
 5 files changed, 135 insertions(+)
 create mode 100644 net/wireless/certs/none.x509

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index f050030055c5..8ac8fda93cfe 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -83,6 +83,16 @@ config CFG80211_CERTIFICATION_ONUS
  you are a wireless researcher and are working in a controlled
  and approved environment by your local regulatory agency.
 
+config CFG80211_REQUIRE_SIGNED_REGDB
+   bool "require regdb signature" if CFG80211_CERTIFICATION_ONUS
+   default y
+   select SYSTEM_DATA_VERIFICATION
+   help
+ Require that in addition to the "regulatory.db" file a
+ "regulatory.db.p7s" can be loaded with a valid PKCS#7
+ signature for the regulatory.db file made by one of the
+ keys in the certs/ directory.
+
 config CFG80211_REG_CELLULAR_HINTS
bool "cfg80211 regulatory support for cellular base station hints"
depends on CFG80211_CERTIFICATION_ONUS
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 5f20dac5d8c6..20994876d42a 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -16,3 +16,13 @@ cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
 cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
 
 CFLAGS_trace.o := -I$(src)
+
+cfg80211-$(CONFIG_CFG80211_REQUIRE_SIGNED_REGDB) += certs.o
+
+$(obj)/certs.c: $(wildcard $(srctree)/$(src)/certs/*.x509)
+   @echo "  GEN $@"
+   @echo '#include "reg.h"' > $@
+   @echo 'const u8 regdb_certs[] = {' >> $@
+   @hexdump -v -e '1/1 "0x%.2x," "\n"' < $< >> $@
+   @echo '};' >> $@
+   @echo 'unsigned int regdb_certs_len = sizeof(regdb_certs);' >> $@
diff --git a/net/wireless/certs/none.x509 b/net/wireless/certs/none.x509
new file mode 100644
index ..e69de29bb2d1
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dd453bdad3a..2a04118c500a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -652,6 +653,105 @@ static bool valid_country(const struct firmware *db,
return true;
 }
 
+#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB
+static struct key *builtin_regdb_keys;
+
+static int load_builtin_regdb_keys(void)
+{
+   key_ref_t key;
+   const u8 *p, *end;
+   size_t plen;
+
+   builtin_regdb_keys =
+   keyring_alloc(".builtin_regdb_keys",
+ KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
+ ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
+ KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH),
+ KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
+   if (IS_ERR(builtin_regdb_keys))
+   return PTR_ERR(builtin_regdb_keys);
+
+   pr_notice("Loading compiled-in X.509 certificates\n");
+
+   p = regdb_certs;
+   end = p + regdb_certs_len;
+   while (p < end) {
+   /* Each cert begins with an ASN.1 SEQUENCE tag and must be more
+* than 256 bytes in size.
+*/
+   if (end - p < 4)
+   goto dodgy_cert;
+   if (p[0] != 0x30 &&
+   p[1] != 0x82)
+   goto dodgy_cert;
+   plen = (p[2] << 8) | p[3];
+   plen += 4;
+   if (plen > end - p)
+   goto dodgy_cert;
+
+   key = key_create_or_update(make_key_ref(builtin_regdb_keys, 1),
+  "asymmetric",
+  NULL,
+  p,
+  plen,
+  ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
+  KEY_USR_VIEW | KEY_USR_READ),
+  KEY_ALLOC_NOT_IN_QUOTA |
+  KEY_ALLOC_BUILT_IN |
+  KEY_ALLOC_BYPASS_RESTRICTION);
+ 

[RFC 2/4] cfg80211: support reloading regulatory database

[Johannes Berg]

From: Johannes Berg 

If the regulatory database is loaded, and then updated, it may
be necessary to reload it. Add an nl80211 command to do this,
and RCU-ify the pointer to the regdb "firmware" to allow it to
be replaced at runtime.

Signed-off-by: Johannes Berg 
---
 include/uapi/linux/nl80211.h |  4 +++
 net/wireless/nl80211.c   | 11 ++
 net/wireless/reg.c   | 84 
 net/wireless/reg.h   |  6 
 4 files changed, 90 insertions(+), 15 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 51626b4175c0..926eb92cb4a8 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -983,6 +983,8 @@
  * configured PMK for the authenticator address identified by
  * _ATTR_MAC.
  *
+ * @NL80211_CMD_RELOAD_REGDB: Request that the regdb firmware file is reloaded.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1185,6 +1187,8 @@ enum nl80211_commands {
NL80211_CMD_SET_PMK,
NL80211_CMD_DEL_PMK,
 
+   NL80211_CMD_RELOAD_REGDB,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ce85420ecb0..ee902ea13833 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5669,6 +5669,11 @@ static int nl80211_req_set_reg(struct sk_buff *skb, 
struct genl_info *info)
}
 }
 
+static int nl80211_reload_regdb(struct sk_buff *skb, struct genl_info *info)
+{
+   return reg_reload_regdb();
+}
+
 static int nl80211_get_mesh_config(struct sk_buff *skb,
   struct genl_info *info)
 {
@@ -12668,6 +12673,12 @@ static const struct genl_ops nl80211_ops[] = {
.policy = nl80211_policy,
.flags = GENL_ADMIN_PERM,
},
+   {
+   .cmd = NL80211_CMD_RELOAD_REGDB,
+   .doit = nl80211_reload_regdb,
+   .policy = nl80211_policy,
+   .flags = GENL_ADMIN_PERM,
+   },
{
.cmd = NL80211_CMD_GET_MESH_CONFIG,
.doit = nl80211_get_mesh_config,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 7a1d6cda64f3..8d366738c08a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -602,7 +602,7 @@ static inline int call_crda(const char *alpha2)
 #endif /* CONFIG_CFG80211_CRDA_SUPPORT */
 
 /* code to directly load a firmware database through request_firmware */
-static const struct firmware *regdb;
+static const struct firmware __rcu *regdb;
 static unsigned int fwregdb_attempts = 10;
 
 struct fwdb_country {
@@ -756,47 +756,76 @@ static int query_regdb(const char *alpha2)
 {
const struct fwdb_header *hdr;
const struct fwdb_country *country;
+   const struct firmware *db;
+   int err;
 
-   if (IS_ERR(regdb))
-   return PTR_ERR(regdb);
+   rcu_read_lock();
+   db = rcu_dereference(regdb);
 
-   hdr = (void *)regdb->data;
+   if (IS_ERR(db)) {
+   err = PTR_ERR(db);
+   goto out;
+   }
+
+   hdr = (void *)db->data;
country = >country[0];
while (country->coll_ptr) {
-   if (alpha2_equal(alpha2, country->alpha2))
-   return regdb_query_country(regdb, country);
+   if (alpha2_equal(alpha2, country->alpha2)) {
+   err = regdb_query_country(db, country);
+   goto out;
+   }
country++;
}
 
-   return -ENODATA;
+   err = -ENODATA;
+ out:
+   rcu_read_unlock();
+   return err;
 }
 
 static void regdb_fw_cb(const struct firmware *fw, void *context)
 {
+   const struct firmware *db;
+
+   rtnl_lock();
+
+   db = rcu_dereference_protected(regdb, lockdep_rtnl_is_held());
+
+   if (WARN_ON(db)) {
+   release_firmware(fw);
+   goto out;
+   }
+
if (!fw) {
pr_info("failed to load regulatory.db\n");
if (fwregdb_attempts-- == 0)
-   regdb = ERR_PTR(-ENODATA);
+   rcu_assign_pointer(regdb, ERR_PTR(-ENODATA));
goto restore;
}
 
if (!valid_regdb(fw)) {
pr_info("loaded regulatory.db is malformed\n");
release_firmware(fw);
-   regdb = ERR_PTR(-EINVAL);
+   rcu_assign_pointer(regdb, ERR_PTR(-EINVAL));
goto restore;
}
 
-   regdb = fw;
-   if (query_regdb(context))
+   rcu_assign_pointer(regdb, fw);
+
+   if (context && query_regdb(context))
goto restore;
-   goto free;
+   goto out;
+
  restore:
-   rtnl_lock();
restore_regulatory_settings(true);
+ out:
rtnl_unlock();
- free:
kfree(context);
+

[RFC 1/4] cfg80211: support loading regulatory database as firmware file

[Johannes Berg]

From: Johannes Berg 

As the current regulatory database is only about 4k big, and already
difficult to extend, we decided that overall it would be better to
get rid of the complications with CRDA and load the database into the
kernel directly, but in a new format that is extensible.

The new file format can be extended since it carries a length field
on all the structs that need to be extensible.

In order to be able to request firmware when the module initializes,
move cfg80211 from subsys_initcall() to the later fs_initcall(); the
firmware loader is at the same level but linked earlier, so it can
be called from there. Otherwise, when both the firmware loader and
cfg80211 are built-in, the request will crash the kernel. We also
need to be before device_initcall() so that cfg80211 is available
for devices when they initialize.

Signed-off-by: Johannes Berg 
---
 Documentation/networking/regulatory.txt |   8 +
 net/wireless/Kconfig|   4 +-
 net/wireless/core.c |   2 +-
 net/wireless/reg.c  | 265 +---
 4 files changed, 255 insertions(+), 24 deletions(-)

diff --git a/Documentation/networking/regulatory.txt 
b/Documentation/networking/regulatory.txt
index 7818b5fe448b..46c8d8b1cc66 100644
--- a/Documentation/networking/regulatory.txt
+++ b/Documentation/networking/regulatory.txt
@@ -19,6 +19,14 @@ core regulatory domain all wireless devices should adhere to.
 How to get regulatory domains to the kernel
 ---
 
+When the regulatory domain is first set up, the kernel will request a
+database file (regulatory.db) containing all the regulatory rules. It
+will then use that database when it needs to look up the rules for a
+given country.
+
+How to get regulatory domains to the kernel (old CRDA solution)
+---
+
 Userspace gets a regulatory domain in the kernel by having
 a userspace agent build it and send it via nl80211. Only
 expected regulatory domains will be respected by the kernel.
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 6c606120abfe..24eec5516649 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -19,6 +19,7 @@ config WEXT_PRIV
 config CFG80211
tristate "cfg80211 - wireless configuration API"
depends on RFKILL || !RFKILL
+   select FW_LOADER
---help---
  cfg80211 is the Linux wireless LAN (802.11) configuration API.
  Enable this if you have a wireless device.
@@ -167,7 +168,8 @@ config CFG80211_CRDA_SUPPORT
depends on CFG80211
help
  You should enable this option unless you know for sure you have no
- need for it, for example when using internal regdb (above.)
+ need for it, for example when using internal regdb (above) or the
+ database loaded as a firmware file.
 
  If unsure, say Y.
 
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7b33e8c366bc..fdde0d98fde1 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1384,7 +1384,7 @@ static int __init cfg80211_init(void)
 out_fail_pernet:
return err;
 }
-subsys_initcall(cfg80211_init);
+fs_initcall(cfg80211_init);
 
 static void __exit cfg80211_exit(void)
 {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5fae296a6a58..7a1d6cda64f3 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "core.h"
 #include "reg.h"
@@ -99,7 +100,7 @@ static struct regulatory_request core_request_world = {
 static struct regulatory_request __rcu *last_request =
(void __force __rcu *)_request_world;
 
-/* To trigger userspace events */
+/* To trigger userspace events and load firmware */
 static struct platform_device *reg_pdev;
 
 /*
@@ -442,7 +443,6 @@ reg_copy_regd(const struct ieee80211_regdomain *src_regd)
return regd;
 }
 
-#ifdef CONFIG_CFG80211_INTERNAL_REGDB
 struct reg_regdb_apply_request {
struct list_head list;
const struct ieee80211_regdomain *regdom;
@@ -474,41 +474,44 @@ static void reg_regdb_apply(struct work_struct *work)
 
 static DECLARE_WORK(reg_regdb_work, reg_regdb_apply);
 
-static int reg_query_builtin(const char *alpha2)
+static int reg_schedule_apply(const struct ieee80211_regdomain *regdom)
 {
-   const struct ieee80211_regdomain *regdom = NULL;
struct reg_regdb_apply_request *request;
-   unsigned int i;
-
-   for (i = 0; i < reg_regdb_size; i++) {
-   if (alpha2_equal(alpha2, reg_regdb[i]->alpha2)) {
-   regdom = reg_regdb[i];
-   break;
-   }
-   }
-
-   if (!regdom)
-   return -ENODATA;
 
request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
-   if (!request)
-   return -ENOMEM;
-
-   

[RFC 0/4] cfg80211: in-kernel regulatory database

[Johannes Berg]

I've been sitting on these patches for pretty much 2 years, waiting
for the firmware loader to gain signature checking abilities. This
hasn't happened, and even the suggested code from AKASHI Takahiro
doesn't fulfill all requirements, notably having extra keys/keyring.

I'm not sure building the keys into the module really is the best
option, but then again, that's the same way it's done with crda.

Additionally, we've not been able to extend the regulatory database
format, and for even longer we've been wanting to do that, e.g. to
add spectral density power limits and DFS configuration. Since the
new database format is easily extensible (variable size on all of
the structures used, with only the minimum size being required), the
extensions can finally be done with this.

johannes

[RFC 3/4] cfg80211: reg: remove support for built-in regdb

[Johannes Berg]

From: Johannes Berg 

Parsing and building C structures from a regdb is no longer needed
since the "firmware" file (regulatory.db) can be linked into the
kernel image to achieve the same effect.

Signed-off-by: Johannes Berg 
---
 Documentation/networking/regulatory.txt |  22 +
 net/wireless/Kconfig|  24 +
 net/wireless/Makefile   |   6 --
 net/wireless/db.txt |  17 
 net/wireless/genregdb.awk   | 158 
 net/wireless/reg.c  |  38 
 6 files changed, 3 insertions(+), 262 deletions(-)
 delete mode 100644 net/wireless/db.txt
 delete mode 100644 net/wireless/genregdb.awk

diff --git a/Documentation/networking/regulatory.txt 
b/Documentation/networking/regulatory.txt
index 46c8d8b1cc66..381e5b23d61d 100644
--- a/Documentation/networking/regulatory.txt
+++ b/Documentation/networking/regulatory.txt
@@ -200,23 +200,5 @@ Then in some part of your code after your wiphy has been 
registered:
 Statically compiled regulatory database
 ---
 
-In most situations the userland solution using CRDA as described
-above is the preferred solution.  However in some cases a set of
-rules built into the kernel itself may be desirable.  To account
-for this situation, a configuration option has been provided
-(i.e. CONFIG_CFG80211_INTERNAL_REGDB).  With this option enabled,
-the wireless database information contained in net/wireless/db.txt is
-used to generate a data structure encoded in net/wireless/regdb.c.
-That option also enables code in net/wireless/reg.c which queries
-the data in regdb.c as an alternative to using CRDA.
-
-The file net/wireless/db.txt should be kept up-to-date with the db.txt
-file available in the git repository here:
-
-git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
-
-Again, most users in most situations should be using the CRDA package
-provided with their distribution, and in most other situations users
-should be building and using CRDA on their own rather than using
-this option.  If you are not absolutely sure that you should be using
-CONFIG_CFG80211_INTERNAL_REGDB then _DO_NOT_USE_IT_.
+When a database should be fixed into the kernel, it can be provided as a
+firmware file at build time that is then linked into the kernel.
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 24eec5516649..f050030055c5 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -140,30 +140,8 @@ config CFG80211_DEBUGFS
 
  If unsure, say N.
 
-config CFG80211_INTERNAL_REGDB
-   bool "use statically compiled regulatory rules database" if EXPERT
-   default n
-   depends on CFG80211
-   ---help---
- This option generates an internal data structure representing
- the wireless regulatory rules described in net/wireless/db.txt
- and includes code to query that database. This is an alternative
- to using CRDA for defining regulatory rules for the kernel.
-
- Using this option requires some parsing of the db.txt at build time,
- the parser will be upkept with the latest wireless-regdb updates but
- older wireless-regdb formats will be ignored. The parser may later
- be replaced to avoid issues with conflicts on versions of
- wireless-regdb.
-
- For details see:
-
- http://wireless.kernel.org/en/developers/Regulatory
-
- Most distributions have a CRDA package. So if unsure, say N.
-
 config CFG80211_CRDA_SUPPORT
-   bool "support CRDA" if CFG80211_INTERNAL_REGDB
+   bool "support CRDA" if EXPERT
default y
depends on CFG80211
help
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index d06e5015751a..5f20dac5d8c6 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -14,11 +14,5 @@ cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o 
ap.o trace.o ocb.o
 cfg80211-$(CONFIG_OF) += of.o
 cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
 cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
-cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
 
 CFLAGS_trace.o := -I$(src)
-
-$(obj)/regdb.c: $(src)/db.txt $(src)/genregdb.awk
-   @$(AWK) -f $(srctree)/$(src)/genregdb.awk < $< > $@
-
-clean-files := regdb.c
diff --git a/net/wireless/db.txt b/net/wireless/db.txt
deleted file mode 100644
index a2fc3a09ccdc..
--- a/net/wireless/db.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-#
-# This file is a placeholder to prevent accidental build breakage if someone
-# enables CONFIG_CFG80211_INTERNAL_REGDB.  Almost no one actually needs to
-# enable that build option.
-#
-# You should be using CRDA instead.  It is even better if you use the CRDA
-# package provided by your distribution, since they will probably keep it
-# up-to-date on your behalf.
-#
-# If you _really_ intend to use 

RE: [EXT] Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps

[Ganapathi Bhat]

Hi Brian,
> 
> Hi Ganapathi,
> 
> On Thu, Sep 14, 2017 at 02:14:24PM +, Ganapathi Bhat wrote:
> > > On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote:
> > > > Current driver prints dev_alloc_skb failures everytime while
> > > > submitting RX URBs. This failure might be frequent in some low
> > > > resource platforms. So, wait for a threshold failure count before
> > > > start priting the error. This change is a follow up for the
> > > > 'commit
> > > > 7b368e3d15c3
> > > > ("mwifiex: resubmit failed to submit RX URBs in main thread")'
> > >
> > > []
> > >
> > > > diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c
> > > > b/drivers/net/wireless/marvell/mwifiex/usb.c
> > > []
> > > > @@ -300,9 +300,16 @@ static int mwifiex_usb_submit_rx_urb(struct
> > > urb_context *ctx, int size)
> > > > if (card->rx_cmd_ep != ctx->ep) {
> > > > ctx->skb = dev_alloc_skb(size);
> > > > if (!ctx->skb) {
> > > > -   mwifiex_dbg(adapter, ERROR,
> > > > -   "%s: dev_alloc_skb failed\n",
> __func__);
> > > > +   if (++card->rx_urb_failure_count >
> > > > +   MWIFIEX_RX_URB_FAILURE_THRESHOLD) {
> > > > +   mwifiex_dbg(adapter, ERROR,
> > > > +   "%s: dev_alloc_skb failed,
> failure
> > > count = %u\n",
> > > > +   __func__,
> > > > +   card->rx_urb_failure_count);
> > > > +   }
> > > > return -ENOMEM;
> > >
> > > Why not use a ratelimit?
> > Since this is for receive, the packets are from AP side and we cannot
> > lower the rate from AP. On some low performance systems this change
> > will be helpful.
> 
> I think Joe was referring to things like printk_ratelimited() or
> dev_err_ratelimited(). Those automatically ratelimit prints for you,
> using a static counter. You'd just need to make a small warpper for
> mwifiex_dbg() using __ratelimit().

Got it. Yet it looks he meant the same. Thank you.

> 
> Those sort of rate limits are significantly different than yours
> though.
> You were looking to avoid printing errors when there are only a few
> failures in a row, whereas the existing rate-limiting infrastructure
> looks to avoid printing errors if too many happen in a row. Those are
> different goals.
> 
> Brian

Ok.

Hi Joe,

Let us know your comments on the above.

Thanks,
Ganapathi

What makes USB WiFi so difficult in Linux and may I help out?

[Ernst Wegner]

Dear list!

I recently suffer from attempts to use some USB WiFi sticks to connect
to a wireless network using Linux. I tried that with a number of
distros, but found that there seem to be kind of the same problems all
the way from Linux 2.6.x to 4.x. Most USB WiFi sticks don't work
reliably.

As I am a developer also (and very interested in these things) I would
be willing to help debugging drivers and possibly fix them. But I
don't really know where to start searching. So some hints would be
very welcome.

Currently I try to get this one here to work:

Bus 001 Device 006: ID 148f:5370 Ralink Technology, Corp. RT5370
Wireless Adapter

I am on Debian 9 with a pretty recent kernel:

Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
x86_64 GNU/Linux

I was able to get this stick to work kind of. Actually, it drops the
connection every couple of minutes, without any error messages in
dmesg or syslog, actually. But I was able to reach that state only
after applying some tweaks like disabling hardware encrypt, i.e.

options rt2800usb nohwcrypt=y

and

[device]
wifi.scan-rand-mac-address=no

So any pointers would be welcome.

I am not afraid to dig into the code of the driver and recompile.

I could also possibly add or enable some debugging code so I will get
some more debugging output to see what actually happens when I loose
the connection, i.e. if this is an external event, a special kind of
package, overload, ...

And finally: This isn't the only USB Wifi stick which has serious
problems with Linux. The Internet is full of this including drivers
for some sticks which don't work at all and don't go anywhere for
month. Obviously it's not the sticks to blame, as they all work fine
on Windows. So what's the underlying story here which I am missing?

Regards,
Torsten

Re: [RFC 2/4] mac80211_hwsim: add hwsim_tx_rate_flags to Netlink Attributes

[Johannes Berg]

On Mon, 2017-09-11 at 11:49 +0200, Benjamin Beichler wrote:

> I don't know what is the problem with the details. The only flag,
> which is a bit to verbose is  MAC80211_HWSIM_TX_RC_DUP_DATA, which we
> may omit. All others describe directly terms used in the IEEE 802.11
> standard. Also the representation, that a rate is an MCS-index is
> quite good. If you take look here http://mcsindex.com/ , the bitrate
> would be not sufficient to get the exact coding and fec rate,
> therefore you would also need additional flags. You are right
> regarding legacy rates, which are in an encoded table. I tried to
> decouple internal and external API, but currently there is no big
> difference.

Yeah, I was just concerned that maybe this API was too tightly coupled
to mac80211, but I guess it should be fine.

> Nonetheless the whole hwsim API is highly specialized and only usable
> with the linux kernel. Of course the Userland API should be more or
> less stable, but the backward compatibility is not touched by this
> change. As I already said, this is nearly a fix for hwsim, since
> currently it's impossible to differentiate between legacy and MCS-
> rates, although they could appear in a single tx_rates array. I think
> currently minstrel does not mix HT and legacy rates for data frames,
> but AFAIK Management/Action frames are always sent with legacy rates,
> so there are mixed already.

Ok.

johannes

[PATCH] Revert "PCI: Avoid race while enabling upstream bridges"

[Bjorn Helgaas]

This reverts commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9.

Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
gen4:

  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed 
with error -2
  iwlwifi :04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
  ...
  iwlwifi :04:00.0: Failed to load firmware chunk!
  iwlwifi :04:00.0: Could not load the [0] uCode section
  iwlwifi :04:00.0: Failed to start INIT ucode: -110
  iwlwifi :04:00.0: Failed to run INIT ucode: -110

He bisected it to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream
bridges").  Revert that commit to fix the regression.

Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6...@kernel.dk
Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
Signed-off-by: Bjorn Helgaas 
CC: Srinath Mannam 
CC: Jens Axboe 
CC: Luca Coelho 
CC: Johannes Berg 
CC: Emmanuel Grumbach 
---
 drivers/pci/pci.c |   13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0002daa50f3..6078dfc11b11 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -52,7 +52,6 @@ static void pci_pme_list_scan(struct work_struct *work);
 static LIST_HEAD(pci_pme_list);
 static DEFINE_MUTEX(pci_pme_list_mutex);
 static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan);
-static DEFINE_MUTEX(pci_bridge_mutex);
 
 struct pci_pme_device {
struct list_head list;
@@ -1351,16 +1350,10 @@ static void pci_enable_bridge(struct pci_dev *dev)
if (bridge)
pci_enable_bridge(bridge);
 
-   /*
-* Hold pci_bridge_mutex to prevent a race when enabling two
-* devices below the bridge simultaneously.  The race may cause a
-* PCI_COMMAND_MEMORY update to be lost (see changelog).
-*/
-   mutex_lock(_bridge_mutex);
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
-   goto end;
+   return;
}
 
retval = pci_enable_device(dev);
@@ -1368,8 +1361,6 @@ static void pci_enable_bridge(struct pci_dev *dev)
dev_err(>dev, "Error enabling bridge (%d), continuing\n",
retval);
pci_set_master(dev);
-end:
-   mutex_unlock(_bridge_mutex);
 }
 
 static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
@@ -1394,7 +1385,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
return 0;   /* already enabled */
 
bridge = pci_upstream_bridge(dev);
-   if (bridge && !pci_is_enabled(bridge))
+   if (bridge)
pci_enable_bridge(bridge);
 
/* only skip sriov related */

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 15:57 -0700, Ben Greear wrote:
> 
> What about two APs with ssid LEDE and open-auth, each serving DHCP,
> each connected to a switch that connects to a cable modem, etc.

Take a cluebat to the adminstrator?

It's really simple to disable DHCP on one of them, and if you properly
connect them to the same switch, everything works. I've done that in a
few places (not my own house because a single AP covers it well enough
for me, so ...).

> On initial connection to the network, the station does DHCP and gets
> a response, like normal.
> But, that response has a special message in it that says "you don't
> need to re-do dhcp if you roam here".
> User-space remembers this response for future roams...
> 
> After that, then you skip DHCP on roam to this SSID/auth network, so
> you have zero extra network overhead when roaming.

That will be so much harder to configure.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 13:47 -0700, Ben Greear wrote:

> Seems like we would need some way for the DHCP server and/or AP to
> proactively notify the station that they can skip DHCP, and default
> to not skipping.

I really disagree with that - every sane network should behave the
proper way, trying to push workarounds for stupid networks into all
layers of the stack seems like a really bad idea.

johannes

Re: ROAM/CONNECT event with PORT_AUTHORIZED

[Johannes Berg]

On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:

> If you want roaming to keep oper state UP in all cases, then
> yes.  Does this work on full mac cards as well?

I don't see why not.

> E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue
> a CMD_CONNECT to AP2?

That's not something you can do with full-MAC cards?

And even mac80211 doesn't really support pre-authentication (unless you
mean over-the-DS)

johannes

Re: [PATCH] nl80211: check for the required netlink attributes presence

[Johannes Berg]

On Wed, 2017-09-13 at 00:21 +0200, Vladis Dronov wrote:
> nl80211_set_rekey_data() does not check if the required attributes
> NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
> NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
> users with CAP_NET_ADMIN privilege and may result in NULL dereference
> and a system crash. Add a check for the required attributes presence.
> This patch is based on the patch by bo Zhang.

Huh. Applied, thanks.

johannes

Re: rtlwifi/rtl8188ee baseband config explanation request

[Farhan Khan]

Thank you for your prompt response.

I am trying to write a FreeBSD port of this driver. The structures of
the two drivers are significantly different, so it is not a trivial
exercise.

The FreeBSD driver also has a similar block of code that writes over an
array of data using an array of registers, and this should be easy to
re-create. But I do not see the equivalent of phy_config_bb_with_pghdr()
anywhere. I do not know if I need to maintain the order for any reason.

I attempted to reach out to Realtek through multiple mediums but did not
receive any replies. Ultimately, I may end up re-playing the same bits
without understanding what is happening.

On 09/15/2017 02:01 AM, Larry Finger wrote:
> On 09/15/2017 12:08 AM, Farhan Khan wrote:
>> Hi all,
>>
>> I am trying to get a high-level understanding of what occurs in
>> rtl88e_phy_bb_config() in
>> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c. I understand the
>> code up until it runs _rtl88e_phy_bb8188e_config_parafile() .
>>
>>> From there, I see that phy_config_bb_with_headerfile() will write the
>> values in RTL8188EEPHY_REG_1TARRAY, runs phy_config_bb_with_pghdr(),
>> then write the values in RTL8188EEAGCTAB_1TARRAY.
>>
>> Please provide a high-level explanation of
>> phy_config_bb_with_headerfile(), and more particularly, of
>> phy_config_bb_pghdr(). What are their objectives? Also, is there a
>> reason for this specific order or can it be in any otherwise?
> 
> Why do you want to know this information? Are you trying to
> reverse-engineer the Realtek wifi devices. Note that I do not know much
> about the internals of any of the Realtek devices, but I can read the
> code. The data in RTL8188EEPHY_REG_1TARRAY consists of two parts per
> entry. The first is an address, and the second is the data to be loaded
> into that address. These data are used by the firmware to calibrate
> radios, etc., and have been determined by the Realtek engineers. There
> is a similar interpretation for RTL8188EEAGCTAB_1TARRAY. I do not know
> for sure, but as the data values here are ALL written to the same
> address, I fully expect that these must be written AFTER the PHY_REG
> information. Something needs to be controlling where the data are being
> stored.
> 
> The "high-level" interpretation of this code is this is what must be
> done for the device to work. If you want more information, you will need
> to investigate getting an NDA with Realtek. I do not have one, and I do
> not want such an agreement.
> 
> Larry

Re: rtlwifi/rtl8188ee baseband config explanation request

[Larry Finger]

On 09/15/2017 12:08 AM, Farhan Khan wrote:

Hi all,

I am trying to get a high-level understanding of what occurs in
rtl88e_phy_bb_config() in
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c. I understand the
code up until it runs _rtl88e_phy_bb8188e_config_parafile() .


From there, I see that phy_config_bb_with_headerfile() will write the

values in RTL8188EEPHY_REG_1TARRAY, runs phy_config_bb_with_pghdr(),
then write the values in RTL8188EEAGCTAB_1TARRAY.

Please provide a high-level explanation of
phy_config_bb_with_headerfile(), and more particularly, of
phy_config_bb_pghdr(). What are their objectives? Also, is there a
reason for this specific order or can it be in any otherwise?


Why do you want to know this information? Are you trying to reverse-engineer the 
Realtek wifi devices. Note that I do not know much about the internals of any of 
the Realtek devices, but I can read the code. The data in 
RTL8188EEPHY_REG_1TARRAY consists of two parts per entry. The first is an 
address, and the second is the data to be loaded into that address. These data 
are used by the firmware to calibrate radios, etc., and have been determined by 
the Realtek engineers. There is a similar interpretation for 
RTL8188EEAGCTAB_1TARRAY. I do not know for sure, but as the data values here are 
ALL written to the same address, I fully expect that these must be written AFTER 
the PHY_REG information. Something needs to be controlling where the data are 
being stored.


The "high-level" interpretation of this code is this is what must be done for 
the device to work. If you want more information, you will need to investigate 
getting an NDA with Realtek. I do not have one, and I do not want such an agreement.


Larry