* [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Rafał Miłecki @ 2017-02-24 13:10 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
It avoids some unnecessary work. Most likely there wasn't much sense in
doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (only bus implementing reset) we e.g.
use watchdog to perform a chip "reboot".
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 05f22ff81d60..670f2f50f9e5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -967,16 +967,14 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
if (ret)
return ret;
- /* assure chip is passive for core access */
- brcmf_chip_set_passive(&ci->pub);
-
/* Call bus specific reset function now. Cores have been determined
* but further access may require a chip specific reset at this point.
*/
- if (ci->ops->reset) {
+ if (ci->ops->reset)
ci->ops->reset(ci->ctx, &ci->pub);
- brcmf_chip_set_passive(&ci->pub);
- }
+
+ /* assure chip is passive for core access */
+ brcmf_chip_set_passive(&ci->pub);
return brcmf_chip_get_raminfo(ci);
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Arend Van Spriel @ 2017-02-24 13:21 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224122739.1778-1-zajec5@gmail.com>
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
> brcmfmac there is support for 43602a1 and from what I know supporting
> 43602a0 would require loading a different firmware.
This is not necessarily true. It depends on whether the rom image is
different or not and there is no way to tell up front. So if a0 has same
rom image as a1 the firmware is compatible and no distinction is needed.
This tends to be the case for chips that only change the digit and not
the letter in the chip revision. Anyway, I do not know if a0 has
different rom image, but the a0 was never sold so there is no harm in
keeping it as is.
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 6fae4cf3f6ab..2a171479b42b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>
> static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
>
^ permalink raw reply
* Re: [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table
From: Arend Van Spriel @ 2017-02-24 13:28 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224122739.1778-2-zajec5@gmail.com>
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
> 4366c0. Cutting name at the letter isn't a good idea as sometimes we may
> have e.g. a0 and a1.
As explained in 1/2, the revision may change but if rom image is
unchanged the firmware stays compatible. As predicting chip development
is impossible initially we choose a common name as entry ID. So if there
would come a 4366c1 with incompatible rom image it would be time to
change the entry ID.
Regards,
Arend
> This is just a cosmetic change, a trivial cleanup. It obviously doesn't
> change fw filenames as we don't want to break user space.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 2a171479b42b..7039f7f09653 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -46,7 +46,7 @@ enum brcmf_pcie_state {
> BRCMFMAC_PCIE_STATE_UP
> };
>
> -BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", "brcmfmac4350c2-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt");
> @@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", "brcmfmac4358-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366c0, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>
> static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602a1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366c0),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C),
> @@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366b1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366c0),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
> };
>
>
^ permalink raw reply
* [PATCH] mwifiex: fix kernel crash after shutdown command timeout
From: Amitkumar Karwar @ 2017-02-24 13:29 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
We observed a SHUTDOWN command timeout during reboot stress test due
to a corner case firmware bug. It leads to use-after-free on adapter
structure pointer and crash.
We already have a cancel_work_sync() call in teardown thread. This
issue is fixed by having this call just before mwifiex_remove_card().
At this point no further work will be scheduled.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 3 +--
drivers/net/wireless/marvell/mwifiex/sdio.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a0d9180..f31c5ea 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -294,8 +294,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&card->work);
-
reg = card->pcie.reg;
if (reg)
ret = mwifiex_read_reg(adapter, reg->fw_status, &fw_status);
@@ -312,6 +310,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ cancel_work_sync(&card->work);
mwifiex_remove_card(adapter);
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index a4b356d..9534b47 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -387,8 +387,6 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&card->work);
-
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
ret = mwifiex_sdio_read_fw_status(adapter, &firmware_stat);
@@ -400,6 +398,7 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ cancel_work_sync(&card->work);
mwifiex_remove_card(adapter);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Arend Van Spriel @ 2017-02-24 13:31 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224131027.29880-1-zajec5@gmail.com>
On 24-2-2017 14:10, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It avoids some unnecessary work. Most likely there wasn't much sense in
> doing this before bus reset anyway, as reset is supposed to put chip
> into default state. In PCIe code (only bus implementing reset) we e.g.
> use watchdog to perform a chip "reboot".
Sorry, but removing the fisrt passive call will cause chip lockups for
sure on certain systems. We learned the hard way :-p
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> index 05f22ff81d60..670f2f50f9e5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> @@ -967,16 +967,14 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
> if (ret)
> return ret;
>
> - /* assure chip is passive for core access */
> - brcmf_chip_set_passive(&ci->pub);
> -
> /* Call bus specific reset function now. Cores have been determined
> * but further access may require a chip specific reset at this point.
> */
> - if (ci->ops->reset) {
> + if (ci->ops->reset)
> ci->ops->reset(ci->ctx, &ci->pub);
> - brcmf_chip_set_passive(&ci->pub);
> - }
> +
> + /* assure chip is passive for core access */
> + brcmf_chip_set_passive(&ci->pub);
>
> return brcmf_chip_get_raminfo(ci);
> }
>
^ permalink raw reply
* Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Rafał Miłecki @ 2017-02-24 13:47 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <cbcb8722-15bb-bf6e-f329-972797b02028@broadcom.com>
On 2017-02-24 14:31, Arend Van Spriel wrote:
> On 24-2-2017 14:10, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> It avoids some unnecessary work. Most likely there wasn't much sense
>> in
>> doing this before bus reset anyway, as reset is supposed to put chip
>> into default state. In PCIe code (only bus implementing reset) we e.g.
>> use watchdog to perform a chip "reboot".
>
> Sorry, but removing the fisrt passive call will cause chip lockups for
> sure on certain systems. We learned the hard way :-p
OK, acknowledged! ;) I just tested it on my BCM43602 doing warm reboots
(they
were causing problems earlier) and it worked fine.
It also seems I don't use SDK recent enough as my reference :)
Kalle please drop this patch.
^ permalink raw reply
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Rafał Miłecki @ 2017-02-24 13:43 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <c7c82c1f-df42-c4a2-4f1f-1ff4928590d1@broadcom.com>
On 2017-02-24 14:21, Arend Van Spriel wrote:
> On 24-2-2017 13:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
>> brcmfmac there is support for 43602a1 and from what I know supporting
>> 43602a0 would require loading a different firmware.
>
> This is not necessarily true. It depends on whether the rom image is
> different or not and there is no way to tell up front. So if a0 has
> same
> rom image as a1 the firmware is compatible and no distinction is
> needed.
> This tends to be the case for chips that only change the digit and not
> the letter in the chip revision. Anyway, I do not know if a0 has
> different rom image, but the a0 was never sold so there is no harm in
> keeping it as is.
Just to be sure (I don't have such a good hardware knowledge):
1) Does ROM image mean some code that is permanently on the device?
2) Does firmware mean code we upload from the host driver?
I'm not sure if I understand the rest of your description.
AFAIU first you said ROM image tends to be the same on chipset
variations using
the same letter. If this is so, why we need different firmware for
43602a0 and
43602a1? Or different firmware for 43570a0 and 43570a2?
Also if what you said about sharing one ROM image between chip
variations using
the same letter was correct, shouldn't you expect the same ROM image on
43602a0
and 43602a1?
Forgive me if something of this is obvious for you, I just don't have
access to
any Broadcom internal documentation :)
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Ben Greear @ 2017-02-24 15:19 UTC (permalink / raw)
To: Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <CAOq732+L3KDLP-5E4XnKE0-+TKV6KG_V5AVqeBjQRdyQ5Nr74g@mail.gmail.com>
On 02/24/2017 12:45 AM, Andrew Zaborowski wrote:
> On 24 February 2017 at 01:28, <greearb@candelatech.com> wrote:
>> Modify the receive-from-user-space logic to do length
>> and 'is-down' checks before trying to allocate an skb.
>>
>> And, if we are going to ignore the pkt due to radio idle,
>> then do not return an error code to user-space. User-space
>> cannot reliably know exactly when a radio is idle or not.
>
> You probably want to return some error code anyway because 0, if you
> compare to the kernel medium, currently maps to the ack returned bit
> and is possibly the only way for userspace to set the
> HWSIM_TX_STAT_ACK flag in a meaningful way.
Maybe there is a way to return a specific error code so that
the user-space doesn't get concerned when radio is idle. I
didn't want to spam logs in user-space app...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Seth Forshee @ 2017-02-24 14:55 UTC (permalink / raw)
To: Ryan Mounce; +Cc: wireless-regdb, linux-wireless, Johannes Berg
In-Reply-To: <CAN+fvRYhW4hhHfyzvE8uJZ+qu8hneUni_je=3kdNe+bPa+WQxA@mail.gmail.com>
On Fri, Feb 24, 2017 at 01:20:24PM +1030, Ryan Mounce wrote:
> On 24 February 2017 at 02:05, Seth Forshee <seth.forshee@canonical.com> wrote:
> > On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
> >> Sourced from the current legislation at
> >> https://www.legislation.gov.au/Details/F2016C00432
> >>
> >> The current rules exceed legal limits between 5250-5330MHz, and permit
> >> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> >>
> >> Frequency ranges and EIRP limits for all ranges have been updated to
> >> match items 59-63, 65 in the linked document. As the rules for AU have
> >> never previously mirrored local regulations, changes include a
> >> significant increase in the allowable 2.4GHz EIRP and smaller increases
> >> in most other bands.
> >>
> >> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> >> bands) the lower, more restrictive band has been rounded up by 5MHz.
> >>
> >> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
> >> ---
> >> db.txt | 15 ++++++++++-----
> >> 1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index 05108e0..00e81b6 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
> >> # 60 GHz band channels 1-4, ref: Etsi En 302 567
> >> (57000 - 66000 @ 2160), (40)
> >>
> >> +# Source:
> >> +# https://www.legislation.gov.au/Details/F2016C00432
> >> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
> >> country AU: DFS-ETSI
> >> - (2402 - 2482 @ 40), (20)
> >> - (5170 - 5250 @ 80), (17), AUTO-BW
> >> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> >> - (5490 - 5710 @ 160), (24), DFS
> >> - (5735 - 5835 @ 80), (30)
> >> + (2400 - 2483.5 @ 40), (36)
> >
> > The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
> > this is the limit we should be using, i.e. 500 mW. It is a bit confusing
> > though since it seems like such devices would also fall under "digital
> > modulation transmitters."
>
> Item 55 applies only to frequency hopping transmitters e.g. Bluetooth.
> As a local, I can say with some degree of certainty that 4W/36dBm is
> the correct 2.4GHz ISM EIRP for Australia. It is advertised as the
> EIRP in the 802.11d IE of commercial devices e.g. Cisco Aironet APs
> and widely deployed ISP gateways in Australia, among other devices
> that have received relevant approvals.
Okay, looking at that section again that makes sense.
> >> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> >
> > This looks correct.
> >
> >> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> >
> > Since this range requires TPC we need to set the power limit at 100 mW.
> >
> >> + (5470 - 5600 @ 80), (30), DFS
> >> + (5650 - 5730 @ 80), (30), DFS
> >
> > These ranges also require TPC so we need to set the limit at 500 mW.
>
> I was unsure about this one. Setting this to 27dBm also affects the
> 802.11d country information IE, however when the DFS flag is set a 3dB
> 802.11h power constraint IE is also advertised so stations will limit
> themselves to (27-3)=24dBm/250mW.
>
> Given the choice between unnecessarily halving transmit power on
> stations and potentially transmitting at twice the permissible power
> on APs without TPC I agree that the conservative approach should be
> taken for now. Ideally I think that the actual EIRP limits should be
> in the regdb and a 3dB constraint should be applied automatically on
> APs that cannot support TPC when the DFS flag is set.
>
> >> + (5730 - 5850 @ 80), (36)
> >
> > In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
> > suspect that the existing rules fudge that to line up with the wifi
> > channels, which technically is okay because the rules in the former
> > range are more restrictive. I wonder if we shouldn't be recording them
> > here as per the document and adding AUTO-BW. Johannes, any thoughts?
>
> I've tested with AUTO-BW and it doesn't work in this case as channel
> 144 will be disabled if it doesn't exist entirely within one band.
> Fudging the more restrictive rules by a mere 5MHz to fit 802.11
> channels seems to be the status quo.
I wonder why AUTO-BW doesn't work. In that case it's certainly fine to
keep those ranges as they are.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH 161/306] mac80211-hwsim: Improve logging.
From: Ben Greear @ 2017-02-24 15:26 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918553.2540.9.camel@sipsolutions.net>
On 02/23/2017 10:42 PM, Johannes Berg wrote:
>
>> + static unsigned int cnt = 0;
>> + /* This is fairly common, and usually not a
>> bug. So, print errors
>> + rarely. */
>> + if (((cnt++ & 0x3FF) == 0x3FF) && net_ratelimit())
>> + printk(KERN_DEBUG " hwsim rx-nl: radio %pM
>> idle: %d or not started: %d cnt: %d\n",
>> + dst, data2->idle, !data2->started,
>> cnt);
>> goto out;
>> }
>
> You just added that in the previous patch...
>
> Please take a bit more care, or I'll eventually stop looking at your
> patches since things like that seem to happen over and over again. I
> don't get a feeling that you actually care about getting things
> upstream much anyway.
I wrote these patches over a long period of time. Some, like the binary
API things I already knew you did not want, but I posted them since
it seems several people are looking at this sort of thing and maybe
they will have a good idea how to add similar behaviour in an efficient
manner. I think your previous suggestion was that I should map each
flag in some translate code and/or bloat up netlink API, and neither
of those options seemed like an efficient use of CPU time.
I'll work to fix the cosmetic problems and squash these logging patches
and re-submit those.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink
From: Ben Greear @ 2017-02-24 15:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918388.2540.6.camel@sipsolutions.net>
On 02/23/2017 10:39 PM, Johannes Berg wrote:
>
>> + !info->attrs[HWSIM_ATTR_SIGNAL]) {
>> + if (net_ratelimit())
>> + printk(KERN_DEBUG " hwsim rx-nl: Missing
>> required attribute\n");
>
> I'm not convinced net_ratelimit() is a good idea, that's a global rate
> limiter.
Is there a better rate-limiter w/out hand-crafting something?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Ben Greear @ 2017-02-24 15:39 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918197.2540.1.camel@sipsolutions.net>
On 02/23/2017 10:36 PM, Johannes Berg wrote:
>
>
>> + msg_head = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0,
>> + HWSIM_CMD_NOTIFY);
>
> I think you should use a more specific command name.
My idea was that other attributes could be added over time without
having to add a new cmd-id, so that is why I left it general. If you
still want a different command, do you want it to be something like
'HWSIM_CMD_CHANNEL_CHANGE' ?
Thanks,
Ben
>
>> + if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
>> + ETH_ALEN, data->addresses[1].addr))
>> + goto nla_put_failure;
>
> and at least also add a more specific identifier like the radio ID.
>
>> + if (data->channel)
>> + center_freq = data->channel->center_freq;
>> +
>> + if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
>> + goto nla_put_failure;
>
> and have the full channel definition
>
>
> Also the indentation in the documentation didn't match the convention
> used there.
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] brcmfmac: always print error when PSM's watchdog fires
From: Rafał Miłecki @ 2017-02-24 16:32 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in
brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This
event means something went wrong and firmware / hardware usually can't
be expected to work (reliably).
Such a problem is significant for user experience so I believe we should
print an error unconditionally (even with debugging disabled). What can
be indeed optional is dumping bus memory as this is clearly part of
debugging process.
In the future we may also try to extend this listener by trying to
recover from the error or at least signal it to the cfg80211.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 22 ++++++++++++++++++
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 26 +++-------------------
.../wireless/broadcom/brcm80211/brcmfmac/debug.h | 9 ++++++++
3 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 60da86a8d95b..2f2f3a5ad86a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -738,6 +738,24 @@ void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked)
brcmf_del_if(ifp->drvr, ifp->bsscfgidx, rtnl_locked);
}
+static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
+ const struct brcmf_event_msg *evtmsg,
+ void *data)
+{
+ int err;
+
+ brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
+
+ brcmf_err("PSM's watchdog has fired!\n");
+
+ err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
+ evtmsg->datalen);
+ if (err)
+ brcmf_err("Failed to get memory dump, %d\n", err);
+
+ return err;
+}
+
#ifdef CONFIG_INET
#define ARPOL_MAX_ENTRIES 8
static int brcmf_inetaddr_changed(struct notifier_block *nb,
@@ -917,6 +935,10 @@ int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
goto fail;
}
+ /* Attach to events important for core code */
+ brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
+ brcmf_psm_watchdog_notify);
+
/* attach firmware event handler */
brcmf_fweh_attach(drvr);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index f4644cf371c7..1447a8352383 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -27,8 +27,8 @@
static struct dentry *root_folder;
-static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
- size_t len)
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len)
{
void *dump;
size_t ramsize;
@@ -54,24 +54,6 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
return 0;
}
-static int brcmf_debug_psm_watchdog_notify(struct brcmf_if *ifp,
- const struct brcmf_event_msg *evtmsg,
- void *data)
-{
- int err;
-
- brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
-
- brcmf_err("PSM's watchdog has fired!\n");
-
- err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
- evtmsg->datalen);
- if (err)
- brcmf_err("Failed to get memory dump, %d\n", err);
-
- return err;
-}
-
void brcmf_debugfs_init(void)
{
root_folder = debugfs_create_dir(KBUILD_MODNAME, NULL);
@@ -99,9 +81,7 @@ int brcmf_debug_attach(struct brcmf_pub *drvr)
if (IS_ERR(drvr->dbgfs_dir))
return PTR_ERR(drvr->dbgfs_dir);
-
- return brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
- brcmf_debug_psm_watchdog_notify);
+ return 0;
}
void brcmf_debug_detach(struct brcmf_pub *drvr)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 066126123e96..389166abb520 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -99,6 +99,7 @@ do { \
extern int brcmf_msg_level;
+struct brcmf_bus;
struct brcmf_pub;
#ifdef DEBUG
void brcmf_debugfs_init(void);
@@ -108,6 +109,8 @@ void brcmf_debug_detach(struct brcmf_pub *drvr);
struct dentry *brcmf_debugfs_get_devdir(struct brcmf_pub *drvr);
int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
int (*read_fn)(struct seq_file *seq, void *data));
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len);
#else
static inline void brcmf_debugfs_init(void)
{
@@ -128,6 +131,12 @@ int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
{
return 0;
}
+static inline
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len)
+{
+ return 0;
+}
#endif
#endif /* BRCMFMAC_DEBUG_H */
--
2.11.0
^ permalink raw reply related
* [PATCH RFC] brcmfmac: shutdown interfaces on PSM's watchdog fire
From: Rafał Miłecki @ 2017-02-24 17:24 UTC (permalink / raw)
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
When PSM's watchdog fires hardware / firmware is not operational. It
seems there isn't a way to restart firmware & reapply all settings so
instead shut all interfaces down. This is at least some signal for the
user things went wrong and allows reacting to it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
This patch is RFC as I'm wondering if there is any other way to handle
such errors. I couldn't find anything except for that
cfg80211_shutdown_all_interfaces.
Unfortunately hostapd doesn't seem to react to this except for sth like:
Fri Feb 24 13:41:07 2017 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Shall we introduce some nl80211 even for such cases maybe?
Or maybe I'm totally wrong and there is some simple way for a driver to
request reconfiguration of all interfaces?
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 10098b7586f3..520d397bb963 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6981,3 +6981,8 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg)
wl_deinit_priv(cfg);
brcmf_free_wiphy(cfg->wiphy);
}
+
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg)
+{
+ cfg80211_shutdown_all_interfaces(cfg->wiphy);
+}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 8f19d95d4175..77dafe03bb31 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -385,6 +385,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
struct device *busdev,
bool p2pdev_forced);
void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg);
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg);
s32 brcmf_cfg80211_up(struct net_device *ndev);
s32 brcmf_cfg80211_down(struct net_device *ndev);
enum nl80211_iftype brcmf_cfg80211_get_iftype(struct brcmf_if *ifp);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 2f2f3a5ad86a..c6c0f3e8ef00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -753,6 +753,10 @@ static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
if (err)
brcmf_err("Failed to get memory dump, %d\n", err);
+ brcmf_cfg80211_shutdown(ifp->drvr->config);
+
+ /* TODO: Stop the firmware */
+
return err;
}
--
2.11.0
^ permalink raw reply related
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Oliver Freyermuth @ 2017-02-24 18:51 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487938277.2540.13.camel@sipsolutions.net>
Am 24.02.2017 um 13:11 schrieb Johannes Berg:
>> However, when trying to suspend to RAM ( echo mem > /sys/power/state
>> ), I get:
>> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
>> returns -16
>> [46656.403769] PM: Device phy0 failed to suspend async: error -16
>>
>
> However, I don't see EBUSY anywhere there in the driver.
>
> Can you recompile the kernel and run a quick experiment?
>
> Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
> like this after the includes:
>
> #undef EBUSY
> #define EBUSY ({ WARN_ON(1); 16; })
>
> that should trigger a warning at the place where the EBUSY came from,
> assuming it did in fact come from the driver. You could repeat it for
> net/mac80211/ieee80211_i.h if that doesn't trigger.
Thanks for your reply and the suggestion! I have put the two lines directly after the last #include
in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and net/mac80211/ieee80211_i.h .
Sadly, none of them triggers when trying to enter suspend.
I still get:
[ 85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[ 85.308757] PM: Device phy0 failed to suspend async: error -16
[ 85.310518] sd 5:0:0:0: [sdb] Stopping disk
[ 85.857976] PM: Some devices failed to suspend, or early wake event detected
with nothing in between.
Just to make sure, I can confirm the change is effective, since I get many of:
[ 57.819114] WARNING: CPU: 4 PID: 4092 at drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503 iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
(with the tracebacks) for example when connecting to a different network. But none of these when trying to suspend...
Any other ideas on where I could look, or how I could trace the origin of this -16?
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
>
> That device is like mine, afaict, so this seems to be a different bug.
You are right about the bug report - I provided the wrong link, sorry.
The report I meant is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1362311
for a 7260 similar to mine.
I believe that
https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
i.e. comment 25 was made by the same person who just hijacked that kernel
bug report even though it was indeed for a very different hardware.
I'm open for any other suggestions, let me know if anything comes to mind.
Cheers and thanks for your reply,
Oliver
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Johannes Berg @ 2017-02-24 19:37 UTC (permalink / raw)
To: Oliver Freyermuth, linux-wireless
In-Reply-To: <5d69cf9b-1113-835a-8423-3796586eae20@googlemail.com>
On Fri, 2017-02-24 at 19:51 +0100, Oliver Freyermuth wrote:
>
> Thanks for your reply and the suggestion! I have put the two lines
> directly after the last #include
> in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
> and net/mac80211/ieee80211_i.h .
> Sadly, none of them triggers when trying to enter suspend.
>
> I still get:
> [ 85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [ 85.308757] PM: Device phy0 failed to suspend async: error -16
> [ 85.310518] sd 5:0:0:0: [sdb] Stopping disk
> [ 85.857976] PM: Some devices failed to suspend, or early wake
> event detected
> with nothing in between.
I'd have expected the message to show up *before* the first one
(dpm_run_callback) you quoted, because this one already has the -16
return value printed, and it must've been generated before that.
I just tried on one of my systems, but it's not exactly the same kernel
version (would be difficult to install right now), and it works just
fine for me. Perhaps there's something going on with your system.
> Just to make sure, I can confirm the change is effective, since I get
> many of:
> [ 57.819114] WARNING: CPU: 4 PID: 4092 at
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503
> iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
> (with the tracebacks) for example when connecting to a different
> network. But none of these when trying to suspend...
Oops. I didn't see this instance of EBUSY in the success path - it's
used for a comparison that probably never triggered. Anyway, no harm
done apart from logging lots of useless stack traces :)
> Any other ideas on where I could look, or how I could trace the
> origin of this -16?
(see below)
> You are right about the bug report - I provided the wrong link,
> sorry.
> The report I meant is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1362311
> for a 7260 similar to mine.
Yes, that one looks like the same as yours.
> I believe that
> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> i.e. comment 25 was made by the same person who just hijacked that
> kernel
> bug report even though it was indeed for a very different hardware.
Ok, that's possible.
So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
it's still returned through wiphy_suspend(). That function just calls
mac80211 though, and never generates any error conditions by itself. As
a consequence, this must be generated in some callee of wiphy_suspend()
that *isn't* in mac80211/iwlwifi...
__ieee80211_suspend() also doesn't generate any error codes by itself,
let's take a look at iwlmvm's suspend (called through drv_suspend()),
that's iwl_mvm_suspend().
Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
configuration? If you do, please turn it off and see if that fixes it.
This still looks fishy in the code though, but let's see if that's the
problem first.
johannes
^ permalink raw reply
* [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Alexis Green @ 2017-02-24 19:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Jesse Jones
From: Jesse Jones <jjones@uniumwifi.com>
Changes since v1: Only flush tx queue if interface is mesh mode.
This prevents kernel panics due to uninitialized spin_lock.
When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
Signed-off-by: Benjamin Morgan <bmorgan@uniumwifi.com>
---
net/mac80211/ieee80211_i.h | 11 ++++
net/mac80211/iface.c | 61 ++++++++++++++++++++++
net/mac80211/mesh.c | 2 +
net/mac80211/mesh_hwmp.c | 124 +++++++++++++++++++++++++++++++++++----------
4 files changed, 171 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
};
+struct mesh_tx_queue {
+ struct list_head list;
+ struct sk_buff *skb;
+};
+
struct ieee80211_roc_work {
struct list_head list;
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+ /* Spinlock for trasmitted MPATH frames */
+ spinlock_t mesh_tx_queue_lock;
+ struct mesh_tx_queue tx_queue;
+ int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
struct work_struct work;
struct sk_buff_head skb_queue;
+ struct delayed_work tx_work;
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..d5b4bf4 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(&sdata->wdev, true);
}
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ /* Note that this check is important because of the two-stage
+ * way that ieee80211_if_mesh is initialized.
+ */
+ if (ifmsh->tx_queue_len > 0) {
+ mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ kfree_skb(tx_node->skb);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+ }
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(
+ wk, struct ieee80211_sub_if_data,
+ tx_work.work);
+
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ list_for_each_entry(tx_node, &ifmsh->tx_queue.list, list) {
+ ieee80211_tx_skb(sdata, tx_node->skb);
+ }
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
bool going_down)
{
@@ -881,6 +934,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ /* Nothing to flush if the interface is not in mesh mode */
+ if (sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
+ flush_tx_skbs(sdata);
+
+ cancel_delayed_work_sync(&sdata->tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1905,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(&sdata->dec_tailroom_needed_wk,
ieee80211_delayed_tailroom_dec);
+ INIT_DELAYED_WORK(&sdata->tx_work,
+ mesh_jittered_tx);
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c28b0af..f0d3cd9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1381,6 +1381,8 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
ieee80211_mesh_path_root_timer,
(unsigned long) sdata);
INIT_LIST_HEAD(&ifmsh->preq_queue.list);
+ INIT_LIST_HEAD(&ifmsh->tx_queue.list);
+ spin_lock_init(&ifmsh->mesh_tx_queue_lock);
skb_queue_head_init(&ifmsh->ps.bc_buf);
spin_lock_init(&ifmsh->mesh_preq_queue_lock);
spin_lock_init(&ifmsh->sync_offset_lock);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d07ee3c..5c22daf 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -18,6 +18,7 @@
#define ARITH_SHIFT 8
#define MAX_PREQ_QUEUE_LEN 64
+#define MAX_TX_QUEUE_LEN 8
static void mesh_queue_preq(struct mesh_path *, u8);
@@ -98,13 +99,15 @@ enum mpath_frame_type {
static const u8 broadcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
- const u8 *orig_addr, u32 orig_sn,
- u8 target_flags, const u8 *target,
- u32 target_sn, const u8 *da,
- u8 hop_count, u8 ttl,
- u32 lifetime, u32 metric, u32 preq_id,
- struct ieee80211_sub_if_data *sdata)
+static struct sk_buff *alloc_mesh_path_sel_frame(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct sk_buff *skb;
@@ -117,7 +120,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
hdr_len +
2 + 37); /* max HWMP IE */
if (!skb)
- return -1;
+ return NULL;
skb_reserve(skb, local->tx_headroom);
mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
memset(mgmt, 0, hdr_len);
@@ -153,7 +156,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
break;
default:
kfree_skb(skb);
- return -ENOTSUPP;
+ return NULL;
}
*pos++ = ie_len;
*pos++ = flags;
@@ -192,10 +195,72 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
pos += 4;
}
- ieee80211_tx_skb(sdata, skb);
- return 0;
+ return skb;
+}
+
+static void mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
+ const u8 *orig_addr, u32 orig_sn,
+ u8 target_flags, const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric, u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn, target_flags, target, target_sn,
+ da, hop_count, ttl, lifetime, metric, preq_id, sdata);
+ if (skb)
+ ieee80211_tx_skb(sdata, skb);
}
+static void mesh_path_sel_frame_tx_jittered(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target, u32 target_sn,
+ const u8 *da, u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ u32 jitter;
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn,
+ target_flags, target,
+ target_sn, da,
+ hop_count, ttl,
+ lifetime, metric,
+ preq_id, sdata);
+ if (skb) {
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node = kmalloc(
+ sizeof(struct mesh_tx_queue), GFP_ATOMIC);
+ if (!tx_node) {
+ mhwmp_dbg(sdata, "could not allocate mesh_hwmp tx node");
+ return;
+ }
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+ if (ifmsh->tx_queue_len == MAX_TX_QUEUE_LEN) {
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+ kfree(tx_node);
+ kfree_skb(skb);
+ if (printk_ratelimit())
+ mhwmp_dbg(sdata, "mesh_hwmp tx node queue full");
+ return;
+ }
+
+ tx_node->skb = skb;
+ list_add_tail(&tx_node->list, &ifmsh->tx_queue.list);
+ ++ifmsh->tx_queue_len;
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ jitter = prandom_u32() % 25;
+
+ ieee80211_queue_delayed_work(
+ &sdata->local->hw,
+ &sdata->tx_work, msecs_to_jiffies(jitter));
+ }
+}
/* Headroom is not adjusted. Caller should ensure that skb has sufficient
* headroom in case the frame is encrypted. */
@@ -620,11 +685,13 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
ttl = ifmsh->mshcfg.element_ttl;
if (ttl != 0) {
mhwmp_dbg(sdata, "replying to the PREQ\n");
- mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
- orig_sn, 0, target_addr,
- target_sn, mgmt->sa, 0, ttl,
- lifetime, target_metric, 0,
- sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, 0,
+ orig_addr, orig_sn,
+ 0, target_addr,
+ target_sn, mgmt->sa,
+ 0, ttl, lifetime,
+ target_metric, 0,
+ sdata);
} else {
ifmsh->mshstats.dropped_frames_ttl++;
}
@@ -652,10 +719,11 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
}
- mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
- orig_sn, target_flags, target_addr,
- target_sn, da, hopcount, ttl, lifetime,
- orig_metric, preq_id, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREQ, flags, orig_addr,
+ orig_sn, target_flags,
+ target_addr, target_sn, da,
+ hopcount, ttl, lifetime,
+ orig_metric, preq_id, sdata);
if (!is_multicast_ether_addr(da))
ifmsh->mshstats.fwded_unicast++;
else
@@ -721,9 +789,10 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREP_IE_TARGET_SN(prep_elem);
orig_sn = PREP_IE_ORIG_SN(prep_elem);
- mesh_path_sel_frame_tx(MPATH_PREP, flags, orig_addr, orig_sn, 0,
- target_addr, target_sn, next_hop, hopcount,
- ttl, lifetime, metric, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, flags, orig_addr, orig_sn,
+ 0, target_addr, target_sn, next_hop,
+ hopcount, ttl, lifetime, metric, 0,
+ sdata);
rcu_read_unlock();
sdata->u.mesh.mshstats.fwded_unicast++;
@@ -873,10 +942,11 @@ static void hwmp_rann_frame_process(struct ieee80211_sub_if_data *sdata,
ttl--;
if (ifmsh->mshcfg.dot11MeshForwarding) {
- mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr,
- orig_sn, 0, NULL, 0, broadcast_addr,
- hopcount, ttl, interval,
- metric + metric_txsta, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_RANN, flags, orig_addr,
+ orig_sn, 0, NULL, 0,
+ broadcast_addr, hopcount, ttl,
+ interval, metric + metric_txsta,
+ 0, sdata);
}
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH] NFC: remove TI nfcwilink driver
From: Rob Herring @ 2017-02-24 20:56 UTC (permalink / raw)
To: Samuel Ortiz, Lauro Ramos Venancio, Aloisio Almeida Jr
Cc: linux-kernel@vger.kernel.org, linux-wireless, Ilan Elias,
Marcel Holtmann
In-Reply-To: <3B67FD13-A482-4BEF-B619-DD9AF9CC129F@holtmann.org>
On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Rob,
>
>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
>> shipped. The only information I found were announcements in Feb
>> 2012 about the parts. There's been no activity on this driver besided
>> common changes since initially added in Jan 2012. There's also no in
>> users that instantiate the platform device (nor DT bindings).
>>
>> This is a first step in removing TI ST (shared transport) driver in
>> favor of extending the BT hci_ll driver to support WL183x chips.
>
> since the firmware files TINfcInit_* also never made it into the linux-firmware tree, I have no idea who is using this driver. I am actually fine with removing it since it would be easy enough to bring back based on hci_ll driver once there is hardware to test this on.
Ping. Someone going to pick up this patch?
Rob
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Oliver Freyermuth @ 2017-02-24 21:16 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487965047.30601.2.camel@sipsolutions.net>
Am 24.02.2017 um 20:37 schrieb Johannes Berg:
> So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
> it's still returned through wiphy_suspend(). That function just calls
> mac80211 though, and never generates any error conditions by itself. As
> a consequence, this must be generated in some callee of wiphy_suspend()
> that *isn't* in mac80211/iwlwifi...
>
> __ieee80211_suspend() also doesn't generate any error codes by itself,
> let's take a look at iwlmvm's suspend (called through drv_suspend()),
> that's iwl_mvm_suspend().
>
> Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
> configuration? If you do, please turn it off and see if that fixes it.
Indeed, you got it!
I had it on, and turning that off lets me suspend just fine after activating WoWLAN!
See here, the syslog is now clean (I removed the EBUSY-WARNONs for now):
[12383.757181] PM: Syncing filesystems ... done.
[12383.924701] PM: Preparing system for sleep (mem)
[12384.249363] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.323377] Freezing user space processes ... (elapsed 0.001 seconds) done.
[12385.325193] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[12385.326602] PM: Suspending system (mem)
[12385.326619] Suspending console(s) (use no_console_suspend to debug)
[12385.326989] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[12385.327076] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[12385.327199] sd 0:0:0:0: [sda] Stopping disk
[12385.329952] sd 5:0:0:0: [sdb] Stopping disk
[12385.335474] iwlwifi 0000:0a:00.0: L1 Enabled - LTR Enabled
[12385.335737] iwlwifi 0000:0a:00.0: L1 Enabled - LTR Enabled
[12385.426964] ACPI : EC: event blocked
[12385.637708] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.678281] nvidia-modeset: WARNING: GPU:0: Failed to determine which devices were hotplugged: 0x11
[12385.892099] PM: suspend of devices complete after 565.370 msecs
[12385.892586] PM: late suspend of devices complete after 0.484 msecs
[12385.892942] ACPI : EC: interrupt blocked
[12385.893495] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
[12385.893685] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[12385.893754] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[12385.905567] PM: noirq suspend of devices complete after 12.970 msecs
[12385.905967] ACPI: Preparing to enter system sleep state S3
[12385.906505] ACPI : EC: EC stopped
[12385.906505] PM: Saving platform NVS memory
[12385.906511] Disabling non-boot CPUs ...
[12385.908459] smpboot: CPU 1 is now offline
[12385.919596] smpboot: CPU 2 is now offline
[12385.928100] smpboot: CPU 3 is now offline
[12385.939661] smpboot: CPU 4 is now offline
[12385.952240] smpboot: CPU 5 is now offline
[12385.965252] smpboot: CPU 6 is now offline
[12385.975465] smpboot: CPU 7 is now offline
The problem is that it seems I cannot actually wake the machine anymore afterwards...
While in the suspend procedure, I see:
[12385.893568] iwlwifi 0000:0a:00.0: System wakeup enabled by ACPI
as expected, I could neither get it to make a tcp connection in tcp-connection mode,
nor could I wake the machine via magic packet in magic-packet mode.
Could that be some hardware / system firmware limitation, e.g. if my UEFI does not support actually powering
the WiFi hardware if I am in S3? I have yet to (re)check the UEFI config, but since the options are
extremely limited on this Alienware laptop, I guess I will not find anything related to that.
At least, the suspend problem seems to be clearly related to some path only used if CONFIG_IWLWIFI_PCIE_RTPM is on.
>
> This still looks fishy in the code though, but let's see if that's the
> problem first.
>
> johannes
>
^ permalink raw reply
* Re: [PATCH] NFC: remove TI nfcwilink driver
From: Marcel Holtmann @ 2017-02-24 21:43 UTC (permalink / raw)
To: Rob Herring
Cc: Samuel Ortiz, Lauro Ramos Venancio, Aloisio Almeida Jr,
linux-kernel@vger.kernel.org, linux-wireless, Ilan Elias
In-Reply-To: <CAL_JsqL1c9vU0R0m73UXi6wvPscqNT9ZAxX8FxhMmLFGMRAeVQ@mail.gmail.com>
Hi Rob,
>>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
>>> shipped. The only information I found were announcements in Feb
>>> 2012 about the parts. There's been no activity on this driver besided
>>> common changes since initially added in Jan 2012. There's also no in
>>> users that instantiate the platform device (nor DT bindings).
>>>
>>> This is a first step in removing TI ST (shared transport) driver in
>>> favor of extending the BT hci_ll driver to support WL183x chips.
>>
>> since the firmware files TINfcInit_* also never made it into the linux-firmware tree, I have no idea who is using this driver. I am actually fine with removing it since it would be easy enough to bring back based on hci_ll driver once there is hardware to test this on.
>
> Ping. Someone going to pick up this patch?
if Samuel does not have anything pending for his tree, I can take it through bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] NFC: remove TI nfcwilink driver
From: Rob Herring @ 2017-02-24 21:52 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Samuel Ortiz, Lauro Ramos Venancio, Aloisio Almeida Jr,
linux-kernel@vger.kernel.org, linux-wireless, Ilan Elias
In-Reply-To: <9E986B17-64EA-46E5-BEE3-76217E31B0D1@holtmann.org>
On Fri, Feb 24, 2017 at 3:43 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Rob,
>
>>>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
>>>> shipped. The only information I found were announcements in Feb
>>>> 2012 about the parts. There's been no activity on this driver besided
>>>> common changes since initially added in Jan 2012. There's also no in
>>>> users that instantiate the platform device (nor DT bindings).
>>>>
>>>> This is a first step in removing TI ST (shared transport) driver in
>>>> favor of extending the BT hci_ll driver to support WL183x chips.
>>>
>>> since the firmware files TINfcInit_* also never made it into the linux-firmware tree, I have no idea who is using this driver. I am actually fine with removing it since it would be easy enough to bring back based on hci_ll driver once there is hardware to test this on.
>>
>> Ping. Someone going to pick up this patch?
>
> if Samuel does not have anything pending for his tree, I can take it through bluetooth-next tree.
>From the looks of -next, it doesn't appear so.
Rob
^ permalink raw reply
* [PATCH v4 0/3] staging: wilc1000: multiple coding style changes to struct tstrRSSI
From: Tahia Khan @ 2017-02-24 22:05 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
Multiple coding style changes to struct tstrRSSI. Initially reported by checkpath.pl:
Avoid CamelCase: <tstrRSSI>
Avoid CamelCase: <u8Full>
Avoid CamelCase: <u8Index>
Changes since v3: Reformatting commit messages, as requested by
Julia Lawall <julia.lawall@lip6.fr>
Tahia Khan (3):
staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer for
clarity and to remove camel casing.
staging: wilc1000: Remove Hungarian notation and camel casing from all
tstrRSSI members’ names. Additionally, change type of u8Full to bool
since it only takes values 1 or 0.
staging: wilc1000: Change name of str_rssi to rssi_history within the
network_info struct for clarity.
drivers/staging/wilc1000/coreconfigurator.h | 10 +++++-----
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 12 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v4 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool
From: Tahia Khan @ 2017-02-24 22:05 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487947616.git.tahia.khan@gmail.com>
Remove Hungarian notation and camel casing from all tstrRSSI members'
names. Additionally, change type of u8Full to bool since it only takes
values 1 or 0.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/staging/wilc1000/coreconfigurator.h | 6 +++---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index 1c77529..9712d89 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -71,9 +71,9 @@ enum connect_status {
};
struct rssi_history_buffer {
- u8 u8Full;
- u8 u8Index;
- s8 as8RSSI[NUM_RSSI];
+ bool full;
+ u8 index;
+ s8 samples[NUM_RSSI];
};
struct network_info {
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f7ce47c..9601ab8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
{
u8 i;
int rssi_v = 0;
- u8 num_rssi = (network_info->str_rssi.u8Full) ?
- NUM_RSSI : (network_info->str_rssi.u8Index);
+ u8 num_rssi = (network_info->str_rssi.full) ?
+ NUM_RSSI : (network_info->str_rssi.index);
for (i = 0; i < num_rssi; i++)
- rssi_v += network_info->str_rssi.as8RSSI[i];
+ rssi_v += network_info->str_rssi.samples[i];
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
} else {
ap_index = ap_found;
}
- rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
- last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = pstrNetworkInfo->rssi;
+ rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
+ last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
- last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
+ last_scanned_shadow[ap_index].str_rssi.full = true;
}
- last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
+ last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history
From: Tahia Khan @ 2017-02-24 22:05 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487947616.git.tahia.khan@gmail.com>
Change name of str_rssi to rssi_history within the network_info
struct for clarity.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/staging/wilc1000/coreconfigurator.h | 2 +-
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index 9712d89..10101f8 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
- struct rssi_history_buffer str_rssi;
+ struct rssi_history_buffer rssi_history;
u64 tsf_hi;
};
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 9601ab8..4a6fe90 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
{
u8 i;
int rssi_v = 0;
- u8 num_rssi = (network_info->str_rssi.full) ?
- NUM_RSSI : (network_info->str_rssi.index);
+ u8 num_rssi = (network_info->rssi_history.full) ?
+ NUM_RSSI : (network_info->rssi_history.index);
for (i = 0; i < num_rssi; i++)
- rssi_v += network_info->str_rssi.samples[i];
+ rssi_v += network_info->rssi_history.samples[i];
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
} else {
ap_index = ap_found;
}
- rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
- last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
+ rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
+ last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] = pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
- last_scanned_shadow[ap_index].str_rssi.full = true;
+ last_scanned_shadow[ap_index].rssi_history.full = true;
}
- last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
+ last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer
From: Tahia Khan @ 2017-02-24 22:05 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487947616.git.tahia.khan@gmail.com>
Rename struct tstrRSSI to rssi_history_buffer for clarity
and to remove camel casing.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
---
drivers/staging/wilc1000/coreconfigurator.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index cff1698..1c77529 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -70,7 +70,7 @@ enum connect_status {
CONNECT_STS_FORCE_16_BIT = 0xFFFF
};
-struct tstrRSSI {
+struct rssi_history_buffer {
u8 u8Full;
u8 u8Index;
s8 as8RSSI[NUM_RSSI];
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
- struct tstrRSSI str_rssi;
+ struct rssi_history_buffer str_rssi;
u64 tsf_hi;
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox