* Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Johannes Berg @ 2017-02-27 13:30 UTC (permalink / raw)
To: agreen, linux-wireless; +Cc: Jesse Jones
In-Reply-To: <58B09082.7020704@cococorp.com>
On Fri, 2017-02-24 at 11:58 -0800, Alexis Green wrote:
> 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.
It's not clear to me what you mean by "collision"? Over the air the NAV
should handle the avoidance thereof, so I don't really see what this
does wrt. collisions?
Are these frames somehow duplicates? But I don't see any suppression if
you've already put a frame on the "jittered" list then it will never be
deleted from it again, so it doesn't suppress anything in that sense?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Print text for disassociation reason
From: Johannes Berg @ 2017-02-27 13:16 UTC (permalink / raw)
To: Arkadiusz Miśkiewicz; +Cc: linux-wireless, Arkadiusz Miśkiewicz
In-Reply-To: <20170215132127.17177-1-arekm@maven.pl>
On Wed, 2017-02-15 at 14:21 +0100, Arkadiusz Miśkiewicz wrote:
> When disassociation happens only numeric reason is printed
> in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix mesh fail_avg check
From: Johannes Berg @ 2017-02-27 13:16 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1487191610-20948-1-git-send-email-rmanohar@qca.qualcomm.com>
On Wed, 2017-02-15 at 12:46 -0800, Rajkumar Manoharan wrote:
> Mesh failure average never be more than 100. Only in case of
> fixed path, average will be more than threshold limit (95%).
> With recent EWMA changes it may go upto 99 as it is scaled to
> 100. It make sense to return maximum metric when average is
> greater than threshold limit.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-02-27 14:34 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <e7500b9a-5020-0dcc-5d67-4a2d12704c33@candelatech.com>
On Fri, 2017-02-24 at 07:39 -0800, Ben Greear wrote:
>
> 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' ?
We won't run out of command IDs any time soon, so I don't really see a
problem with using a new one for all of those things if needed.
But having a general NOTIFY just means that the application will have
to parse the attributes and understand what means what - that seems
like a case of the cure being worse than the disease?
johannes
^ permalink raw reply
* Re: BUG_ON in sg code
From: Ard Biesheuvel @ 2017-02-27 15:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1488207986.28431.17.camel@sipsolutions.net>
On 27 February 2017 at 15:06, Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi Ard,
>
> Apologies for the non-follow-up - couldn't find the original patch.
>
> Your patch "crypto: ccm - switch to separate cbcmac driver" causes a
> BUG_ON when virtual stacks are used, in crypto_ccm_auth() is called,
> because you put odata/idata on the stack. What's going on there? I
> thought we knew we can't do that? Did I miss something?
>
It was I who missed something, obviously.
I will send out a fix asap
^ permalink raw reply
* Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name
From: Andrew Zaborowski @ 2017-02-27 15:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1488201862.28431.5.camel@sipsolutions.net>
Hi,
On 27 February 2017 at 14:24, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
>> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
>> emitted contain the name string and are exactly of the right length
>> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
>> assumed to be NUL-terminated.
>
> I'll agree this is a bit strange - I guess it's too late to fix now
> though since userspace might assume "length/data" is the string, rather
> than "0-terminated" (especially if there's something like python
> userspace where strings can trivially contain NUL bytes).
>
> nla_put_string() would have added the NUL byte.
>
>> Is there a guarantee that a 0-byte
>> follows an attribute, or should this be changed for consistency?
>
> [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
>
> enforces that a NUL byte *must* be present when userspace gives us the
> information, so we're save - just asymmetric.
It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
optional, I know because I didn't add the NUL in my userspace and
things still worked. We can copy the received nla_data into a buffer
and add the 0-byte there to support this as an option. I don't have a
problem with the asymmetric usage though.
>
> Anyway, patch applied.
Thanks
Best regards
^ permalink raw reply
* Re: [PATCH 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain
From: Johannes Berg @ 2017-02-27 14:38 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1487587155-30487-2-git-send-email-vthiagar@qti.qualcomm.com>
On Mon, 2017-02-20 at 16:09 +0530, Vasanthakumar Thiagarajan wrote:
> DFS requirement for ETSI domain (section 4.7.1.4 in
> ETSI EN 301 893 V1.8.1) is the only one which explicitly
> states that once DFS channel is marked as available afer
> the CAC, this channel will remain in available state even
> moving to a different operating channel. But the same is
> not explicitly stated in FCC DFS requirement. Also, Pre-CAC
> requriements are not explicitly mentioned in FCC requirement.
> Current implementation in keeping DFS channel in available
> state is same as described in ETSI domain.
>
> For ETSI DFS domain, this patch gives a grace period of 2 seconds
You mean non-ETSI, right?
Just making sure I understood correctly - no need to resend, I can fix
that.
johannes
^ permalink raw reply
* BUG_ON in sg code
From: Johannes Berg @ 2017-02-27 15:06 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless
Hi Ard,
Apologies for the non-follow-up - couldn't find the original patch.
Your patch "crypto: ccm - switch to separate cbcmac driver" causes a
BUG_ON when virtual stacks are used, in crypto_ccm_auth() is called,
because you put odata/idata on the stack. What's going on there? I
thought we knew we can't do that? Did I miss something?
johannes
^ permalink raw reply
* Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink
From: Johannes Berg @ 2017-02-27 14:33 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <c014eb8c-7f93-3831-3375-07f6f6325a6a@candelatech.com>
On Fri, 2017-02-24 at 07:27 -0800, Ben Greear wrote:
>
> 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?
You can use include/linux/ratelimit.h to do that?
johannes
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Andrew Zaborowski @ 2017-02-27 15:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1488202062.28431.7.camel@sipsolutions.net>
Hi,
On 27 February 2017 at 14:27, Johannes Berg <johannes@sipsolutions.net> wrote:
>> Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy
>> index directly without users going through wiphy name to index
>> mapping, but get_wiphy_idx() is internal to cfg80211. The index is
>> exposed to userspace and is more useful than the name so I wonder if
>> this function should be exported from cfg80211.
>
> Do you really need the address?
As it turns out it can be read from /sys, but I do need it so I can
know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
addr in the frame or if I want to forward the frame to all radios. Or
is there another way to know that?
>
> I'd actually prefer to *only* have the wiphy index, and I don't really
> see a problem with moving the wiphy_idx from struct
> cfg80211_registered_device to struct wiphy.
Ok, I'll try that. get_wiphy_idx can stay in place, not sure if I
should just drop it.
By having *only* the wiphy index you don't mean dropping the radio
names altogether? The don't seem useful but userspace may expect
them.
Best regards
^ permalink raw reply
* Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name
From: Johannes Berg @ 2017-02-27 16:08 UTC (permalink / raw)
To: Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <CAOq732L0wT+HMouihfSYu4hwxy=fh6pieMY3r2DOO1tVXxqw1A@mail.gmail.com>
> > [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },
> >
> > enforces that a NUL byte *must* be present when userspace gives us
> > the
> > information, so we're save - just asymmetric.
>
> It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
> optional,
Oops. I indeed misread the code there.
> I know because I didn't add the NUL in my userspace and
> things still worked.
:)
Then you probably had some 0 padding or so.
> We can copy the received nla_data into a buffer
> and add the 0-byte there to support this as an option.
I'll do that.
johannes
^ permalink raw reply
* [PATCH] mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
From: Johannes Berg @ 2017-02-27 16:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Andrew Zaborowski, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME
as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a
NUL-terminated string in the kernel.
Rather than break the API, kasprintf() the string to a new buffer to
guarantee NUL termination.
Reported-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 0889fc81ce9e..50c219fb1a52 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3056,6 +3056,7 @@ static int hwsim_register_received_nl(struct sk_buff *skb_2,
static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
{
struct hwsim_new_radio_params param = { 0 };
+ const char *hwname = NULL;
param.reg_strict = info->attrs[HWSIM_ATTR_REG_STRICT_REG];
param.p2p_device = info->attrs[HWSIM_ATTR_SUPPORT_P2P_DEVICE];
@@ -3069,8 +3070,14 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
if (info->attrs[HWSIM_ATTR_NO_VIF])
param.no_vif = true;
- if (info->attrs[HWSIM_ATTR_RADIO_NAME])
- param.hwname = nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]);
+ if (info->attrs[HWSIM_ATTR_RADIO_NAME]) {
+ hwname = kasprintf(GFP_KERNEL, "%.*s",
+ nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ (char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]));
+ if (!hwname)
+ return -ENOMEM;
+ param.hwname = hwname;
+ }
if (info->attrs[HWSIM_ATTR_USE_CHANCTX])
param.use_chanctx = true;
@@ -3098,11 +3105,15 @@ static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
s64 idx = -1;
const char *hwname = NULL;
- if (info->attrs[HWSIM_ATTR_RADIO_ID])
+ if (info->attrs[HWSIM_ATTR_RADIO_ID]) {
idx = nla_get_u32(info->attrs[HWSIM_ATTR_RADIO_ID]);
- else if (info->attrs[HWSIM_ATTR_RADIO_NAME])
- hwname = (void *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]);
- else
+ } else if (info->attrs[HWSIM_ATTR_RADIO_NAME]) {
+ hwname = kasprintf(GFP_KERNEL, "%.*s",
+ nla_len(info->attrs[HWSIM_ATTR_RADIO_NAME]),
+ (char *)nla_data(info->attrs[HWSIM_ATTR_RADIO_NAME]));
+ if (!hwname)
+ return -ENOMEM;
+ } else
return -EINVAL;
spin_lock_bh(&hwsim_radio_lock);
@@ -3111,7 +3122,8 @@ static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
if (data->idx != idx)
continue;
} else {
- if (strcmp(hwname, wiphy_name(data->hw->wiphy)))
+ if (!hwname ||
+ strcmp(hwname, wiphy_name(data->hw->wiphy)))
continue;
}
@@ -3122,10 +3134,12 @@ static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
spin_unlock_bh(&hwsim_radio_lock);
mac80211_hwsim_del_radio(data, wiphy_name(data->hw->wiphy),
info);
+ kfree(hwname);
return 0;
}
spin_unlock_bh(&hwsim_radio_lock);
+ kfree(hwname);
return -ENODEV;
}
--
2.11.0
^ permalink raw reply related
* Re: BUG_ON in sg code
From: Johannes Berg @ 2017-02-27 16:06 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless
In-Reply-To: <CAKv+Gu8zSARqLY6-_XRQAC2tY0DWuYpARG0deUGLsu3qoa2AVw@mail.gmail.com>
On Mon, 2017-02-27 at 15:10 +0000, Ard Biesheuvel wrote:
>
> > because you put odata/idata on the stack. What's going on there? I
> > thought we knew we can't do that? Did I miss something?
> >
>
> It was I who missed something, obviously.
Ok. I thought maybe I missed a plan to actually make it allowed or
something :)
Thanks!
johannes
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-27 17:02 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <9c8e71d8-c6af-1d2b-3d91-ac791bc33327@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 13:15 +0100, Arend Van Spriel wrote:
> 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.
I loaded the brcmfmac driver with the debug setting and started wpa_cli
wps_pbc while the device operates in AP mode.
This is the log after running the command:
"""
kern.err kernel: [ 73.277473] brcmfmac: brcmf_vif_set_mgmt_ie: vndr
ie set error : -30
kern.err kernel: [ 73.284647] brcmfmac: brcmf_config_ap_mgmt_ie: Set
Beacon IE Failed
daemon.err wpa_supplicant[176]: Failed to set beacon parameters
daemon.notice wpa_supplicant[176]: wlan0: WPS-PBC-ACTIVE
kern.debug kernel: [ 73.298749] brcmfmac: CONSOLE:
user.notice ACTION_WPA: WPS-PBC-ACTIVE
daemon.notice wpa_supplicant[176]: wlan0: WPS-TIMEOUT
daemon.err wpa_supplicant[176]: Failed to set beacon parameters
kern.err kernel: [ 193.319897] brcmfmac: brcmf_vif_set_mgmt_ie: vndr
ie set error : -30
kern.err kernel: [ 193.333464] brcmfmac: brcmf_config_ap_mgmt_ie: Set
Beacon IE Failed
kern.debug kernel: [ 193.347876] brcmfmac: CONSOLE: wl0: wlc_del_ie:
IE not in list
user.notice ACTION_WPA: WPS-TIMEOUT
"""
Note, that the first brcmfmac CONSOLE message is empty, whereas the
second one is "wl0: wlc_del_ie: IE not in list".
Best regards,
Jörg Krause
^ permalink raw reply
* [PATCH] ath9k: don't trigger spectral scan when not enabled
From: Zefir Kurtisi @ 2017-02-27 14:49 UTC (permalink / raw)
To: linux-wireless
Doing so enables the FFT generation without prior
configuration, leading to an IRQ storm caused by
invalid (or at least unwanted) PHY errors.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 58f1ed1..51b618c 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -739,6 +739,9 @@ void ath9k_cmn_spectral_scan_trigger(struct ath_common *common,
return;
}
+ if (!spec_priv->spec_config.enabled)
+ return;
+
ath_ps_ops(common)->wakeup(common);
rxfilter = ath9k_hw_getrxfilter(ah);
ath9k_hw_setrxfilter(ah, rxfilter |
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Ben Greear @ 2017-02-27 17:10 UTC (permalink / raw)
To: Andrew Zaborowski, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <CAOq732JzrGxFUa5BiuO=Sz7gscRV7PFxOOyy1xf6mtmQfUqkaA@mail.gmail.com>
On 02/27/2017 07:26 AM, Andrew Zaborowski wrote:
> Hi,
>
> On 27 February 2017 at 14:27, Johannes Berg <johannes@sipsolutions.net> wrote:
>>> Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy
>>> index directly without users going through wiphy name to index
>>> mapping, but get_wiphy_idx() is internal to cfg80211. The index is
>>> exposed to userspace and is more useful than the name so I wonder if
>>> this function should be exported from cfg80211.
>>
>> Do you really need the address?
>
> As it turns out it can be read from /sys, but I do need it so I can
> know what to put in HWSIM_ATTR_ADDR_RECEIVER based on the destination
> addr in the frame or if I want to forward the frame to all radios. Or
> is there another way to know that?
>
>>
>> I'd actually prefer to *only* have the wiphy index, and I don't really
>> see a problem with moving the wiphy_idx from struct
>> cfg80211_registered_device to struct wiphy.
>
> Ok, I'll try that. get_wiphy_idx can stay in place, not sure if I
> should just drop it.
>
> By having *only* the wiphy index you don't mean dropping the radio
> names altogether? The don't seem useful but userspace may expect
> them.
I find the name and addr more useful than an 'index', because if you remove/add
a virtual phy, then the index will probably change, even if name and MAC addr may stay
the same (and so probably be the same logical entitity).
Since phys can be renamed, you cannot assume that the phy will be called
phyX where X is the device-id.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 4.12] brcmfmac: move brcmf_txcomplete function to fwsignal.c
From: kbuild test robot @ 2017-02-27 18:04 UTC (permalink / raw)
To: Rafał Miłecki
Cc: kbuild-all, Kalle Valo, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170227124251.30338-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
Hi Rafał,
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on next-20170227]
[cannot apply to v4.10]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-move-brcmf_txcomplete-function-to-fwsignal-c/20170228-004934
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: In function 'brcmf_sdio_txpkt':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2268:3: error: implicit declaration of function 'brcmf_fws_txcomplete' [-Werror=implicit-function-declaration]
brcmf_fws_txcomplete(bus->sdiodev->dev, pkt_next, ret == 0);
^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_tx_complete':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:485:2: error: implicit declaration of function 'brcmf_fws_txcomplete' [-Werror=implicit-function-declaration]
brcmf_fws_txcomplete(devinfo->dev, req->skb, urb->status == 0);
^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/brcmf_fws_txcomplete +2268 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
2262 done:
2263 brcmf_sdio_txpkt_postp(bus, pktq);
2264 if (ret == 0)
2265 bus->tx_seq = (bus->tx_seq + pktq->qlen) % SDPCM_SEQ_WRAP;
2266 skb_queue_walk_safe(pktq, pkt_next, tmp) {
2267 __skb_unlink(pkt_next, pktq);
> 2268 brcmf_fws_txcomplete(bus->sdiodev->dev, pkt_next, ret == 0);
2269 }
2270 return ret;
2271 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57963 bytes --]
^ permalink raw reply
* Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Alexis Green @ 2017-02-27 20:10 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Jesse Jones
In-Reply-To: <1488202227.28431.9.camel@sipsolutions.net>
Hi Johannes,
This is loosely based on RFC5148, specifically event-triggered message generation as described in section 5.2.
The frames are not duplicated, but, hopefully offset enough so they don't collide at the receiver (and, since, these are management frames, there is no retransmission and we may lose the information contained in them). If the two (or more) devices that reply are synchronized well enough, carrier sense will tell them that air is clear and messages will go out at the same time. It doesn't happen too often, but we found it noticeable enough in our testing.
Best regards,
Alexis Green
On 2/27/2017 5:30 AM, Johannes Berg wrote:
> On Fri, 2017-02-24 at 11:58 -0800, Alexis Green wrote:
>> From: Jesse Jones <jjones@uniumwifi.com>
>>
>> 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.
>
> It's not clear to me what you mean by "collision"? Over the air the NAV
> should handle the avoidance thereof, so I don't really see what this
> does wrt. collisions?
>
> Are these frames somehow duplicates? But I don't see any suppression if
> you've already put a frame on the "jittered" list then it will never be
> deleted from it again, so it doesn't suppress anything in that sense?
>
> johannes
>
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Ben Greear @ 2017-02-27 20:48 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.
>
>> + 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
You want chandef.center_freq1,
chandef.center_freq2,
chandef.width?
Anything else?
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-27 21:00 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.
>
>> + 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.
Looks like there are two conventions used (see HWSIM_CMD_TX_INFO_FRAME,
and HWSIM_CMD_NEW_RADIO). I guess you want it indented like the NEW_RADIO
command?
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3/3] ath9k: ahb: Add OF support
From: Rafał Miłecki @ 2017-02-27 21:13 UTC (permalink / raw)
To: Alban
Cc: Linux Kernel Mailing List, Boris Brezillon, Richard Weinberger,
Marek Vasut, linux-mtd@lists.infradead.org, Greg Kroah-Hartman,
Cyrille Pitchen, Brian Norris, David Woodhouse,
linux-wireless@vger.kernel.org
In-Reply-To: <1488227292-18906-4-git-send-email-albeu@free.fr>
Why you didn't cc linux-wireless?!?!
On 27 February 2017 at 21:28, Alban <albeu@free.fr> wrote:
> @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> release_firmware(sc->sc_ah->eeprom_blob);
> }
>
> +#ifdef CONFIG_OF
> +static int ath9k_init_of(struct ath_softc *sc)
> +{
> + struct device_node *np = sc->dev->of_node;
> + struct ath_hw *ah = sc->sc_ah;
> + const void *macaddr;
> + struct clk *clk;
> + int ret = 0;
> +
> + if (!np) {
> + dev_err(sc->dev, "no platform data or OF node\n");
> + return -EINVAL;
> + }
> +
> + clk = clk_get(sc->dev, "ref");
> + if (!IS_ERR(clk)) {
> + ah->is_clk_25mhz = (clk_get_rate(clk) == 25000000);
> + clk_put(clk);
> + }
> +
> + ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> + ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
Please use ieee80211-freq-limit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896
Most likely with the wiphy_read_of_freq_limits helper:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17
Example:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b
^ permalink raw reply
* [PATCH v2 2/4] brcmfmac: p2p and normal ap access are not always possible at the same time
From: Hans de Goede @ 2017-02-27 21:45 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo
Cc: Hans de Goede, Takashi Iwai, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <20170227214539.16422-1-hdegoede@redhat.com>
The firmware responding with -EBUSY when trying to add an extra virtual-if
is a normal thing, do not print an error for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 14 ++++++++++----
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 5 ++++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..c54e8b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -688,11 +688,17 @@ static struct wireless_dev *brcmf_cfg80211_add_iface(struct wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
- if (IS_ERR(wdev))
- brcmf_err("add iface %s type %d failed: err=%d\n",
- name, type, (int)PTR_ERR(wdev));
- else
+ if (IS_ERR(wdev)) {
+ err = PTR_ERR(wdev);
+ if (err != -EBUSY)
+ brcmf_err("add iface %s type %d failed: err=%d\n",
+ name, type, err);
+ else
+ brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+ name, type, err);
+ } else {
brcmf_cfg80211_update_proto_addr_mode(wdev);
+ }
return wdev;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index de19c7c..b5df0a0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev *brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
/* Initialize P2P Discovery in the firmware */
err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
if (err < 0) {
- brcmf_err("set p2p_disc error\n");
+ if (err != -EBUSY)
+ brcmf_err("set p2p_disc error\n");
+ else
+ brcmf_dbg(INFO, "set p2p_disc error\n");
brcmf_fweh_p2pdev_setup(pri_ifp, false);
brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
goto fail;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/4] brcmfmac: Do not complain about country code "00"
From: Hans de Goede @ 2017-02-27 21:45 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo
Cc: Hans de Goede, Takashi Iwai, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <20170227214539.16422-1-hdegoede@redhat.com>
The country code gets set to "00" by default at boot, ignore this
rather then logging an error about it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index c54e8b4..c0b7f69 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6705,6 +6705,10 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy *wiphy,
s32 err;
int i;
+ /* The country code gets set to "00" by default at boot, ignore */
+ if (req->alpha2[0] == '0' && req->alpha2[1] == '0')
+ return;
+
/* ignore non-ISO3166 country codes */
for (i = 0; i < sizeof(req->alpha2); i++)
if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/4] brcmfmac: Do not print the firmware version as an error
From: Hans de Goede @ 2017-02-27 21:45 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo
Cc: Hans de Goede, Takashi Iwai, linux-wireless,
brcm80211-dev-list.pdl
Using pr_err for things which are not errors is a bad idea. E.g. it
will cause the plymouth bootsplash screen to drop back to the text
console so that the user can see the error, which is not what we
normally want to happen.
Instead add a new brcmf_info macro and use that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Fix brcm_err typo (should be brcmf_err) in CONFIG_BRCM_TRACING case
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 3e15d64..6d565f1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -161,7 +161,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
strsep(&ptr, "\n");
/* Print fw version info */
- brcmf_err("Firmware version = %s\n", buf);
+ brcmf_info("Firmware version = %s\n", buf);
/* locate firmware version number for ethtool */
ptr = strrchr(buf, ' ') + 1;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 6687812..605f260 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -59,11 +59,14 @@
pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
} while (0)
#endif
+#define brcmf_info(fmt, ...) pr_info("%s: " fmt, __func__, ##__VA_ARGS__)
#else
__printf(2, 3)
void __brcmf_err(const char *func, const char *fmt, ...);
#define brcmf_err(fmt, ...) \
__brcmf_err(__func__, fmt, ##__VA_ARGS__)
+/* For tracing purposes treat info messages as errors */
+#define brcmf_info brcmf_err
#endif
#if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 3/3] ath9k: ahb: Add OF support
From: Alban @ 2017-02-27 22:48 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Aban Bedel, Linux Kernel Mailing List, Boris Brezillon,
Richard Weinberger, Marek Vasut, linux-mtd@lists.infradead.org,
Greg Kroah-Hartman, Cyrille Pitchen, Brian Norris,
David Woodhouse, linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rzZ-UiJR8oBJ9oHE+ZNT=nm6oLiKyW4bsiZ34TMRDh5Xw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]
On Mon, 27 Feb 2017 22:13:21 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> Why you didn't cc linux-wireless?!?!
I first wanted to be sure that the devdata part was generally
acceptable, this patch was just included as an example of a user.
But it sound like that part will have to move to nvmem first.
I'll come back with a new patch once MTD support for nvmem is
done.
> On 27 February 2017 at 21:28, Alban <albeu@free.fr> wrote:
> > @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> > release_firmware(sc->sc_ah->eeprom_blob);
> > }
> >
> > +#ifdef CONFIG_OF
> > +static int ath9k_init_of(struct ath_softc *sc)
> > +{
> > + struct device_node *np = sc->dev->of_node;
> > + struct ath_hw *ah = sc->sc_ah;
> > + const void *macaddr;
> > + struct clk *clk;
> > + int ret = 0;
> > +
> > + if (!np) {
> > + dev_err(sc->dev, "no platform data or OF node\n");
> > + return -EINVAL;
> > + }
> > +
> > + clk = clk_get(sc->dev, "ref");
> > + if (!IS_ERR(clk)) {
> > + ah->is_clk_25mhz = (clk_get_rate(clk) == 25000000);
> > + clk_put(clk);
> > + }
> > +
> > + ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> > + ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
>
> Please use ieee80211-freq-limit:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896
>
> Most likely with the wiphy_read_of_freq_limits helper:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17
>
> Example:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b
Thanks, I'll check this.
Alban
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox