* [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: Regression with Intel 3160 AP: client not reconnecting
From: Jarek Kamiński @ 2017-02-24 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Emmanuel Grumbach, Intel Linux Wireless, linux-wireless
In-Reply-To: <1487938414.2540.15.camel@sipsolutions.net>
W dniu 24.02.2017 o 13:13, Johannes Berg pisze:
> Hi Jarek,
Hello Johannes,
>> What might be the cause? Is there anything I can do to help debug or
>> fix this?
>
> Thanks for the detailed bug report and analysis! I can't analyse this
> in depth right now, can you please file a bug on bugzilla.kernel.org?
Sure, I'll do that during the weekend. Thanks for response!
--
pozdr(); // Jarek
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Johannes Berg @ 2017-02-24 12:11 UTC (permalink / raw)
To: Oliver Freyermuth, linux-wireless
In-Reply-To: <cc035655-0869-f7d7-bdb4-61e7a38b7fc8@googlemail.com>
> I have been trying to get basic WoWLAN to work with the following
> configuration:
> - Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi
> driver
So I just tried on 4.9 with a 6205 NIC and it works there. The
difference must be somewhere in mvm/d3.c then, I guess. I got a lot of
warnings at resume time though, not sure why.
> 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.
> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
That device is like mine, afaict, so this seems to be a different bug.
johannes
^ permalink raw reply
* [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table
From: Rafał Miłecki @ 2017-02-24 12:27 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
In-Reply-To: <20170224122739.1778-1-zajec5@gmail.com>
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.
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),
};
--
2.11.0
^ permalink raw reply related
* [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Rafał Miłecki @ 2017-02-24 12:27 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>
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.
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),
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: jeffy @ 2017-02-24 12:20 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Brian Norris, Rajat Jain, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <87d1e726p5.fsf@codeaurora.org>
Hi Kalle,
On 02/24/2017 07:01 PM, Kalle Valo wrote:
> Jeffy Chen <jeffy.chen@rock-chips.com> writes:
>
>> Currrently we are disabling this wake irq after receiving it. If this
>> happens before we finish suspend and the pm event check is disabled,
>> the system will continue suspending, and this irq would not work again.
>>
>> We may need to abort system suspend to avoid that.
>>
>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> I only see patch 3 in patchwork. Where are patches 1 and 2?
>
the other two are much like this one, but for bluetooth :)
please check:
https://patchwork.kernel.org/patch/9589455 New [1/3] btusb:
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589453 New [2/3] btmrvl:
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589457 New [3/3] mwifiex:
wake system up when receives a wake irq
(sorry, this is a resent mail, because the last one was rejected due to
wrong format)
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 12:15 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487932016.3812.10.camel@embedded.rocks>
On 24-2-2017 11:26, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
>> On 24-2-2017 10:43, Jörg Krause wrote:
>>> Hi Arend,
>>>
>>> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>>>
>>>> On 23-2-2017 21:21, Jörg Krause wrote:
>>>>> Hi,
>>>>>
>>>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
>>>>> running
>>>>> 'wpa_cli wps_pin any', the following messages are printed:
>>>>>
>>>>> """
>>>>>> wps_pin any
>>>>>
>>>>> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
>>>>> error :
>>>>> -30
>>>>> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
>>>>> Failed
>>>>> """
>>>>>
>>>>> .. and nothing happens. The data sheet for the BCM43362 states
>>>>> that
>>>>> the
>>>>> module supports WPS.
>>>>
>>>> Hi Jörg,
>>>>
>>>> We have never tested WPS with brcmfmac. Most of it is in firmware
>>>> so
>>>> it
>>>> might work. We had some fixes related to setting management IE,
>>>> but
>>>> it
>>>> should be in 4.9. I did not check it (yet).
>>>
>>> As it turns out, WPS does not work if a network configuration in
>>> wpa_supplicant has the flag `mode=2` (access point mode) set:
>>>
>>> """
>>> ctrl_interface=/var/run/wpa_supplicant
>>> update_config=1
>>>
>>> network={
>>> ssid="AP"
>>> key_mgmt=NONE
>>> mode=2
>>> id_str="ap"
>>> }
>>> """
>>>
>>> Setting mode=2 for a network and having ap_scan=1 (default) means
>>> if no
>>> APs matching to the currently enabled networks are found, a new
>>> network
>>> (IBSS or AP mode operation) may be initialized (if configured).
>>>
>>> So, WPS does not work if the interface is operating in AP mode. I
>>> wonder, if this is a desired behavior? At least, wpa_supplicant
>>> does
>>> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
>>> following, until "WPS-TIMEOUT".
>>
>> So what do you expect exactly? Are you trying to connect with some
>> other
>> device to this AP interface?
>
> Sorry, I got confused. The device operating in AP mode shall be
> connected to some other AP as a station. Of course, WPS cannot be used
> to do so as long as the interface is operation in AP mode, as the
> device should be the WPS enrollee and not the registrar. My bad! Thanks
> for pointing that out.
>
> So, to use WPS for connecting the device to another AP I have to bring
> the interface into an non-AP mode first.
>
> So, I can confirm that using WPS works when the interface is
> unconfigured. However, if the in the interface is in AP mode and WPS is
> started the error messages pop up.
You mean the message you emailed earlier as below?
[ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
error :
-30
[ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
Failed
You get firmware error -30 which is BCME_NOTFOUND. This can happen in
firmware upon deleting an IE. However, it is hard to say what is exactly
happening without knowing the message content that goes to firmware. You
can enable firmware console logging to see if you get any message
regarding this, eg. "wlc_del_ie: IE not in list". Do insmod with
debug=0x00100000.
if (total_ie_buf_len) {
err = brcmf_fil_bsscfg_data_set(ifp, "vndr_ie", iovar_ie_buf,
total_ie_buf_len);
if (err)
brcmf_err("vndr ie set error : %d\n", err);
}
If this happens in the .start_ap() callback the error is ignored so it
should not affect AP operation although beacon may not be setup properly.
Regards,
Arend
^ permalink raw reply
* Re: Regression with Intel 3160 AP: client not reconnecting
From: Johannes Berg @ 2017-02-24 12:13 UTC (permalink / raw)
To: Jarek Kamiński, Emmanuel Grumbach, Intel Linux Wireless
Cc: linux-wireless
In-Reply-To: <20170221213340.GA14974@Straylight.freeside.be>
Hi Jarek,
[snip]
> What might be the cause? Is there anything I can do to help debug or
> fix this?
Thanks for the detailed bug report and analysis! I can't analyse this
in depth right now, can you please file a bug on bugzilla.kernel.org?
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: Kalle Valo @ 2017-02-24 11:01 UTC (permalink / raw)
To: Jeffy Chen
Cc: Amitkumar Karwar, Brian Norris, Rajat Jain, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <1487917471-5501-3-git-send-email-jeffy.chen@rock-chips.com>
Jeffy Chen <jeffy.chen@rock-chips.com> writes:
> Currrently we are disabling this wake irq after receiving it. If this
> happens before we finish suspend and the pm event check is disabled,
> the system will continue suspending, and this irq would not work again.
>
> We may need to abort system suspend to avoid that.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I only see patch 3 in patchwork. Where are patches 1 and 2?
--
Kalle Valo
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 10:26 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <ce3bf3a5-2cd7-eb77-bb7d-57df8388e1ba@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
> On 24-2-2017 10:43, Jörg Krause wrote:
> > Hi Arend,
> >
> > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> > >
> > > On 23-2-2017 21:21, Jörg Krause wrote:
> > > > Hi,
> > > >
> > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
> > > > running
> > > > 'wpa_cli wps_pin any', the following messages are printed:
> > > >
> > > > """
> > > > > wps_pin any
> > > >
> > > > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> > > > error :
> > > > -30
> > > > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > > > Failed
> > > > """
> > > >
> > > > .. and nothing happens. The data sheet for the BCM43362 states
> > > > that
> > > > the
> > > > module supports WPS.
> > >
> > > Hi Jörg,
> > >
> > > We have never tested WPS with brcmfmac. Most of it is in firmware
> > > so
> > > it
> > > might work. We had some fixes related to setting management IE,
> > > but
> > > it
> > > should be in 4.9. I did not check it (yet).
> >
> > As it turns out, WPS does not work if a network configuration in
> > wpa_supplicant has the flag `mode=2` (access point mode) set:
> >
> > """
> > ctrl_interface=/var/run/wpa_supplicant
> > update_config=1
> >
> > network={
> > ssid="AP"
> > key_mgmt=NONE
> > mode=2
> > id_str="ap"
> > }
> > """
> >
> > Setting mode=2 for a network and having ap_scan=1 (default) means
> > if no
> > APs matching to the currently enabled networks are found, a new
> > network
> > (IBSS or AP mode operation) may be initialized (if configured).
> >
> > So, WPS does not work if the interface is operating in AP mode. I
> > wonder, if this is a desired behavior? At least, wpa_supplicant
> > does
> > not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> > following, until "WPS-TIMEOUT".
>
> So what do you expect exactly? Are you trying to connect with some
> other
> device to this AP interface?
Sorry, I got confused. The device operating in AP mode shall be
connected to some other AP as a station. Of course, WPS cannot be used
to do so as long as the interface is operation in AP mode, as the
device should be the WPS enrollee and not the registrar. My bad! Thanks
for pointing that out.
So, to use WPS for connecting the device to another AP I have to bring
the interface into an non-AP mode first.
So, I can confirm that using WPS works when the interface is
unconfigured. However, if the in the interface is in AP mode and WPS is
started the error messages pop up.
Jörg
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 9:58 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487929408.3812.3.camel@embedded.rocks>
On 24-2-2017 10:43, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>
>> On 23-2-2017 21:21, Jörg Krause wrote:
>>> Hi,
>>>
>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
>>> 'wpa_cli wps_pin any', the following messages are printed:
>>>
>>> """
>>>> wps_pin any
>>>
>>> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
>>> -30
>>> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
>>> Failed
>>> """
>>>
>>> .. and nothing happens. The data sheet for the BCM43362 states that
>>> the
>>> module supports WPS.
>>
>> Hi Jörg,
>>
>> We have never tested WPS with brcmfmac. Most of it is in firmware so
>> it
>> might work. We had some fixes related to setting management IE, but
>> it
>> should be in 4.9. I did not check it (yet).
>
> As it turns out, WPS does not work if a network configuration in
> wpa_supplicant has the flag `mode=2` (access point mode) set:
>
> """
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
>
> network={
> ssid="AP"
> key_mgmt=NONE
> mode=2
> id_str="ap"
> }
> """
>
> Setting mode=2 for a network and having ap_scan=1 (default) means if no
> APs matching to the currently enabled networks are found, a new network
> (IBSS or AP mode operation) may be initialized (if configured).
>
> So, WPS does not work if the interface is operating in AP mode. I
> wonder, if this is a desired behavior? At least, wpa_supplicant does
> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> following, until "WPS-TIMEOUT".
So what do you expect exactly? Are you trying to connect with some other
device to this AP interface?
Regards,
Arend
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 9:43 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <dd241eff-7e0d-26c1-1758-b3f4d51bc359@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> >
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> >
> > """
> > > wps_pin any
> >
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> >
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
>
> Hi Jörg,
>
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).
As it turns out, WPS does not work if a network configuration in
wpa_supplicant has the flag `mode=2` (access point mode) set:
"""
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
ssid="AP"
key_mgmt=NONE
mode=2
id_str="ap"
}
"""
Setting mode=2 for a network and having ap_scan=1 (default) means if no
APs matching to the currently enabled networks are found, a new network
(IBSS or AP mode operation) may be initialized (if configured).
So, WPS does not work if the interface is operating in AP mode. I
wonder, if this is a desired behavior? At least, wpa_supplicant does
not complain, but prints "WPS-PBC-ACTIVE", but no messages are
following, until "WPS-TIMEOUT".
Jörg
^ permalink raw reply
* Re: Request for brcmfmac4366c-pcie.bin
From: Arend Van Spriel @ 2017-02-24 9:07 UTC (permalink / raw)
To: Rafał Miłecki, Hante Meuleman, bcm-kernel-feedback-list
Cc: linux-wireless@vger.kernel.org, Hauke Mehrtens, Nathan Grennan
In-Reply-To: <CACna6rywt_U+SSLRGAgnqZiwO8TmY8z406m8o5gCOsGiyUc+oQ@mail.gmail.com>
On 23-2-2017 21:53, Rafał Miłecki wrote:
> Hi guys,
>
> On 12 September 2016 at 07:22, Rafał Miłecki <zajec5@gmail.com> wrote:
>> Few months ago Hante added support for 4366c0 to the brcmfmac. There
>> are already few devices with this chipset on the market. We even have
>> some related bug report at kernel:
>> https://bugzilla.kernel.org/show_bug.cgi?id=135321
>>
>> Unfortunately the firmware for this chipset is still missing. Can you
>> build it and submit to linux-firmware.git, please?
>
> Last answer I got from Arend was "Router group still working on a
> solution. Will ask about status again :-(" in December.
> Are there any news on 4366c1 firmware?
There have been some firmware changes being made, but these need to be
validated. As the validation is in DFS area it may take some time and we
have to free up resources to actually do the validation.
Regards,
Arend
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 8:51 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <dd241eff-7e0d-26c1-1758-b3f4d51bc359@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> >
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> >
> > """
> > > wps_pin any
> >
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> >
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
>
> Hi Jörg,
>
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).
I've tested WPS on another board, the Banana Pro, which also has the
BCM43362 and it works with Linux v4.9.12. So, I'll look why it does not
work on my custom board.
Jörg
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Andrew Zaborowski @ 2017-02-24 8:45 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1487896109-23851-7-git-send-email-greearb@candelatech.com>
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.
Best regards
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 8:16 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487881302.20481.3.camel@embedded.rocks>
On 23-2-2017 21:21, Jörg Krause wrote:
> Hi,
>
> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> 'wpa_cli wps_pin any', the following messages are printed:
>
> """
>> wps_pin any
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE Failed
> """
>
> .. and nothing happens. The data sheet for the BCM43362 states that the
> module supports WPS.
Hi Jörg,
We have never tested WPS with brcmfmac. Most of it is in firmware so it
might work. We had some fixes related to setting management IE, but it
should be in 4.9. I did not check it (yet).
Regards,
Arend
^ permalink raw reply
* Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X
From: Arend Van Spriel @ 2017-02-24 8:08 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Avraham Stern
In-Reply-To: <20170221123758.5339-2-johannes@sipsolutions.net>
On 21-2-2017 13:37, Johannes Berg wrote:
> From: Avraham Stern <avraham.stern@intel.com>
>
> Add API for setting the PMK to the driver. For FT support, allow
> setting also the PMK-R0 Name.
>
> This can be used by drivers that support 4-Way handshake offload
> while IEEE802.1X authentication is managed by upper layers.
>
> Signed-off-by: Avraham Stern <avraham.stern@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> include/linux/ieee80211.h | 3 ++
> include/net/cfg80211.h | 27 ++++++++++++
> include/uapi/linux/nl80211.h | 24 ++++++++++-
> net/wireless/core.c | 5 +++
> net/wireless/nl80211.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
> net/wireless/rdev-ops.h | 25 +++++++++++
> net/wireless/trace.h | 60 +++++++++++++++++++++++++++
> 7 files changed, 241 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index 2049e983a994..fb1f533e75b3 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -2356,8 +2356,11 @@ enum ieee80211_sa_query_action {
>
> #define WLAN_MAX_KEY_LEN 32
>
> +#define WLAN_PMK_NAME_LEN 16
> #define WLAN_PMKID_LEN 16
> +#define WLAN_PMK_LEN_EAP_LEAP 16
> #define WLAN_PMK_LEN 32
> +#define WLAN_PMK_LEN_SUITE_B_192 48
>
> #define WLAN_OUI_WFA 0x506f9a
> #define WLAN_OUI_TYPE_WFA_P2P 9
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 4ca968927d60..a68c6db6ac55 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2507,6 +2507,23 @@ struct cfg80211_nan_func {
> };
>
> /**
> + * struct cfg80211_pmk_conf - PMK configuration
> + *
> + * @aa: authenticator address
> + * @pmk_len: PMK length in bytes.
> + * @pmk: the PMK material
> + * @pmk_r0_name: PMK-R0 Name. NULL if not applicable (i.e., the PMK
> + * is not PMK-R0). When pmk_r0_name is not NULL, the pmk field
> + * holds PMK-R0.
> + */
> +struct cfg80211_pmk_conf {
> + const u8 *aa;
> + u8 pmk_len;
> + const u8 *pmk;
> + const u8 *pmk_r0_name;
> +};
> +
> +/**
> * struct cfg80211_ops - backend description for wireless configuration
> *
> * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -2823,6 +2840,11 @@ struct cfg80211_nan_func {
> * All other parameters must be ignored.
> *
> * @set_multicast_to_unicast: configure multicast to unicast conversion for BSS
> + *
> + * @set_pmk: configure the PMK to be used for offloaded 4-Way handshake.
> + * (invoked with the wireless_dev mutex held)
> + * @del_pmk: delete the previously configured PMK for the given authenticator.
> + * (invoked with the wireless_dev mutex held)
> */
> struct cfg80211_ops {
> int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
> @@ -3111,6 +3133,11 @@ struct cfg80211_ops {
> int (*set_multicast_to_unicast)(struct wiphy *wiphy,
> struct net_device *dev,
> const bool enabled);
> +
> + int (*set_pmk)(struct wiphy *wiphy, struct net_device *dev,
> + const struct cfg80211_pmk_conf *conf);
> + int (*del_pmk)(struct wiphy *wiphy, struct net_device *dev,
> + const u8 *aa);
Minor nit, but prefer clr_pmk to clear the pmk.
> };
>
> /*
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index bb5e1904a107..89295fc2336b 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -901,6 +901,14 @@
> * does not result in a change for the current association. Currently,
> * only the %NL80211_ATTR_IE data is used and updated with this command.
> *
> + * @NL80211_CMD_SET_PMK: For offloaded 4-Way handshake, set the PMK or PMK-R0
> + * for the given authenticator address (specified with &NL80211_ATTR_MAC).
> + * When &NL80211_ATTR_PMKR0_NAME is set, &NL80211_ATTR_PMK specifies the
> + * PMK-R0, otherwise it specifies the PMK.
> + * @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the previously
> + * configured PMK for the authenticator address identified by
> + * &NL80211_ATTR_MAC.
Maybe better to indicate it is for 802.1X. Here also preference for
NL80211_CMD_CLR_PMK.
> + *
> * @NL80211_CMD_MAX: highest used command number
> * @__NL80211_CMD_AFTER_LAST: internal use
> */
> @@ -1100,6 +1108,9 @@ enum nl80211_commands {
>
> NL80211_CMD_UPDATE_CONNECT_PARAMS,
>
> + NL80211_CMD_SET_PMK,
> + NL80211_CMD_DEL_PMK,
> +
> /* add new commands above here */
>
> /* used to define NL80211_CMD_MAX below */
> @@ -2012,8 +2023,12 @@ enum nl80211_commands {
> * u32 attribute with an &enum nl80211_timeout_reason value. This is used,
> * e.g., with %NL80211_CMD_CONNECT event.
> *
> - * @NL80211_ATTR_PMK: PSK for offloaded 4-Way Handshake. Relevant only
> - * with %NL80211_CMD_CONNECT (for WPA/WPA2-PSK networks).
> + * @NL80211_ATTR_PMK: PMK for offloaded 4-Way Handshake. Relevant with
> + * %NL80211_CMD_CONNECT (for WPA/WPA2-PSK networks) when PSK is used, or
> + * with %NL80211_CMD_SET_PMK when 802.1X authentication is used.
> + * When &NL80211_ATTR_PMKR0_NAME is specified, this attribute specifies
> + * the PMK-R0.
> + * @NL80211_ATTR_PMKR0_NAME: PMK-R0 Name for offloaded FT.
> *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> @@ -2427,6 +2442,7 @@ enum nl80211_attrs {
> NL80211_ATTR_TIMEOUT_REASON,
>
> NL80211_ATTR_PMK,
> + NL80211_ATTR_PMKR0_NAME,
>
> /* add attributes here, update the policy in nl80211.c */
>
> @@ -4767,6 +4783,9 @@ enum nl80211_feature_flags {
> * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK: Device supports doing 4-way
> * handshake with PSK in station mode (PSK is passed as part of the connect
> * and associate commands).
> + * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X: Device supports doing 4-way
> + * handshake with 802.1X in station mode (needs to pass EAP frames to
> + * the host and accept the set_pmk/del_pmk commands).
> *
> * @NUM_NL80211_EXT_FEATURES: number of extended features.
> * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
> @@ -4787,6 +4806,7 @@ enum nl80211_ext_feature_index {
> NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI,
> NL80211_EXT_FEATURE_CQM_RSSI_LIST,
> NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK,
> + NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X,
So do we need this flag. Is the fact that the driver implements the
set_pmk and del_pmk (or clr_pmk) callbacks not sufficient provided they
are listed in the "supported commands" message of wiphy dump (not in
this patch). Which reminds me, is "supported commands" no longer
preferred because that list does not seem complete?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-02-24 6:36 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-1-git-send-email-greearb@candelatech.com>
> + msg_head = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0,
> + HWSIM_CMD_NOTIFY);
I think you should use a more specific command name.
> + 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
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Johannes Berg @ 2017-02-24 6:43 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-7-git-send-email-greearb@candelatech.com>
And here's the third patch in a row modifying the same code ...
johannes
^ permalink raw reply
* Re: [PATCH 161/306] mac80211-hwsim: Improve logging.
From: Johannes Berg @ 2017-02-24 6:42 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-6-git-send-email-greearb@candelatech.com>
> + 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.
johannes
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer
From: Julia Lawall @ 2017-02-24 6:40 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <da73d1aef379243ba94a5c1a4e1d6663160451fd.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> Rename struct tstrRSSI to rssi_history_buffer for clarity and to remove camel casing.
Here the commit log messge line is definitely too long.
julia
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/da73d1aef379243ba94a5c1a4e1d6663160451fd.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool
From: Julia Lawall @ 2017-02-24 6:40 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <e4e0e4da09635d0cb7ef43223022490b6de739a8.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> 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.
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Maybe the second line of the commit message is a little too long. It is
under 80 characters, but they come out a bit indented in the git log, so a
little shorter is better.
julia
>
> Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
> ---
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/e4e0e4da09635d0cb7ef43223022490b6de739a8.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink
From: Johannes Berg @ 2017-02-24 6:39 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-5-git-send-email-greearb@candelatech.com>
> + !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.
johannes
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history
From: Julia Lawall @ 2017-02-24 6:39 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <6fd3f34baa31c00a77e2805d5d8a820b3ac7a43f.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> 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>
Good job at cutting up the patch in a meaningful way.
julia
> ---
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/6fd3f34baa31c00a77e2805d5d8a820b3ac7a43f.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH 102/306] mac80211-hwsim: enable better rx-status when using netlink.
From: Johannes Berg @ 2017-02-24 6:38 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-4-git-send-email-greearb@candelatech.com>
> +/**
> + * This relates to the ieee80211_rx_status struct in mac80211.h
> + * @rx_flags: %RX_FLAG_* (see mac80211_rx_flags)
> + * @vht_flags: %RX_VHT_FLAG_*
> + * @vht_nss: number of streams (VHT only)
> + * @ampdu_reference: A-MPDU reference number, must be a different
> value for
> + * each A-MPDU but the same for each subframe within one A-
> MPDU
> + */
> +struct hwsim_rx_info {
> + u32 rx_flags;
> + u8 vht_flags;
> + u8 vht_nss;
> + u16 unused_pad; /* pad to 32-bits, and space for growth */
> + u32 ampdu_reference;
> +} __packed;
Same as in the previous patch.
johannes
^ 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