* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Jes Sorensen @ 2016-10-01 20:32 UTC (permalink / raw)
To: Joe Perches; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1475352058.1996.1.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote:
>> Joe Perches <joe@perches.com> writes:
>> > Make the init arrays const to reduce data.
>> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o*
>> > (allyesconfig: x86-32)
>> > text data bss dec hex filename
>> > 80107 13651 58 93816 16e78
>> > drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
>> > 65303 28435 58 93796 16e64
>> > drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
>> In total you grow the kernel by 20 bytes. You reduce the data segment
>> substantially while growing the text segment instead.
>
> No, not really. The alignment boundaries move a bit for
> this particular compilation. It could go the other way for
> a different compiler version or set of CONFIG options.
>
> What's important is multiple pages of .data move to .rodata.
Your output shows it moving to the text segment - if it's in a different
segment, eg. rodata, you should use output demonstrating that to justify
the change.
Jes
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Joe Perches @ 2016-10-01 20:00 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfj37kf6gvd.fsf@redhat.com>
On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote:
> Joe Perches <joe@perches.com> writes:
> > Make the init arrays const to reduce data.
> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
> > text data bss dec hex filename
> > 80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
> > 65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
> In total you grow the kernel by 20 bytes. You reduce the data segment
> substantially while growing the text segment instead.
No, not really. The alignment boundaries move a bit for
this particular compilation. It could go the other way for
a different compiler version or set of CONFIG options.
What's important is multiple pages of .data move to .rodata.
^ permalink raw reply
* Re: [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Jes Sorensen @ 2016-10-01 18:53 UTC (permalink / raw)
To: Joe Perches; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <459bf15427d92cd052fb2fe080438fd97a8a6cd8.1475343483.git.joe@perches.com>
Joe Perches <joe@perches.com> writes:
> Make the init arrays const to reduce data.
>
> $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
> text data bss dec hex filename
> 80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
> 65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
In total you grow the kernel by 20 bytes. You reduce the data segment
substantially while growing the text segment instead.
If any architecture replicates the text segment onto individual numa
nodes, this would actually be a real loss rather than a win. Some archs
used to do this, not sure if they are doing it anymore.
I am not against this patch, but I am not sure it's really a win either.
Jes
^ permalink raw reply
* [PATCH] realtek: rtl8xxxu: Use const init arrays
From: Joe Perches @ 2016-10-01 17:39 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
Make the init arrays const to reduce data.
$ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig: x86-32)
text data bss dec hex filename
80107 13651 58 93816 16e78 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.new
65303 28435 58 93796 16e64 drivers/net/wireless/realtek/rtl8xxxu/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 ++++----
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 6 +++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++--------
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 1016628926d2..bd4449704dfa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1355,7 +1355,7 @@ struct rtl8xxxu_fileops {
u16 trxff_boundary;
u8 pbp_rx;
u8 pbp_tx;
- struct rtl8xxxu_reg8val *mactable;
+ const struct rtl8xxxu_reg8val *mactable;
u8 total_page_num;
u8 page_num_hi;
u8 page_num_lo;
@@ -1364,7 +1364,7 @@ struct rtl8xxxu_fileops {
extern int rtl8xxxu_debug;
-extern struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[];
+extern const struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[];
extern const u32 rtl8xxxu_iqk_phy_iq_bb_reg[];
u8 rtl8xxxu_read8(struct rtl8xxxu_priv *priv, u16 addr);
u16 rtl8xxxu_read16(struct rtl8xxxu_priv *priv, u16 addr);
@@ -1396,7 +1396,7 @@ int rtl8xxxu_init_phy_rf(struct rtl8xxxu_priv *priv,
struct rtl8xxxu_rfregval *table,
enum rtl8xxxu_rfpath path);
int rtl8xxxu_init_phy_regs(struct rtl8xxxu_priv *priv,
- struct rtl8xxxu_reg32val *array);
+ const struct rtl8xxxu_reg32val *array);
int rtl8xxxu_load_firmware(struct rtl8xxxu_priv *priv, char *fw_name);
void rtl8xxxu_firmware_self_reset(struct rtl8xxxu_priv *priv);
void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27e7851..934a380f09b1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -40,7 +40,7 @@
#include "rtl8xxxu.h"
#include "rtl8xxxu_regs.h"
-static struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
+static const struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
{0x011, 0xeb}, {0x012, 0x07}, {0x014, 0x75}, {0x303, 0xa7},
{0x428, 0x0a}, {0x429, 0x10}, {0x430, 0x00}, {0x431, 0x00},
{0x432, 0x00}, {0x433, 0x01}, {0x434, 0x04}, {0x435, 0x05},
@@ -70,7 +70,7 @@ static struct rtl8xxxu_reg8val rtl8192e_mac_init_table[] = {
{0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -202,7 +202,7 @@ static struct rtl8xxxu_reg32val rtl8192eu_phy_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
{0xc78, 0xfb000001}, {0xc78, 0xfb010001},
{0xc78, 0xfb020001}, {0xc78, 0xfb030001},
{0xc78, 0xfb040001}, {0xc78, 0xfb050001},
@@ -271,7 +271,7 @@ static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_std_table[] = {
{0xffff, 0xffffffff}
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8192eu_highpa_table[] = {
{0xc78, 0xfa000001}, {0xc78, 0xf9010001},
{0xc78, 0xf8020001}, {0xc78, 0xf7030001},
{0xc78, 0xf6040001}, {0xc78, 0xf5050001},
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 6c086b5657e9..3f173b67fc0d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -40,7 +40,7 @@
#include "rtl8xxxu.h"
#include "rtl8xxxu_regs.h"
-static struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
+static const struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
{0x02f, 0x30}, {0x035, 0x00}, {0x039, 0x08}, {0x04e, 0xe0},
{0x064, 0x00}, {0x067, 0x20}, {0x428, 0x0a}, {0x429, 0x10},
{0x430, 0x00}, {0x431, 0x00},
@@ -71,7 +71,7 @@ static struct rtl8xxxu_reg8val rtl8723b_mac_init_table[] = {
{0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -172,7 +172,7 @@ static struct rtl8xxxu_reg32val rtl8723b_phy_1t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_8723bu_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_8723bu_table[] = {
{0xc78, 0xfd000001}, {0xc78, 0xfc010001},
{0xc78, 0xfb020001}, {0xc78, 0xfa030001},
{0xc78, 0xf9040001}, {0xc78, 0xf8050001},
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index b2d7f6e69667..7c62293948cb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -135,7 +135,7 @@ static struct ieee80211_supported_band rtl8xxxu_supported_band = {
.n_bitrates = ARRAY_SIZE(rtl8xxxu_rates),
};
-struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
+const struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
{0x420, 0x80}, {0x423, 0x00}, {0x430, 0x00}, {0x431, 0x00},
{0x432, 0x00}, {0x433, 0x01}, {0x434, 0x04}, {0x435, 0x05},
{0x436, 0x06}, {0x437, 0x07}, {0x438, 0x00}, {0x439, 0x00},
@@ -160,7 +160,7 @@ struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[] = {
{0x70a, 0x65}, {0x70b, 0x87}, {0xffff, 0xff},
};
-static struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
{0x800, 0x80040000}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
{0x810, 0x10001331}, {0x814, 0x020c3d10},
@@ -258,7 +258,7 @@ static struct rtl8xxxu_reg32val rtl8723a_phy_1t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
+static const struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
{0x024, 0x0011800f}, {0x028, 0x00ffdb83},
{0x800, 0x80040002}, {0x804, 0x00000003},
{0x808, 0x0000fc00}, {0x80c, 0x0000000a},
@@ -356,7 +356,7 @@ static struct rtl8xxxu_reg32val rtl8192cu_phy_2t_init_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
{0x024, 0x0011800f}, {0x028, 0x00ffdb83},
{0x040, 0x000c0004}, {0x800, 0x80040000},
{0x804, 0x00000001}, {0x808, 0x0000fc00},
@@ -455,7 +455,7 @@ static struct rtl8xxxu_reg32val rtl8188ru_phy_1t_highpa_table[] = {
{0xffff, 0xffffffff},
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
{0xc78, 0x7b000001}, {0xc78, 0x7b010001},
{0xc78, 0x7b020001}, {0xc78, 0x7b030001},
{0xc78, 0x7b040001}, {0xc78, 0x7b050001},
@@ -539,7 +539,7 @@ static struct rtl8xxxu_reg32val rtl8xxx_agc_standard_table[] = {
{0xffff, 0xffffffff}
};
-static struct rtl8xxxu_reg32val rtl8xxx_agc_highpa_table[] = {
+static const struct rtl8xxxu_reg32val rtl8xxx_agc_highpa_table[] = {
{0xc78, 0x7b000001}, {0xc78, 0x7b010001},
{0xc78, 0x7b020001}, {0xc78, 0x7b030001},
{0xc78, 0x7b040001}, {0xc78, 0x7b050001},
@@ -2146,7 +2146,7 @@ void rtl8xxxu_firmware_self_reset(struct rtl8xxxu_priv *priv)
static int
rtl8xxxu_init_mac(struct rtl8xxxu_priv *priv)
{
- struct rtl8xxxu_reg8val *array = priv->fops->mactable;
+ const struct rtl8xxxu_reg8val *array = priv->fops->mactable;
int i, ret;
u16 reg;
u8 val;
@@ -2174,7 +2174,7 @@ rtl8xxxu_init_mac(struct rtl8xxxu_priv *priv)
}
int rtl8xxxu_init_phy_regs(struct rtl8xxxu_priv *priv,
- struct rtl8xxxu_reg32val *array)
+ const struct rtl8xxxu_reg32val *array)
{
int i, ret;
u16 reg;
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Jes Sorensen @ 2016-10-01 12:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-wireless, kvalo, Larry.Finger, stable
In-Reply-To: <20161001115622.GB15156@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Fri, Sep 30, 2016 at 07:35:17PM -0400, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> The generic disable_rf() function clears bits 22 and 23 in
>> REG_RX_WAIT_CCA, however we did not re-enable them again in
>> rtl8723b_enable_rf()
>>
>> This resolves the problem for me with 8723bu devices not working again
>> after reloading the driver.
>>
>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>> ---
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
DOH Kalle told me to CC stable I took it for granted that you meant CC
in the email sense. Guess I get to blame my self for looking like a
fool in public.
I'll send you an email directly with the SHA once it hits Linus' tree
instead.
Jes
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Greg KH @ 2016-10-01 11:56 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, kvalo, Larry.Finger, stable
In-Reply-To: <1475278518-18527-2-git-send-email-Jes.Sorensen@redhat.com>
On Fri, Sep 30, 2016 at 07:35:17PM -0400, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The generic disable_rf() function clears bits 22 and 23 in
> REG_RX_WAIT_CCA, however we did not re-enable them again in
> rtl8723b_enable_rf()
>
> This resolves the problem for me with 8723bu devices not working again
> after reloading the driver.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
> 1 file changed, 4 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Krishna Chaitanya @ 2016-10-01 12:02 UTC (permalink / raw)
To: Arend van Spriel
Cc: Gucea Doru, Arend van Spriel, Andra Paraschiv, linux-wireless
In-Reply-To: <ed4a7366-3f67-79da-0868-876a69b1da54@broadcom.com>
On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
>
> On 29-09-16 13:32, Gucea Doru wrote:
>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>> What is the decision triggering the exit from the PS mode immediately
>>> after the ping request? I am asking this because 802.11 PS legacy
>>> specifies that the client should wait for a beacon with TIM set in
>>> order to wake up: in my case, there is no beacon between the ping
>>> request message and the Null frame that announces the exit from the PS
>>> mode.
>>
>>
>> Any help would be highly appreciated :)
>
> Actually though I already sent you are reply, but alas here it is.
>
> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
> drivers. Regardless your question is more for firmware running on the
> device. So like the same behavior would be observed when using brcmfmac
> with same firmware.
>
>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>> shall issue a PS Poll". In my capture there are cases when the STA
>> exits the PS mode without waiting for a beacon.
>
> It is a bit tricky, but the standard does not explicitly say the STA
> should be in power-save at any other time. So it is difficult to say
> what event occurred on the STA side to exit PS mode. Also STA means
> P2P-Client as you say. That means that you have multiple interfaces:
> regular STA and P2P-Client. So is the STA connected to some other AP or
> just not connected. wpa_supplicant will do intermittent scan or initiate
> scheduled scan by which firmware will scan at a certain interval. That
> is just some things I can come up with and I am sure there are more.
Keeping the STA aside, as far as AP is concerned the STA is still in PS,
so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
Because the STA might be in power-off mode things seem to work.
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Arend van Spriel @ 2016-10-01 9:56 UTC (permalink / raw)
To: Lior David, Luca Coelho, Johannes Berg
Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <b7022d3c-51ff-96eb-f6f0-319eb5ea66b0@codeaurora.org>
On 20-09-16 22:57, Lior David wrote:
> On 9/20/2016 9:39 AM, Luca Coelho wrote:
>> On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>>>
>>> On 19-9-2016 19:31, Lior David wrote:
>>>>
>>>> Hi Johannes,
>>>>
>>>> We are working on adding indoor location support to the wil6210
>>>> 11ad driver. This includes fine timing measurement (FTM) as well as
>>>> something we call angle of arrival (AOA) which measures azimuth and
>>>> elevation.
>>>> Initially we implemented it internally using vendor commands but we
>>>> would like to upstream it using standard nl80211 API.
>>>> I noticed a patch you sent some time ago (https://patchwork.kernel.
>>>> org/patch/7790701/) for adding fine timing measurement support to
>>>> nl80211, it looks like a good baseline though we do have few issues
>>>> with it... However I did not see any comments or response on this
>>>> patch. Can you please update if you plan on eventually submitting
>>>> this patch?
>>>
>>> You can find several FTM related patches in backport-iwlwifi repo on
>>> kernel.org. See link to git log of nl80211.h there [1].
>>
>> We have a full FTM implementation in our internal tree (which is
>> published in the URL Arend provided) and we are currently working on
>> cleaning it up for upstream submission. You should see patches from us
>> this week.
>>
> That's great to hear, thanks :-)
> I reviewed your FTM nl80211 API and have some comments. I can send these
> comments once you send the cleaned up patch (most are small issues), but there
> is one issue I would like to raise in advance:
> In the measurement response you report the final calculated RTT (is this
> for each burst or calculated from all bursts?). Our implementation
> reports the raw measurement results (t1, t2, t3, t4 for each measurement
> as well as TOD and TOA errors at responder and initiator as defined in IEEE
> P802.11-REVmc/D7.0, 9.6.8.33). Reporting the final RTT does have benefits, so I
> checked with our location framework developers. The general consensus is they
> prefer to get the raw results, mainly because there are some useful analysis
> algorithms they can run, and in addition the firmware may not be strong enough
> to perform the calculations for deriving the final RTT (it could be done in the
> driver but I don't think this is a proper place for it). Maybe we should
> provide option for reporting both raw and RTT results where drivers can
> support either or both?
If raw results are mainly used for analysis algorithms how about
providing raw measurement data through debugfs. May even consider adding
rtt calculation in cfg80211/mac80211 for drivers that choose to provide
raw measurement data and still only report final RTT in nl80211 api.
Regards,
Arend
> For reference, we have also implemented FTM internally using vendor
> commands. The vendor commands API that we defined can be seen at [1],
> the actual implementation is still under internal review so not yet
> published.
>
> Thanks,
> Lior
>
> [1] http://w1.fi/cgit/hostap/commit/?id=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
>
>
>> --
>> Cheers,
>> Luca.
>>
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Arend van Spriel @ 2016-10-01 9:22 UTC (permalink / raw)
To: Gucea Doru, Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless
In-Reply-To: <CANfLQrZxEUX0UMwrVNZHps9ztqxmOaeovy34fey2NkErCDDarQ@mail.gmail.com>
On 29-09-16 13:32, Gucea Doru wrote:
> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>> What is the decision triggering the exit from the PS mode immediately
>> after the ping request? I am asking this because 802.11 PS legacy
>> specifies that the client should wait for a beacon with TIM set in
>> order to wake up: in my case, there is no beacon between the ping
>> request message and the Null frame that announces the exit from the PS
>> mode.
>
>
> Any help would be highly appreciated :)
Actually though I already sent you are reply, but alas here it is.
bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
drivers. Regardless your question is more for firmware running on the
device. So like the same behavior would be observed when using brcmfmac
with same firmware.
> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
> detects that the bit corresponding to its AID is 1 i the TIM, the STA
> shall issue a PS Poll". In my capture there are cases when the STA
> exits the PS mode without waiting for a beacon.
It is a bit tricky, but the standard does not explicitly say the STA
should be in power-save at any other time. So it is difficult to say
what event occurred on the STA side to exit PS mode. Also STA means
P2P-Client as you say. That means that you have multiple interfaces:
regular STA and P2P-Client. So is the STA connected to some other AP or
just not connected. wpa_supplicant will do intermittent scan or initiate
scheduled scan by which firmware will scan at a certain interval. That
is just some things I can come up with and I am sure there are more.
Regards,
Arend
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Jes Sorensen @ 2016-09-30 23:39 UTC (permalink / raw)
To: Franc[e]sco; +Cc: linux-wireless
In-Reply-To: <80b8ae50-ca27-674f-0e7e-79b931bae199@waifu.club>
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
"Franc[e]sco" <lolisamurai@waifu.club> writes:
> Oops, forgot to forward the previous reply to the mailing list.
>
> I have attached the output of iw link
>
> the AP is an asus dsl-n55u router in 2.4 GHz mode, using WPA2-Personal
> with AES encryption. It's also running a second 5GHz wireless network
> which has a different SSID.
>
> Also, this seems to be some kind of power saving kicking in, as the
> dongle keeps working as long as I keep doing things over ssh.
I just pushed a patch into rtl8xxxu-devel which may resolve this issue.
There were problems with the 8192eu not handling driver reload very
well. It is possible the network scripts you run would trigger the shut
down and restart that caused this problem.
I would be interested in knowing if this patch resolves the problem for
you.
Jes
PS: Please fix your mail client - adding unlisted-recipients to the Cc
line and cutting out the person you are responding to is really
annoying.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-rtl8xxxu-Fix-rtl8192eu-driver-reload-issue.patch --]
[-- Type: text/x-patch, Size: 1873 bytes --]
>From 93064d0ae3e9d97c03a3aabd71e6048e1ac82f46 Mon Sep 17 00:00:00 2001
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Date: Fri, 30 Sep 2016 19:18:34 -0400
Subject: [PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue
The 8192eu suffered from two issues when reloading the driver.
The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().
In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.
With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27..a793fed 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1461,7 +1461,9 @@ static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
int count, ret = 0;
/* Turn off RF */
- rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+ val8 = rtl8xxxu_read8(priv, REG_RF_CTRL);
+ val8 &= ~RF_ENABLE;
+ rtl8xxxu_write8(priv, REG_RF_CTRL, val8);
/* Switch DPDT_SEL_P output from register 0x65[2] */
val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
@@ -1593,6 +1595,10 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
val8 = rtl8xxxu_read8(priv, REG_GPIO_MUXCFG);
val8 |= BIT(5);
rtl8xxxu_write8(priv, REG_GPIO_MUXCFG, val8);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] rtl8xxxu: Fix driver reload issues with 8723bu and 8192eu
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
These two patches fix issues where rtl8723bu and rtl8192eu dongles
would stop receving data if one reloaded the driver module, requiring
it to be physically removed and reinserted.
Both issues are applicable to 4.9. The first patch for 8723bu is
applicable to stable 4.7 and 4.8. The second patch will only be
applicable to stable 4.8, once patches currently in flight are merged
by the network maintainers.
Cheers,
Jes
Jes Sorensen (2):
rtl8xxxu: Fix rtl8723bu driver reload issue
rtl8xxxu: Fix rtl8192eu driver reload issue
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
2 files changed, 11 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475278518-18527-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The 8192eu suffered from two issues when reloading the driver.
The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().
In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.
With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index df54d27..a793fed 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1461,7 +1461,9 @@ static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
int count, ret = 0;
/* Turn off RF */
- rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+ val8 = rtl8xxxu_read8(priv, REG_RF_CTRL);
+ val8 &= ~RF_ENABLE;
+ rtl8xxxu_write8(priv, REG_RF_CTRL, val8);
/* Switch DPDT_SEL_P output from register 0x65[2] */
val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
@@ -1593,6 +1595,10 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
val8 = rtl8xxxu_read8(priv, REG_GPIO_MUXCFG);
val8 |= BIT(5);
rtl8xxxu_write8(priv, REG_GPIO_MUXCFG, val8);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Jes.Sorensen @ 2016-09-30 23:35 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, stable, Jes Sorensen
In-Reply-To: <1475278518-18527-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()
This resolves the problem for me with 8723bu devices not working again
after reloading the driver.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 6c086b5..02b8ddd 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1498,6 +1498,10 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
/*
* No indication anywhere as to what 0x0790 does. The 2 antenna
* vendor code preserves bits 6-7 here.
--
2.7.4
^ permalink raw reply related
* pull-request: mac80211-next 2016-09-30
From: Johannes Berg @ 2016-09-30 16:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Last pull request before the merge window, since it's about to open :)
It seems that everyone finally agreed on the NAN (neighbor awareness
networking) APIs, so we have that, along with some other things.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit c13ed534b8db543e4d8ead3885f4b06585a5771c:
Merge tag 'mac80211-next-for-davem-2016-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next (2016-09-18 22:29:08 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-09-30
for you to fetch changes up to bb42f2d13ffcd0baed7547b37d05add51fcd50e1:
mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue (2016-09-30 14:46:57 +0200)
----------------------------------------------------------------
This time around, we have
* Neighbor Awareness Networking (NAN) APIs
* a fix for a previous patch that caused memory corruption
in wireless extensions key settings
* beacon rate configuration for AP and mesh
* memory limits for mac80211's internal TXQs
* a (fairly involved) fix for the TXQ vs. crypto problems
* direct cfg80211 driver API for WEP keys
----------------------------------------------------------------
Ayala Beker (9):
cfg80211: add start / stop NAN commands
mac80211: add boilerplate code for start / stop NAN
cfg80211: add add_nan_func / del_nan_func
cfg80211: allow the user space to change current NAN configuration
cfg80211: provide a function to report a match for NAN
cfg80211: Provide an API to report NAN function termination
mac80211: implement nan_change_conf
mac80211: Implement add_nan_func and rm_nan_func
mac80211: Add API to report NAN function match
David Spinadel (1):
cfg80211: Add support for static WEP in the driver
Johannes Berg (2):
cfg80211: add checks for beacon rate, extend to mesh
cfg80211: wext: really don't store non-WEP keys
Pedersen, Thomas (2):
mac80211: add offset_tsf driver op and use it for mesh
mac80211: mesh: decrease max drift
Purushottam Kushwaha (1):
cfg80211: Add support to configure a beacon data rate
Toke Høiland-Jørgensen (5):
mac80211: Move ieee802111_tx_dequeue() to later in tx.c
fq.h: Port memory limit mechanism from fq_codel
mac80211: Export fq memory limit information in debugfs
mac80211: Set lower memory limit for non-VHT devices
mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
include/net/cfg80211.h | 223 +++++++-
include/net/fq.h | 3 +
include/net/fq_impl.h | 7 +-
include/net/mac80211.h | 75 +++
include/uapi/linux/nl80211.h | 270 ++++++++-
net/mac80211/cfg.c | 208 +++++++
net/mac80211/chan.c | 6 +
net/mac80211/debugfs.c | 8 +
net/mac80211/debugfs_netdev.c | 12 +-
net/mac80211/driver-ops.c | 15 +
net/mac80211/driver-ops.h | 83 +++
net/mac80211/ieee80211_i.h | 26 +
net/mac80211/iface.c | 28 +-
net/mac80211/main.c | 8 +
net/mac80211/mesh_sync.c | 12 +-
net/mac80211/offchannel.c | 4 +-
net/mac80211/rx.c | 7 +-
net/mac80211/sta_info.c | 10 +-
net/mac80211/trace.h | 159 ++++++
net/mac80211/tx.c | 351 ++++++++----
net/mac80211/util.c | 61 ++-
net/wireless/chan.c | 2 +
net/wireless/core.c | 35 ++
net/wireless/core.h | 7 +-
net/wireless/ibss.c | 5 +-
net/wireless/mlme.c | 1 +
net/wireless/nl80211.c | 1220 ++++++++++++++++++++++++++++++++---------
net/wireless/rdev-ops.h | 58 ++
net/wireless/sme.c | 6 +-
net/wireless/trace.h | 90 +++
net/wireless/util.c | 30 +-
net/wireless/wext-compat.c | 14 +-
net/wireless/wext-sme.c | 2 +-
33 files changed, 2648 insertions(+), 398 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Arnd Bergmann @ 2016-09-30 14:58 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <557be2b8-5ff1-83ea-f6d1-6421c2465969@nbd.name>
On Friday 30 September 2016, Felix Fietkau wrote:
> >> >> >> + device_type = "pci";
> >> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
> >> >> >> + mediatek,2ghz = <0>;
> >> >
> >> > It's not clear what the possible values for the 2ghz property are,
> >> > can you be more verbose in the description? How is <0> different
> >> > from no property?
> >> 0 means disabled, no property means unchanged (compared to EEPROM).
> >
> > Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
> >
> > If zero is the only possible value, there is no need to put a number in there.
> 1 is also possible, which will force-enable the capability.
Ok, then both those values should be documented in the binding.
Arnd
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Felix Fietkau @ 2016-09-30 14:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <201609301636.43363.arnd@arndb.de>
On 2016-09-30 16:36, Arnd Bergmann wrote:
> On Friday 30 September 2016, Felix Fietkau wrote:
>> >> >> + pcie0 {
>> >> >> + mt76@0,0 {
>> >> >> + reg = <0x0000 0 0 0 0>;
>> >
>> > Maybe have an examplep of a real register address other than zero?
>> This is a real example referring to the first device on a PCI bus.
>> I copy&pasted this from a .dts file that we use in LEDE.
>
> Ok, I see.
>
>> >> >> + device_type = "pci";
>> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> >> >> + mediatek,2ghz = <0>;
>> >
>> > It's not clear what the possible values for the 2ghz property are,
>> > can you be more verbose in the description? How is <0> different
>> > from no property?
>> 0 means disabled, no property means unchanged (compared to EEPROM).
>
> Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
>
> If zero is the only possible value, there is no need to put a number in there.
1 is also possible, which will force-enable the capability.
- Felix
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Arnd Bergmann @ 2016-09-30 14:36 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless, devicetree
In-Reply-To: <3334122f-0d79-f910-a414-5b9cafd9901f@nbd.name>
On Friday 30 September 2016, Felix Fietkau wrote:
> >> >> + pcie0 {
> >> >> + mt76@0,0 {
> >> >> + reg = <0x0000 0 0 0 0>;
> >
> > Maybe have an examplep of a real register address other than zero?
> This is a real example referring to the first device on a PCI bus.
> I copy&pasted this from a .dts file that we use in LEDE.
Ok, I see.
> >> >> + device_type = "pci";
> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
> >> >> + mediatek,2ghz = <0>;
> >
> > It's not clear what the possible values for the 2ghz property are,
> > can you be more verbose in the description? How is <0> different
> > from no property?
> 0 means disabled, no property means unchanged (compared to EEPROM).
Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
If zero is the only possible value, there is no need to put a number in there.
Arnd
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices
From: Toke Høiland-Jørgensen @ 2016-09-30 14:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: make-wifi-fast, linux-wireless, netdev
In-Reply-To: <1475239915.17481.63.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> > I kinda see the logic here - we really don't need to queue as much
>> > if we can't possibly transmit it out quickly - but it seems to me
>> > we should also throw in some kind of limit that's relative to the
>> > amount of memory you have on the system?
>>
>> Yes, ideally. That goes for FQ-CoDel as well, BTW. LEDE currently
>> carries a patch for that which just changes the hard-coded default to
>> another hard-coded default. Not sure how to get a good value to use,
>> though; and deciding on how large a fraction of memory to use for
>> packets starts smelling an awful lot like setting policy in the
>> kernel, doesn't it?
>
> Yeah, I agree it does seem awkward.
>
> Perhaps we should instead pick a low limit and let users change it
> more easily (i.e. not debugfs)? I don't know a good answer to this
> either.
Hmm, I'll talk it over with some of the LEDE people who are more used to
dealing with these sorts of memory-constrained devices than I am. Will
send a patch if we come up with a good solution :)
-Toke
^ permalink raw reply
* Re: ath10k stuck on 6Mbps and spam syslog
From: Ben Greear @ 2016-09-30 14:22 UTC (permalink / raw)
To: Matteo Grandi; +Cc: LinuxWireless Mailing List
In-Reply-To: <CAHdg3xa8g3hGhC2SdrnYNAwVtGT+kSuQGOm+WO4PO6Wa_V3p3Q@mail.gmail.com>
At least some stock ath10k firmware can send frames at CCK (.11b) encodings
on 5Ghz, which is out-of-spec, and may cause this warning. Maybe you
could check the values printed and see if that is indeed what is causing
this splat?
Thanks,
Ben
On 09/30/2016 12:23 AM, Matteo Grandi wrote:
> Dear Ben,
> Thank you for your reply.
> The fact that stock ath10k firmware does not report tx-rate explains
> why the station dump shows 6Mbps but the iperf test reach 14.6 (even
> if it is really under the expected data rate...).
> About the syslog spam, this is the code of the function that seems to
> cause the error (I put a comment at line 2621 side). (The warning
> start to spam as soon as I assign the channel "iw dev <if_name> set
> channel <ch_number>)
>
> /**
> * ieee80211_calculate_rx_timestamp - calculate timestamp in frame
> * @local: mac80211 hw info struct
> * @status: RX status
> * @mpdu_len: total MPDU length (including FCS)
> * @mpdu_offset: offset into MPDU to calculate timestamp at
> *
> * This function calculates the RX timestamp at the given MPDU offset, taking
> * into account what the RX timestamp was. An offset of 0 will just normalize
> * the timestamp to TSF at beginning of MPDU reception.
> */
> u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
> struct ieee80211_rx_status *status,
> unsigned int mpdu_len,
> unsigned int mpdu_offset)
> {
> u64 ts = status->mactime;
> struct rate_info ri;
> u16 rate;
>
> if (WARN_ON(!ieee80211_have_rx_timestamp(status))) //this is the
> line 2621 reported in the warning
> return 0;
>
> memset(&ri, 0, sizeof(ri));
>
> /* Fill cfg80211 rate info */
> if (status->flag & RX_FLAG_HT) {
> ri.mcs = status->rate_idx;
> ri.flags |= RATE_INFO_FLAGS_MCS;
> if (status->flag & RX_FLAG_40MHZ)
> ri.bw = RATE_INFO_BW_40;
> else
> ri.bw = RATE_INFO_BW_20;
> if (status->flag & RX_FLAG_SHORT_GI)
> ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
> } else if (status->flag & RX_FLAG_VHT) {
> ri.flags |= RATE_INFO_FLAGS_VHT_MCS;
> ri.mcs = status->rate_idx;
> ri.nss = status->vht_nss;
> if (status->flag & RX_FLAG_40MHZ)
> ri.bw = RATE_INFO_BW_40;
> else if (status->vht_flag & RX_VHT_FLAG_80MHZ)
> ri.bw = RATE_INFO_BW_80;
> else if (status->vht_flag & RX_VHT_FLAG_160MHZ)
> ri.bw = RATE_INFO_BW_160;
> else
> ri.bw = RATE_INFO_BW_20;
> if (status->flag & RX_FLAG_SHORT_GI)
> ri.flags |= RATE_INFO_FLAGS_SHORT_GI;
> } else {
> struct ieee80211_supported_band *sband;
> int shift = 0;
> int bitrate;
>
> if (status->flag & RX_FLAG_10MHZ) {
> shift = 1;
> ri.bw = RATE_INFO_BW_10;
> } else if (status->flag & RX_FLAG_5MHZ) {
> shift = 2;
> ri.bw = RATE_INFO_BW_5;
> } else {
> ri.bw = RATE_INFO_BW_20;
> }
>
> sband = local->hw.wiphy->bands[status->band];
> bitrate = sband->bitrates[status->rate_idx].bitrate;
> ri.legacy = DIV_ROUND_UP(bitrate, (1 << shift));
> }
>
> rate = cfg80211_calculate_bitrate(&ri);
> if (WARN_ONCE(!rate,
> "Invalid bitrate: flags=0x%x, idx=%d, vht_nss=%d\n",
> status->flag, status->rate_idx, status->vht_nss))
> return 0;
>
> /* rewind from end of MPDU */
> if (status->flag & RX_FLAG_MACTIME_END)
> ts -= mpdu_len * 8 * 10 / rate;
>
> ts += mpdu_offset * 8 * 10 / rate;
> /* [SESAME] I2CAT. dbg*/
> //printk(KERN_DEBUG "calculate_rx_timestamp: ts = %lu;\t rate =
> %lu;\tmpdu_offset = %lu;\tmpdu_len = %lu\n",
> // (long unsigned int) ts, (long unsigned int) rate, (long unsigned
> int) mpdu_offset, (long unsigned int) mpdu_len );
>
> return ts;
> }
>
> Thank you so much!
>
> All the best
>
> Matteo
>
>
> 2016-09-29 16:47 GMT+02:00 Ben Greear <greearb@candelatech.com>:
>> stock ath10k firmware does not report tx-rate so the kernel always sees
>> 6Mbps.
>>
>> I don't know about the splat..maybe post the function
>> that is causing that?
>>
>> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>>
>> Thanks,
>> Ben
>>
>>
>> On 09/29/2016 06:39 AM, Matteo Grandi wrote:
>>>
>>> Hello all,
>>>
>>> I'm struggling with a problem related on ath10k drivers:
>>> I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
>>> tests needed for my thesis.
>>> I'm using ath10k drivers for this card, and backports-4.4.2, in
>>> particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
>>> more recent.
>>> I've connected in mesh mode the WLE600V5 card with an 802.11n card
>>> (using ath9k drivers) but looking at the station dump, the tx bitrate
>>> is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
>>> watch -n1 iw <interfacename> station dump
>>> let me see changes of the tx rate and MCS on the ath9k during iperf
>>> tests, but the ath10k stucks on 6.0 Mbit/s.
>>>
>>> Then something misterious (for me) happen while the channel
>>> assignment: the syslog is spammed by this message:
>>>
>>> [17554.919459] ------------[ cut here ]------------
>>> [17554.919839] WARNING: CPU: 0 PID: 0 at
>>> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
>>> ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
>>> [17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
>>> ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
>>> [17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
>>> 3.14.48-g408ccb9 #4
>>> [17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
>>> (show_stack+0x10/0x14)
>>> [17554.920038] [<80011330>] (show_stack) from [<806537dc>]
>>> (dump_stack+0x80/0x90)
>>> [17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
>>> (warn_slowpath_common+0x6c/0x88)
>>> [17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
>>> (warn_slowpath_null+0x1c/0x24)
>>> [17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
>>> (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
>>> [17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
>>> [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
>>> [mac80211])
>>> [17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
>>> [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
>>> [17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
>>> from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
>>> [ath10k_core])
>>> [17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
>>> [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
>>> [ath10k_pci])
>>> [17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
>>> from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
>>> [ath10k_pci])
>>> [17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
>>> [ath10k_pci]) from [<7f15b464>]
>>> (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
>>> [17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
>>> [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
>>> [ath10k_pci])
>>> [17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
>>> [<800304c8>] (tasklet_action+0x80/0x110)
>>> [17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
>>> (__do_softirq+0x10c/0x248)
>>> [17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
>>> (irq_exit+0xac/0xf4)
>>> [17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>]
>>> (handle_IRQ+0x44/0x90)
>>> [17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
>>> (gic_handle_irq+0x2c/0x5c)
>>> [17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
>>> (__irq_svc+0x40/0x50)
>>> [17554.922122] Exception stack(0x80917f18 to 0x80917f60)
>>> [17554.922141] 7f00:
>>> 80917f60 000d3334
>>> [17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
>>> 80924060 00000001 a7705014
>>> [17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
>>> 80492940 60000013 ffffffff
>>> [17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
>>> (cpuidle_enter_state+0x50/0xe0)
>>> [17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
>>> (cpuidle_idle_call+0xf8/0x148)
>>> [17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
>>> (arch_cpu_idle+0x8/0x44)
>>> [17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
>>> (cpu_startup_entry+0xfc/0x140)
>>> [17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
>>> (start_kernel+0x360/0x36c)
>>> [17554.922379] ---[ end trace 87d4775146813aed ]---
>>> [17555.943454] ------------[ cut here ]------------
>>>
>>> that repeat continuously...
>>> Forcing legacy bitrates doesn't change the situation.
>>>
>>> I made some measurements using iperf, please find it in attachment.
>>>
>>> Other info:
>>>
>>> root@Yazi:~# modinfo ath10k_pci
>>> filename:
>>>
>>> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
>>> firmware: ath10k/QCA9377/hw1.0/board.bin
>>> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
>>> firmware: ath10k/QCA6174/hw3.0/board-2.bin
>>> firmware: ath10k/QCA6174/hw3.0/board.bin
>>> firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
>>> firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
>>> firmware: ath10k/QCA6174/hw2.1/board-2.bin
>>> firmware: ath10k/QCA6174/hw2.1/board.bin
>>> firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
>>> firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
>>> firmware: ath10k/QCA988X/hw2.0/board-2.bin
>>> firmware: ath10k/QCA988X/hw2.0/board.bin
>>> firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
>>> firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
>>> firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
>>> firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
>>> firmware: ath10k/QCA988X/hw2.0/firmware.bin
>>> license: Dual BSD/GPL
>>> description: Driver support for Atheros QCA988X PCIe devices
>>> author: Qualcomm Atheros
>>> version: backported from Linux (v4.4.2-0-g1cb8570) using
>>> backports v4.4.2-1-0-gbec4037
>>> srcversion: EBB3D4E36DE49B7EC8057D0
>>> alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
>>> alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
>>> alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
>>> alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
>>> alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
>>> depends: ath10k_core,compat
>>> vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
>>> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
>>> parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
>>>
>>> I don't know if it's only a problem of iw station dump that can't show
>>> the tx rate, but the spammed syslog honestly warn me...
>>>
>>> How shall I check what's wrong and see the HT work?
>>>
>>> Thanks a lot!
>>>
>>> Matteo
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v9 2/2] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Toke Høiland-Jørgensen @ 2016-09-30 14:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: make-wifi-fast, linux-wireless
In-Reply-To: <1475239765.17481.61.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Applied, with the nits fixed as discussed.
Awesome, thanks!
> Come to think of it, if somebody is bored ;-) perhaps a hwsim option
> to use TXQs (should be optional I guess) would be nice so we can
> exercise this code with the wpa_supplicant hwsim tests. That would
> have caught the TKIP issues etc. pretty early on too, I think.
Noted. I'll look into that the next time I'm bored ;)
-Toke
^ permalink raw reply
* [PATCH v2] ath10k: allow setting coverage class
From: Kalle Valo @ 2016-09-30 13:38 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Benjamin Berg, Simon Wunderlich,
Mathias Kretschmer
From: Benjamin Berg <benjamin@sipsolutions.net>
Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.
This is a hack and might cause subtle problems but as it's not enabled by
default (only when user space changes the coverage class explicitly) it should
not cause new problems for existing setups. But still this should be considered
as an experimental feature and used with caution.
This patch implements the support for first generation cards (QCA9880, QCA9887
and so on) which are based on a core that is similar to ath9k. The registers
are modified in place and need to be re-written every time the firmware sets
them. To achieve this the register status is verified after certain WMI events
from the firmware.
The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.
Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
v2:
* cc linux-wireless
* fold "ath10k: Fix spinlock use in coverage class hack" into this one (Benjamin)
* emphasise more on the commit log that this is a hack
* remove unnecessary use of unlikely(), this is not in hotpath
* workaround ifdef CONFIG_ATH10K_DEBUGFS with adding
ath10k_debug_get_fw_dbglog_[mask|level]()
drivers/net/wireless/ath/ath10k/core.c | 11 +++
drivers/net/wireless/ath/ath10k/core.h | 13 +++
drivers/net/wireless/ath/ath10k/debug.h | 22 +++++
drivers/net/wireless/ath/ath10k/hw.c | 142 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/hw.h | 28 +++++-
drivers/net/wireless/ath/ath10k/mac.c | 19 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 48 +++++++++++
7 files changed, 282 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 867a8403b15b..7005e2a98726 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1562,6 +1562,15 @@ static void ath10k_core_restart(struct work_struct *work)
mutex_unlock(&ar->conf_mutex);
}
+static void ath10k_core_set_coverage_class_work(struct work_struct *work)
+{
+ struct ath10k *ar = container_of(work, struct ath10k,
+ set_coverage_class_work);
+
+ if (ar->hw_params.hw_ops->set_coverage_class)
+ ar->hw_params.hw_ops->set_coverage_class(ar, -1);
+}
+
static int ath10k_core_init_firmware_features(struct ath10k *ar)
{
struct ath10k_fw_file *fw_file = &ar->normal_mode_fw.fw_file;
@@ -2344,6 +2353,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
INIT_WORK(&ar->register_work, ath10k_core_register_work);
INIT_WORK(&ar->restart_work, ath10k_core_restart);
+ INIT_WORK(&ar->set_coverage_class_work,
+ ath10k_core_set_coverage_class_work);
init_dummy_netdev(&ar->napi_dev);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c091306bca33..6e5aa2d09699 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -912,6 +912,19 @@ struct ath10k {
struct net_device napi_dev;
struct napi_struct napi;
+ struct work_struct set_coverage_class_work;
+ /* protected by conf_mutex */
+ struct {
+ /* writing also protected by data_lock */
+ s16 coverage_class;
+
+ u32 reg_phyclk;
+ u32 reg_slottime_conf;
+ u32 reg_slottime_orig;
+ u32 reg_ack_cts_timeout_conf;
+ u32 reg_ack_cts_timeout_orig;
+ } fw_coverage;
+
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index c458fa96a6d4..335512b11ca2 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -94,7 +94,19 @@ int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ethtool_stats *stats, u64 *data);
+
+static inline u64 ath10k_debug_get_fw_dbglog_mask(struct ath10k *ar)
+{
+ return ar->debug.fw_dbglog_mask;
+}
+
+static inline u32 ath10k_debug_get_fw_dbglog_level(struct ath10k *ar)
+{
+ return ar->debug.fw_dbglog_level;
+}
+
#else
+
static inline int ath10k_debug_start(struct ath10k *ar)
{
return 0;
@@ -144,6 +156,16 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
return NULL;
}
+static inline u64 ath10k_debug_get_fw_dbglog_mask(struct ath10k *ar)
+{
+ return 0;
+}
+
+static inline u32 ath10k_debug_get_fw_dbglog_level(struct ath10k *ar)
+{
+ return 0;
+}
+
#define ATH10K_DFS_STAT_INC(ar, c) do { } while (0)
#define ath10k_debug_get_et_strings NULL
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index 675e75d66db2..33fb26833cd0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -17,11 +17,14 @@
#include <linux/types.h>
#include "core.h"
#include "hw.h"
+#include "hif.h"
+#include "wmi-ops.h"
const struct ath10k_hw_regs qca988x_regs = {
.rtc_soc_base_address = 0x00004000,
.rtc_wmac_base_address = 0x00005000,
.soc_core_base_address = 0x00009000,
+ .wlan_mac_base_address = 0x00020000,
.ce_wrapper_base_address = 0x00057000,
.ce0_base_address = 0x00057400,
.ce1_base_address = 0x00057800,
@@ -48,6 +51,7 @@ const struct ath10k_hw_regs qca6174_regs = {
.rtc_soc_base_address = 0x00000800,
.rtc_wmac_base_address = 0x00001000,
.soc_core_base_address = 0x0003a000,
+ .wlan_mac_base_address = 0x00020000,
.ce_wrapper_base_address = 0x00034000,
.ce0_base_address = 0x00034400,
.ce1_base_address = 0x00034800,
@@ -74,6 +78,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
.rtc_soc_base_address = 0x00080000,
.rtc_wmac_base_address = 0x00000000,
.soc_core_base_address = 0x00082000,
+ .wlan_mac_base_address = 0x00030000,
.ce_wrapper_base_address = 0x0004d000,
.ce0_base_address = 0x0004a000,
.ce1_base_address = 0x0004a400,
@@ -109,6 +114,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
const struct ath10k_hw_regs qca4019_regs = {
.rtc_soc_base_address = 0x00080000,
.soc_core_base_address = 0x00082000,
+ .wlan_mac_base_address = 0x00030000,
.ce_wrapper_base_address = 0x0004d000,
.ce0_base_address = 0x0004a000,
.ce1_base_address = 0x0004a400,
@@ -220,7 +226,143 @@ void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
survey->time_busy = CCNT_TO_MSEC(ar, rcc);
}
+/* The firmware does not support setting the coverage class. Instead this
+ * function monitors and modifies the corresponding MAC registers.
+ */
+static void ath10k_hw_qca988x_set_coverage_class(struct ath10k *ar,
+ s16 value)
+{
+ u32 slottime_reg;
+ u32 slottime;
+ u32 timeout_reg;
+ u32 ack_timeout;
+ u32 cts_timeout;
+ u32 phyclk_reg;
+ u32 phyclk;
+ u64 fw_dbglog_mask;
+ u32 fw_dbglog_level;
+
+ mutex_lock(&ar->conf_mutex);
+
+ /* Only modify registers if the core is started. */
+ if ((ar->state != ATH10K_STATE_ON) &&
+ (ar->state != ATH10K_STATE_RESTARTED))
+ goto unlock;
+
+ /* Retrieve the current values of the two registers that need to be
+ * adjusted.
+ */
+ slottime_reg = ath10k_hif_read32(ar, WLAN_MAC_BASE_ADDRESS +
+ WAVE1_PCU_GBL_IFS_SLOT);
+ timeout_reg = ath10k_hif_read32(ar, WLAN_MAC_BASE_ADDRESS +
+ WAVE1_PCU_ACK_CTS_TIMEOUT);
+ phyclk_reg = ath10k_hif_read32(ar, WLAN_MAC_BASE_ADDRESS +
+ WAVE1_PHYCLK);
+ phyclk = MS(phyclk_reg, WAVE1_PHYCLK_USEC) + 1;
+
+ if (value < 0)
+ value = ar->fw_coverage.coverage_class;
+
+ /* Break out if the coverage class and registers have the expected
+ * value.
+ */
+ if (value == ar->fw_coverage.coverage_class &&
+ slottime_reg == ar->fw_coverage.reg_slottime_conf &&
+ timeout_reg == ar->fw_coverage.reg_ack_cts_timeout_conf &&
+ phyclk_reg == ar->fw_coverage.reg_phyclk)
+ goto unlock;
+
+ /* Store new initial register values from the firmware. */
+ if (slottime_reg != ar->fw_coverage.reg_slottime_conf)
+ ar->fw_coverage.reg_slottime_orig = slottime_reg;
+ if (timeout_reg != ar->fw_coverage.reg_ack_cts_timeout_conf)
+ ar->fw_coverage.reg_ack_cts_timeout_orig = timeout_reg;
+ ar->fw_coverage.reg_phyclk = phyclk_reg;
+
+ /* Calculat new value based on the (original) firmware calculation. */
+ slottime_reg = ar->fw_coverage.reg_slottime_orig;
+ timeout_reg = ar->fw_coverage.reg_ack_cts_timeout_orig;
+
+ /* Do some sanity checks on the slottime register. */
+ if (slottime_reg % phyclk) {
+ ath10k_warn(ar,
+ "failed to set coverage class: expected integer microsecond value in register\n");
+
+ goto store_regs;
+ }
+
+ slottime = MS(slottime_reg, WAVE1_PCU_GBL_IFS_SLOT);
+ slottime = slottime / phyclk;
+ if (slottime != 9 && slottime != 20) {
+ ath10k_warn(ar,
+ "failed to set coverage class: expected slot time of 9 or 20us in HW register. It is %uus.\n",
+ slottime);
+
+ goto store_regs;
+ }
+
+ /* Recalculate the register values by adding the additional propagation
+ * delay (3us per coverage class).
+ */
+
+ slottime = MS(slottime_reg, WAVE1_PCU_GBL_IFS_SLOT);
+ slottime += value * 3 * phyclk;
+ slottime = min_t(u32, slottime, WAVE1_PCU_GBL_IFS_SLOT_MAX);
+ slottime = SM(slottime, WAVE1_PCU_GBL_IFS_SLOT);
+ slottime_reg = (slottime_reg & ~WAVE1_PCU_GBL_IFS_SLOT_MASK) | slottime;
+
+ /* Update ack timeout (lower halfword). */
+ ack_timeout = MS(timeout_reg, WAVE1_PCU_ACK_CTS_TIMEOUT_ACK);
+ ack_timeout += 3 * value * phyclk;
+ ack_timeout = min_t(u32, ack_timeout, WAVE1_PCU_ACK_CTS_TIMEOUT_MAX);
+ ack_timeout = SM(ack_timeout, WAVE1_PCU_ACK_CTS_TIMEOUT_ACK);
+
+ /* Update cts timeout (upper halfword). */
+ cts_timeout = MS(timeout_reg, WAVE1_PCU_ACK_CTS_TIMEOUT_CTS);
+ cts_timeout += 3 * value * phyclk;
+ cts_timeout = min_t(u32, cts_timeout, WAVE1_PCU_ACK_CTS_TIMEOUT_MAX);
+ cts_timeout = SM(cts_timeout, WAVE1_PCU_ACK_CTS_TIMEOUT_CTS);
+
+ timeout_reg = ack_timeout | cts_timeout;
+
+ ath10k_hif_write32(ar,
+ WLAN_MAC_BASE_ADDRESS + WAVE1_PCU_GBL_IFS_SLOT,
+ slottime_reg);
+ ath10k_hif_write32(ar,
+ WLAN_MAC_BASE_ADDRESS + WAVE1_PCU_ACK_CTS_TIMEOUT,
+ timeout_reg);
+
+ /* Ensure we have a debug level of WARN set for the case that the
+ * coverage class is larger than 0. This is important as we need to
+ * set the registers again if the firmware does an internal reset and
+ * this way we will be notified of the event.
+ */
+ fw_dbglog_mask = ath10k_debug_get_fw_dbglog_mask(ar);
+ fw_dbglog_level = ath10k_debug_get_fw_dbglog_level(ar);
+
+ if (value > 0) {
+ if (fw_dbglog_level > ATH10K_DBGLOG_LEVEL_WARN)
+ fw_dbglog_level = ATH10K_DBGLOG_LEVEL_WARN;
+ fw_dbglog_mask = ~0;
+ }
+
+ ath10k_wmi_dbglog_cfg(ar, fw_dbglog_mask, fw_dbglog_level);
+
+store_regs:
+ /* After an error we will not retry setting the coverage class. */
+ spin_lock_bh(&ar->data_lock);
+ ar->fw_coverage.coverage_class = value;
+ spin_unlock_bh(&ar->data_lock);
+
+ ar->fw_coverage.reg_slottime_conf = slottime_reg;
+ ar->fw_coverage.reg_ack_cts_timeout_conf = timeout_reg;
+
+unlock:
+ mutex_unlock(&ar->conf_mutex);
+}
+
const struct ath10k_hw_ops qca988x_ops = {
+ .set_coverage_class = ath10k_hw_qca988x_set_coverage_class,
};
static int ath10k_qca99x0_rx_desc_get_l3_pad_bytes(struct htt_rx_desc *rxd)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 6038b7486f1d..883547f3347c 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -230,6 +230,7 @@ struct ath10k_hw_regs {
u32 rtc_soc_base_address;
u32 rtc_wmac_base_address;
u32 soc_core_base_address;
+ u32 wlan_mac_base_address;
u32 ce_wrapper_base_address;
u32 ce0_base_address;
u32 ce1_base_address;
@@ -418,6 +419,7 @@ struct htt_rx_desc;
/* Defines needed for Rx descriptor abstraction */
struct ath10k_hw_ops {
int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
+ void (*set_coverage_class)(struct ath10k *ar, s16 value);
};
extern const struct ath10k_hw_ops qca988x_ops;
@@ -614,7 +616,7 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
#define WLAN_SI_BASE_ADDRESS 0x00010000
#define WLAN_GPIO_BASE_ADDRESS 0x00014000
#define WLAN_ANALOG_INTF_BASE_ADDRESS 0x0001c000
-#define WLAN_MAC_BASE_ADDRESS 0x00020000
+#define WLAN_MAC_BASE_ADDRESS ar->regs->wlan_mac_base_address
#define EFUSE_BASE_ADDRESS 0x00030000
#define FPGA_REG_BASE_ADDRESS 0x00039000
#define WLAN_UART2_BASE_ADDRESS 0x00054c00
@@ -814,4 +816,28 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
#define RTC_STATE_V_GET(x) (((x) & RTC_STATE_V_MASK) >> RTC_STATE_V_LSB)
+/* Register definitions for first generation ath10k cards. These cards include
+ * a mac thich has a register allocation similar to ath9k and at least some
+ * registers including the ones relevant for modifying the coverage class are
+ * identical to the ath9k definitions.
+ * These registers are usually managed by the ath10k firmware. However by
+ * overriding them it is possible to support coverage class modifications.
+ */
+#define WAVE1_PCU_ACK_CTS_TIMEOUT 0x8014
+#define WAVE1_PCU_ACK_CTS_TIMEOUT_MAX 0x00003FFF
+#define WAVE1_PCU_ACK_CTS_TIMEOUT_ACK_MASK 0x00003FFF
+#define WAVE1_PCU_ACK_CTS_TIMEOUT_ACK_LSB 0
+#define WAVE1_PCU_ACK_CTS_TIMEOUT_CTS_MASK 0x3FFF0000
+#define WAVE1_PCU_ACK_CTS_TIMEOUT_CTS_LSB 16
+
+#define WAVE1_PCU_GBL_IFS_SLOT 0x1070
+#define WAVE1_PCU_GBL_IFS_SLOT_MASK 0x0000FFFF
+#define WAVE1_PCU_GBL_IFS_SLOT_MAX 0x0000FFFF
+#define WAVE1_PCU_GBL_IFS_SLOT_LSB 0
+#define WAVE1_PCU_GBL_IFS_SLOT_RESV0 0xFFFF0000
+
+#define WAVE1_PHYCLK 0x801C
+#define WAVE1_PHYCLK_USEC_MASK 0x0000007F
+#define WAVE1_PHYCLK_USEC_LSB 0
+
#endif /* _HW_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 837384e4422b..0f3d4cf7dc00 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5411,6 +5411,20 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
mutex_unlock(&ar->conf_mutex);
}
+static void ath10k_mac_op_set_coverage_class(struct ieee80211_hw *hw, s16 value)
+{
+ struct ath10k *ar = hw->priv;
+
+ /* This function should never be called if setting the coverage class
+ * is not supported on this hardware.
+ */
+ if (!ar->hw_params.hw_ops->set_coverage_class) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+ ar->hw_params.hw_ops->set_coverage_class(ar, value);
+}
+
static int ath10k_hw_scan(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_scan_request *hw_req)
@@ -7436,6 +7450,7 @@ static const struct ieee80211_ops ath10k_ops = {
.remove_interface = ath10k_remove_interface,
.configure_filter = ath10k_configure_filter,
.bss_info_changed = ath10k_bss_info_changed,
+ .set_coverage_class = ath10k_mac_op_set_coverage_class,
.hw_scan = ath10k_hw_scan,
.cancel_hw_scan = ath10k_cancel_hw_scan,
.set_key = ath10k_set_key,
@@ -8120,6 +8135,10 @@ int ath10k_mac_register(struct ath10k *ar)
goto err_dfs_detector_exit;
}
+ /* Disable set_coverage_class for chipsets that do not support it. */
+ if (!ar->hw_params.hw_ops->set_coverage_class)
+ ar->ops->set_coverage_class = NULL;
+
ret = ath_regd_init(&ar->ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index b4cfaf9aa0ac..387c4eede388 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4931,6 +4931,23 @@ exit:
return 0;
}
+static inline void ath10k_wmi_queue_set_coverage_class_work(struct ath10k *ar)
+{
+ if (ar->hw_params.hw_ops->set_coverage_class) {
+ spin_lock_bh(&ar->data_lock);
+
+ /* This call only ensures that the modified coverage class
+ * persists in case the firmware sets the registers back to
+ * their default value. So calling it is only necessary if the
+ * coverage class has a non-zero value.
+ */
+ if (ar->fw_coverage.coverage_class)
+ queue_work(ar->workqueue, &ar->set_coverage_class_work);
+
+ spin_unlock_bh(&ar->data_lock);
+ }
+}
+
static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_cmd_hdr *cmd_hdr;
@@ -4951,6 +4968,7 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
return;
case WMI_SCAN_EVENTID:
ath10k_wmi_event_scan(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_CHAN_INFO_EVENTID:
ath10k_wmi_event_chan_info(ar, skb);
@@ -4960,15 +4978,18 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_DEBUG_MESG_EVENTID:
ath10k_wmi_event_debug_mesg(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_UPDATE_STATS_EVENTID:
ath10k_wmi_event_update_stats(ar, skb);
break;
case WMI_VDEV_START_RESP_EVENTID:
ath10k_wmi_event_vdev_start_resp(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_VDEV_STOPPED_EVENTID:
ath10k_wmi_event_vdev_stopped(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_PEER_STA_KICKOUT_EVENTID:
ath10k_wmi_event_peer_sta_kickout(ar, skb);
@@ -4984,12 +5005,14 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_ROAM_EVENTID:
ath10k_wmi_event_roam(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_PROFILE_MATCH:
ath10k_wmi_event_profile_match(ar, skb);
break;
case WMI_DEBUG_PRINT_EVENTID:
ath10k_wmi_event_debug_print(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_PDEV_QVIT_EVENTID:
ath10k_wmi_event_pdev_qvit(ar, skb);
@@ -5038,6 +5061,7 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
return;
case WMI_READY_EVENTID:
ath10k_wmi_event_ready(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
@@ -5081,6 +5105,7 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
return;
case WMI_10X_SCAN_EVENTID:
ath10k_wmi_event_scan(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_CHAN_INFO_EVENTID:
ath10k_wmi_event_chan_info(ar, skb);
@@ -5090,15 +5115,18 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10X_DEBUG_MESG_EVENTID:
ath10k_wmi_event_debug_mesg(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_UPDATE_STATS_EVENTID:
ath10k_wmi_event_update_stats(ar, skb);
break;
case WMI_10X_VDEV_START_RESP_EVENTID:
ath10k_wmi_event_vdev_start_resp(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_VDEV_STOPPED_EVENTID:
ath10k_wmi_event_vdev_stopped(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_PEER_STA_KICKOUT_EVENTID:
ath10k_wmi_event_peer_sta_kickout(ar, skb);
@@ -5114,12 +5142,14 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10X_ROAM_EVENTID:
ath10k_wmi_event_roam(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_PROFILE_MATCH:
ath10k_wmi_event_profile_match(ar, skb);
break;
case WMI_10X_DEBUG_PRINT_EVENTID:
ath10k_wmi_event_debug_print(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_PDEV_QVIT_EVENTID:
ath10k_wmi_event_pdev_qvit(ar, skb);
@@ -5159,6 +5189,7 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb)
return;
case WMI_10X_READY_EVENTID:
ath10k_wmi_event_ready(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10X_PDEV_UTF_EVENTID:
/* ignore utf events */
@@ -5205,6 +5236,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
return;
case WMI_10_2_SCAN_EVENTID:
ath10k_wmi_event_scan(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_CHAN_INFO_EVENTID:
ath10k_wmi_event_chan_info(ar, skb);
@@ -5214,15 +5246,18 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_2_DEBUG_MESG_EVENTID:
ath10k_wmi_event_debug_mesg(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_UPDATE_STATS_EVENTID:
ath10k_wmi_event_update_stats(ar, skb);
break;
case WMI_10_2_VDEV_START_RESP_EVENTID:
ath10k_wmi_event_vdev_start_resp(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_VDEV_STOPPED_EVENTID:
ath10k_wmi_event_vdev_stopped(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_PEER_STA_KICKOUT_EVENTID:
ath10k_wmi_event_peer_sta_kickout(ar, skb);
@@ -5238,12 +5273,14 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_2_ROAM_EVENTID:
ath10k_wmi_event_roam(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_PROFILE_MATCH:
ath10k_wmi_event_profile_match(ar, skb);
break;
case WMI_10_2_DEBUG_PRINT_EVENTID:
ath10k_wmi_event_debug_print(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_PDEV_QVIT_EVENTID:
ath10k_wmi_event_pdev_qvit(ar, skb);
@@ -5274,15 +5311,18 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_2_VDEV_STANDBY_REQ_EVENTID:
ath10k_wmi_event_vdev_standby_req(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_VDEV_RESUME_REQ_EVENTID:
ath10k_wmi_event_vdev_resume_req(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_SERVICE_READY_EVENTID:
ath10k_wmi_event_service_ready(ar, skb);
return;
case WMI_10_2_READY_EVENTID:
ath10k_wmi_event_ready(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_2_PDEV_TEMPERATURE_EVENTID:
ath10k_wmi_event_temperature(ar, skb);
@@ -5345,12 +5385,14 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_4_DEBUG_MESG_EVENTID:
ath10k_wmi_event_debug_mesg(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_SERVICE_READY_EVENTID:
ath10k_wmi_event_service_ready(ar, skb);
return;
case WMI_10_4_SCAN_EVENTID:
ath10k_wmi_event_scan(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_CHAN_INFO_EVENTID:
ath10k_wmi_event_chan_info(ar, skb);
@@ -5360,12 +5402,14 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_4_READY_EVENTID:
ath10k_wmi_event_ready(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_PEER_STA_KICKOUT_EVENTID:
ath10k_wmi_event_peer_sta_kickout(ar, skb);
break;
case WMI_10_4_ROAM_EVENTID:
ath10k_wmi_event_roam(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_HOST_SWBA_EVENTID:
ath10k_wmi_event_host_swba(ar, skb);
@@ -5375,12 +5419,15 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
break;
case WMI_10_4_DEBUG_PRINT_EVENTID:
ath10k_wmi_event_debug_print(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_VDEV_START_RESP_EVENTID:
ath10k_wmi_event_vdev_start_resp(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_VDEV_STOPPED_EVENTID:
ath10k_wmi_event_vdev_stopped(ar, skb);
+ ath10k_wmi_queue_set_coverage_class_work(ar);
break;
case WMI_10_4_WOW_WAKEUP_HOST_EVENTID:
case WMI_10_4_PEER_RATECODE_LIST_EVENTID:
@@ -6099,6 +6146,7 @@ void ath10k_wmi_start_scan_init(struct ath10k *ar,
| WMI_SCAN_EVENT_COMPLETED
| WMI_SCAN_EVENT_BSS_CHANNEL
| WMI_SCAN_EVENT_FOREIGN_CHANNEL
+ | WMI_SCAN_EVENT_FOREIGN_CHANNEL_EXIT
| WMI_SCAN_EVENT_DEQUEUED;
arg->scan_ctrl_flags |= WMI_SCAN_CHAN_STAT_EVENT;
arg->n_bssids = 1;
--
1.7.9.5
^ permalink raw reply related
* Re: pull-request: wireless-drivers-next 2016-09-29
From: Aaron Conole @ 2016-09-30 13:30 UTC (permalink / raw)
To: David Miller, Pablo Neira Ayuso
Cc: kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160930.013245.1474369794552343595.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Thu, 29 Sep 2016 19:57:28 +0300
>
...
>> Or actually I had one problem. While doing a test merge I noticed that
>> net-next fails to compile for me, but I don't think this is anything
>> wireless related:
>>
>> CC net/netfilter/core.o
>> net/netfilter/core.c: In function 'nf_set_hooks_head':
>> net/netfilter/core.c:96:149: error: 'struct net_device' has no
>> member named 'nf_hooks_ingress'
>
> Yes, I am aware of this build issue and will tackle it myself if someone
> doesn't beat me to it.
Sorry, I introduced this. I posted a series targetted at nf-next to
solve this, but it could be merged to net-next instead, if that makes
sense.
The patches are here:
https://patchwork.ozlabs.org/patch/676287/
https://patchwork.ozlabs.org/patch/676288/
Again, sorry for this.
^ permalink raw reply
* Re: [PATCH 2/2] Revert "staging: wilc1000: Replace kthread with workqueue for host interface"
From: Greg KH @ 2016-09-30 13:22 UTC (permalink / raw)
To: Aditya Shankar
Cc: ganesh.krishna, linux-wireless, devel, linux-kernel,
Nicolas.Ferre
In-Reply-To: <20160930101318.GA24973@aditya-ubuntu.local>
On Fri, Sep 30, 2016 at 03:43:18PM +0530, Aditya Shankar wrote:
> This reverts commit 2518ac59eb27 ("staging: wilc1000: Replace kthread
> with workqueue for host interface")
>
> This commit breaks wilc1000 driver init. A crash was seen
> everytime the wlan interface was brought up and wilc device
> open was attempted. This change is being reverted until we
> figure out the problem in this change. The driver is
> usable now with this change reverted.
>
> Signed-off-by: Aditya Shankar <Aditya.Shankar@microchip.com>
>
> Conflicts:
> drivers/staging/wilc1000/host_interface.c
What is this line doing here?
And shouldn't we add a cc: stable tag as well? Or at the least, put a
"fixes:" tag to let people know exactly what commit it is fixing (the
id that it is reverting.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/3] cw1200: Don't leak memory if krealloc failes
From: Johannes Thumshirn @ 2016-09-30 13:00 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Solomon Peachy, Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <25a38254-f0e3-1f4e-de46-688d9fd1b736@cogentembedded.com>
On Fri, Sep 30, 2016 at 03:56:45PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 9/30/2016 3:11 PM, Johannes Thumshirn wrote:
>
> > The call to krealloc() in wsm_buf_reserve() directly assigns the newly
> > returned memory to buf->begin. This is all fine except when krealloc()
> > failes we loose the ability to free the old memory pointed to by
>
> Fails.
>
> > buf->begin. If we just create a temporary variable to assign memory to
> > and assign the memory to it we can mitigate the memory leak.
> >
> > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> > ---
> > drivers/net/wireless/st/cw1200/wsm.c | 16 +++++++++-------
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/wireless/st/cw1200/wsm.c b/drivers/net/wireless/st/cw1200/wsm.c
> > index 680d60e..12fad99 100644
> > --- a/drivers/net/wireless/st/cw1200/wsm.c
> > +++ b/drivers/net/wireless/st/cw1200/wsm.c
> > @@ -1807,16 +1807,18 @@ static int wsm_buf_reserve(struct wsm_buf *buf, size_t extra_size)
> > {
> > size_t pos = buf->data - buf->begin;
> > size_t size = pos + extra_size;
> > + u8 *tmp;
> >
> > size = round_up(size, FWLOAD_BLOCK_SIZE);
> >
> > - buf->begin = krealloc(buf->begin, size, GFP_KERNEL | GFP_DMA);
> > - if (buf->begin) {
> > - buf->data = &buf->begin[pos];
> > - buf->end = &buf->begin[size];
> > - return 0;
> > - } else {
> > - buf->end = buf->data = buf->begin;
> > + tmp = krealloc(buf->begin, size, GFP_KERNEL | GFP_DMA);
> > + if (tmp) {
>
> !tmp, you mean?
Yes, I've already sent out a v2.
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH] ath10k: Fix spinlock use in coverage class hack
From: Valo, Kalle @ 2016-09-30 12:58 UTC (permalink / raw)
To: Benjamin Berg
Cc: Simon Wunderlich, Thiagarajan, Vasanthakumar,
linux-wireless@vger.kernel.org, Sebastian Gottschall,
ath10k @ lists . infradead . org, michal.kazior@tieto.com,
Mathias Kretschmer
In-Reply-To: <20160914163231.20863-1-benjamin@sipsolutions.net>
Benjamin Berg <benjamin@sipsolutions.net> writes:
> ath10k_hw_qca988x_set_coverage_class needs to hold both conf_mutex and
> the data_lock spin lock for parts of the function. However, data_lock
> is only needed while storing the coverage_class to store the value that
> the card is configured to.
>
> Fix the locking issue by only holding data_lock for the required duration=
.
>
> Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Thanks, I also folded this with the patch in the pending branch.
> And yes, I fully agree with your points of it being rather fragile. But a=
s
> you said, it should be entirely safe if not used.
That's good.
> Obviously a firmware implementation would be preferential.
That's a shame as this feature is quite often requested. But if the
firmware ever starts supporting the featrue we can then remove this hack
from ath10k.
> This locking issue was pretty unnecessary. Lets see if any more issues sh=
ow
> up in a closer review.
I can't see the locking problem anymore so it seems to be fixed. I'll
fix some minor things and send v2. I'll also CC linux-wireless.
--=20
Kalle Valo=
^ 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