* Re: PS-Poll not behaving as expected
From: Yuri Shih @ 2017-11-14 3:01 UTC (permalink / raw)
To: Daniel Ghansah; +Cc: Steve deRosier, linux-wireless
In-Reply-To: <CAL3ir7J5GwTjgo6U4k_r91uqMV4Nowr10k8-Kd+t8cXfrwKQDQ@mail.gmail.com>
Hello Steve,
For our hardware/driver information, they are the following:
Linux FW: Linux LEDE 4.4.87
AP Hardware: Compex WPJ563HV (radio chip QCA9563, driver Ath9k)
5G Radio: WLE1216V5-20 (radio chip QCA9984, driver Ath10k)
Driver: Base Driver is compat-wireless-2017-01-31 (with various
patches installed)
Station: Marvell RD-88W-8897-WIFI-S0 (radio chip 88W8897)
Driver - PCIE8897-15.68.6.p5-M2615485.p3-GPL-(FP68)
Here's also a link to the wireshark sniffer recordings:
https://drive.google.com/open?id=1GGNpMhfZ9Ya7HPrdISTxGLfXIuBgL1PR
Right now we don't have kernel logs since we weren't the ones who did
the test (test lab did them), but I can ask test lab to do the test
and give us the logs.
Thanks.
Sincerely,
Yuri
On Tue, Nov 14, 2017 at 10:45 AM, Daniel Ghansah <smartwires@gmail.com> wrote:
> Hello Steve,
> Thanks for your prompt response, and sorry for my lack of
> details my colleague Yuri will provide this info shortly Thanks
>
> Regards
> Daniel
>
> On Mon, Nov 13, 2017 at 7:01 PM, Steve deRosier <derosier@gmail.com> wrote:
>> Hi Daniel,
>>
>> On Mon, Nov 13, 2017 at 2:40 PM, Daniel Ghansah <smartwires@gmail.com> wrote:
>>> Here is the problem we experience:
>>>
>>> When the station (wifi devices) sends a null QoS frame with power save
>>> telling our AP that it is going into power save mode. RIght now, our
>>> problem is that the AP will not stop sending data packets to the
>>> station. Correct behavior is that the AP will buffer data packets and
>>> stop sending any data or null packets (WiFi Alliance allows at most 2
>>> of these packets to be sent by the AP before station sends ps-poll,
>>> exclude retries) until a PS-Poll packet is sent by the station to
>>> collect data. The AP should also respond only 1 packet per PS-Poll
>>> (exclude any retries). Right now, we are also experiencing that the AP
>>> will, at times, send more than 1 data packet to the station per
>>> PS-Poll. The first and second problems may be linked together.
>>>
>>
>> You've given no context with which we can help you. Things like the
>> Linux version, the hardware running on the AP and client, which it is
>> you're trying to report a bug on (the AP or Client), dmesg logs,
>> wireless traces, and so on would all be somewhere between mandatory to
>> helpful information. Trying to give us nothing but your interpretation
>> of what the 802.11 standard says (which most of us know very well)
>> isn't a useful bug report.
>>
>> This might help:
>> https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs
>>
>> Please try again and send us the information we need to be able to help.
>>
>> Thanks,
>> - Steve
>
>
>
> --
> Regards,
> Daniel Ghansah
^ permalink raw reply
* Re: PS-Poll not behaving as expected
From: Daniel Ghansah @ 2017-11-14 2:45 UTC (permalink / raw)
To: Steve deRosier; +Cc: linux-wireless, yurishih1985
In-Reply-To: <CALLGbRKwcm0ugSKAV1p3rxGseAkp6Zk9RZvKZeTrWFJ_=-pSKg@mail.gmail.com>
Hello Steve,
Thanks for your prompt response, and sorry for my lack of
details my colleague Yuri will provide this info shortly Thanks
Regards
Daniel
On Mon, Nov 13, 2017 at 7:01 PM, Steve deRosier <derosier@gmail.com> wrote:
> Hi Daniel,
>
> On Mon, Nov 13, 2017 at 2:40 PM, Daniel Ghansah <smartwires@gmail.com> wrote:
>> Here is the problem we experience:
>>
>> When the station (wifi devices) sends a null QoS frame with power save
>> telling our AP that it is going into power save mode. RIght now, our
>> problem is that the AP will not stop sending data packets to the
>> station. Correct behavior is that the AP will buffer data packets and
>> stop sending any data or null packets (WiFi Alliance allows at most 2
>> of these packets to be sent by the AP before station sends ps-poll,
>> exclude retries) until a PS-Poll packet is sent by the station to
>> collect data. The AP should also respond only 1 packet per PS-Poll
>> (exclude any retries). Right now, we are also experiencing that the AP
>> will, at times, send more than 1 data packet to the station per
>> PS-Poll. The first and second problems may be linked together.
>>
>
> You've given no context with which we can help you. Things like the
> Linux version, the hardware running on the AP and client, which it is
> you're trying to report a bug on (the AP or Client), dmesg logs,
> wireless traces, and so on would all be somewhere between mandatory to
> helpful information. Trying to give us nothing but your interpretation
> of what the 802.11 standard says (which most of us know very well)
> isn't a useful bug report.
>
> This might help:
> https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs
>
> Please try again and send us the information we need to be able to help.
>
> Thanks,
> - Steve
--
Regards,
Daniel Ghansah
305-801-4895
^ permalink raw reply
* Re: PS-Poll not behaving as expected
From: Steve deRosier @ 2017-11-14 0:01 UTC (permalink / raw)
To: Daniel Ghansah; +Cc: linux-wireless
In-Reply-To: <CAL3ir7JHwLpNFRSv0jEED50XeFAWmSz4gXXOs0MpM=VeTGiKnQ@mail.gmail.com>
Hi Daniel,
On Mon, Nov 13, 2017 at 2:40 PM, Daniel Ghansah <smartwires@gmail.com> wrote:
> Here is the problem we experience:
>
> When the station (wifi devices) sends a null QoS frame with power save
> telling our AP that it is going into power save mode. RIght now, our
> problem is that the AP will not stop sending data packets to the
> station. Correct behavior is that the AP will buffer data packets and
> stop sending any data or null packets (WiFi Alliance allows at most 2
> of these packets to be sent by the AP before station sends ps-poll,
> exclude retries) until a PS-Poll packet is sent by the station to
> collect data. The AP should also respond only 1 packet per PS-Poll
> (exclude any retries). Right now, we are also experiencing that the AP
> will, at times, send more than 1 data packet to the station per
> PS-Poll. The first and second problems may be linked together.
>
You've given no context with which we can help you. Things like the
Linux version, the hardware running on the AP and client, which it is
you're trying to report a bug on (the AP or Client), dmesg logs,
wireless traces, and so on would all be somewhere between mandatory to
helpful information. Trying to give us nothing but your interpretation
of what the 802.11 standard says (which most of us know very well)
isn't a useful bug report.
This might help:
https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs
Please try again and send us the information we need to be able to help.
Thanks,
- Steve
^ permalink raw reply
* PS-Poll not behaving as expected
From: Daniel Ghansah @ 2017-11-13 22:40 UTC (permalink / raw)
To: linux-wireless
Here is the problem we experience:
When the station (wifi devices) sends a null QoS frame with power save
telling our AP that it is going into power save mode. RIght now, our
problem is that the AP will not stop sending data packets to the
station. Correct behavior is that the AP will buffer data packets and
stop sending any data or null packets (WiFi Alliance allows at most 2
of these packets to be sent by the AP before station sends ps-poll,
exclude retries) until a PS-Poll packet is sent by the station to
collect data. The AP should also respond only 1 packet per PS-Poll
(exclude any retries). Right now, we are also experiencing that the AP
will, at times, send more than 1 data packet to the station per
PS-Poll. The first and second problems may be linked together.
--
Regards,
Daniel
^ permalink raw reply
* Re: [v2] ath9k: add MSI support
From: Daniel Drake @ 2017-11-13 22:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Russell Hu, linux-wireless@vger.kernel.org, Ryan Hsu,
Robert Chang, Aeolus Yang, ath9k-devel, linux@endlessm.com,
rafael.j.wysocki@intel.com, andy@infradead.org
In-Reply-To: <87y3na7eei.fsf@qca.qualcomm.com>
On Mon, Nov 13, 2017 at 4:48 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Enabling MSI by default is just too invasive, ath9k is used in so many
> different enviroments that risk of regressions is high. MSI needs a lot
> of testing before we can even consider enabling it by default.
And it seems like we already found a regression here - the MSI Message
Data is being corrupted as described in my last mail. Can't be fixed
in firmware, but it would be good to have confirmation of the hardware
behavivour, and maybe some other solution is possible? Are you
following this up within Qualcomm?
>> I have tested your patch on Acer Aspire ES1-432. It does not work -
>> I still can't connect to wifi.
>> /proc/interrupts shows that no MSI interrupts are delivered, the
>> counters are 0.
>>
>> lspci -vv shows:
>> Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+
>> Address: 00000000fee0f00c Data: 4142
>> Masking: 0000000e Pending: 00000000
>>
>> So MSI is enabled and the vector number is 0x42 (decimal 66).
>> However my kernel log is now totally spammed with:
>> do_IRQ: 0.64 No irq handler for vector
>>
>> My assumption here is that the ath9k hardware implementation of
>> MSI is buggy, and it is therefore corrupting the MSI vector number
>> by zeroing out the lower 2 bits (e.g. 66 -> 64).
Thanks
Daniel
^ permalink raw reply
* Re: Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s
From: Larry Finger @ 2017-11-13 22:23 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-wireless, linux-kernel, Berg, Emmanuel Grumbach,
Luca Coelho
In-Reply-To: <CAMRc=Mf-sy79yoJiyZC8pOtHTo4P7SpHPsTmuHxEBfbc8xa+Uw@mail.gmail.com>
On 11/13/2017 03:30 PM, Bartosz Golaszewski wrote:
> 2017-11-13 21:45 GMT+01:00 Larry Finger <Larry.Finger@lwfinger.net>:
>> On 11/13/2017 02:22 PM, Bartosz Golaszewski wrote:
>>>
>>> Forwarding here too as I messed up the address the last time.
>>> --
>>>
>>> Hi,
>>>
>>> I noticed my wireless interface can't get up with linux v4.14 and the
>>> kernel log is flooded with firmware errors:
>>>
>>> iwlwifi 0000:03:00.0: Firmware error during reconfiguration - reprobe!
>>> iwlwifi 0000:03:00.0: FW error in SYNC CMD DQA_ENABLE_CMD
>>>
>>> and
>>>
>>> ieee80211 phy63: Hardware restart was requested.
>>>
>>> The wireless controller is: Intel Corporation Wireless 7260 (rev 83)
>>> Firmware used is: iwlwifi-7260-17
>>>
>>> Everything works fine with v4.13.12.
>>>
>>> I didn't have time today to bisect for the offending commit. Full log
>>> uploaded[1].
>>>
>>> Best regards,
>>> Bartosz Golaszewski
>>>
>>> [1] https://pastebin.com/jksqxvS6
>>
>>
>> Your log shows "iwlwifi 0000:03:00.0: loaded firmware version 17.228510.0
>> op_mode iwlmvm"
>>
>> Mine, where the 7260 works, shows "iwlwifi 0000:04:00.0: loaded firmware
>> version 17.459231.0 op_mode iwlmvm".
>>
>> It seems as if you need newer firmware. A detailed file listing shows
>> "-rw-r--r-- 1 root root 1049340 Oct 9 12:03
>> /lib/firmware/iwlwifi-7260-17.ucode". That date is likely when I installed
>> the updated kernel firmware package from my distro. The md5sum for the file
>> is 73a217f55c47d3a70bb5dbbe1d676423.
>>
>> Larry
>>
>
> Ok so it seems the version in linux-firmware is outdated. The file
> you're using is available on github[1] and fixed the issue for me.
>
> Thanks!
> Bartosz Golaszewski
>
> [1] https://github.com/OpenELEC/iwlwifi-firmware
Interesting. Using md5sum of the git repo for linux-firmware gets
73a217f55c47d3a70bb5dbbe1d676423 iwlwifi-7260-17.ucode.
That is the file I'm using.
Larry
^ permalink raw reply
* Re: Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s
From: Bartosz Golaszewski @ 2017-11-13 21:30 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, linux-kernel, Berg, Emmanuel Grumbach,
Luca Coelho
In-Reply-To: <3045d677-8f24-b258-0eaf-ee8dae5ecd4c@lwfinger.net>
2017-11-13 21:45 GMT+01:00 Larry Finger <Larry.Finger@lwfinger.net>:
> On 11/13/2017 02:22 PM, Bartosz Golaszewski wrote:
>>
>> Forwarding here too as I messed up the address the last time.
>> --
>>
>> Hi,
>>
>> I noticed my wireless interface can't get up with linux v4.14 and the
>> kernel log is flooded with firmware errors:
>>
>> iwlwifi 0000:03:00.0: Firmware error during reconfiguration - reprobe!
>> iwlwifi 0000:03:00.0: FW error in SYNC CMD DQA_ENABLE_CMD
>>
>> and
>>
>> ieee80211 phy63: Hardware restart was requested.
>>
>> The wireless controller is: Intel Corporation Wireless 7260 (rev 83)
>> Firmware used is: iwlwifi-7260-17
>>
>> Everything works fine with v4.13.12.
>>
>> I didn't have time today to bisect for the offending commit. Full log
>> uploaded[1].
>>
>> Best regards,
>> Bartosz Golaszewski
>>
>> [1] https://pastebin.com/jksqxvS6
>
>
> Your log shows "iwlwifi 0000:03:00.0: loaded firmware version 17.228510.0
> op_mode iwlmvm"
>
> Mine, where the 7260 works, shows "iwlwifi 0000:04:00.0: loaded firmware
> version 17.459231.0 op_mode iwlmvm".
>
> It seems as if you need newer firmware. A detailed file listing shows
> "-rw-r--r-- 1 root root 1049340 Oct 9 12:03
> /lib/firmware/iwlwifi-7260-17.ucode". That date is likely when I installed
> the updated kernel firmware package from my distro. The md5sum for the file
> is 73a217f55c47d3a70bb5dbbe1d676423.
>
> Larry
>
Ok so it seems the version in linux-firmware is outdated. The file
you're using is available on github[1] and fixed the issue for me.
Thanks!
Bartosz Golaszewski
[1] https://github.com/OpenELEC/iwlwifi-firmware
^ permalink raw reply
* Re: [PATCH 0/3] rtlwifi: Refactor TX/RX flow to improve throughput
From: Larry Finger @ 2017-11-13 21:23 UTC (permalink / raw)
To: pkshih, kvalo; +Cc: linux-wireless, steventing, yhchuang
In-Reply-To: <20171113093935.20431-1-pkshih@realtek.com>
On 11/13/2017 03:39 AM, pkshih@realtek.com wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> This patchset is aim to reduce IO to improve TX/RX performance, and also I
> cleanup the code to make it easier and simpler.
>
> Ping-Ke Shih (3):
> rtlwifi: Reduce IO in RX interrupt to boost throughput
> rtlwifi: fix the wrong size to calculate fifo space
> rtlwifi: cleanup the code that check whether TX ring is available
All 3 Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
>
> drivers/net/wireless/realtek/rtlwifi/pci.c | 13 ++---
> drivers/net/wireless/realtek/rtlwifi/pci.h | 5 +-
> .../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 57 ++++------------------
> 3 files changed, 15 insertions(+), 60 deletions(-)
>
^ permalink raw reply
* Re: Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s
From: Larry Finger @ 2017-11-13 20:45 UTC (permalink / raw)
To: Bartosz Golaszewski, linux-wireless
In-Reply-To: <CAMRc=Mf-4HnRXLxoiPrzZVjeCpfY5+Q2Ydmee0GkViejk8nzaQ@mail.gmail.com>
On 11/13/2017 02:22 PM, Bartosz Golaszewski wrote:
> Forwarding here too as I messed up the address the last time.
> --
>
> Hi,
>
> I noticed my wireless interface can't get up with linux v4.14 and the
> kernel log is flooded with firmware errors:
>
> iwlwifi 0000:03:00.0: Firmware error during reconfiguration - reprobe!
> iwlwifi 0000:03:00.0: FW error in SYNC CMD DQA_ENABLE_CMD
>
> and
>
> ieee80211 phy63: Hardware restart was requested.
>
> The wireless controller is: Intel Corporation Wireless 7260 (rev 83)
> Firmware used is: iwlwifi-7260-17
>
> Everything works fine with v4.13.12.
>
> I didn't have time today to bisect for the offending commit. Full log
> uploaded[1].
>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://pastebin.com/jksqxvS6
Your log shows "iwlwifi 0000:03:00.0: loaded firmware version 17.228510.0
op_mode iwlmvm"
Mine, where the 7260 works, shows "iwlwifi 0000:04:00.0: loaded firmware version
17.459231.0 op_mode iwlmvm".
It seems as if you need newer firmware. A detailed file listing shows
"-rw-r--r-- 1 root root 1049340 Oct 9 12:03
/lib/firmware/iwlwifi-7260-17.ucode". That date is likely when I installed the
updated kernel firmware package from my distro. The md5sum for the file is
73a217f55c47d3a70bb5dbbe1d676423.
Larry
^ permalink raw reply
* [PATCH 06/10] brcmfmac: Remove bandaid for SleepCSR
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
Register access code is not the place for band-aid fixes like this.
If this is a genuine problem, it should be fixed further up in the driver
stack.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 28 +---------------------
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index ad81ea4..355aebd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -334,21 +334,8 @@ static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
} while (ret != 0 && ret != -ENOMEDIUM &&
retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
- if (ret == -ENOMEDIUM) {
+ if (ret == -ENOMEDIUM)
brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
- } else if (ret != 0) {
- /*
- * SleepCSR register access can fail when
- * waking up the device so reduce this noise
- * in the logs.
- */
- if (addr != SBSDIO_FUNC1_SLEEPCSR)
- brcmf_err("failed to write data F%d@0x%05x, err: %d\n",
- func, addr, ret);
- else
- brcmf_dbg(SDIO, "failed to write data F%d@0x%05x, err: %d\n",
- func, addr, ret);
- }
return ret;
}
@@ -389,19 +376,6 @@ static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
if (ret == -ENOMEDIUM)
brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
- else if (ret != 0) {
- /*
- * SleepCSR register access can fail when
- * waking up the device so reduce this noise
- * in the logs.
- */
- if (addr != SBSDIO_FUNC1_SLEEPCSR)
- brcmf_err("failed to read data F%d@0x%05x, err: %d\n",
- func, addr, ret);
- else
- brcmf_dbg(SDIO, "failed to read data F%d@0x%05x, err: %d\n",
- func, addr, ret);
- }
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 01/10] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
All the other IO functions are the other way round in this
driver. Make this one match.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index cd58732..a8976a76 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -230,8 +230,8 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev,
sdiodev->state = state;
}
-static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func,
- uint regaddr, u8 byte)
+static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte,
+ uint regaddr)
{
int err_ret;
@@ -269,8 +269,8 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
if (fn)
sdio_writeb(func, *(u8 *)data, addr, &ret);
else
- ret = brcmf_sdiod_f0_writeb(func, addr,
- *(u8 *)data);
+ ret = brcmf_sdiod_f0_writeb(func, *(u8 *)data,
+ addr);
} else {
if (fn)
*(u8 *)data = sdio_readb(func, addr, &ret);
--
1.9.1
^ permalink raw reply related
* [PATCH 08/10] brcmfmac: Fix asymmetric IO functions.
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
Unlikely to be a problem, but brcmf_sdiod_regrl() is
not symmetric with brcmf_sdiod_regrb() in initializing
the data value on stack. Fix that.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
[arend: reword the commit message a bit]
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index bb2ebe6..e89e242 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -383,7 +383,7 @@ u8 brcmf_sdiod_regrb(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
{
- u32 data = 0;
+ u32 data;
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
--
1.9.1
^ permalink raw reply related
* [PATCH 02/10] brcmfmac: Register sizes on hardware are not dependent on compiler types
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
The 4 IO functions in this patch are incorrect as they use compiler types
to determine how many bytes to send to the hardware.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index a8976a76..25b5e9b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -264,7 +264,7 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
func = sdiodev->func[fn];
switch (regsz) {
- case sizeof(u8):
+ case 1:
if (write) {
if (fn)
sdio_writeb(func, *(u8 *)data, addr, &ret);
@@ -278,13 +278,13 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
*(u8 *)data = sdio_f0_readb(func, addr, &ret);
}
break;
- case sizeof(u16):
+ case 2:
if (write)
sdio_writew(func, *(u16 *)data, addr, &ret);
else
*(u16 *)data = sdio_readw(func, addr, &ret);
break;
- case sizeof(u32):
+ case 4:
if (write)
sdio_writel(func, *(u32 *)data, addr, &ret);
else
@@ -368,7 +368,7 @@ static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
for (i = 0; i < 3; i++) {
err = brcmf_sdiod_regrw_helper(sdiodev,
SBSDIO_FUNC1_SBADDRLOW + i,
- sizeof(u8), &addr[i], true);
+ 1, &addr[i], true);
if (err) {
brcmf_err("failed at addr: 0x%0x\n",
SBSDIO_FUNC1_SBADDRLOW + i);
@@ -407,7 +407,7 @@ u8 brcmf_sdiod_regrb(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, sizeof(data), &data,
+ retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 1, &data,
false);
brcmf_dbg(SDIO, "data:0x%02x\n", data);
@@ -423,10 +423,10 @@ u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
- retval = brcmf_sdiod_addrprep(sdiodev, sizeof(data), &addr);
+ retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
if (retval)
goto done;
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, sizeof(data), &data,
+ retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 4, &data,
false);
brcmf_dbg(SDIO, "data:0x%08x\n", data);
@@ -443,7 +443,7 @@ void brcmf_sdiod_regwb(struct brcmf_sdio_dev *sdiodev, u32 addr,
int retval;
brcmf_dbg(SDIO, "addr:0x%08x, data:0x%02x\n", addr, data);
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, sizeof(data), &data,
+ retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 1, &data,
true);
if (ret)
*ret = retval;
@@ -455,10 +455,10 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 addr,
int retval;
brcmf_dbg(SDIO, "addr:0x%08x, data:0x%08x\n", addr, data);
- retval = brcmf_sdiod_addrprep(sdiodev, sizeof(data), &addr);
+ retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
if (retval)
goto done;
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, sizeof(data), &data,
+ retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 4, &data,
true);
done:
@@ -876,7 +876,7 @@ int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, uint fn)
/* issue abort cmd52 command through F0 */
brcmf_sdiod_request_data(sdiodev, SDIO_FUNC_0, SDIO_CCCR_ABORT,
- sizeof(t_func), &t_func, true);
+ 1, &t_func, true);
brcmf_dbg(SDIO, "Exit\n");
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 09/10] brcmfmac: Remove noisy debugging.
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
If you need debugging this low level, you're doing something wrong.
Remove these noisy debug statements so the code is more readable.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index e89e242..9a3f903 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -371,9 +371,7 @@ u8 brcmf_sdiod_regrb(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
u8 data;
int retval;
- brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
retval = brcmf_sdiod_reg_read(sdiodev, addr, 1, &data);
- brcmf_dbg(SDIO, "data:0x%02x\n", data);
if (ret)
*ret = retval;
@@ -386,9 +384,7 @@ u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
u32 data;
int retval;
- brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
retval = brcmf_sdiod_reg_read(sdiodev, addr, 4, &data);
- brcmf_dbg(SDIO, "data:0x%08x\n", data);
if (ret)
*ret = retval;
@@ -401,7 +397,6 @@ void brcmf_sdiod_regwb(struct brcmf_sdio_dev *sdiodev, u32 addr,
{
int retval;
- brcmf_dbg(SDIO, "addr:0x%08x, data:0x%02x\n", addr, data);
retval = brcmf_sdiod_reg_write(sdiodev, addr, 1, &data);
if (ret)
@@ -413,7 +408,6 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 addr,
{
int retval;
- brcmf_dbg(SDIO, "addr:0x%08x, data:0x%08x\n", addr, data);
retval = brcmf_sdiod_reg_write(sdiodev, addr, 4, &data);
if (ret)
--
1.9.1
^ permalink raw reply related
* [PATCH 10/10] brcmfmac: Rename bcmerror to err
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
Trivial cleanup of nasty variable name
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 9a3f903..30ab0aa 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -746,7 +746,7 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
brcmf_sdiod_ramrw(struct brcmf_sdio_dev *sdiodev, bool write, u32 address,
u8 *data, uint size)
{
- int bcmerror = 0;
+ int err = 0;
struct sk_buff *pkt;
u32 sdaddr;
uint dsize;
@@ -771,8 +771,8 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
/* Do the transfer(s) */
while (size) {
/* Set the backplane window to include the start address */
- bcmerror = brcmf_sdiod_set_sbaddr_window(sdiodev, address);
- if (bcmerror)
+ err = brcmf_sdiod_set_sbaddr_window(sdiodev, address);
+ if (err)
break;
brcmf_dbg(SDIO, "%s %d bytes at offset 0x%08x in window 0x%08x\n",
@@ -785,9 +785,9 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
skb_put(pkt, dsize);
if (write)
memcpy(pkt->data, data, dsize);
- bcmerror = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_1, write,
- sdaddr, pkt);
- if (bcmerror) {
+ err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_1, write, sdaddr,
+ pkt);
+ if (err) {
brcmf_err("membytes transfer failed\n");
break;
}
@@ -814,7 +814,7 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
sdio_release_host(sdiodev->func[1]);
- return bcmerror;
+ return err;
}
int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, u8 fn)
--
1.9.1
^ permalink raw reply related
* [PATCH 04/10] brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
This function sets the address of the IO window used for
SDIO accesses onto the backplane of the chip.
It currently uses 3 separate masks despite the full mask being
defined in the code already. Remove the separate masks and clean up.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 17 +++++------------
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 3 ---
2 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 3acc0ff..1ea42c3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -410,23 +410,16 @@ static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev, u32 address)
{
int err = 0, i;
- u8 addr[3];
+ u32 addr;
if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
return -ENOMEDIUM;
- addr[0] = (address >> 8) & SBSDIO_SBADDRLOW_MASK;
- addr[1] = (address >> 16) & SBSDIO_SBADDRMID_MASK;
- addr[2] = (address >> 24) & SBSDIO_SBADDRHIGH_MASK;
+ addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
- for (i = 0; i < 3; i++) {
- brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, addr[i],
- &err);
- if (err) {
- brcmf_err("failed at addr: 0x%0x\n",
- SBSDIO_FUNC1_SBADDRLOW + i);
- }
- }
+ for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
+ brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
+ addr & 0xff, &err);
return err;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index f3da32f..e3b78db 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -133,9 +133,6 @@
/* valid bits in SBSDIO_FUNC1_SBADDRxxx regs */
-#define SBSDIO_SBADDRLOW_MASK 0x80 /* Valid bits in SBADDRLOW */
-#define SBSDIO_SBADDRMID_MASK 0xff /* Valid bits in SBADDRMID */
-#define SBSDIO_SBADDRHIGH_MASK 0xffU /* Valid bits in SBADDRHIGH */
/* Address bits from SBADDR regs */
#define SBSDIO_SBWINDOW_MASK 0xffff8000
--
1.9.1
^ permalink raw reply related
* [PATCH 07/10] brcmfmac: Remove brcmf_sdiod_request_data()
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
This function is obfuscating how IO works on this chip. Remove it
and push its logic into brcmf_sdiod_reg_{read,write}().
Handling of -ENOMEDIUM is altered, but as that's pretty much broken anyway
we can ignore that.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 237 ++++++++-------------
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 2 +-
2 files changed, 87 insertions(+), 152 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 355aebd..bb2ebe6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -230,6 +230,43 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev,
sdiodev->state = state;
}
+static int brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev,
+ u32 address)
+{
+ int err = 0, i;
+ u32 addr;
+
+ if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
+ return -ENOMEDIUM;
+
+ addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
+
+ for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
+ brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
+ addr & 0xff, &err);
+
+ return err;
+}
+
+static int brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr)
+{
+ uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK;
+ int err = 0;
+
+ if (bar0 != sdiodev->sbwad) {
+ err = brcmf_sdiod_set_sbaddr_window(sdiodev, bar0);
+ if (err)
+ return err;
+
+ sdiodev->sbwad = bar0;
+ }
+
+ *addr &= SBSDIO_SB_OFT_ADDR_MASK;
+ *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
+
+ return 0;
+}
+
static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte,
uint regaddr)
{
@@ -249,173 +286,84 @@ static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte,
return err_ret;
}
-static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
- u32 addr, u8 regsz, void *data, bool write)
-{
- struct sdio_func *func;
- int ret = -EINVAL;
-
- brcmf_dbg(SDIO, "rw=%d, func=%d, addr=0x%05x, nbytes=%d\n",
- write, fn, addr, regsz);
-
- /* only allow byte access on F0 */
- if (WARN_ON(regsz > 1 && !fn))
- return -EINVAL;
- func = sdiodev->func[fn];
-
- switch (regsz) {
- case 1:
- if (write) {
- if (fn)
- sdio_writeb(func, *(u8 *)data, addr, &ret);
- else
- ret = brcmf_sdiod_f0_writeb(func, *(u8 *)data,
- addr);
- } else {
- if (fn)
- *(u8 *)data = sdio_readb(func, addr, &ret);
- else
- *(u8 *)data = sdio_f0_readb(func, addr, &ret);
- }
- break;
- case 2:
- if (write)
- sdio_writew(func, *(u16 *)data, addr, &ret);
- else
- *(u16 *)data = sdio_readw(func, addr, &ret);
- break;
- case 4:
- if (write)
- sdio_writel(func, *(u32 *)data, addr, &ret);
- else
- *(u32 *)data = sdio_readl(func, addr, &ret);
- break;
- default:
- brcmf_err("invalid size: %d\n", regsz);
- break;
- }
-
- if (ret)
- brcmf_dbg(SDIO, "failed to %s data F%d@0x%05x, err: %d\n",
- write ? "write" : "read", fn, addr, ret);
-
- return ret;
-}
-
static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
u8 regsz, void *data)
{
- u8 func;
- s32 retry = 0;
int ret;
- if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
- return -ENOMEDIUM;
-
/*
* figure out how to read the register based on address range
* 0x00 ~ 0x7FF: function 0 CCCR and FBR
* 0x10000 ~ 0x1FFFF: function 1 miscellaneous registers
* The rest: function 1 silicon backplane core registers
+ * f0 writes must be bytewise
*/
- if ((addr & ~REG_F0_REG_MASK) == 0)
- func = SDIO_FUNC_0;
- else
- func = SDIO_FUNC_1;
- do {
- /* for retry wait for 1 ms till bus get settled down */
- if (retry)
- usleep_range(1000, 2000);
-
- ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
- data, true);
-
- } while (ret != 0 && ret != -ENOMEDIUM &&
- retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
+ if ((addr & ~REG_F0_REG_MASK) == 0) {
+ if (WARN_ON(regsz > 1))
+ return -EINVAL;
+ ret = brcmf_sdiod_f0_writeb(sdiodev->func[0],
+ *(u8 *)data, addr);
+ } else {
+ switch (regsz) {
+ case 1:
+ sdio_writeb(sdiodev->func[1], *(u8 *)data, addr, &ret);
+ break;
+ case 4:
+ ret = brcmf_sdiod_addrprep(sdiodev, &addr);
+ if (ret)
+ goto done;
- if (ret == -ENOMEDIUM)
- brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
+ sdio_writel(sdiodev->func[1], *(u32 *)data, addr, &ret);
+ break;
+ default:
+ WARN(1, "Invalid reg size\n");
+ ret = -EINVAL;
+ break;
+ }
+ }
+done:
return ret;
}
static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
u8 regsz, void *data)
{
- u8 func;
- s32 retry = 0;
int ret;
- if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
- return -ENOMEDIUM;
-
/*
* figure out how to read the register based on address range
* 0x00 ~ 0x7FF: function 0 CCCR and FBR
* 0x10000 ~ 0x1FFFF: function 1 miscellaneous registers
* The rest: function 1 silicon backplane core registers
+ * f0 reads must be bytewise
*/
- if ((addr & ~REG_F0_REG_MASK) == 0)
- func = SDIO_FUNC_0;
- else
- func = SDIO_FUNC_1;
-
- do {
- memset(data, 0, regsz);
-
- /* for retry wait for 1 ms till bus get settled down */
- if (retry)
- usleep_range(1000, 2000);
-
- ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
- data, false);
-
- } while (ret != 0 && ret != -ENOMEDIUM &&
- retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
-
- if (ret == -ENOMEDIUM)
- brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
-
- return ret;
-}
-
-static int
-brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev, u32 address)
-{
- int err = 0, i;
- u32 addr;
-
- if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
- return -ENOMEDIUM;
-
- addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
-
- for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
- brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
- addr & 0xff, &err);
-
- return err;
-}
-
-static int
-brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr)
-{
- uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK;
- int err = 0;
-
- if (bar0 != sdiodev->sbwad) {
- err = brcmf_sdiod_set_sbaddr_window(sdiodev, bar0);
- if (err)
- return err;
+ if ((addr & ~REG_F0_REG_MASK) == 0) {
+ if (WARN_ON(regsz > 1))
+ return -EINVAL;
+ *(u8 *)data = sdio_f0_readb(sdiodev->func[0], addr, &ret);
+ } else {
+ switch (regsz) {
+ case 1:
+ *(u8 *)data = sdio_readb(sdiodev->func[1], addr, &ret);
+ break;
+ case 4:
+ ret = brcmf_sdiod_addrprep(sdiodev, &addr);
+ if (ret)
+ goto done;
- sdiodev->sbwad = bar0;
+ *(u32 *)data = sdio_readl(sdiodev->func[1], addr, &ret);
+ break;
+ default:
+ WARN(1, "Invalid reg size\n");
+ ret = -EINVAL;
+ break;
+ }
}
- *addr &= SBSDIO_SB_OFT_ADDR_MASK;
- *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
-
- return 0;
+done:
+ return ret;
}
u8 brcmf_sdiod_regrb(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
@@ -439,15 +387,9 @@ u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
- retval = brcmf_sdiod_addrprep(sdiodev, &addr);
- if (retval)
- goto done;
-
retval = brcmf_sdiod_reg_read(sdiodev, addr, 4, &data);
-
brcmf_dbg(SDIO, "data:0x%08x\n", data);
-done:
if (ret)
*ret = retval;
@@ -472,13 +414,8 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 addr,
int retval;
brcmf_dbg(SDIO, "addr:0x%08x, data:0x%08x\n", addr, data);
- retval = brcmf_sdiod_addrprep(sdiodev, &addr);
- if (retval)
- goto done;
-
retval = brcmf_sdiod_reg_write(sdiodev, addr, 4, &data);
-done:
if (ret)
*ret = retval;
}
@@ -886,14 +823,12 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
return bcmerror;
}
-int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, uint fn)
+int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, u8 fn)
{
- char t_func = (char)fn;
brcmf_dbg(SDIO, "Enter\n");
/* issue abort cmd52 command through F0 */
- brcmf_sdiod_request_data(sdiodev, SDIO_FUNC_0, SDIO_CCCR_ABORT,
- 1, &t_func, true);
+ brcmf_sdiod_reg_write(sdiodev, SDIO_CCCR_ABORT, 1, &fn);
brcmf_dbg(SDIO, "Exit\n");
return 0;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index e3b78db..1e4b476 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -339,7 +339,7 @@ int brcmf_sdiod_ramrw(struct brcmf_sdio_dev *sdiodev, bool write, u32 address,
u8 *data, uint size);
/* Issue an abort to the specified function */
-int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, uint fn);
+int brcmf_sdiod_abort(struct brcmf_sdio_dev *sdiodev, u8 fn);
void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev);
void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev,
enum brcmf_sdiod_state state);
--
1.9.1
^ permalink raw reply related
* [PATCH 05/10] brcmfmac: Remove dead IO code
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
The value passed to brcmf_sdiod_addrprep() is *always* 4
remove this parameter and the unused code to handle it.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 1ea42c3..ad81ea4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -425,7 +425,7 @@ static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
}
static int
-brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, uint width, u32 *addr)
+brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr)
{
uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK;
int err = 0;
@@ -439,9 +439,7 @@ static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
}
*addr &= SBSDIO_SB_OFT_ADDR_MASK;
-
- if (width == 4)
- *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
+ *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;
return 0;
}
@@ -467,7 +465,7 @@ u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
- retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ retval = brcmf_sdiod_addrprep(sdiodev, &addr);
if (retval)
goto done;
@@ -500,7 +498,7 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 addr,
int retval;
brcmf_dbg(SDIO, "addr:0x%08x, data:0x%08x\n", addr, data);
- retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ retval = brcmf_sdiod_addrprep(sdiodev, &addr);
if (retval)
goto done;
@@ -736,7 +734,7 @@ int brcmf_sdiod_recv_pkt(struct brcmf_sdio_dev *sdiodev, struct sk_buff *pkt)
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n", addr, pkt->len);
- err = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ err = brcmf_sdiod_addrprep(sdiodev, &addr);
if (err)
goto done;
@@ -757,7 +755,7 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n",
addr, pktq->qlen);
- err = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ err = brcmf_sdiod_addrprep(sdiodev, &addr);
if (err)
goto done;
@@ -801,7 +799,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
memcpy(mypkt->data, buf, nbytes);
- err = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ err = brcmf_sdiod_addrprep(sdiodev, &addr);
if (!err)
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, true, addr,
@@ -821,7 +819,7 @@ int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
brcmf_dbg(SDIO, "addr = 0x%x, size = %d\n", addr, pktq->qlen);
- err = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
+ err = brcmf_sdiod_addrprep(sdiodev, &addr);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH 00/10] brcmfmac: restructuring sdio access functions
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
These patches were originally submitted by Ian Molton a while ago so decided
to resubmit them. This is a first series of 10 patches. Tested using BCM4354
device which showed no regression.
It is intended for 4.16 (no rush ;-) ) and applies to the master branch of
the wireless-drivers-next repository.
Ian Molton (10):
brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
brcmfmac: Register sizes on hardware are not dependent on compiler
types
brcmfmac: Split brcmf_sdiod_regrw_helper() up.
brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
brcmfmac: Remove dead IO code
brcmfmac: Remove bandaid for SleepCSR
brcmfmac: Remove brcmf_sdiod_request_data()
brcmfmac: Fix asymmetric IO functions.
brcmfmac: Remove noisy debugging.
brcmfmac: Rename bcmerror to err
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 280 +++++++++------------
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 5 +-
2 files changed, 114 insertions(+), 171 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 03/10] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
From: Arend van Spriel @ 2017-11-13 20:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ian Molton, Arend van Spriel
In-Reply-To: <1510605347-7629-1-git-send-email-arend.vanspriel@broadcom.com>
From: Ian Molton <ian@mnementh.co.uk>
This large function is concealing a LOT of obscure logic about
how the hardware functions. Time to split it up.
This first patch splits the function into two pieces - read and write,
doing away with the rw flag in the process.
Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 94 +++++++++++++++++-----
1 file changed, 73 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 25b5e9b..3acc0ff 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -302,8 +302,8 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
return ret;
}
-static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
- u8 regsz, void *data, bool write)
+static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
+ u8 regsz, void *data)
{
u8 func;
s32 retry = 0;
@@ -324,13 +324,66 @@ static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
func = SDIO_FUNC_1;
do {
- if (!write)
- memset(data, 0, regsz);
/* for retry wait for 1 ms till bus get settled down */
if (retry)
usleep_range(1000, 2000);
+
+ ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
+ data, true);
+
+ } while (ret != 0 && ret != -ENOMEDIUM &&
+ retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
+
+ if (ret == -ENOMEDIUM) {
+ brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
+ } else if (ret != 0) {
+ /*
+ * SleepCSR register access can fail when
+ * waking up the device so reduce this noise
+ * in the logs.
+ */
+ if (addr != SBSDIO_FUNC1_SLEEPCSR)
+ brcmf_err("failed to write data F%d@0x%05x, err: %d\n",
+ func, addr, ret);
+ else
+ brcmf_dbg(SDIO, "failed to write data F%d@0x%05x, err: %d\n",
+ func, addr, ret);
+ }
+
+ return ret;
+}
+
+static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
+ u8 regsz, void *data)
+{
+ u8 func;
+ s32 retry = 0;
+ int ret;
+
+ if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
+ return -ENOMEDIUM;
+
+ /*
+ * figure out how to read the register based on address range
+ * 0x00 ~ 0x7FF: function 0 CCCR and FBR
+ * 0x10000 ~ 0x1FFFF: function 1 miscellaneous registers
+ * The rest: function 1 silicon backplane core registers
+ */
+ if ((addr & ~REG_F0_REG_MASK) == 0)
+ func = SDIO_FUNC_0;
+ else
+ func = SDIO_FUNC_1;
+
+ do {
+ memset(data, 0, regsz);
+
+ /* for retry wait for 1 ms till bus get settled down */
+ if (retry)
+ usleep_range(1000, 2000);
+
ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
- data, write);
+ data, false);
+
} while (ret != 0 && ret != -ENOMEDIUM &&
retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
@@ -343,12 +396,13 @@ static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
* in the logs.
*/
if (addr != SBSDIO_FUNC1_SLEEPCSR)
- brcmf_err("failed to %s data F%d@0x%05x, err: %d\n",
- write ? "write" : "read", func, addr, ret);
+ brcmf_err("failed to read data F%d@0x%05x, err: %d\n",
+ func, addr, ret);
else
- brcmf_dbg(SDIO, "failed to %s data F%d@0x%05x, err: %d\n",
- write ? "write" : "read", func, addr, ret);
+ brcmf_dbg(SDIO, "failed to read data F%d@0x%05x, err: %d\n",
+ func, addr, ret);
}
+
return ret;
}
@@ -366,13 +420,11 @@ static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
addr[2] = (address >> 24) & SBSDIO_SBADDRHIGH_MASK;
for (i = 0; i < 3; i++) {
- err = brcmf_sdiod_regrw_helper(sdiodev,
- SBSDIO_FUNC1_SBADDRLOW + i,
- 1, &addr[i], true);
+ brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, addr[i],
+ &err);
if (err) {
brcmf_err("failed at addr: 0x%0x\n",
SBSDIO_FUNC1_SBADDRLOW + i);
- break;
}
}
@@ -407,8 +459,7 @@ u8 brcmf_sdiod_regrb(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
int retval;
brcmf_dbg(SDIO, "addr:0x%08x\n", addr);
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 1, &data,
- false);
+ retval = brcmf_sdiod_reg_read(sdiodev, addr, 1, &data);
brcmf_dbg(SDIO, "data:0x%02x\n", data);
if (ret)
@@ -426,8 +477,9 @@ u32 brcmf_sdiod_regrl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
if (retval)
goto done;
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 4, &data,
- false);
+
+ retval = brcmf_sdiod_reg_read(sdiodev, addr, 4, &data);
+
brcmf_dbg(SDIO, "data:0x%08x\n", data);
done:
@@ -443,8 +495,8 @@ void brcmf_sdiod_regwb(struct brcmf_sdio_dev *sdiodev, u32 addr,
int retval;
brcmf_dbg(SDIO, "addr:0x%08x, data:0x%02x\n", addr, data);
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 1, &data,
- true);
+ retval = brcmf_sdiod_reg_write(sdiodev, addr, 1, &data);
+
if (ret)
*ret = retval;
}
@@ -458,8 +510,8 @@ void brcmf_sdiod_regwl(struct brcmf_sdio_dev *sdiodev, u32 addr,
retval = brcmf_sdiod_addrprep(sdiodev, 4, &addr);
if (retval)
goto done;
- retval = brcmf_sdiod_regrw_helper(sdiodev, addr, 4, &data,
- true);
+
+ retval = brcmf_sdiod_reg_write(sdiodev, addr, 4, &data);
done:
if (ret)
--
1.9.1
^ permalink raw reply related
* Fwd: linux v4.14 causes firmware iwlwifi errors on Lenovo Thinkpad T440s
From: Bartosz Golaszewski @ 2017-11-13 20:22 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAMRc=Mf92X2t8wjmE+xkXrA0QKY06uFeXhMY-97Ka=_UxuQbjw@mail.gmail.com>
Forwarding here too as I messed up the address the last time.
--
Hi,
I noticed my wireless interface can't get up with linux v4.14 and the
kernel log is flooded with firmware errors:
iwlwifi 0000:03:00.0: Firmware error during reconfiguration - reprobe!
iwlwifi 0000:03:00.0: FW error in SYNC CMD DQA_ENABLE_CMD
and
ieee80211 phy63: Hardware restart was requested.
The wireless controller is: Intel Corporation Wireless 7260 (rev 83)
Firmware used is: iwlwifi-7260-17
Everything works fine with v4.13.12.
I didn't have time today to bisect for the offending commit. Full log
uploaded[1].
Best regards,
Bartosz Golaszewski
[1] https://pastebin.com/jksqxvS6
^ permalink raw reply
* Re: [PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults
From: Bjorn Andersson @ 2017-11-13 18:16 UTC (permalink / raw)
To: Ramon Fried
Cc: kvalo, k.eugene.e, wcn36xx, linux-wireless, netdev, linux-kernel,
nicolas.dechesne, Eyal Ilsar
In-Reply-To: <1510496506-4428-1-git-send-email-rfried@codeaurora.org>
On Sun 12 Nov 06:21 PST 2017, Ramon Fried wrote:
> From: Eyal Ilsar <eilsar@codeaurora.org>
>
> If the value for the firmware configuration parameters BTC_STATIC_LEN_LE_BT
> and BTC_STATIC_LEN_LE_WLAN are not set the duty cycle between BT and WLAN
> is such that if BT (including BLE) is active WLAN gets 0 bandwidth.
> When tuning these parameters having a too high value for WLAN means that BLE performance degrades.
> The "sweet" point of roughly half of the maximal values was empirically found to achieve
> a balance between BLE and Wi-Fi coexistence performance.
>
Thanks for the patch! Just some minor comments.
Please limit subject to 50 chars and wrap body at 72 chars.
> Signed-off-by: Eyal Ilsar <eilsar@codeaurora.org>
> Signed-off-by: Ramon Fried <rfried@codeaurora.org>
> ---
> drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 9c6590d..1c75987 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -72,8 +72,10 @@ struct wcn36xx_cfg_val {
> WCN36XX_CFG_VAL(DYNAMIC_PS_POLL_VALUE, 0),
> WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
> WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
> - WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
I don't see a need for moving this line.
> + WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 120000),
> + WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 30000),
These looks reasonable, are we okay leaving the other coexistence
properties at their preconfigured values?
> WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
> + WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
> WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
Regards,
Bjorn
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Ben Greear @ 2017-11-13 17:05 UTC (permalink / raw)
To: Johannes Berg, Oleksij Rempel, linux-wireless@vger.kernel.org,
ath10k, kirtika
In-Reply-To: <1510567783.30497.33.camel@sipsolutions.net>
On 11/13/2017 02:09 AM, Johannes Berg wrote:
> On Fri, 2017-10-27 at 13:41 -0700, Ben Greear wrote:
>
>> ath10k ignores the tx rateset pretty much entirely when sending management
>> frames, so even if you set the tx rateset to have only VHT MCS 8,
>> management frames are still sent with legacy ratesets.
>
> So that's a driver bug.
The firmware gives the ability to set a single fixed rate for
multicast, and another for management frames. It is possibly to
set the tx-data frame rate to another fixed rate, or to a more
normal rateset. But, you do not have full control over setting
tx-data rates (no way to tell stock firmware to use 6Mbps /g rate and
mcs 8 (only), for instance). The multicast and mgt frame API is not hooked up in the
stock driver as far as I know.
But even if they were, I don't see a good way to make this fit
with the mac80211 txrate setting framework.
What is the suggested approach to propagate a rateset set with
'iw' to a firmware with these limitations?
For the Intel firmware NICs, how do they set management and bcast
tx rates?
>> My end goal about this part is to be able to configure a single tx rate
>> and have that be allowed again, at least with ath10k.
>>
>> Maybe a new flag for drivers like ath10k that at least somewhat ignore
>> the tx-rateset for management frames, and this flag would allow us to
>> bypass the cannot-set-single-rate check?
>
> What? No, I'm not going to put a driver bug into the API like that!
Thanks for the constructive feedback.
--Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 3/4] cfg80211: reg: remove support for built-in regdb
From: Johannes Berg @ 2017-11-13 14:53 UTC (permalink / raw)
To: Benjamin Beichler, linux-wireless
In-Reply-To: <40a4b97b-7711-43d1-b0fb-3cfb7b8bca88@uni-rostock.de>
On Mon, 2017-11-13 at 15:48 +0100, Benjamin Beichler wrote:
>
> Then this may be a bug, since the loading the regulatory.db fails
> (platform regulatory.0: Direct firmware load for regulatory.db failed
> with error -2) also, when CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not
> set (and of course CONFIG_CFG80211_CERTIFICATION_ONUS is set)
Well that just means you don't have the file (in the right place)
johannes
^ permalink raw reply
* Re: [PATCH v2 3/4] cfg80211: reg: remove support for built-in regdb
From: Benjamin Beichler @ 2017-11-13 14:48 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1510584253.30497.45.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
Am 13.11.2017 um 15:44 schrieb Johannes Berg:
> On Mon, 2017-11-13 at 15:41 +0100, Benjamin Beichler wrote:
>> I use an Alpine Userspace with no proper CRDA
> Ok.
>
>> and I'm not able to
>> disable signature checking. I deactivated
>> CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, but the load of regulatory.db
>> fails. I thought this is intentionally, or do I need any other Configs ?
> This should work, as long as you can actually properly
> unset CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, which requires that you set
> CONFIG_CFG80211_CERTIFICATION_ONUS.
>
> johannes
Then this may be a bug, since the loading the regulatory.db fails
(platform regulatory.0: Direct firmware load for regulatory.db failed
with error -2) also, when CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not
set (and of course CONFIG_CFG80211_CERTIFICATION_ONUS is set)
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5151 bytes --]
^ 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