* Re: regression in ath10k dma allocation
From: Christoph Hellwig @ 2019-08-20 2:14 UTC (permalink / raw)
To: Nicolin Chen
Cc: Hillf Danton, Tobias Klausmann, Christoph Hellwig, kvalo, davem,
ath10k, linux-wireless, netdev, linux-kernel, m.szyprowski,
robin.murphy, iommu, tobias.klausmann
In-Reply-To: <20190820015852.GA15830@Asurada-Nvidia.nvidia.com>
On Mon, Aug 19, 2019 at 06:58:52PM -0700, Nicolin Chen wrote:
> Right...the condition was in-between. However, not every caller
> of dma_alloc_contiguous() is supposed to have a coherent check.
> So we either add a 'bool coherent_ok' to the API or revert the
> dma-direct part back to the original. Probably former option is
> better?
>
> Thank you for the debugging. I have been a bit distracted, may
> not be able to submit a fix very soon. Would you like to help?
Yeah, it turns out that while the idea for the dma_alloc_contiguous
helper was neat it didn't work out at all, and me pushing Nicolin
down that route was not a very smart idea. Sorry for causing this
mess.
I think we'll just need to open code it for dma-direct for 5.3.
Hillf do you want to cook up a patch or should I do it?
^ permalink raw reply
* Re: regression in ath10k dma allocation
From: Nicolin Chen @ 2019-08-20 1:58 UTC (permalink / raw)
To: Hillf Danton, Tobias Klausmann
Cc: Christoph Hellwig, kvalo, davem, ath10k, linux-wireless, netdev,
linux-kernel, m.szyprowski, robin.murphy, iommu, tobias.klausmann
In-Reply-To: <acd7a4b0-fde8-1aa2-af07-2b469e5d5ca7@mni.thm.de>
Hello Hillf,
On Mon, Aug 19, 2019 at 12:38:38AM +0200, Tobias Klausmann wrote:
>
> On 18.08.19 05:13, Hillf Danton wrote:
> > On Sat, 17 Aug 2019 00:42:48 +0200 Tobias Klausmann wrote:
> > > Hi Nicolin,
> > >
> > > On 17.08.19 00:25, Nicolin Chen wrote:
> > > > Hi Tobias
> > > >
> > > > On Fri, Aug 16, 2019 at 10:16:45PM +0200, Tobias Klausmann wrote:
> > > > > > do you have CONFIG_DMA_CMA set in your config? If not please make sure
> > > > > > you have this commit in your testing tree, and if the problem still
> > > > > > persists it would be a little odd and we'd have to dig deeper:
> > > > > >
> > > > > > commit dd3dcede9fa0a0b661ac1f24843f4a1b1317fdb6
> > > > > > Author: Nicolin Chen <nicoleotsuka@gmail.com>
> > > > > > Date: Wed May 29 17:54:25 2019 -0700
> > > > > >
> > > > > > dma-contiguous: fix !CONFIG_DMA_CMA version of dma_{alloc, free}_contiguous()
> > > > > yes CONFIG_DMA_CMA is set (=y, see attached config), the commit you mention
> > > > > above is included, if you have any hints how to go forward, please let me
> > > > > know!
> > > > For CONFIG_DMA_CMA=y, by judging the log with error code -12, I
> > > > feel this one should work for you. Would you please check if it
> > > > is included or try it out otherwise?
> > > >
> > > > dma-contiguous: do not overwrite align in dma_alloc_contiguous()
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c6622a425acd1d2f3a443cd39b490a8777b622d7
> > >
> > > Thanks for the hint, yet the commit is included and does not fix the
> > > problem!
> > >
> Hi Hillf,
>
> i just tested you first hunk (which comes from kernel/dma/direct.c if i'm
> not mistaken), it did not compile on its own, yet with a tiny bit of work it
> did, and it does indeed solve the regression. But if using that is the
> "right" way to do it, not sure, but its not on me to decide.
>
> Anyway: Thanks for the hint,
>
> Tobias
>
>
> > Hi Tobias
> >
> > Two minor diffs below in hope that they might make sense.
> >
> > 1, fallback unless dma coherent ok.
> >
> > --- a/kernel/dma/contiguous.c
> > +++ b/kernel/dma/contiguous.c
> > @@ -246,6 +246,10 @@ struct page *dma_alloc_contiguous(struct
> > size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
> > page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
> > + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > + dma_free_contiguous(dev, page, size);
> > + page = NULL;
> > + }
Right...the condition was in-between. However, not every caller
of dma_alloc_contiguous() is supposed to have a coherent check.
So we either add a 'bool coherent_ok' to the API or revert the
dma-direct part back to the original. Probably former option is
better?
Thank you for the debugging. I have been a bit distracted, may
not be able to submit a fix very soon. Would you like to help?
Thanks!
Nicolin
> > }
> > /* Fallback allocation of normal pages */
> > --
> >
> > 2, cleanup: cma unless contiguous
> >
> > --- a/kernel/dma/contiguous.c
> > +++ b/kernel/dma/contiguous.c
> > @@ -234,18 +234,13 @@ struct page *dma_alloc_contiguous(struct
> > size_t count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > size_t align = get_order(PAGE_ALIGN(size));
> > struct page *page = NULL;
> > - struct cma *cma = NULL;
> > -
> > - if (dev && dev->cma_area)
> > - cma = dev->cma_area;
> > - else if (count > 1)
> > - cma = dma_contiguous_default_area;
> > /* CMA can be used only in the context which permits sleeping */
> > - if (cma && gfpflags_allow_blocking(gfp)) {
> > + if (count > 1 && gfpflags_allow_blocking(gfp)) {
> > size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
> > - page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
> > + page = cma_alloc(dev_get_cma_area(dev), count, cma_align,
> > + gfp & __GFP_NOWARN);
> > if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > dma_free_contiguous(dev, page, size);
> > page = NULL;
> > --
> >
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-08-19
From: David Miller @ 2019-08-20 1:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87tvad9l1v.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 19 Aug 2019 19:28:28 +0300
> here's a pull request to net-next for v5.4, more info below. Please let
> me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* [PATCH] Fix a double free bug in rsi_91x_deinit
From: Hui Peng @ 2019-08-19 22:02 UTC (permalink / raw)
To: security
Cc: Hui Peng, Mathias Payer, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
`dev` (struct rsi_91x_usbdev *) field of adapter
(struct rsi_91x_usbdev *) is allocated and initialized in
`rsi_init_usb_interface`. If any error is detected in information
read from the device side, `rsi_init_usb_interface` will be
freed. However, in the higher level error handling code in
`rsi_probe`, if error is detected, `rsi_91x_deinit` is called
again, in which `dev` will be freed again, resulting double free.
This patch fixes the double free by removing the free operation on
`dev` in `rsi_init_usb_interface`, because `rsi_91x_deinit` is also
used in `rsi_disconnect`, in that code path, the `dev` field is not
(and thus needs to be) freed.
This bug was found in v4.19, but is also present in the latest version
of kernel.
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c
index c0a163e40402..ac917227f708 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -640,7 +640,6 @@ static int rsi_init_usb_interface(struct rsi_hw *adapter,
kfree(rsi_dev->tx_buffer);
fail_eps:
- kfree(rsi_dev);
return status;
}
--
2.22.1
^ permalink raw reply related
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 20:42 UTC (permalink / raw)
To: Johannes Berg, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <52914e64663283eeff9445b8b1fb37986c15223d.camel@sipsolutions.net>
Am 19.08.19 um 22:03 schrieb Johannes Berg:
> On Mon, 2019-08-19 at 21:57 +0200, Alexander Wetzel wrote:
>>>> +
>>>> + /* The new Tx API does not allow to pass the key or keyid of a MPDU to
>>>> + * the hw, preventing us to control which key(id) to use per MPDU.
>>>> + * Till that's fixed we can't use Extended Key ID for the newer cards.
>>>
>>> Technically we still don't need per MPDU, we just need to switch which
>>> one to use for TX after installing it for RX already.
>>
>> The Extended Key ID API we finally merged in mac80211 is not notifying
>> the driver when to switch the key over to the other id.
>
> Oh, right, good point.
>
>> The current API provides the key/keyid per MPDU and let's mac80211 have
>> the full control what's the correct key for each frame.
>
> Yeah, but as you noticed we no longer have that control per MPDU with
> the new TX API in iwlmvm.
>
>> That's especially critical for drivers setting
>> IEEE80211_KEY_FLAG_GENERATE_IV and/or supporting A-MPDU's. Allowing the
>> driver to override the mac80211 decision is only safe when the
>> driver/card generates the PNs itself and also handles the A-MPDU key
>> borders correctly.
>
> Sure, the device does generate the PN itself now with the new TX API
> too. It doesn't care about A-MPDU key borders, but it probably could
> when taught to care about extended key ID.
>
>> While less desirable we still could get that working: The mvm driver
>> would have to detect the key borders and then tell the firmware to
>> switch over to the other key. But we would have to make sure to not
>> re-enable A-MPDU aggregation till the card really has switched.
>
> I'm not entirely sure off the top of my head how it works, but it seems
> possible that if we just assign a new PN to retransmits of the same
> frame but in a new A-MPDU after key switching, it wouldn't actually
> matter?
I was thinking about mac80211 re-enabling A-MPDU aggregation but the
driver still using the old key for some frames and then switching to the
new key within one A-MPDU, causing non-compliant A-MPDUs.
> But then again maybe somewhere it's stated that we must use the same key
> for all transmit attempts of a single frame? Not sure.
I know of course next to nothing how the hardware/firmware is handling
that, but I'm surprised this could be a problem. I assumed the card
would create a full MPDU (with the crypto headers) and use that for
retransmit and not create the MPDU new... After all you still have to
use the old PN and getting that right sounds tricky when you don't have
the full MPDU cached somehow. But I guess the high bandwidth and the
required buffer space forced you to extreme measures to conserve space...
>
> I'm also not sure if we could actually assign a PN from the new key for
> the retransmit, the hardware has to store those back into memory
> normally.
>
> So probably you're right, and we'd have to disable A-MPDUs until we have
> no outstanding old-key-retransmits, but that seems manageable.
Extending the A-MPDU block mac80211 is using to enforce the A-MPDU key
borders should be not very hard. Figuring out the time when we safely
can restart it - when re-transmits indeed are also an issue - I'm less
sure about. I believe re-transmits are handled by the card and not the
driver but so far had no reason to dig deeper into that topic. But I
guess a call to switch over the keyid which blocks till that is done
should take care of it.
Alexander
Alexander
^ permalink raw reply
* Re: [RFC 0/1] Allow MAC change on up interface
From: James Prestwood @ 2019-08-19 21:14 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <4848c3a9d0b330fab4442436244387a2c127fa03.camel@sipsolutions.net>
Hi Johannes,
Without reiterating what Denis said:
<snip>
> I don't, short of
>
> 1) don't do that then
> 2) extend the network stack to have
> IFF_LIVE_BUT_NO_CARRIER_ADDR_CHANGE
> or something like that
So you mean 2 is my only option... ;) I am fine with this.
>
> TBH, I'm not really sure I see any point in this to start with, many
> devices will give the address to the firmware when the interface is
> brought up (even iwlwifi does - I'm not sure we'd want to take your
> patch for iwlwifi even if that works today, nothing says the firmware
> might not change its mind on that), and so it's quite likely only
> going
> to be supported in few devices.
The iwlwifi change was just an example. It ultimately would be up to
the maintainers of each driver to support this or not. Regardless,
doing the ground work for a driver/firmware to support this is more
valuable than continuing to neglect these quirks that make use of
nl80211 difficult/racy.
>
> You've also not really explained what exactly is troubling you with
> changing the MAC address, you just mentioned some sort of "race
> condition"?
In order to change the MAC on a per-AP/SSID is to: ifdown, change MAC,
ifup via RTNL. The problem is that ifdown generates an RTNL link down
event and there is no way of knowing how this event was generated (by
you, hot-unplug, or some other issue in kernel?). Handling this without
a race is simply not possible. You sort of just have to pray none of
this happens (and its unlikely but it *could* happen).
Besides efficiency another obvious reason for this change is simply
ease of use. If the hardware supports doing this then why should
userspace have to jump through hoops to accomplish it?
>
> Now, one thing I can imagine would be that you'd want to optimize
>
> * ifdown
> - remove iface from fw/hw
> - stop fw/hw
> * change MAC
> * ifup
> - start fw/hw
> - add iface to fw/hw
> to just
>
> * ifdown
> - remove iface from fw/hw
> * change MAC
> * ifup
> - add iface to fw/hw
>
> i.e. not restart the firmware (which takes time) for all this, but
> that
> seems much easier to solve by e.g. having a combined operation for
> all
> of this that gets handled in mac80211, or more generally by having a
> "please keep the firmware running" token that you can hold while you
> do
> the operation?
>
>
> Your changes are also a bit strange - you modified the "connect" path
> and iwlwifi, but the connect path is not usually (other than with iw
> or
> even iwconfig) taken for iwlwifi? And if you modify auth/assoc paths,
> you get into even weirder problems - what if you use different
> addresses
> for auth and assoc? What if the assoc (or even connect) really was a
> *re*assoc, and thus must have the same MAC address? To me, the whole
> thing seems like more of a problem than a solution.
The connect path is just what we (IWD) use for almost all types of
connections that support it (apart from things like SAE/OWE/FT). Not
sure what you mean for "usually not taken for iwlwifi"? If you have an
iwlwifi card and you issue CMD_CONNECT thats the path it takes...
Thanks,
James
>
> johannes
>
^ permalink raw reply
* Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 21:15 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <eb0481b1928b0554daeda59cfc1d631e44bb2bdd.camel@sipsolutions.net>
Am 19.08.19 um 22:23 schrieb Johannes Berg:
> On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote:
>
>> We may also get away by adding only means to pass the keyid of the MPDU
>> (zero or one) to the HW. That could be done quite simple, I think:
>>
>> We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and
>> IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures
>> iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3.
>> When the firmware would check and use the key referenced by the STA +
>> flag-id prior to the "last installed" key that should be sufficient.
>> By still using the last installed key without any of the new flags set
>> we also would remain backward compatible.
>>
>> If you have any experimental firmware to test I'm happy to do so:-)
>> Till then I'm back using older iwlwifi cards.
>
> I'm not convinced that we can change the TX API at all, I suspect we
> have to go detect it as we saw in the other patch. If we do actually
> have the ability to change the TX API it might be simpler overall, but
> anyway, I'd have to go look at how this is all implemented before I
> comment further. Doesn't seem like an intractable problem, the only
> question is if we get to spend time on it :)
You are thinking about keeping the tx API untouched and modify the key
install logic?
Just prevent the firmware to activate a key for Tx when it's installed
and notify the firmware by some means when the key can be used for Tx
and then switch everything to the new key?
I guess there is no practical way I can get access to the firmware code,
correct? For me it sounds harder than the optional flag extension I had
in mind for the new tx API.
After all one of the existing flags can already suppress the encryption.
Checking for the presence of two optional flags and use these to select
a different key sounded not very hard. But then I literally know nothing
about that and if the card/firmware has some fundamental issue handling
two unicast keys the picture changes of course...
So let's wait and see what you can turn up. Till then we have more than
enough other cards supporting Extended Key ID:-)
Alexander
^ permalink raw reply
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 20:50 UTC (permalink / raw)
To: Johannes Berg, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <5bc077f7b2f017da7c027edd27a543910dd6ac32.camel@sipsolutions.net>
Am 19.08.19 um 22:09 schrieb Johannes Berg:
> On Mon, 2019-08-19 at 22:03 +0200, Johannes Berg wrote:
>>
>>> While less desirable we still could get that working: The mvm driver
>>> would have to detect the key borders and then tell the firmware to
>>> switch over to the other key. But we would have to make sure to not
>>> re-enable A-MPDU aggregation till the card really has switched.
>
>> So probably you're right, and we'd have to disable A-MPDUs until we have
>> no outstanding old-key-retransmits, but that seems manageable.
>
> Actually, we probably have to even delay the key switch until there are
> no more frames to retransmit, because the hardware is involved to some
> extent and it won't know about two keys or something... Not really sure
> how it all works though, off the top of my head.
This sounds like the card is not really able to handle two unicast key
per STA, which would be a show stopper.
But not sure if I can believe that: After all the card is setting the
correct keyid for the key and e.g. able to use keyid 1 for both send and
receive, so it's not simply assuming unicast keys are always using keyid 0.
Honoring the keyid for that but then not be able to differentiate
between the keyids for re-transmits is nothing I would have expected. So
I still hope you are wrong here:-)
Alexander
^ permalink raw reply
* Re: [RFC 0/1] Allow MAC change on up interface
From: Denis Kenzior @ 2019-08-19 20:58 UTC (permalink / raw)
To: Johannes Berg, James Prestwood, linux-wireless
In-Reply-To: <4848c3a9d0b330fab4442436244387a2c127fa03.camel@sipsolutions.net>
Hi Johannes,
> TBH, I'm not really sure I see any point in this to start with, many
> devices will give the address to the firmware when the interface is
> brought up (even iwlwifi does - I'm not sure we'd want to take your
> patch for iwlwifi even if that works today, nothing says the firmware
> might not change its mind on that), and so it's quite likely only going
> to be supported in few devices.
Hmm... I sense a pattern of you not seeing a point in doing many
things... Do you actually use the stuff you maintain?
>
> You've also not really explained what exactly is troubling you with
> changing the MAC address, you just mentioned some sort of "race
> condition"?
Well, one possible use case might be, oh something like this:
https://source.android.com/devices/tech/connect/wifi-mac-randomization
>
> Now, one thing I can imagine would be that you'd want to optimize
>
> * ifdown
> - remove iface from fw/hw
> - stop fw/hw
> * change MAC
> * ifup
> - start fw/hw
> - add iface to fw/hw
>
> to just
>
> * ifdown
> - remove iface from fw/hw
> * change MAC
> * ifup
> - add iface to fw/hw
>
That would be a part of it...
> i.e. not restart the firmware (which takes time) for all this, but that
> seems much easier to solve by e.g. having a combined operation for all
> of this that gets handled in mac80211, or more generally by having a
> "please keep the firmware running" token that you can hold while you do
> the operation?
And also maybe a bunch of other optimizations like not flushing scan
results?
>
> Your changes are also a bit strange - you modified the "connect" path
> and iwlwifi, but the connect path is not usually (other than with iw or
> even iwconfig) taken for iwlwifi? And if you modify auth/assoc paths,
> you get into even weirder problems - what if you use different addresses
> for auth and assoc? What if the assoc (or even connect) really was a
> *re*assoc, and thus must have the same MAC address? To me, the whole
> thing seems like more of a problem than a solution.
>
Okay, so there are some obstacles. But can you get over the whole
"Don't hold it like this" part and actually offer up something constructive?
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 15:52 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <d3c6d084728e4203832688b63e884d25b0f74fcf.camel@sipsolutions.net>
Am 19.08.19 um 11:43 schrieb Johannes Berg:
> On Sat, 2019-08-17 at 10:31 +0200, Alexander Wetzel wrote:
>>> All iwlwifi cards are able to handle multiple keyids per STA and are
>>> therefore fully compatible with the Extended Key ID implementation
>>> provided by mac80211.
>>
>> I just tried Extended Key ID with a AX200 card and it really looks like
>> it's incompatible:-(
>
> Hmm.
>
>> The card is starting to use the PTK key immediately after installation,
>> encrypting EAPOL #3 with the new (still Rx only!) key.
>
> Right. This wasn't considered, I guess.
>
>> Digging around in the driver code it looks like we do not even pass the
>> key information any longer to the card: iwl_mvm_set_tx_params() is
>> bypassing iwl_mvm_set_tx_cmd_crypto() completely when we use the "new tx
>> API". So all cards setting "use_tfh" to true are now incompatible.
>>
>> Therefore it looks like that all cards starting with the 22000 series
>> can't be used with Extended Key ID any longer.
>>
>> Is there a way to hand over the key information within the new API or is
>> the way forward to block Extended Key ID when the "new tx API" is being
>> used?
>
> Not right now, but I think it could be fixed.
That would be great!
We may also get away by adding only means to pass the keyid of the MPDU
(zero or one) to the HW. That could be done quite simple, I think:
We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and
IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures
iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3.
When the firmware would check and use the key referenced by the STA +
flag-id prior to the "last installed" key that should be sufficient.
By still using the last installed key without any of the new flags set
we also would remain backward compatible.
If you have any experimental firmware to test I'm happy to do so:-)
Till then I'm back using older iwlwifi cards.
>
>> The card is fine with using keyid 1 for unicast keys. But it looks like
>> it assumes that a new key install also tells it to use the new key
>> immediately... Still digging around but pretty sure that's happening now.
>
> Right.
>
> For now I guess we have to disable it with the new TX API (which is
> really what it depends on), we can try to fix the firmware later.
Ok. I'll update the iwlwifi Extended key ID support patch accordingly.
Alexander
^ permalink raw reply
* Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm
From: Johannes Berg @ 2019-08-19 20:23 UTC (permalink / raw)
To: Alexander Wetzel, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <ae321cd5-6ef4-87c5-98ec-dbac37e83c6d@wetzel-home.de>
On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote:
> We may also get away by adding only means to pass the keyid of the MPDU
> (zero or one) to the HW. That could be done quite simple, I think:
>
> We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and
> IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures
> iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3.
> When the firmware would check and use the key referenced by the STA +
> flag-id prior to the "last installed" key that should be sufficient.
> By still using the last installed key without any of the new flags set
> we also would remain backward compatible.
>
> If you have any experimental firmware to test I'm happy to do so:-)
> Till then I'm back using older iwlwifi cards.
I'm not convinced that we can change the TX API at all, I suspect we
have to go detect it as we saw in the other patch. If we do actually
have the ability to change the TX API it might be simpler overall, but
anyway, I'd have to go look at how this is all implemented before I
comment further. Doesn't seem like an intractable problem, the only
question is if we get to spend time on it :)
johannes
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Johannes Berg @ 2019-08-19 20:21 UTC (permalink / raw)
To: Josef Miegl; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <20190819113706.ujsz67sxcwt2ulmt@pepin-laptop.localdomain>
On Mon, 2019-08-19 at 13:37 +0200, Josef Miegl wrote:
> On Mon, Aug 19, 2019 at 12:12:43PM +0200, Johannes Berg wrote:
> > Contrary to what Sebastian states, it certainly is possible today,
> > although not through wpa_supplicant's config file, only through the
> > wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
> > tests showing how to use this.
>
> Thanks Johannes. I noticed this too and tried adding a config file
> option (OpenWRT doesn't compile wpa_supplicant with wpa_cli). I've added
> sta_vendor_elements option (exactly like ap_vendor_elements). This is
> the code setting vendor_elem:
>
> +++ b/wpa_supplicant/wpa_supplicant.c
> @@ -5833,6 +5833,16 @@
> wpas_mbo_update_non_pref_chan(wpa_s, wpa_s->conf->non_pref_chan);
> #endif /* CONFIG_MBO */
>
> + if (wpa_s->conf->sta_vendor_elements) {
> + if (wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] == NULL) {
> + wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] = wpa_s->conf->sta_vendor_elements;
> + } else {
> + wpabuf_resize(&wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpabuf_len(wpa_s->conf->sta_vendor_elements));
> + wpabuf_put_buf(wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpa_s->conf->sta_vendor_elements);
> + }
> + }
> +
> wpa_supplicant_set_default_scan_ies(wpa_s);
>
> return 0;
>
>
> But when I actually set sta_vendor_elements to something, all it does is
> failing the 4-way handshake during association. The IE is perfectly
> valid and it works with ap_vendor_elements, no nl80211 malformed IEs
> error either. Am I missing something?
I don't know, try capturing over the air?
Perhaps the vendor IEs added this way are added *first* before all the
RSN IEs, and that's tripping up your AP, and you'd have to add them
*after* the normal elements? Not really sure where/how they're added?
johannes
^ permalink raw reply
* Re: [RFC 0/1] Allow MAC change on up interface
From: Johannes Berg @ 2019-08-19 20:20 UTC (permalink / raw)
To: James Prestwood, linux-wireless
In-Reply-To: <394092a2f20697c9b055166a8254a5ef888551a5.camel@gmail.com>
Hi James,
> > It actually seems wrong to set IFF_LIVE_ADDR_CHANGE at all, because
> > you
> > don't actually support that - you only support setting it while not
> > connected?
>
> You are right, we only care about setting the MAC while not connected.
> But, the eth_ API's that set the MAC are contingent on
> IFF_LIVE_ADDR_CHANGE when the interface is running. If you follow down
> 'dev_set_mac_address':
>
> dev_set_mac_address ->
> ndo_set_mac_address (ieee80211_change_mac) ->
> eth_mac_addr ->
> eth_prepare_mac_addr_change:
>
> You see the check for:
>
> !(dev->priv_flags & IFF_LIVE_ADDR_CHANGE) && netif_running(dev)
Right.
> Like I said in my commit message, I did not think setting
> IFF_LIVE_ADDR_CHANGE where I did was the correct way to do it, but
> unless this eth code is changed its looking like it does need to be set
> somewhere to change the MAC while 'running'.
Also right.
> Maybe this is a historical thing but the comment about
> IFF_LIVE_ADDR_CHANGE says "device supports hardware address change when
> it's running". Isn't a wireless adapter 'running' when not connected?
> Or does 'running' indicate some different state than up/down?
>
> If you have any suggestions on how I could do this without setting
> IFF_LIVE_ADDR_CHANGE I am all ears.
I don't, short of
1) don't do that then
2) extend the network stack to have IFF_LIVE_BUT_NO_CARRIER_ADDR_CHANGE
or something like that
TBH, I'm not really sure I see any point in this to start with, many
devices will give the address to the firmware when the interface is
brought up (even iwlwifi does - I'm not sure we'd want to take your
patch for iwlwifi even if that works today, nothing says the firmware
might not change its mind on that), and so it's quite likely only going
to be supported in few devices.
You've also not really explained what exactly is troubling you with
changing the MAC address, you just mentioned some sort of "race
condition"?
Now, one thing I can imagine would be that you'd want to optimize
* ifdown
- remove iface from fw/hw
- stop fw/hw
* change MAC
* ifup
- start fw/hw
- add iface to fw/hw
to just
* ifdown
- remove iface from fw/hw
* change MAC
* ifup
- add iface to fw/hw
i.e. not restart the firmware (which takes time) for all this, but that
seems much easier to solve by e.g. having a combined operation for all
of this that gets handled in mac80211, or more generally by having a
"please keep the firmware running" token that you can hold while you do
the operation?
Your changes are also a bit strange - you modified the "connect" path
and iwlwifi, but the connect path is not usually (other than with iw or
even iwconfig) taken for iwlwifi? And if you modify auth/assoc paths,
you get into even weirder problems - what if you use different addresses
for auth and assoc? What if the assoc (or even connect) really was a
*re*assoc, and thus must have the same MAC address? To me, the whole
thing seems like more of a problem than a solution.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Johannes Berg @ 2019-08-19 20:09 UTC (permalink / raw)
To: Alexander Wetzel, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <52914e64663283eeff9445b8b1fb37986c15223d.camel@sipsolutions.net>
On Mon, 2019-08-19 at 22:03 +0200, Johannes Berg wrote:
>
> > While less desirable we still could get that working: The mvm driver
> > would have to detect the key borders and then tell the firmware to
> > switch over to the other key. But we would have to make sure to not
> > re-enable A-MPDU aggregation till the card really has switched.
> So probably you're right, and we'd have to disable A-MPDUs until we have
> no outstanding old-key-retransmits, but that seems manageable.
Actually, we probably have to even delay the key switch until there are
no more frames to retransmit, because the hardware is involved to some
extent and it won't know about two keys or something... Not really sure
how it all works though, off the top of my head.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Johannes Berg @ 2019-08-19 20:03 UTC (permalink / raw)
To: Alexander Wetzel, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <da471544-3370-8ba1-2265-d02ab09cdcee@wetzel-home.de>
On Mon, 2019-08-19 at 21:57 +0200, Alexander Wetzel wrote:
> > > +
> > > + /* The new Tx API does not allow to pass the key or keyid of a MPDU to
> > > + * the hw, preventing us to control which key(id) to use per MPDU.
> > > + * Till that's fixed we can't use Extended Key ID for the newer cards.
> >
> > Technically we still don't need per MPDU, we just need to switch which
> > one to use for TX after installing it for RX already.
>
> The Extended Key ID API we finally merged in mac80211 is not notifying
> the driver when to switch the key over to the other id.
Oh, right, good point.
> The current API provides the key/keyid per MPDU and let's mac80211 have
> the full control what's the correct key for each frame.
Yeah, but as you noticed we no longer have that control per MPDU with
the new TX API in iwlmvm.
> That's especially critical for drivers setting
> IEEE80211_KEY_FLAG_GENERATE_IV and/or supporting A-MPDU's. Allowing the
> driver to override the mac80211 decision is only safe when the
> driver/card generates the PNs itself and also handles the A-MPDU key
> borders correctly.
Sure, the device does generate the PN itself now with the new TX API
too. It doesn't care about A-MPDU key borders, but it probably could
when taught to care about extended key ID.
> While less desirable we still could get that working: The mvm driver
> would have to detect the key borders and then tell the firmware to
> switch over to the other key. But we would have to make sure to not
> re-enable A-MPDU aggregation till the card really has switched.
I'm not entirely sure off the top of my head how it works, but it seems
possible that if we just assign a new PN to retransmits of the same
frame but in a new A-MPDU after key switching, it wouldn't actually
matter?
But then again maybe somewhere it's stated that we must use the same key
for all transmit attempts of a single frame? Not sure.
I'm also not sure if we could actually assign a PN from the new key for
the retransmit, the hardware has to store those back into memory
normally.
So probably you're right, and we'd have to disable A-MPDUs until we have
no outstanding old-key-retransmits, but that seems manageable.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 19:57 UTC (permalink / raw)
To: Johannes Berg, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <204c346ab9fc71865e4cb5f5c29ec33ca05050e2.camel@sipsolutions.net>
>> +
>> + /* The new Tx API does not allow to pass the key or keyid of a MPDU to
>> + * the hw, preventing us to control which key(id) to use per MPDU.
>> + * Till that's fixed we can't use Extended Key ID for the newer cards.
>
> Technically we still don't need per MPDU, we just need to switch which
> one to use for TX after installing it for RX already.
The Extended Key ID API we finally merged in mac80211 is not notifying
the driver when to switch the key over to the other id.
The current API provides the key/keyid per MPDU and let's mac80211 have
the full control what's the correct key for each frame.
That's especially critical for drivers setting
IEEE80211_KEY_FLAG_GENERATE_IV and/or supporting A-MPDU's. Allowing the
driver to override the mac80211 decision is only safe when the
driver/card generates the PNs itself and also handles the A-MPDU key
borders correctly.
While less desirable we still could get that working: The mvm driver
would have to detect the key borders and then tell the firmware to
switch over to the other key. But we would have to make sure to not
re-enable A-MPDU aggregation till the card really has switched.
Alexander
^ permalink raw reply
* Re: [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Johannes Berg @ 2019-08-19 18:51 UTC (permalink / raw)
To: Alexander Wetzel, luciano.coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <20190819180540.2855-1-alexander@wetzel-home.de>
On Mon, 2019-08-19 at 20:05 +0200, Alexander Wetzel wrote:
> All iwlwifi cards below the 22000 series are able to handle multiple
> keyids per STA and allow the selection of the encryption key per MPDU.
>
> These are therefore fully compatible with the Extended Key ID support
> implementation in mac80211.
>
> Enable Extended Key ID support for all dvm cards and the mvm cards not
> using the incompatible new Tx API introduced for the 22000 series.
>
> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
LGTM.
> +
> + /* The new Tx API does not allow to pass the key or keyid of a MPDU to
> + * the hw, preventing us to control which key(id) to use per MPDU.
> + * Till that's fixed we can't use Extended Key ID for the newer cards.
Technically we still don't need per MPDU, we just need to switch which
one to use for TX after installing it for RX already.
johannes
^ permalink raw reply
* [PATCH] iwlwifi: Extended Key ID support for mvm and dvm
From: Alexander Wetzel @ 2019-08-19 18:05 UTC (permalink / raw)
To: johannes, luciano.coelho; +Cc: linux-wireless, linuxwifi, Alexander Wetzel
All iwlwifi cards below the 22000 series are able to handle multiple
keyids per STA and allow the selection of the encryption key per MPDU.
These are therefore fully compatible with the Extended Key ID support
implementation in mac80211.
Enable Extended Key ID support for all dvm cards and the mvm cards not
using the incompatible new Tx API introduced for the 22000 series.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---
This is basically the V3 of the patch, but the other patches were part
of series and this here is the first standalone version.
V1: https://patchwork.kernel.org/patch/10931879/
V2: https://patchwork.kernel.org/patch/11024137/
V1 become deprecated due to redesigning the Extended Key ID support API.
V2 became deprecated due to the discovery that the 22000 is not (yet)
able to support Extended Key ID.
The patch is still super trivial, but I cross checked that Extended Key
ID support is enabled with my old 3168 card and disabled with my new
AX200 card.
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c
index 6c170636110a..ac88c19f4f18 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c
@@ -200,6 +200,7 @@ int iwlagn_mac_setup_register(struct iwl_priv *priv,
iwl_leds_init(priv);
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
+ wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_EXT_KEY_ID);
ret = ieee80211_register_hw(priv->hw);
if (ret) {
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index b74bd58f3f45..034bf959153b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -617,6 +617,14 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
+
+ /* The new Tx API does not allow to pass the key or keyid of a MPDU to
+ * the hw, preventing us to control which key(id) to use per MPDU.
+ * Till that's fixed we can't use Extended Key ID for the newer cards.
+ */
+ if (!iwl_mvm_has_new_tx_api(mvm))
+ wiphy_ext_feature_set(hw->wiphy,
+ NL80211_EXT_FEATURE_EXT_KEY_ID);
hw->wiphy->features |= NL80211_FEATURE_HT_IBSS;
hw->wiphy->regulatory_flags |= REGULATORY_ENABLE_RELAX_NO_IR;
--
2.22.0
^ permalink raw reply related
* [PATCH 5.4] rtw88: drop unused rtw_coex_coex_dm_reset()
From: Brian Norris @ 2019-08-19 18:17 UTC (permalink / raw)
To: linux-wireless
Cc: Yan-Hsuan Chuang, Guenter Roeck, kbuild test robot, Brian Norris
From: Guenter Roeck <groeck@chromium.org>
0day reports:
sparse warnings:
drivers/net/wireless/realtek/rtw88/coex.c:2457:6: sparse:
symbol 'rtw_coex_coex_dm_reset' was not declared. Should it be static?
rtw_coex_coex_dm_reset() is not called. Remove it.
Fixes: 4136214f7c46 ("rtw88: add BT co-existence support")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/net/wireless/realtek/rtw88/coex.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/coex.c b/drivers/net/wireless/realtek/rtw88/coex.c
index 4577fceddc5e..9ee860db651a 100644
--- a/drivers/net/wireless/realtek/rtw88/coex.c
+++ b/drivers/net/wireless/realtek/rtw88/coex.c
@@ -2454,11 +2454,6 @@ void rtw_coex_wl_fwdbginfo_notify(struct rtw_dev *rtwdev, u8 *buf, u8 length)
rtw_coex_wl_ccklock_detect(rtwdev);
}
-void rtw_coex_coex_dm_reset(struct rtw_dev *rtwdev)
-{
- __rtw_coex_init_hw_config(rtwdev, false);
-}
-
void rtw_coex_wl_status_change_notify(struct rtw_dev *rtwdev)
{
struct rtw_coex *coex = &rtwdev->coex;
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* Re: [PATCH 2/2] staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)
From: Larry Finger @ 2019-08-19 17:57 UTC (permalink / raw)
To: Christina Quast, ard.biesheuvel
Cc: Greg Kroah-Hartman, Payal Kshirsagar, Eric Biggers, Herbert Xu,
devel, linux-kernel, Anushka Shukla, Bartlomiej Zolnierkiewicz,
Zach Turner, linux-wireless, Johannes Berg, David S. Miller,
linux-crypto
In-Reply-To: <20190816065936.12214-3-contact@christina-quast.de>
On 8/16/19 1:59 AM, Christina Quast wrote:
> Use ccm(aes) aead transform instead of invoking the AES block cipher
> block by block.
>
> Signed-off-by: Christina Quast <contact@christina-quast.de>
> ---
> drivers/staging/rtl8192e/Kconfig | 1 +
> drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ++++++++-----------
> 2 files changed, 78 insertions(+), 110 deletions(-)
Tested-by: Larry Finger <Larry.finger@lwfinger.net>
This change for the RTL8192E works. I do not have the hardware for testing the
equivalent change for r8192u, but as the changes look the same, that one is
likely OK as well.
Thanks for the change,
Larry
^ permalink raw reply
* [PATCH v3 22/22] iwlwifi: remove the code under IWLWIFI_PCIE_RTPM
From: Luca Coelho @ 2019-08-19 16:50 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190819165007.10181-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This flag should never be set unless integration work with the
platform is done. We don't support any platforms officially and don't
plan to do so in the near future, so we can remove this option
entirely in order to avoid having it enabled by mistake.
This has been marked with "depends on EXPERT", so there shouldn't be
many systems running with it set. And, if there are systems, they
should not be using this flag.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/Kconfig | 14 ----
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 71 -------------------
.../net/wireless/intel/iwlwifi/pcie/trans.c | 4 --
3 files changed, 89 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 235349a33a3c..7dbc0d38bb3b 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -92,20 +92,6 @@ config IWLWIFI_BCAST_FILTERING
If unsure, don't enable this option, as some programs might
expect incoming broadcasts for their normal operations.
-config IWLWIFI_PCIE_RTPM
- bool "Enable runtime power management mode for PCIe devices"
- depends on IWLMVM && PM && EXPERT
- help
- Say Y here to enable runtime power management for PCIe
- devices. If enabled, the device will go into low power mode
- when idle for a short period of time, allowing for improved
- power saving during runtime. Note that this feature requires
- a tight integration with the platform. It is not recommended
- to enable this feature without proper validation with the
- specific target platform.
-
- If unsure, say N.
-
menu "Debugging Options"
config IWLWIFI_DEBUG
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 407abc835012..2a34f074d72c 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1248,80 +1248,9 @@ int iwl_pci_fw_exit_d0i3(struct iwl_trans *trans)
return ret;
}
-#ifdef CONFIG_IWLWIFI_PCIE_RTPM
-static int iwl_pci_runtime_suspend(struct device *device)
-{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
- int ret;
-
- IWL_DEBUG_RPM(trans, "entering runtime suspend\n");
-
- if (test_bit(STATUS_DEVICE_ENABLED, &trans->status)) {
- ret = iwl_pci_fw_enter_d0i3(trans);
- if (ret < 0)
- return ret;
- }
-
- trans->system_pm_mode = IWL_PLAT_PM_MODE_D0I3;
-
- iwl_trans_d3_suspend(trans, false, false);
-
- return 0;
-}
-
-static int iwl_pci_runtime_resume(struct device *device)
-{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
- enum iwl_d3_status d3_status;
-
- IWL_DEBUG_RPM(trans, "exiting runtime suspend (resume)\n");
-
- iwl_trans_d3_resume(trans, &d3_status, false, false);
-
- if (test_bit(STATUS_DEVICE_ENABLED, &trans->status))
- return iwl_pci_fw_exit_d0i3(trans);
-
- return 0;
-}
-
-static int iwl_pci_system_prepare(struct device *device)
-{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
-
- IWL_DEBUG_RPM(trans, "preparing for system suspend\n");
-
- /* Wake the device up from runtime suspend before going to
- * platform suspend. This is needed because we don't know
- * whether wowlan any is set and, if it's not, mac80211 will
- * disconnect (in which case, we can't be in D0i3).
- */
- pm_runtime_resume(device);
-
- return 0;
-}
-
-static void iwl_pci_system_complete(struct device *device)
-{
- struct pci_dev *pdev = to_pci_dev(device);
- struct iwl_trans *trans = pci_get_drvdata(pdev);
-
- IWL_DEBUG_RPM(trans, "completing system suspend\n");
-}
-#endif /* CONFIG_IWLWIFI_PCIE_RTPM */
-
static const struct dev_pm_ops iwl_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(iwl_pci_suspend,
iwl_pci_resume)
-#ifdef CONFIG_IWLWIFI_PCIE_RTPM
- SET_RUNTIME_PM_OPS(iwl_pci_runtime_suspend,
- iwl_pci_runtime_resume,
- NULL)
- .prepare = iwl_pci_system_prepare,
- .complete = iwl_pci_system_complete,
-#endif /* CONFIG_IWLWIFI_PCIE_RTPM */
};
#define IWL_PM_OPS (&iwl_dev_pm_ops)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index a6deb61a3ab4..a423c5c6605e 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3658,11 +3658,7 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
WQ_HIGHPRI | WQ_UNBOUND, 1);
INIT_WORK(&trans_pcie->rba.rx_alloc, iwl_pcie_rx_allocator_work);
-#ifdef CONFIG_IWLWIFI_PCIE_RTPM
- trans->runtime_pm_mode = IWL_PLAT_PM_MODE_D0I3;
-#else
trans->runtime_pm_mode = IWL_PLAT_PM_MODE_DISABLED;
-#endif /* CONFIG_IWLWIFI_PCIE_RTPM */
#ifdef CONFIG_IWLWIFI_DEBUGFS
trans_pcie->fw_mon_data.state = IWL_FW_MON_DBGFS_STATE_CLOSED;
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH v3 12/22] iwlwifi: mvm: start to remove the code for d0i3
From: Luca Coelho @ 2019-08-19 16:49 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190819165007.10181-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
For runtime PM to work with d0i3 code, a lot of integration work needs
to be done with the platform (e.g. the out-of-band wake up interrupt)
and we currently don't have any platforms where this integration
happened. So, this code has been pretty much stale for a while and
when someone enables it, it just breaks things.
Therefore, to simplify the code base and make sure no one enables this
by mistake, we will remove the whole code.
This is only the very start, much more work is needed.
Remove the places where we check iwl_mvm_is_d0i3_supported
but leave all the refs, those will be removed in a different
patch.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 438a8b5b90c2..07d576d29086 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -762,12 +762,6 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
mvm->rts_threshold = IEEE80211_MAX_RTS_THRESHOLD;
#ifdef CONFIG_PM_SLEEP
- if (iwl_mvm_is_d0i3_supported(mvm) &&
- device_can_wakeup(mvm->trans->dev)) {
- mvm->wowlan.flags = WIPHY_WOWLAN_ANY;
- hw->wiphy->wowlan = &mvm->wowlan;
- }
-
if ((unified || mvm->fw->img[IWL_UCODE_WOWLAN].num_sec) &&
mvm->trans->ops->d3_suspend &&
mvm->trans->ops->d3_resume &&
@@ -1359,17 +1353,6 @@ static void iwl_mvm_restart_complete(struct iwl_mvm *mvm)
mutex_unlock(&mvm->mutex);
}
-static void iwl_mvm_resume_complete(struct iwl_mvm *mvm)
-{
- if (iwl_mvm_is_d0i3_supported(mvm) &&
- iwl_mvm_enter_d0i3_on_suspend(mvm))
- WARN_ONCE(!wait_event_timeout(mvm->d0i3_exit_waitq,
- !test_bit(IWL_MVM_STATUS_IN_D0I3,
- &mvm->status),
- HZ),
- "D0i3 exit on resume timed out\n");
-}
-
static void
iwl_mvm_mac_reconfig_complete(struct ieee80211_hw *hw,
enum ieee80211_reconfig_type reconfig_type)
@@ -1381,7 +1364,6 @@ iwl_mvm_mac_reconfig_complete(struct ieee80211_hw *hw,
iwl_mvm_restart_complete(mvm);
break;
case IEEE80211_RECONFIG_TYPE_SUSPEND:
- iwl_mvm_resume_complete(mvm);
break;
}
}
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH v3 18/22] iwlwifi: mvm: remove iwl_mvm_update_d0i3_power_mode
From: Luca Coelho @ 2019-08-19 16:50 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190819165007.10181-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Also change the signature of the power functions that won't
receive d0i3=true anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 -
.../net/wireless/intel/iwlwifi/mvm/power.c | 82 +++----------------
2 files changed, 11 insertions(+), 74 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 4a9e8ae99cac..15780e994a30 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1845,9 +1845,6 @@ iwl_mvm_beacon_filter_debugfs_parameters(struct ieee80211_vif *vif,
struct iwl_beacon_filter_cmd *cmd)
{}
#endif
-int iwl_mvm_update_d0i3_power_mode(struct iwl_mvm *mvm,
- struct ieee80211_vif *vif,
- bool enable, u32 flags);
int iwl_mvm_enable_beacon_filter(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
u32 flags);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/power.c b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
index 36f5fa1ee793..22136e4832ea 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/power.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
@@ -127,12 +127,11 @@ int iwl_mvm_beacon_filter_send_cmd(struct iwl_mvm *mvm,
static
void iwl_mvm_beacon_filter_set_cqm_params(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
- struct iwl_beacon_filter_cmd *cmd,
- bool d0i3)
+ struct iwl_beacon_filter_cmd *cmd)
{
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
- if (vif->bss_conf.cqm_rssi_thold && !d0i3) {
+ if (vif->bss_conf.cqm_rssi_thold) {
cmd->bf_energy_delta =
cpu_to_le32(vif->bss_conf.cqm_rssi_hyst);
/* fw uses an absolute value for this */
@@ -849,8 +848,7 @@ iwl_mvm_beacon_filter_debugfs_parameters(struct ieee80211_vif *vif,
static int _iwl_mvm_enable_beacon_filter(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
struct iwl_beacon_filter_cmd *cmd,
- u32 cmd_flags,
- bool d0i3)
+ u32 cmd_flags)
{
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
int ret;
@@ -859,13 +857,11 @@ static int _iwl_mvm_enable_beacon_filter(struct iwl_mvm *mvm,
vif->type != NL80211_IFTYPE_STATION || vif->p2p)
return 0;
- iwl_mvm_beacon_filter_set_cqm_params(mvm, vif, cmd, d0i3);
- if (!d0i3)
- iwl_mvm_beacon_filter_debugfs_parameters(vif, cmd);
+ iwl_mvm_beacon_filter_set_cqm_params(mvm, vif, cmd);
+ iwl_mvm_beacon_filter_debugfs_parameters(vif, cmd);
ret = iwl_mvm_beacon_filter_send_cmd(mvm, cmd, cmd_flags);
- /* don't change bf_enabled in case of temporary d0i3 configuration */
- if (!ret && !d0i3)
+ if (!ret)
mvmvif->bf_data.bf_enabled = true;
return ret;
@@ -880,12 +876,12 @@ int iwl_mvm_enable_beacon_filter(struct iwl_mvm *mvm,
.bf_enable_beacon_filter = cpu_to_le32(1),
};
- return _iwl_mvm_enable_beacon_filter(mvm, vif, &cmd, flags, false);
+ return _iwl_mvm_enable_beacon_filter(mvm, vif, &cmd, flags);
}
static int _iwl_mvm_disable_beacon_filter(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
- u32 flags, bool d0i3)
+ u32 flags)
{
struct iwl_beacon_filter_cmd cmd = {};
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
@@ -896,8 +892,7 @@ static int _iwl_mvm_disable_beacon_filter(struct iwl_mvm *mvm,
ret = iwl_mvm_beacon_filter_send_cmd(mvm, &cmd, flags);
- /* don't change bf_enabled in case of temporary d0i3 configuration */
- if (!ret && !d0i3)
+ if (!ret)
mvmvif->bf_data.bf_enabled = false;
return ret;
@@ -907,7 +902,7 @@ int iwl_mvm_disable_beacon_filter(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
u32 flags)
{
- return _iwl_mvm_disable_beacon_filter(mvm, vif, flags, false);
+ return _iwl_mvm_disable_beacon_filter(mvm, vif, flags);
}
static int iwl_mvm_power_set_ps(struct iwl_mvm *mvm)
@@ -958,7 +953,7 @@ static int iwl_mvm_power_set_ba(struct iwl_mvm *mvm,
!vif->bss_conf.ps ||
iwl_mvm_vif_low_latency(mvmvif));
- return _iwl_mvm_enable_beacon_filter(mvm, vif, &cmd, 0, false);
+ return _iwl_mvm_enable_beacon_filter(mvm, vif, &cmd, 0);
}
int iwl_mvm_power_update_ps(struct iwl_mvm *mvm)
@@ -1022,58 +1017,3 @@ int iwl_mvm_power_update_mac(struct iwl_mvm *mvm)
return 0;
}
-
-int iwl_mvm_update_d0i3_power_mode(struct iwl_mvm *mvm,
- struct ieee80211_vif *vif,
- bool enable, u32 flags)
-{
- int ret;
- struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
- struct iwl_mac_power_cmd cmd = {};
-
- if (vif->type != NL80211_IFTYPE_STATION || vif->p2p)
- return 0;
-
- if (!vif->bss_conf.assoc)
- return 0;
-
- iwl_mvm_power_build_cmd(mvm, vif, &cmd, !enable);
-
- iwl_mvm_power_log(mvm, &cmd);
-#ifdef CONFIG_IWLWIFI_DEBUGFS
- memcpy(&mvmvif->mac_pwr_cmd, &cmd, sizeof(cmd));
-#endif
- ret = iwl_mvm_send_cmd_pdu(mvm, MAC_PM_POWER_TABLE, flags,
- sizeof(cmd), &cmd);
- if (ret)
- return ret;
-
- /* configure beacon filtering */
- if (mvmvif != mvm->bf_allowed_vif)
- return 0;
-
- if (enable) {
- struct iwl_beacon_filter_cmd cmd_bf = {
- IWL_BF_CMD_CONFIG_D0I3,
- .bf_enable_beacon_filter = cpu_to_le32(1),
- };
- /*
- * When beacon storing is supported - disable beacon filtering
- * altogether - the latest beacon will be sent when exiting d0i3
- */
- if (fw_has_capa(&mvm->fw->ucode_capa,
- IWL_UCODE_TLV_CAPA_BEACON_STORING))
- ret = _iwl_mvm_disable_beacon_filter(mvm, vif, flags,
- true);
- else
- ret = _iwl_mvm_enable_beacon_filter(mvm, vif, &cmd_bf,
- flags, true);
- } else {
- if (mvmvif->bf_data.bf_enabled)
- ret = iwl_mvm_enable_beacon_filter(mvm, vif, flags);
- else
- ret = iwl_mvm_disable_beacon_filter(mvm, vif, flags);
- }
-
- return ret;
-}
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH v3 10/22] iwlwifi: mvm: fix scan config command size
From: Luca Coelho @ 2019-08-19 16:49 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190819165007.10181-1-luca@coelho.fi>
From: Beker Ayala <ayala.beker@intel.com>
Use the actual length of channels array and not the max capable length.
Signed-off-by: Beker Ayala <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index c284e6975b1b..5999b4ebd699 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@ -1205,7 +1205,7 @@ int iwl_mvm_config_scan(struct iwl_mvm *mvm)
cmd_size = sizeof(struct iwl_scan_config);
else
cmd_size = sizeof(struct iwl_scan_config_v1);
- cmd_size += mvm->fw->ucode_capa.n_scan_channels;
+ cmd_size += num_channels;
cfg = kzalloc(cmd_size, GFP_KERNEL);
if (!cfg)
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH v3 14/22] iwlwifi: mvm: remove the tx defer for d0i3
From: Luca Coelho @ 2019-08-19 16:49 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20190819165007.10181-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This is not needed anymore
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 45 +------------
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 --
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 63 -------------------
3 files changed, 1 insertion(+), 111 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index b815d2b0b2ad..cb99a07ad689 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -742,42 +742,6 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
return ret;
}
-static bool iwl_mvm_defer_tx(struct iwl_mvm *mvm,
- struct ieee80211_sta *sta,
- struct sk_buff *skb)
-{
- struct iwl_mvm_sta *mvmsta;
- bool defer = false;
-
- /*
- * double check the IN_D0I3 flag both before and after
- * taking the spinlock, in order to prevent taking
- * the spinlock when not needed.
- */
- if (likely(!test_bit(IWL_MVM_STATUS_IN_D0I3, &mvm->status)))
- return false;
-
- spin_lock(&mvm->d0i3_tx_lock);
- /*
- * testing the flag again ensures the skb dequeue
- * loop (on d0i3 exit) hasn't run yet.
- */
- if (!test_bit(IWL_MVM_STATUS_IN_D0I3, &mvm->status))
- goto out;
-
- mvmsta = iwl_mvm_sta_from_mac80211(sta);
- if (mvmsta->sta_id == IWL_MVM_INVALID_STA ||
- mvmsta->sta_id != mvm->d0i3_ap_sta_id)
- goto out;
-
- __skb_queue_tail(&mvm->d0i3_tx, skb);
-
- defer = true;
-out:
- spin_unlock(&mvm->d0i3_tx_lock);
- return defer;
-}
-
static void iwl_mvm_mac_tx(struct ieee80211_hw *hw,
struct ieee80211_tx_control *control,
struct sk_buff *skb)
@@ -822,8 +786,6 @@ static void iwl_mvm_mac_tx(struct ieee80211_hw *hw,
}
if (sta) {
- if (iwl_mvm_defer_tx(mvm, sta, skb))
- return;
if (iwl_mvm_tx_skb(mvm, skb, sta))
goto drop;
return;
@@ -1156,9 +1118,6 @@ int __iwl_mvm_mac_start(struct iwl_mvm *mvm)
* would do.
*/
clear_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status);
-#ifdef CONFIG_PM
- iwl_mvm_d0i3_enable_tx(mvm, NULL);
-#endif
}
return ret;
@@ -1196,9 +1155,7 @@ static void iwl_mvm_restart_complete(struct iwl_mvm *mvm)
mutex_lock(&mvm->mutex);
clear_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status);
-#ifdef CONFIG_PM
- iwl_mvm_d0i3_enable_tx(mvm, NULL);
-#endif
+
ret = iwl_mvm_update_quotas(mvm, true, NULL);
if (ret)
IWL_ERR(mvm, "Failed to update quotas after restart (%d)\n",
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 245e8c721102..6a79b6c49cd5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1019,12 +1019,9 @@ struct iwl_mvm {
u8 d0i3_ap_sta_id;
bool d0i3_offloading;
struct work_struct d0i3_exit_work;
- struct sk_buff_head d0i3_tx;
/* protect d0i3_suspend_flags */
struct mutex d0i3_suspend_mutex;
unsigned long d0i3_suspend_flags;
- /* sync d0i3_tx queue and IWL_MVM_STATUS_IN_D0I3 status flag */
- spinlock_t d0i3_tx_lock;
wait_queue_head_t d0i3_exit_waitq;
wait_queue_head_t rx_sync_waitq;
@@ -1861,7 +1858,6 @@ int iwl_mvm_send_proto_offload(struct iwl_mvm *mvm,
u32 cmd_flags);
#ifdef CONFIG_PM
-void iwl_mvm_d0i3_enable_tx(struct iwl_mvm *mvm, __le16 *qos_seq);
int iwl_mvm_enter_d0i3(struct iwl_op_mode *op_mode);
int iwl_mvm_exit_d0i3(struct iwl_op_mode *op_mode);
int _iwl_mvm_exit_d0i3(struct iwl_mvm *mvm);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index 255b402f7b19..e9b0aee38f35 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -713,8 +713,6 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct iwl_cfg *cfg,
INIT_WORK(&mvm->add_stream_wk, iwl_mvm_add_new_dqa_stream_wk);
INIT_LIST_HEAD(&mvm->add_stream_txqs);
- spin_lock_init(&mvm->d0i3_tx_lock);
- skb_queue_head_init(&mvm->d0i3_tx);
init_waitqueue_head(&mvm->d0i3_exit_waitq);
init_waitqueue_head(&mvm->rx_sync_waitq);
@@ -1590,62 +1588,6 @@ static void iwl_mvm_d0i3_exit_work_iter(void *_data, u8 *mac,
iwl_mvm_d0i3_update_keys(data->mvm, vif, data->status);
}
-void iwl_mvm_d0i3_enable_tx(struct iwl_mvm *mvm, __le16 *qos_seq)
-{
- struct ieee80211_sta *sta = NULL;
- struct iwl_mvm_sta *mvm_ap_sta;
- int i;
- bool wake_queues = false;
-
- lockdep_assert_held(&mvm->mutex);
-
- spin_lock_bh(&mvm->d0i3_tx_lock);
-
- if (mvm->d0i3_ap_sta_id == IWL_MVM_INVALID_STA)
- goto out;
-
- IWL_DEBUG_RPM(mvm, "re-enqueue packets\n");
-
- /* get the sta in order to update seq numbers and re-enqueue skbs */
- sta = rcu_dereference_protected(
- mvm->fw_id_to_mac_id[mvm->d0i3_ap_sta_id],
- lockdep_is_held(&mvm->mutex));
-
- if (IS_ERR_OR_NULL(sta)) {
- sta = NULL;
- goto out;
- }
-
- if (mvm->d0i3_offloading && qos_seq) {
- /* update qos seq numbers if offloading was enabled */
- mvm_ap_sta = iwl_mvm_sta_from_mac80211(sta);
- for (i = 0; i < IWL_MAX_TID_COUNT; i++) {
- u16 seq = le16_to_cpu(qos_seq[i]);
- /* firmware stores last-used one, we store next one */
- seq += 0x10;
- mvm_ap_sta->tid_data[i].seq_number = seq;
- }
- }
-out:
- /* re-enqueue (or drop) all packets */
- while (!skb_queue_empty(&mvm->d0i3_tx)) {
- struct sk_buff *skb = __skb_dequeue(&mvm->d0i3_tx);
-
- if (!sta || iwl_mvm_tx_skb(mvm, skb, sta))
- ieee80211_free_txskb(mvm->hw, skb);
-
- /* if the skb_queue is not empty, we need to wake queues */
- wake_queues = true;
- }
- clear_bit(IWL_MVM_STATUS_IN_D0I3, &mvm->status);
- wake_up(&mvm->d0i3_exit_waitq);
- mvm->d0i3_ap_sta_id = IWL_MVM_INVALID_STA;
- if (wake_queues)
- ieee80211_wake_queues(mvm->hw);
-
- spin_unlock_bh(&mvm->d0i3_tx_lock);
-}
-
static void iwl_mvm_d0i3_exit_work(struct work_struct *wk)
{
struct iwl_mvm *mvm = container_of(wk, struct iwl_mvm, d0i3_exit_work);
@@ -1655,7 +1597,6 @@ static void iwl_mvm_d0i3_exit_work(struct work_struct *wk)
struct iwl_wowlan_status *status;
u32 wakeup_reasons = 0;
- __le16 *qos_seq = NULL;
mutex_lock(&mvm->mutex);
@@ -1667,7 +1608,6 @@ static void iwl_mvm_d0i3_exit_work(struct work_struct *wk)
}
wakeup_reasons = le32_to_cpu(status->wakeup_reasons);
- qos_seq = status->qos_seq_ctr;
IWL_DEBUG_RPM(mvm, "wakeup reasons: 0x%x\n", wakeup_reasons);
@@ -1678,12 +1618,9 @@ static void iwl_mvm_d0i3_exit_work(struct work_struct *wk)
iwl_mvm_d0i3_exit_work_iter,
&iter_data);
out:
- iwl_mvm_d0i3_enable_tx(mvm, qos_seq);
-
IWL_DEBUG_INFO(mvm, "d0i3 exit completed (wakeup reasons: 0x%x)\n",
wakeup_reasons);
- /* qos_seq might point inside resp_pkt, so free it only now */
kfree(status);
/* the FW might have updated the regdomain */
--
2.23.0.rc1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox