* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Ard Biesheuvel @ 2016-10-14 8:47 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Stephen Rothwell, linux-next@vger.kernel.org,
Sergey Senozhatsky, Network Development, Sergey Senozhatsky,
Herbert Xu, David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476434561.31114.7.camel@sipsolutions.net>
On 14 October 2016 at 09:42, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
>
>> > I assume the stack buffer itself is not the problem here, but aad,
>> > which is allocated on the stack one frame up.
>> > Do we really need to revert the whole patch to fix that?
>>
>> Ah never mind, this is about 'odata'. Apologies, should have read
>> first
>
> Right, odata also goes into an sg list and further on.
>
> I think we should wait for Herbert to chime in before we do any further
> work though, perhaps he has any better ideas.
>
Do you have a reference for the sg_set_buf() call on odata?
crypto/ccm.c does not seem to have it (afaict), and the same problem
does not exist in the accelerated arm64 implementation. In the mean
time, I will try and see if we can move aad[] off the stack in the WPA
code.
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-14 8:45 UTC (permalink / raw)
To: Sergey Senozhatsky, Andy Lutomirski
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Network Development,
Sergey Senozhatsky, Herbert Xu, David S. Miller,
Linux Wireless List, linux-kernel@vger.kernel.org
In-Reply-To: <20161014083957.GA421@swordfish>
On Fri, 2016-10-14 at 17:39 +0900, Sergey Senozhatsky wrote:
>
> given that we have a known issue shouldn't VMAP_STACK be
> disabled for now, or would you rather prefer to mark MAC80211
> as incompatible: "depends on CFG80211 && !VMAP_STACK"?
Yeah. It's a bit complicated by the fact that most people will probably
have hardware crypto in their wifi NICs, so that they won't actually
hit the software crypto path. As I said in my other email though, we
can't guarantee - even if the driver says it can do hardware crypto -
that it really will do it for all frames (some might not be able to do
for management frames for example), so we also can't really catch this
at runtime ...
Making mac80211 depend on !VMAP_STACK is probably technically best, but
I fear it'll break a lot of people's configurations who don't have a
problem right now (e.g. Linus's, who probably enabled this, but I know
where he uses wifi he uses an Intel NIC that will always do HW crypto).
Andy, what do you think?
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-14 8:42 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Stephen Rothwell, linux-next@vger.kernel.org,
Sergey Senozhatsky, Network Development, Sergey Senozhatsky,
Herbert Xu, David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu_v+4D_7EvRkrSrStheuP1L-oPh=o7Ub+NU7-wgLYks4w@mail.gmail.com>
On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
> > I assume the stack buffer itself is not the problem here, but aad,
> > which is allocated on the stack one frame up.
> > Do we really need to revert the whole patch to fix that?
>
> Ah never mind, this is about 'odata'. Apologies, should have read
> first
Right, odata also goes into an sg list and further on.
I think we should wait for Herbert to chime in before we do any further
work though, perhaps he has any better ideas.
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Ard Biesheuvel @ 2016-10-14 8:41 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Stephen Rothwell, linux-next@vger.kernel.org,
Sergey Senozhatsky, Network Development, Sergey Senozhatsky,
Herbert Xu, David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu8hTy8U7FcA58P1YWt2rHU09xP9v1UU0KcnD4uuaK8How@mail.gmail.com>
On 14 October 2016 at 09:39, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 14 October 2016 at 09:28, Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>>> 1. revert that patch (doing so would need some major adjustments now,
>>> since it's pretty old and a number of new things were added in the
>>> meantime)
>>
>> This it will have to be, I guess.
>>
>>> 2. allocate a per-CPU buffer for all the things that we put on the
>>> stack and use in SG lists, those are:
>>> * CCM/GCM: AAD (32B), B_0/J_0 (16B)
>>> * GMAC: AAD (20B), zero (16B)
>>> * (not sure why CMAC isn't using this API, but it would be like GMAC)
>>
>> This doesn't work - I tried to move the mac80211 buffers, but because
>> we also put the struct aead_request on the stack, and crypto_ccm has
>> the "odata" in there, and we can't separate the odata from that struct,
>> we'd have to also put that into a per-CPU buffer, but it's very big -
>> 456 bytes for CCM, didn't measure the others but I'd expect them to be
>> larger, if different.
>>
>> I don't think we can allocate half a kb for each CPU just to be able to
>> possibly use the acceleration here. We can't even make that conditional
>> on not having hardware crypto in the wifi NIC because drivers are
>> always allowed to pass undecrypted frames, regardless of whether or not
>> HW crypto was attempted, so we don't know upfront if we'll have to
>> decrypt anything in software...
>>
>> Given that, I think we have had a bug in here basically since Ard's
>> patch, we never should've put these structs on the stack. Herbert, you
>> also touched this later and converted the API usage, did you see the
>> way the stack is used here and think it should be OK, or did you simply
>> not realize that?
>>
>> Ard, are you able to help out working on a revert of your patch? That
>> would require also reverting a number of other patches (various fixes,
>> API adjustments, etc. to the AEAD usage), but the more complicated part
>> is that in the meantime Jouni introduced GCMP and CCMP-256, both of
>> which we of course need to retain.
>>
>
> I am missing some context here, but could you explain what exactly is
> the problem here?
>
> Look at this code
>
> """
> struct scatterlist sg[3];
>
> char aead_req_data[sizeof(struct aead_request) +
> crypto_aead_reqsize(tfm)]
> __aligned(__alignof__(struct aead_request));
> struct aead_request *aead_req = (void *) aead_req_data;
>
> memset(aead_req, 0, sizeof(aead_req_data));
>
> sg_init_table(sg, 3);
> sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
> sg_set_buf(&sg[1], data, data_len);
> sg_set_buf(&sg[2], mic, mic_len);
>
> aead_request_set_tfm(aead_req, tfm);
> aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
> aead_request_set_ad(aead_req, sg[0].length);
> """
>
> I assume the stack buffer itself is not the problem here, but aad,
> which is allocated on the stack one frame up.
> Do we really need to revert the whole patch to fix that?
Ah never mind, this is about 'odata'. Apologies, should have read first
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-14 8:39 UTC (permalink / raw)
To: Andy Lutomirski, Johannes Berg
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sergey Senozhatsky,
Network Development, Sergey Senozhatsky, Herbert Xu,
David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org
In-Reply-To: <CALCETrW8imkGTtR9-mFB=e=Gdr1QXVuhXN3GRs2B6wbmPaaGhA@mail.gmail.com>
On (10/13/16 14:49), Andy Lutomirski wrote:
[..]
> > > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > > >> 39) == 130
> >
> > Yeah, we already know that in this function the aad variable is on the
> > stack, it explicitly is.
> >
> > The question, though, is why precisely that fails in the crypto code.
> > Can you send the Oops report itself?
> >
>
> It's failing before that. With CONFIG_VMAP_STACK=y, the stack may not
> be physically contiguous and can't be used for DMA, so putting it in a
> scatterlist is bogus in general, and the crypto code mostly wants a
> scatterlist.
>
> There are a couple (faster!) APIs for crypto that don't use
> scatterlists, but I don't think AEAD works with them.
given that we have a known issue shouldn't VMAP_STACK be
disabled for now, or would you rather prefer to mark MAC80211
as incompatible: "depends on CFG80211 && !VMAP_STACK"?
-ss
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Ard Biesheuvel @ 2016-10-14 8:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Stephen Rothwell, linux-next@vger.kernel.org,
Sergey Senozhatsky, Network Development, Sergey Senozhatsky,
Herbert Xu, David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476433699.31114.6.camel@sipsolutions.net>
On 14 October 2016 at 09:28, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> 1. revert that patch (doing so would need some major adjustments now,
>> since it's pretty old and a number of new things were added in the
>> meantime)
>
> This it will have to be, I guess.
>
>> 2. allocate a per-CPU buffer for all the things that we put on the
>> stack and use in SG lists, those are:
>> * CCM/GCM: AAD (32B), B_0/J_0 (16B)
>> * GMAC: AAD (20B), zero (16B)
>> * (not sure why CMAC isn't using this API, but it would be like GMAC)
>
> This doesn't work - I tried to move the mac80211 buffers, but because
> we also put the struct aead_request on the stack, and crypto_ccm has
> the "odata" in there, and we can't separate the odata from that struct,
> we'd have to also put that into a per-CPU buffer, but it's very big -
> 456 bytes for CCM, didn't measure the others but I'd expect them to be
> larger, if different.
>
> I don't think we can allocate half a kb for each CPU just to be able to
> possibly use the acceleration here. We can't even make that conditional
> on not having hardware crypto in the wifi NIC because drivers are
> always allowed to pass undecrypted frames, regardless of whether or not
> HW crypto was attempted, so we don't know upfront if we'll have to
> decrypt anything in software...
>
> Given that, I think we have had a bug in here basically since Ard's
> patch, we never should've put these structs on the stack. Herbert, you
> also touched this later and converted the API usage, did you see the
> way the stack is used here and think it should be OK, or did you simply
> not realize that?
>
> Ard, are you able to help out working on a revert of your patch? That
> would require also reverting a number of other patches (various fixes,
> API adjustments, etc. to the AEAD usage), but the more complicated part
> is that in the meantime Jouni introduced GCMP and CCMP-256, both of
> which we of course need to retain.
>
I am missing some context here, but could you explain what exactly is
the problem here?
Look at this code
"""
struct scatterlist sg[3];
char aead_req_data[sizeof(struct aead_request) +
crypto_aead_reqsize(tfm)]
__aligned(__alignof__(struct aead_request));
struct aead_request *aead_req = (void *) aead_req_data;
memset(aead_req, 0, sizeof(aead_req_data));
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
aead_request_set_tfm(aead_req, tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
"""
I assume the stack buffer itself is not the problem here, but aad,
which is allocated on the stack one frame up.
Do we really need to revert the whole patch to fix that?
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-14 8:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sergey Senozhatsky,
Network Development, Sergey Senozhatsky, Herbert Xu,
David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Ard Biesheuvel, Jouni Malinen
In-Reply-To: <1476429916.4382.12.camel@sipsolutions.net>
> 1. revert that patch (doing so would need some major adjustments now,
> since it's pretty old and a number of new things were added in the
> meantime)
This it will have to be, I guess.
> 2. allocate a per-CPU buffer for all the things that we put on the
> stack and use in SG lists, those are:
> * CCM/GCM: AAD (32B), B_0/J_0 (16B)
> * GMAC: AAD (20B), zero (16B)
> * (not sure why CMAC isn't using this API, but it would be like GMAC)
This doesn't work - I tried to move the mac80211 buffers, but because
we also put the struct aead_request on the stack, and crypto_ccm has
the "odata" in there, and we can't separate the odata from that struct,
we'd have to also put that into a per-CPU buffer, but it's very big -
456 bytes for CCM, didn't measure the others but I'd expect them to be
larger, if different.
I don't think we can allocate half a kb for each CPU just to be able to
possibly use the acceleration here. We can't even make that conditional
on not having hardware crypto in the wifi NIC because drivers are
always allowed to pass undecrypted frames, regardless of whether or not
HW crypto was attempted, so we don't know upfront if we'll have to
decrypt anything in software...
Given that, I think we have had a bug in here basically since Ard's
patch, we never should've put these structs on the stack. Herbert, you
also touched this later and converted the API usage, did you see the
way the stack is used here and think it should be OK, or did you simply
not realize that?
Ard, are you able to help out working on a revert of your patch? That
would require also reverting a number of other patches (various fixes,
API adjustments, etc. to the AEAD usage), but the more complicated part
is that in the meantime Jouni introduced GCMP and CCMP-256, both of
which we of course need to retain.
johannes
^ permalink raw reply
* [PATCH] brcmfmac: print name of connect status event
From: Rafał Miłecki @ 2016-10-14 7:45 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This simplifies debugging. Format %s (%u) comes from similar debugging
message in brcmf_fweh_event_worker.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 4 ++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h | 2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..1e7c6f0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5506,7 +5506,8 @@ brcmf_notify_connect_status_ap(struct brcmf_cfg80211_info *cfg,
u32 reason = e->reason;
struct station_info sinfo;
- brcmf_dbg(CONN, "event %d, reason %d\n", event, reason);
+ brcmf_dbg(CONN, "event %s (%u), reason %d\n",
+ brcmf_fweh_event_name(event), event, reason);
if (event == BRCMF_E_LINK && reason == BRCMF_E_REASON_LINK_BSSCFG_DIS &&
ndev != cfg_to_ndev(cfg)) {
brcmf_dbg(CONN, "AP mode link down\n");
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index 79c081f..c79306b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -69,7 +69,7 @@ static struct brcmf_fweh_event_name fweh_event_names[] = {
*
* @code: code to lookup.
*/
-static const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code)
+const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code)
{
int i;
for (i = 0; i < ARRAY_SIZE(fweh_event_names); i++) {
@@ -79,7 +79,7 @@ static const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code)
return "unknown";
}
#else
-static const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code)
+const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code)
{
return "nodebug";
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h
index 26ff5a9..5fba4b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h
@@ -287,6 +287,8 @@ struct brcmf_fweh_info {
void *data);
};
+const char *brcmf_fweh_event_name(enum brcmf_fweh_event_code code);
+
void brcmf_fweh_attach(struct brcmf_pub *drvr);
void brcmf_fweh_detach(struct brcmf_pub *drvr);
int brcmf_fweh_register(struct brcmf_pub *drvr, enum brcmf_fweh_event_code code,
--
2.9.3
^ permalink raw reply related
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Valo, Kalle @ 2016-10-14 7:34 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> This patch series is intended to prepare the ath6kl driver
> for newer chipsets that doesn't use the current WMI data
> endpoints for data traffic.
>
> The chipset I have been working with (and used for testing)
> is QCA6584. It is SDIO based (at least the variant I have
> been using) with 802.11p WAVE DSRC capabilities.
>
> This chipset is different from the AR600X family in that
> it does not use the WMI data services (service id's 0x101
> to 0x104 ) for data traffic.
> Instead it uses the HTT data service for data and wmi unified
> for control messages.
> It is also different when it comes to mailbox addresses
> and HTC header format as well, but these differences are not
> part of this patch series.
Do you have more patches implemented, like something already working or
have just started?
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support to update connection parameters
From: Johannes Berg @ 2016-10-14 7:32 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1476373178-31105-1-git-send-email-jouni@qca.qualcomm.com>
In addition to Arend's comments...
> * (invoked with the wireless_dev mutex held)
> + * @update_connect_params: Update the connect parameters while connected to a
> + * BSS. The updated parameters can be used by driver/firmware for
> + * subsequent BSS selection (roaming) decisions and to form the
> + * Authentication/(Re)Association Request frames. This call does not
> + * request an immediate disassociation or reassociation with the current
> + * BSS, i.e., this impacts only subsequence (re)associations.
The other related calls are all invoked with the wireless_dev mutex
held, I think it'd be better for consistency to replicate that here.
> +static int nl80211_update_connect_params(struct sk_buff *skb,
> + struct genl_info *info)
> +{
> + struct cfg80211_connect_params connect;
> + struct cfg80211_connect_params_valid cpv;
> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
> + struct net_device *dev = info->user_ptr[1];
> + struct wireless_dev *wdev = dev->ieee80211_ptr;
> +
> + memset(&connect, 0, sizeof(connect));
> + memset(&cpv, 0, sizeof(cpv));
I tend to prefer (0) C99 initalizers since it makes the code shorter,
but it doesn't really matter much.
> + if (!wdev->current_bss)
> + return -ENOLINK;
Also, regarding the locking, there's no guarantee that this won't
become NULL immediately after the check, if you don't have any locking.
Now, the driver (or more likely firmware!), would still have to protect
against races, say where the firmware disconnected while userspace
called this ... but at least software wise it'd be consistent.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support to update connection parameters
From: Johannes Berg @ 2016-10-14 7:27 UTC (permalink / raw)
To: Arend van Spriel, Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <61aa0cc9-6485-b206-56ce-cd682d91dd96@broadcom.com>
> > /**
> > + * struct cfg80211_connect_params_valid - Connection parame ters
> > to be updated
>
> What's in a name? Could we just use '_updated' instead of '_valid'
> here and below.
In mac80211 we typically just have a single "u32 changed" argument,
with bits defined in an enum - wouldn't that be sufficient here as
well?
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-14 7:25 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sergey Senozhatsky,
Network Development, Sergey Senozhatsky, Herbert Xu,
David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Ard Biesheuvel
In-Reply-To: <CALCETrW8imkGTtR9-mFB=e=Gdr1QXVuhXN3GRs2B6wbmPaaGhA@mail.gmail.com>
On Thu, 2016-10-13 at 14:49 -0700, Andy Lutomirski wrote:
>
> It's failing before that. With CONFIG_VMAP_STACK=y, the stack may
> not be physically contiguous and can't be used for DMA, so putting it
> in a scatterlist is bogus in general, and the crypto code mostly
> wants a scatterlist.
I see, so all this stuff is getting inlined, and we crash in
sg_set_buf() because it does sg_set_page() and that obviously needs to
do virt_to_page(), which is invalid on this address now.
With CONFIG_DEBUG_SG we'd have hit the BUG_ON there instead.
It does indeed look like AEAD doesn't have any non-SG API.
So ultimately, the bug already goes back to Ard's commit 7ec7c4a9a686
("mac80211: port CCMP to cryptoapi's CCM driver") since that already
potentially used stack space for DMA.
Since we don't have any space in the SKB or anywhere else at this point
(other than the stack that we can't use), I see two ways out of this:
1. revert that patch (doing so would need some major adjustments now,
since it's pretty old and a number of new things were added in the
meantime)
2. allocate a per-CPU buffer for all the things that we put on the
stack and use in SG lists, those are:
* CCM/GCM: AAD (32B), B_0/J_0 (16B)
* GMAC: AAD (20B), zero (16B)
* (not sure why CMAC isn't using this API, but it would be like
GMAC)
Thoughts?
johannes
^ permalink raw reply
* pull-request: wireless-drivers 2016-10-14
From: Kalle Valo @ 2016-10-14 7:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
first wireless-drivers pull request for 4.9 and this time we have
unusually many fixes even before -rc1 is released. Most important here
are the wlcore and rtlwifi commits which fix critical regressions,
otherwise smaller impact fixes and one new sdio id for ath6kl.
Please let me know if there are any problems.
Kalle
The following changes since commit 03a1eabc3f54469abd4f1784182851b2e29630cc:
Merge branch 'mlxsw-fixes' (2016-10-04 20:28:10 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-10-14
for you to fetch changes up to 1ea2643961b0d1b8d0e4a11af5aa69b0f92d0533:
ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro (2016-10-13 14:16:33 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.9
wlcore
* fix a double free regression causing hard to track crashes
rtl8xxxu
* fix driver reload issues, a memory leak and an endian bug
rtlwifi
* fix a major regression introduced in 4.9 with firmware loading on
certain hardware
ath10k
* fix regression about broken cal_data debugfs file (since 4.7)
ath9k
* revert temperature compensation for AR9003+ devices, it was causing
too much problems
ath6kl
* add Dell OEM SDIO I/O for the Venue 8 Pro
----------------------------------------------------------------
Adam Williamson (1):
ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro
Felix Fietkau (1):
Revert "ath9k_hw: implement temperature compensation support for AR9003+"
Jes Sorensen (4):
rtl8xxxu: Fix memory leak in handling rxdesc16 packets
rtl8xxxu: Fix big-endian problem reporting mactime
rtl8xxxu: Fix rtl8723bu driver reload issue
rtl8xxxu: Fix rtl8192eu driver reload issue
Larry Finger (1):
rtlwifi: Fix regression caused by commit d86e64768859
Marty Faltesek (1):
ath10k: cache calibration data when the core is stopped
Wei Yongjun (1):
wlcore: sdio: drop kfree for memory allocated with devm_kzalloc
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debug.c | 75 ++++++++++----------
drivers/net/wireless/ath/ath6kl/sdio.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 25 +------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 ++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 11 ++-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 8 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 13 ++--
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 12 ++--
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 8 +--
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 9 +--
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 12 ++--
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 18 ++---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 -
drivers/net/wireless/ti/wlcore/sdio.c | 1 -
21 files changed, 110 insertions(+), 117 deletions(-)
^ permalink raw reply
* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Rafał Miłecki @ 2016-10-14 6:33 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org,
brcm80211 development
In-Reply-To: <90e69e94-2210-22ec-3aec-67d9605b4b7c@broadcom.com>
On 10/05/2016 11:08 AM, Arend Van Spriel wrote:
> On 4-10-2016 20:15, Rafał Miłecki wrote:
>> On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
>>> I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
>>> sits in linux-firmware.git.
>>>
>>> In OpenWrt we have hostapd with a feature of banning STAs. It works in
>>> a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
>>> STA that is banned it sends NL80211_CMD_DEL_STATION.
>>>
>>> The problem is that in such case BCM43602 firmware happens to randomly
>>> send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
>>> amount between 1 and 3. Looks a bit like some kind of race. It's
>>> nothing really critical, just makes hostapd log a bit confusing.
>>>
>>> Could someone at Broadcom look at firmware source to see if you can
>>> fix this, please?
>>
>> Hey, I didn't get any reply on this for a year. I just saw similar
>> problem with
>> BCM4366. Below you will find a nice log with my extra comments.
>>
>> Could take a look at this issue this time, please?
>
> Can try.
Thank you and sorry for my late reply! I'm back home now ready to provide any
extra details.
>> I think it may be another problem related to the A-MPDU thing (bug?) I
>> reported
>> in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mail
>> thread.
>
> So what firmware version do you have? A colleague pointed me to firmware
> fix that may be related so I want to know the target string to build.
> Firmware version is in the bin file:
>
> $ hexdump -C fw.bin | tail -40
Well, I am pretty sure I was using the one released by Broadcom. Also my only
device with 4366b1 is DIR-885L. Once I was looking for 4366c0 firmware as
described in the kernel's bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=135321
but I don't think I replaced them or anything.
Anyway, I repeated my tests paying attention to the firmware file. I'm pretty
sure it's the same one you can find in:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/brcm/brcmfmac4366b-pcie.bin
root@lede:/# md5sum /lib/firmware/brcm/brcmfmac4366b-pcie.bin
596f13d84e0042035cdb41202cfc385a /lib/firmware/brcm/brcmfmac4366b-pcie.bin
root@lede:/# hexdump -C /lib/firmware/brcm/brcmfmac4366b-pcie.bin | tail -40
000f1670 40 00 03 07 07 07 40 00 03 07 07 07 40 00 03 07 |@.....@.....@...|
000f1680 07 07 40 00 72 61 74 65 73 65 6c 00 73 74 66 00 |..@.ratesel.stf.|
000f1690 63 63 6b 5f 6f 6e 65 63 6f 72 65 5f 74 78 00 74 |cck_onecore_tx.t|
000f16a0 65 6d 70 73 5f 70 65 72 69 6f 64 00 74 78 63 68 |emps_period.txch|
000f16b0 61 69 6e 00 72 78 63 68 61 69 6e 00 4d cc 07 00 |ain.rxchain.M...|
000f16c0 69 44 26 00 71 c9 07 00 91 c6 07 00 2d e9 ff 41 |iD&.q.......-..A|
000f16d0 80 46 4f f4 40 70 0d 46 17 46 1e 46 1f f5 4c ff |.FO.@p.F.F.F..L.|
000f16e0 04 46 48 b9 28 46 1f f5 4d ff 02 46 23 49 24 48 |.FH.(F..M..F#I$H|
000f16f0 13 f7 24 fb 1e 20 3e e0 00 21 4f f4 40 72 12 f5 |..$.. >..!O.@r..|
000f1700 9d fd 0a 9b 40 46 00 93 04 f1 f8 03 01 93 04 f1 |....@F..........|
000f1710 fc 03 02 93 29 46 3a 46 33 46 e0 f7 5f fa c4 f8 |....)F:F3F.._...|
000f1720 f4 00 28 b9 17 48 15 49 0b 25 13 f7 07 fb 1e e0 |..(..H.I.%......|
000f1730 00 22 40 f6 12 01 00 25 22 f5 26 fb c4 f8 00 01 |."@....%".&.....|
000f1740 40 f6 12 01 d4 f8 f4 00 22 f5 06 fa c4 f8 e8 00 |@.......".......|
000f1750 20 46 51 f7 8d fb 0c 21 00 22 20 46 51 f7 94 fb | FQ....!." FQ...|
000f1760 20 46 4d f7 69 f8 d4 f8 f4 00 df f7 d1 fe 20 46 | FM.i......... F|
000f1770 1f f5 16 ff 28 46 04 b0 bd e8 f0 81 88 17 2f 00 |....(F......../.|
000f1780 97 1b 2a 00 e2 f1 29 00 77 6c 63 5f 62 6d 61 63 |..*...).wlc_bmac|
000f1790 5f 70 72 6f 63 65 73 73 5f 75 63 6f 64 65 5f 73 |_process_ucode_s|
000f17a0 72 00 00 00 84 73 3b b4 0a 0a 45 ed 3d 22 90 56 |r....s;...E.=".V|
000f17b0 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 a4 |................|
000f17c0 91 7a c4 13 01 bd 32 08 01 00 34 33 36 36 62 31 |.z....2...4366b1|
000f17d0 2d 72 6f 6d 6c 2f 70 63 69 65 2d 61 67 2d 73 70 |-roml/pcie-ag-sp|
000f17e0 6c 69 74 72 78 2d 66 64 61 70 2d 6d 62 73 73 2d |litrx-fdap-mbss-|
000f17f0 6d 66 70 2d 77 6e 6d 2d 6f 73 65 6e 2d 77 6c 31 |mfp-wnm-osen-wl1|
000f1800 31 6b 2d 77 6c 31 31 75 2d 74 78 62 66 2d 70 6b |1k-wl11u-txbf-pk|
000f1810 74 63 74 78 2d 61 6d 73 64 75 74 78 2d 61 6d 70 |tctx-amsdutx-amp|
000f1820 64 75 72 65 74 72 79 2d 63 68 6b 64 32 68 64 6d |duretry-chkd2hdm|
000f1830 61 2d 70 72 6f 70 74 78 73 74 61 74 75 73 2d 31 |a-proptxstatus-1|
000f1840 31 6e 70 72 6f 70 2d 6f 62 73 73 2d 64 62 77 73 |1nprop-obss-dbws|
000f1850 77 2d 72 69 6e 67 65 72 2d 64 6d 61 69 6e 64 65 |w-ringer-dmainde|
000f1860 78 31 36 2d 62 67 64 66 73 20 56 65 72 73 69 6f |x16-bgdfs Versio|
000f1870 6e 3a 20 31 30 2e 31 30 2e 36 39 2e 32 33 37 20 |n: 10.10.69.237 |
000f1880 43 52 43 3a 20 34 62 63 34 38 63 37 62 20 44 61 |CRC: 4bc48c7b Da|
000f1890 74 65 3a 20 46 72 69 20 32 30 31 36 2d 30 31 2d |te: Fri 2016-01-|
000f18a0 30 38 20 31 32 3a 35 35 3a 32 35 20 50 53 54 20 |08 12:55:25 PST |
000f18b0 55 63 6f 64 65 20 56 65 72 3a 20 31 30 37 33 2e |Ucode Ver: 1073.|
000f18c0 35 33 31 20 46 57 49 44 3a 20 30 31 2d 63 34 37 |531 FWID: 01-c47|
000f18d0 61 39 31 61 34 0a 00 0d 01 |a91a4....|
000f18d9
And there is a log using that very firmware I verified above.
# I got some timeouts, this time without ampdu_dbg or wlc_ampdu_watchdog
Fri Oct 14 06:09:07 2016 kern.err kernel: [ 437.579199] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
Fri Oct 14 06:09:08 2016 kern.err kernel: [ 438.529199] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
# Firmware sends BRCMF_E_DEAUTH and BRCMF_E_DISASSOC_IND events.
# My smartphone never receives deauth/disassoc and it believes it's still
# connected to the AP.
Fri Oct 14 06:09:12 2016 kern.debug kernel: [ 442.276363] brcmfmac: CONSOLE: 027172.113 wl0: Proxy STA 78:d6:f0:9b:ba:bc link is already gone !!??
Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276405] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 3
Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276447] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 3
Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
# My smartphone starts sending packets. Firmware reacts by sending
# BRCMF_E_DEAUTH events to the driver.
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.213534] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321590] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321918] brcmfmac: brcmf_notify_connect_status_ap: event 5, reason 7
Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Valo, Kalle @ 2016-10-14 4:32 UTC (permalink / raw)
To: Steve deRosier; +Cc: Erik Stromdahl, linux-wireless
In-Reply-To: <CALupW3CrY5sZYBcx5Bd3E_M_Kx2sx8_N9h_uexvg_DSO0c-tJA@mail.gmail.com>
Steve deRosier <derosier@gmail.com> writes:
> Hi Eric,
>
> On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
> <erik.stromdahl@gmail.com> wrote:
>> This patch series is intended to prepare the ath6kl driver
>> for newer chipsets that doesn't use the current WMI data
>> endpoints for data traffic.
>>
>> The chipset I have been working with (and used for testing)
>> is QCA6584. It is SDIO based (at least the variant I have
>> been using) with 802.11p WAVE DSRC capabilities.
>>
>> This chipset is different from the AR600X family in that
>> it does not use the WMI data services (service id's 0x101
>> to 0x104 ) for data traffic.
>> Instead it uses the HTT data service for data and wmi unified
>> for control messages.
>> It is also different when it comes to mailbox addresses
>> and HTC header format as well, but these differences are not
>> part of this patch series.
>>
>
> I've only taken a quick look and I'll make specific comments to
> specific patches later, but I've got to ask the question, should these
> changes go into ath6kl or be a new driver?
>
> Just because the number starts with 6000 doesn't mean it's a ath6kl
> chip. The 10k series chips all start with 9000 for example, but they
> rate their own driver.
>
> You state that all of the underpinnings of the communication with the
> chip are totally different:
> * Doesn't use WMI
> * Different mailboxing
> * Different HTC layer
>
> If all of the commands and all of the communication layers to the chip
> are totally different, then perhaps it isn't an ath6kl chip. So if
> it's largely similar, then OK, but seems to me with the changes you're
> saying above, it's mostly different.
>
> I'm saying all that without any knowledge of this chip. My experience
> is limited to various versions of the 6003 and 6004 chips.
Exactly what I was thinking. When I saw terms like "HTT" and "unified
WMI" my first thought was that is this actually an ath10k based design?
The product numbers really don't give any indication what driver
supports, the division goes something like this:
* ath9k: "non-mobile" 11n chips
* ath6k: mobile 11n chips
* ath10k: mobile and "non-mobile" 11ac chips
For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
only supports PCI bus at the moment, but I'm hoping someone would add
USB and SDIO support. Patches are very welcome.
I'm starting to suspect that QCA6584 is actually based on the same
design as QCA6174. If that's the case when we should also think if
instead we should add SDIO support to ath10k, maybe by taking relevant
parts from ath6kl?
I'll investigate more what this QCA6584 is, I haven't heard about it
before.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Steve deRosier @ 2016-10-13 23:57 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
Hi Eric,
On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
<erik.stromdahl@gmail.com> wrote:
> This patch series is intended to prepare the ath6kl driver
> for newer chipsets that doesn't use the current WMI data
> endpoints for data traffic.
>
> The chipset I have been working with (and used for testing)
> is QCA6584. It is SDIO based (at least the variant I have
> been using) with 802.11p WAVE DSRC capabilities.
>
> This chipset is different from the AR600X family in that
> it does not use the WMI data services (service id's 0x101
> to 0x104 ) for data traffic.
> Instead it uses the HTT data service for data and wmi unified
> for control messages.
> It is also different when it comes to mailbox addresses
> and HTC header format as well, but these differences are not
> part of this patch series.
>
I've only taken a quick look and I'll make specific comments to
specific patches later, but I've got to ask the question, should these
changes go into ath6kl or be a new driver?
Just because the number starts with 6000 doesn't mean it's a ath6kl
chip. The 10k series chips all start with 9000 for example, but they
rate their own driver.
You state that all of the underpinnings of the communication with the
chip are totally different:
* Doesn't use WMI
* Different mailboxing
* Different HTC layer
If all of the commands and all of the communication layers to the chip
are totally different, then perhaps it isn't an ath6kl chip. So if
it's largely similar, then OK, but seems to me with the changes you're
saying above, it's mostly different.
I'm saying all that without any knowledge of this chip. My experience
is limited to various versions of the 6003 and 6004 chips.
Just trying to stimulate discussion here.
Thanks,
- Steve
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Andy Lutomirski @ 2016-10-13 21:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Stephen Rothwell, linux-next@vger.kernel.org, Sergey Senozhatsky,
Network Development, Sergey Senozhatsky, Herbert Xu,
David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org
In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net>
On Oct 13, 2016 6:46 AM, "Johannes Berg" <johannes@sipsolutions.net> wrote:
>
> On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:
> >
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> > >
> > > That truly sounds like something we'd rather avoid in the TX/RX
> > > paths though, which should perform well.
> >
> > didn't fix.
>
> It couldn't, since the new helpers weren't used in mac80211 in those
> patches yet.
>
> > so I finally had some time to do a better bug-reporter job.
> >
> > I added a bunch of printk-s and several virt_addr_valid()-s
> > to ieee80211_aes_ccm_encrypt().
> >
> > and right befoe the Oops I see the following report from
> > virt_addr_valid()
> >
> >
> > FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02
> > >> 39) == 130
>
> Yeah, we already know that in this function the aad variable is on the
> stack, it explicitly is.
>
> The question, though, is why precisely that fails in the crypto code.
> Can you send the Oops report itself?
>
It's failing before that. With CONFIG_VMAP_STACK=y, the stack may not
be physically contiguous and can't be used for DMA, so putting it in a
scatterlist is bogus in general, and the crypto code mostly wants a
scatterlist.
There are a couple (faster!) APIs for crypto that don't use
scatterlists, but I don't think AEAD works with them.
--Andy
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support to update connection parameters
From: Arend van Spriel @ 2016-10-13 18:58 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1476373178-31105-1-git-send-email-jouni@qca.qualcomm.com>
On 13-10-16 17:39, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> Add functionality to update the connection parameters when in connected
> state, so that driver/firmware uses the updated parameters for
> subsequent roaming. This is for drivers that support internal BSS
> selection and roaming. The new command does not change the current
> association state, i.e., it can be used to update IE contents for future
> (re)associations without causing an immediate disassociation or
> reassociation with the current BSS.
>
> This commit implements the required functionality for updating IEs for
> (Re)Association Request frame only. Other parameters can be added in
> future when required.
>
> Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
> ---
> include/net/cfg80211.h | 22 ++++++++++++++++++++++
> include/uapi/linux/nl80211.h | 7 +++++++
> net/wireless/core.h | 4 ++++
> net/wireless/nl80211.c | 33 +++++++++++++++++++++++++++++++++
> net/wireless/rdev-ops.h | 13 +++++++++++++
> net/wireless/sme.c | 10 ++++++++++
> net/wireless/trace.h | 19 +++++++++++++++++++
> 7 files changed, 108 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 5000ec7..a4fc28a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2044,6 +2044,18 @@ struct cfg80211_connect_params {
> };
>
> /**
> + * struct cfg80211_connect_params_valid - Connection parame ters to be updated
What's in a name? Could we just use '_updated' instead of '_valid' here
and below.
> + *
> + * This structure provides information of all connect parameters that
> + * have to be updated as part of update_connect_params() call.
> + *
> + * @assoc_ies_valid: Indicates whether association request IEs are updated
> + */
> +struct cfg80211_connect_params_valid {
> + bool assoc_ies_valid;
> +};
> +
> +/**
> * enum wiphy_params_flags - set_wiphy_params bitfield values
> * @WIPHY_PARAM_RETRY_SHORT: wiphy->retry_short has changed
> * @WIPHY_PARAM_RETRY_LONG: wiphy->retry_long has changed
> @@ -2564,6 +2576,12 @@ struct cfg80211_nan_func {
> * cases, the result of roaming is indicated with a call to
> * cfg80211_roamed() or cfg80211_roamed_bss().
> * (invoked with the wireless_dev mutex held)
> + * @update_connect_params: Update the connect parameters while connected to a
> + * BSS. The updated parameters can be used by driver/firmware for
> + * subsequent BSS selection (roaming) decisions and to form the
> + * Authentication/(Re)Association Request frames. This call does not
> + * request an immediate disassociation or reassociation with the current
> + * BSS, i.e., this impacts only subsequence (re)associations.
typo: should be 'subsequent' (I think ;-) ).
> * @disconnect: Disconnect from the BSS/ESS. Once done, call
> * cfg80211_disconnected().
> * (invoked with the wireless_dev mutex held)
> @@ -2848,6 +2866,10 @@ struct cfg80211_ops {
>
> int (*connect)(struct wiphy *wiphy, struct net_device *dev,
> struct cfg80211_connect_params *sme);
> + int (*update_connect_params)(struct wiphy *wiphy,
> + struct net_device *dev,
> + struct cfg80211_connect_params *sme,
> + struct cfg80211_connect_params_valid *cpv);
If the struct is renamed as proposed earlier the parameter might be
called 'cpu' although that might confuse code readers :-p
> int (*disconnect)(struct wiphy *wiphy, struct net_device *dev,
> u16 reason_code);
>
[...]
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index a77db33..93106da 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -1073,6 +1073,16 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
> return 0;
> }
>
> +int cfg80211_update_connect_params(struct cfg80211_registered_device *rdev,
> + struct net_device *dev,
> + struct cfg80211_connect_params *connect,
> + struct cfg80211_connect_params_valid *cpv)
> +{
> + if (rdev->ops->update_connect_params)
> + return rdev_update_connect_params(rdev, dev, connect, cpv);
> + return 0;
> +}
So why is this function added in sme.c. It does not do an awful lot so
is there still something up your sleeve by which this makes more sense?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 17:49 UTC (permalink / raw)
To: Paul Bolle, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476363353.1999.17.camel@tiscali.nl>
On Thu, 2016-10-13 at 14:55 +0200, Paul Bolle wrote:
> On Thu, 2016-10-13 at 15:44 +0300, Luca Coelho wrote:
> > Even though there is apparently something wrong with this part of the
> > ACPI table on you laptop, since it doesn't match our specifications.
> > In any case, it's mostly harmless.
>
>
> Would a correct implementation by Dell have any benefits for the users
> of these laptops? In other words: should I bother somehow contacting
> Dell and point them to this discussion in order to have them fix this?
This value provides a way for the OEM to fine tune the power budget of
the device. This is (usually) used to prevent parts of the platform
from getting too hot. We have a certain default that is good enough
for most cases. If Dell didn't want to set proper limits for this
device, it probably means that it is not a concern. Dell does set
these values correctly for other platforms.
So, I guess it's up to you if you want to clarify this with them. This
could be some default "blank" values when they don't want to change
them.
--
Luca.
^ permalink raw reply
* [RFC 5/5] ath6kl: service connect rewrite
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
This patch removes the hardcoded struct
htc_service_connect_req from ath6kl_init_service_ep and adds
an array of struct htc_service_connect_req's to each element
in hw_list.
The rationale behind this patch is to make it possible to select
which services to connect to depending on chipset.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/core.h | 3 +
drivers/net/wireless/ath/ath6kl/htc-ops.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 2 +-
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 2 +-
drivers/net/wireless/ath/ath6kl/init.c | 187 +++++++++++++++++------------
6 files changed, 117 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index ac25f17..f907ef4 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -799,6 +799,9 @@ struct ath6kl {
const char *testscript;
} fw;
+ const struct htc_service_connect_req *services;
+ u32 service_count;
+
const char *fw_board;
const char *fw_default_board;
} hw;
diff --git a/drivers/net/wireless/ath/ath6kl/htc-ops.h b/drivers/net/wireless/ath/ath6kl/htc-ops.h
index 2d4eed5..80700a4 100644
--- a/drivers/net/wireless/ath/ath6kl/htc-ops.h
+++ b/drivers/net/wireless/ath/ath6kl/htc-ops.h
@@ -36,7 +36,7 @@ static inline int ath6kl_htc_start(struct htc_target *target)
}
static inline int ath6kl_htc_conn_service(struct htc_target *target,
- struct htc_service_connect_req *req,
+ const struct htc_service_connect_req *req,
struct htc_service_connect_resp *resp)
{
return target->dev->ar->htc_ops->conn_service(target, req, resp);
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 532b13b..bfff466 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -550,7 +550,7 @@ struct ath6kl_htc_ops {
int (*wait_target)(struct htc_target *target);
int (*start)(struct htc_target *target);
int (*conn_service)(struct htc_target *target,
- struct htc_service_connect_req *req,
+ const struct htc_service_connect_req *req,
struct htc_service_connect_resp *resp);
int (*tx)(struct htc_target *target, struct htc_packet *packet);
void (*stop)(struct htc_target *target);
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index eed3939..24fb9a7 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -2386,7 +2386,7 @@ static void ath6kl_htc_mbox_flush_rx_buf(struct htc_target *target)
}
static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
- struct htc_service_connect_req *conn_req,
+ const struct htc_service_connect_req *conn_req,
struct htc_service_connect_resp *conn_resp)
{
struct htc_packet *rx_pkt = NULL;
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index 93aac63..9a39f3d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -1226,7 +1226,7 @@ static u8 htc_get_credit_alloc(struct htc_target *target, u16 service_id)
}
static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
- struct htc_service_connect_req *conn_req,
+ const struct htc_service_connect_req *conn_req,
struct htc_service_connect_resp *conn_resp)
{
struct ath6kl *ar = target->dev->ar;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 58fb227..a4c7abe 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -32,6 +32,94 @@
#include "hif-ops.h"
#include "htc-ops.h"
+const struct htc_service_connect_req ar600x_services[] = {
+ {
+ .svc_id = WMI_CONTROL_SVC,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ },
+ {
+ .svc_id = WMI_DATA_BE_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ {
+ .svc_id = WMI_DATA_BK_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ {
+ .svc_id = WMI_DATA_VI_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+ /* VO service, this is currently not mapped to a WMI
+ * priority stream due to historical reasons. WMI originally
+ * defined 3 priorities over 3 mailboxes We can change this when
+ * WMI is reworked so that priorities are not dependent on
+ * mailboxes.
+ */
+ {
+ .svc_id = WMI_DATA_VO_SVC,
+ .conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+ HTC_CONN_FLGS_THRESH_LVL_HALF,
+ .ep_cb = {
+ .tx_comp_multi = ath6kl_tx_complete,
+ .rx = ath6kl_rx,
+ .rx_refill = ath6kl_rx_refill,
+ .tx_full = ath6kl_tx_queue_full,
+ .rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+ .rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+ .rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+ },
+ .max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+ .flags = HTC_FLGS_TX_BNDL_PAD_EN,
+ .max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+ },
+};
+
static const struct ath6kl_hw hw_list[] = {
{
.id = AR6003_HW_2_0_VERSION,
@@ -57,6 +145,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6003_HW_2_0_BOARD_DATA_FILE,
.fw_default_board = AR6003_HW_2_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6003_HW_2_1_1_VERSION,
@@ -82,6 +172,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6003_HW_2_1_1_BOARD_DATA_FILE,
.fw_default_board = AR6003_HW_2_1_1_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_0_VERSION,
@@ -102,6 +194,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_0_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_1_VERSION,
@@ -121,6 +215,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_1_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_1_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_2_VERSION,
@@ -140,6 +236,8 @@ static const struct ath6kl_hw hw_list[] = {
},
.fw_board = AR6004_HW_1_2_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_2_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_1_3_VERSION,
@@ -163,6 +261,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_1_3_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_1_3_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
{
.id = AR6004_HW_3_0_VERSION,
@@ -186,6 +286,8 @@ static const struct ath6kl_hw hw_list[] = {
.fw_board = AR6004_HW_3_0_BOARD_DATA_FILE,
.fw_default_board = AR6004_HW_3_0_DEFAULT_BOARD_DATA_FILE,
+ .services = ar600x_services,
+ .service_count = ARRAY_SIZE(ar600x_services),
},
};
@@ -280,8 +382,7 @@ static inline void set_ac2_ep_map(struct ath6kl *ar,
/* connect to a service */
static int ath6kl_connectservice(struct ath6kl *ar,
- struct htc_service_connect_req *con_req,
- char *desc)
+ const struct htc_service_connect_req *con_req)
{
int status;
struct htc_service_connect_resp response;
@@ -290,8 +391,8 @@ static int ath6kl_connectservice(struct ath6kl *ar,
status = ath6kl_htc_conn_service(ar->htc_target, con_req, &response);
if (status) {
- ath6kl_err("failed to connect to %s service status:%d\n",
- desc, status);
+ ath6kl_err("failed to connect to %x service status: %d\n",
+ con_req->svc_id, status);
return status;
}
@@ -323,80 +424,12 @@ static int ath6kl_connectservice(struct ath6kl *ar,
static int ath6kl_init_service_ep(struct ath6kl *ar)
{
- struct htc_service_connect_req connect;
-
- memset(&connect, 0, sizeof(connect));
-
- /* these fields are the same for all service endpoints */
- connect.ep_cb.tx_comp_multi = ath6kl_tx_complete;
- connect.ep_cb.rx = ath6kl_rx;
- connect.ep_cb.rx_refill = ath6kl_rx_refill;
- connect.ep_cb.tx_full = ath6kl_tx_queue_full;
-
- /*
- * Set the max queue depth so that our ath6kl_tx_queue_full handler
- * gets called.
- */
- connect.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH;
- connect.ep_cb.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4;
- if (!connect.ep_cb.rx_refill_thresh)
- connect.ep_cb.rx_refill_thresh++;
-
- /* connect to control service */
- connect.svc_id = WMI_CONTROL_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI CONTROL"))
- return -EIO;
-
- connect.flags |= HTC_FLGS_TX_BNDL_PAD_EN;
-
- /*
- * Limit the HTC message size on the send path, although e can
- * receive A-MSDU frames of 4K, we will only send ethernet-sized
- * (802.3) frames on the send path.
- */
- connect.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH;
-
- /*
- * To reduce the amount of committed memory for larger A_MSDU
- * frames, use the recv-alloc threshold mechanism for larger
- * packets.
- */
- connect.ep_cb.rx_alloc_thresh = ATH6KL_BUFFER_SIZE;
- connect.ep_cb.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf;
-
- /*
- * For the remaining data services set the connection flag to
- * reduce dribbling, if configured to do so.
- */
- connect.conn_flags |= HTC_CONN_FLGS_REDUCE_CRED_DRIB;
- connect.conn_flags &= ~HTC_CONN_FLGS_THRESH_MASK;
- connect.conn_flags |= HTC_CONN_FLGS_THRESH_LVL_HALF;
-
- connect.svc_id = WMI_DATA_BE_SVC;
-
- if (ath6kl_connectservice(ar, &connect, "WMI DATA BE"))
- return -EIO;
-
- /* connect to back-ground map this to WMI LOW_PRI */
- connect.svc_id = WMI_DATA_BK_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA BK"))
- return -EIO;
-
- /* connect to Video service, map this to HI PRI */
- connect.svc_id = WMI_DATA_VI_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA VI"))
- return -EIO;
+ int i;
- /*
- * Connect to VO service, this is currently not mapped to a WMI
- * priority stream due to historical reasons. WMI originally
- * defined 3 priorities over 3 mailboxes We can change this when
- * WMI is reworked so that priorities are not dependent on
- * mailboxes.
- */
- connect.svc_id = WMI_DATA_VO_SVC;
- if (ath6kl_connectservice(ar, &connect, "WMI DATA VO"))
- return -EIO;
+ for (i = 0; i < ar->hw.service_count; i++) {
+ if (ath6kl_connectservice(ar, &ar->hw.services[i]))
+ return -EIO;
+ }
return 0;
}
--
2.1.4
^ permalink raw reply related
* [RFC 3/5] ath6kl: Added disable credit flow ctrl for mbox
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
Added support for disabling credit flow control for htc_mbox
in a similar way as htc_pipe.
The tx_credit_flow_enabled member was moved out from the pipe
struct in struct htc_endpoint since it is now used by htc_mbox
as well.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 18 ++++++++++++++++--
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 14 +++++++-------
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 112d8a9..532b13b 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -521,12 +521,12 @@ struct htc_endpoint {
u32 conn_flags;
struct htc_endpoint_stats ep_st;
u16 tx_drop_packet_threshold;
+ bool tx_credit_flow_enabled;
struct {
u8 pipeid_ul;
u8 pipeid_dl;
struct list_head tx_lookup_queue;
- bool tx_credit_flow_enabled;
} pipe;
};
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 6e8c493..2c4477d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -603,7 +603,7 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
struct htc_endpoint *endpoint,
struct list_head *queue)
{
- int req_cred;
+ int req_cred = 0;
u8 flags;
struct htc_packet *packet;
unsigned int len;
@@ -623,7 +623,8 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
len = CALC_TXRX_PADDED_LEN(target,
packet->act_len + HTC_HDR_LENGTH);
- if (htc_check_credits(target, endpoint, &flags,
+ if (endpoint->tx_credit_flow_enabled &&
+ htc_check_credits(target, endpoint, &flags,
packet->endpoint, len, &req_cred))
break;
@@ -2434,6 +2435,7 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
struct htc_conn_service_msg *conn_msg;
struct htc_endpoint *endpoint;
enum htc_endpoint_id assigned_ep = ENDPOINT_MAX;
+ bool disable_credit_flowctrl = false;
unsigned int max_msg_sz = 0;
int status = 0;
u16 msg_id;
@@ -2459,6 +2461,10 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
conn_msg->svc_id = cpu_to_le16(conn_req->svc_id);
conn_msg->conn_flags = cpu_to_le16(conn_req->conn_flags);
+ if (conn_req->conn_flags &
+ HTC_CONN_FLGS_DISABLE_CRED_FLOW_CTRL)
+ disable_credit_flowctrl = true;
+
set_htc_pkt_info(tx_pkt, NULL, (u8 *) conn_msg,
sizeof(*conn_msg) + conn_msg->svc_meta_len,
ENDPOINT_0, HTC_SERVICE_TX_PACKET_TAG);
@@ -2562,6 +2568,13 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
/* save local connection flags */
endpoint->conn_flags = conn_req->flags;
+ if (disable_credit_flowctrl && endpoint->tx_credit_flow_enabled) {
+ endpoint->tx_credit_flow_enabled = false;
+ ath6kl_dbg(ATH6KL_DBG_HTC,
+ "SVC: 0x%4.4X ep:%d TX flow control off\n",
+ endpoint->svc_id, assigned_ep);
+ }
+
fail_tx:
if (tx_pkt)
htc_reclaim_txctrl_buf(target, tx_pkt);
@@ -2590,6 +2603,7 @@ static void reset_ep_state(struct htc_target *target)
INIT_LIST_HEAD(&endpoint->rx_bufq);
INIT_LIST_HEAD(&endpoint->txq);
endpoint->target = target;
+ endpoint->tx_credit_flow_enabled = true;
}
/* reset distribution list */
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index ca1a18c..93aac63 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -408,7 +408,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
}
}
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
tx_resources =
ath6kl_hif_pipe_get_free_queue_number(ar,
ep->pipe.pipeid_ul);
@@ -452,7 +452,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
if (get_queue_depth(&ep->txq) == 0)
break;
- if (ep->pipe.tx_credit_flow_enabled) {
+ if (ep->tx_credit_flow_enabled) {
/*
* Credit based mechanism provides flow control
* based on target transmit resource availability,
@@ -482,7 +482,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
/* send what we can */
htc_issue_packets(target, ep, &send_queue);
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
pipeid = ep->pipe.pipeid_ul;
tx_resources =
ath6kl_hif_pipe_get_free_queue_number(ar, pipeid);
@@ -768,7 +768,7 @@ static int ath6kl_htc_pipe_tx_complete(struct ath6kl *ar, struct sk_buff *skb)
}
skb = NULL;
- if (!ep->pipe.tx_credit_flow_enabled) {
+ if (!ep->tx_credit_flow_enabled) {
/*
* note: when using TX credit flow, the re-checking of queues
* happens when credits flow back from the target. in the
@@ -1194,7 +1194,7 @@ static void reset_endpoint_states(struct htc_target *target)
INIT_LIST_HEAD(&ep->pipe.tx_lookup_queue);
INIT_LIST_HEAD(&ep->rx_bufq);
ep->target = target;
- ep->pipe.tx_credit_flow_enabled = true;
+ ep->tx_credit_flow_enabled = true;
}
}
@@ -1399,8 +1399,8 @@ static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
ep->svc_id, ep->pipe.pipeid_ul,
ep->pipe.pipeid_dl, ep->eid);
- if (disable_credit_flowctrl && ep->pipe.tx_credit_flow_enabled) {
- ep->pipe.tx_credit_flow_enabled = false;
+ if (disable_credit_flowctrl && ep->tx_credit_flow_enabled) {
+ ep->tx_credit_flow_enabled = false;
ath6kl_dbg(ATH6KL_DBG_HTC,
"SVC: 0x%4.4X ep:%d TX flow control off\n",
ep->svc_id, assigned_epid);
--
2.1.4
^ permalink raw reply related
* [RFC 4/5] ath6kl: Updated credit setup
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
This patch simplifies the credit setup and removes a dependency
from htc_mbox.c.
The service priority (the order in which the endpoint credits are
added in target->cred_dist_list) is now determined by the sequence
in which the host connects to services.
The HTC control endpoint will have highest prio (just as before) since
it is the first endpoint that is connected (done in htc_wait_target).
The remaining service prio's will be prioritized in the order in
which they are connected.
The rationale behind this patch is to remove the service
dependecies (the prio list in ath6kl_htc_mbox_credit_setup) from
htc_mbox.c.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 50 ++++++------------------------
1 file changed, 9 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 2c4477d..eed3939 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -29,9 +29,6 @@ static void ath6kl_htc_mbox_cleanup(struct htc_target *target);
static void ath6kl_htc_mbox_stop(struct htc_target *target);
static int ath6kl_htc_mbox_add_rxbuf_multiple(struct htc_target *target,
struct list_head *pkt_queue);
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
- struct ath6kl_htc_credit_info *cred_info,
- u16 svc_pri_order[], int len);
/* threshold to re-enable Tx bundling for an AC*/
#define TX_RESUME_BUNDLE_THRESHOLD 1500
@@ -146,18 +143,9 @@ static void ath6kl_credit_init(struct ath6kl_htc_credit_info *cred_info,
static int ath6kl_htc_mbox_credit_setup(struct htc_target *htc_target,
struct ath6kl_htc_credit_info *cred_info)
{
- u16 servicepriority[5];
-
memset(cred_info, 0, sizeof(struct ath6kl_htc_credit_info));
- servicepriority[0] = WMI_CONTROL_SVC; /* highest */
- servicepriority[1] = WMI_DATA_VO_SVC;
- servicepriority[2] = WMI_DATA_VI_SVC;
- servicepriority[3] = WMI_DATA_BE_SVC;
- servicepriority[4] = WMI_DATA_BK_SVC; /* lowest */
-
- /* set priority list */
- ath6kl_htc_set_credit_dist(htc_target, cred_info, servicepriority, 5);
+ htc_target->credit_info = cred_info;
return 0;
}
@@ -1094,34 +1082,6 @@ static int htc_setup_tx_complete(struct htc_target *target)
return status;
}
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
- struct ath6kl_htc_credit_info *credit_info,
- u16 srvc_pri_order[], int list_len)
-{
- struct htc_endpoint *endpoint;
- int i, ep;
-
- target->credit_info = credit_info;
-
- list_add_tail(&target->endpoint[ENDPOINT_0].cred_dist.list,
- &target->cred_dist_list);
-
- for (i = 0; i < list_len; i++) {
- for (ep = ENDPOINT_1; ep < ENDPOINT_MAX; ep++) {
- endpoint = &target->endpoint[ep];
- if (endpoint->svc_id == srvc_pri_order[i]) {
- list_add_tail(&endpoint->cred_dist.list,
- &target->cred_dist_list);
- break;
- }
- }
- if (ep >= ENDPOINT_MAX) {
- WARN_ON(1);
- return;
- }
- }
-}
-
static int ath6kl_htc_mbox_tx(struct htc_target *target,
struct htc_packet *packet)
{
@@ -2575,6 +2535,14 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
endpoint->svc_id, assigned_ep);
}
+ /* Add the credit distribution list of the current endpoint
+ * to target->cred_dist_list.
+ * The order in which this function is called will determine
+ * the priority of the services.
+ */
+ list_add_tail(&endpoint->cred_dist.list,
+ &target->cred_dist_list);
+
fail_tx:
if (tx_pkt)
htc_reclaim_txctrl_buf(target, tx_pkt);
--
2.1.4
^ permalink raw reply related
* [RFC 2/5] ath6kl: Updated TARG_VTOP macro with default value
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
A minor modification of the TARG_VTOP macro.
The AR6004 VTOP macro is used as default (for all
chip's except AR6003)
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/target.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/target.h b/drivers/net/wireless/ath/ath6kl/target.h
index d5eeeae..c6c49b0 100644
--- a/drivers/net/wireless/ath/ath6kl/target.h
+++ b/drivers/net/wireless/ath/ath6kl/target.h
@@ -331,11 +331,11 @@ struct host_interest {
/* Convert a Target virtual address into a Target physical address */
#define AR6003_VTOP(vaddr) ((vaddr) & 0x001fffff)
-#define AR6004_VTOP(vaddr) (vaddr)
+#define DEFAULT_VTOP(vaddr) (vaddr)
#define TARG_VTOP(target_type, vaddr) \
(((target_type) == TARGET_TYPE_AR6003) ? AR6003_VTOP(vaddr) : \
- (((target_type) == TARGET_TYPE_AR6004) ? AR6004_VTOP(vaddr) : 0))
+ DEFAULT_VTOP(vaddr))
#define ATH6KL_FWLOG_PAYLOAD_SIZE 1500
--
2.1.4
^ permalink raw reply related
* [RFC 1/5] ath6kl: HTC mbox tx complete cb support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
In-Reply-To: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com>
The current implementation always call ath6kl_tx_complete
regardless if a tx_complete callback has been associated with the
endpoint or not.
This patch fixes this by calling the associated callback in case
it is present.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da..6e8c493 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -445,7 +445,10 @@ static void htc_tx_complete(struct htc_endpoint *endpoint,
"htc tx complete ep %d pkts %d\n",
endpoint->eid, get_queue_depth(txq));
- ath6kl_tx_complete(endpoint->target, txq);
+ if (endpoint->ep_cb.tx_comp_multi)
+ endpoint->ep_cb.tx_comp_multi(endpoint->target, txq);
+ else
+ ath6kl_tx_complete(endpoint->target, txq);
}
static void htc_tx_comp_handler(struct htc_target *target,
--
2.1.4
^ permalink raw reply related
* [RFC 0/5] ath6kl: non WMI data service support
From: Erik Stromdahl @ 2016-10-13 16:39 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: Erik Stromdahl
This patch series is intended to prepare the ath6kl driver
for newer chipsets that doesn't use the current WMI data
endpoints for data traffic.
The chipset I have been working with (and used for testing)
is QCA6584. It is SDIO based (at least the variant I have
been using) with 802.11p WAVE DSRC capabilities.
This chipset is different from the AR600X family in that
it does not use the WMI data services (service id's 0x101
to 0x104 ) for data traffic.
Instead it uses the HTT data service for data and wmi unified
for control messages.
It is also different when it comes to mailbox addresses
and HTC header format as well, but these differences are not
part of this patch series.
Erik Stromdahl (5):
ath6kl: HTC mbox tx complete cb support
ath6kl: Updated TARG_VTOP macro with default value
ath6kl: Added disable credit flow ctrl for mbox
ath6kl: Updated credit setup
ath6kl: service connect rewrite
drivers/net/wireless/ath/ath6kl/core.h | 3 +
drivers/net/wireless/ath/ath6kl/htc-ops.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc.h | 4 +-
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 75 +++++-------
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 16 +--
drivers/net/wireless/ath/ath6kl/init.c | 187 +++++++++++++++++------------
drivers/net/wireless/ath/ath6kl/target.h | 4 +-
7 files changed, 156 insertions(+), 135 deletions(-)
--
2.1.4
^ permalink raw reply
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