* Re: [PATCHv2 1/4] cfg80211: Add support to enable or disable btcoex
From: Johannes Berg @ 2017-03-02 8:45 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-2-git-send-email-c_traja@qti.qualcomm.com>
You need to fix the build-bot warning, it's legitimate (though hard to
spot):
> + TP_printk(WIPHY_PR_FMT, ", enabled=%d",
> + WIPHY_PR_ARG, __entry->enabled)
> +);
You have a stray comma there after WIPHY_PR_FMT.
johannes
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 8:51 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-4-git-send-email-c_traja@qti.qualcomm.com>
This patch will also (and correctly so) cause compilation warnings in
mac80211, so you really should have just two patches.
johannes
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 8:50 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-4-git-send-email-c_traja@qti.qualcomm.com>
Is there much point in having 4 rather than just 2 patches?
> + int (*set_btcoex)(struct wiphy *wiphy, bool enabled,
> + int btcoex_priority);
Shouldn't that be u32 as a bitmap?
> + bool btcoex_priority_support;
Why not use an extended nl80211 feature flag directly?
> + * @NL80211_ATTR_BTCOEX_PRIORITY: This is for the driver which
> + * support btcoex priority feature. It used with
> %NL80211_CMD_SET_BTCOEX.
> + * This will have u32 BITMAP value which represents
> + * frame(bk, be, vi, vo, mgmt, beacon) type and that will have
> more
> + * priority than a BT traffic.
I think you need to define the bits somewhere in an enum - i.e. which
one is VO, VI, ...
> + int btcoex_priority = -1;
That -1 is pretty useless, if the driver doesn't support it, hopefully
it won't look at the value at all?
johannes
^ permalink raw reply
* Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X
From: Johannes Berg @ 2017-03-02 8:59 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless; +Cc: Avraham Stern
In-Reply-To: <177c53b2-cd5f-97a9-26b0-b590071785cb@broadcom.com>
> > + int (*del_pmk)(struct wiphy *wiphy, struct
> > net_device *dev,
> > + const u8 *aa);
>
> Minor nit, but prefer clr_pmk to clear the pmk.
Why? You don't have "the PMK" that you can clear, you have "a PMK" (for
the network) and after deleting it you don't have it anymore. You don't
have a "cleared PMK" afterwards, you just don't have any. I think the
delete makes more sense?
> > + * @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.
I guess that makes sense.
> > + 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?
It's complicated... We've kinda naturally gravitated towards extended
feature flags because they're so easy to handle now (only need to
define the bit) - and with mac80211 in the picture, relying on the
handlers only often didn't work, so it requires extra code in the CMD()
advertising - and anyway it already requires extra code there unlike
the feature flags...
So overall - while this isn't stated policy (yet?) - I think we prefer
the feature bits.
johannes
^ permalink raw reply
* Re: [v4] ath10k: search SMBIOS for OEM board file extension
From: Kalle Valo @ 2017-03-02 8:53 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-wireless, kvalo, jouni, Waldemar Rymarkiewicz
In-Reply-To: <20170224223003.32156-1-ext.waldemar.rymarkiewicz@tieto.com>
Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> wrote:
> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
> board data file is identified, among others, by device and sybsystem ids.
>
> The problem, however, can occur when the (default) board data file cannot
> fulfill with the vendor requirements and it is necessary to use a different
> board data file.
>
> To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
> Extension to specify the extension/variant name. The driver will take the
> extension suffix into consideration and will load the right (non-default)
> board data file if necessary.
>
> If it is unnecessary to use extension board data file, please leave the
> SMBIOS field blank and default configuration will be used.
>
> Example:
> If a default board data file for a specific board is identified by a string
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310"
> then the OEM specific data file, if used, could be identified by variant
> suffix:
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310,variant=DE_1AB"
>
> If board data file name extension is set but board-2.bin does not contain
> board data file for the variant, the driver will fallback to the default
> board data file not to break backward compatibility.
>
> This was first applied in commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM
> board file extension") but later reverted in commit 005c3490e9db ("Revert
> "ath10k: Search SMBIOS for OEM board file extension"") due to a regression.
> This patch is now otherwise the same as commit f2593cb1b291 except the
> regression fixed.
>
> Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Patch applied to wireless-drivers.git, thanks.
1657b8f84ed9 ath10k: search SMBIOS for OEM board file extension
--
https://patchwork.kernel.org/patch/9591335/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Johannes Berg @ 2017-03-02 8:23 UTC (permalink / raw)
To: Benjamin Beichler, Ben Greear, Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <60000eb2-f404-aab7-5493-9b952adb1dde@uni-rostock.de>
On Wed, 2017-03-01 at 18:04 +0100, Benjamin Beichler wrote:
> Am 01.03.2017 um 16:35 schrieb Ben Greear:
> > That is actually not possible. The permanent MAC-Addresses of hwsim
> >
> > > radios are directly created by there internal ID, which is only
> > > increased for new radios and definitely not reassigned.
> > >
> > > But I would be happy, if this were possible, since it would make
> > > some
> > > simulation related stuff easier (currently we need to unload and
> > > load
> > > the hwsim module over and over again for every run).
> >
> > Ahh, you are right. But you can specify the wiphy name, and then
> > you
> > can use that to query the debugfs to find the MAC addr, and then
> > sync
> > your user-space with that info.
> >
> > It should also be easy enough to specify the MAC address when
> > creating
> > the radio.
> >
> > And, you should be able to create virtual STA, AP, etc, with any
> > specified
> > MAC address, so the MAC of the radio really should not matter much?
> >
>
> That is another problem ... this won't work currently, since the
> frame
> delivery compares the receiver address with the permanent MAC
> addresses
> of all hwsim phys. I work as an idle task on patch, which makes this
> lookup (currently implemented as linear search) as a hashmap mapping
> an
> MAC to a wiphy struct , including scenarios with differing MAC
> addresses
> of vifs.
That's probably something we really ought to fix :)
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Johannes Berg @ 2017-03-02 8:36 UTC (permalink / raw)
To: agreen, linux-wireless; +Cc: Jesse Jones
In-Reply-To: <58B487A8.7000602@cococorp.com>
Hi Alexis,
> This is loosely based on RFC5148, specifically event-triggered
> message generation as described in section 5.2.
I'm confused. I see how that generally seems to apply to any mobile
network, but it *does* state up-front that
In some instances, these problems can be solved in these lower
layers, but in other instances, some help at the network and higher
layers is necessary.
I believe 802.11 *does* in fact solve these issues at lower layers.
Can you explain how you observed any problem in this area?
> The frames are not duplicated, but, hopefully offset enough so they
> don't collide at the receiver
That wasn't my question - my question regarding duplicating was if this
was intended to *suppress* duplicates, but it sounds like not.
> (and, since, these are management frames, there is no retransmission
> and we may lose the information contained in them).
That statement isn't true in general, though it does seem that some of
the frames you're touching are actually *multicast* frames and as such
don't have any retries.
> 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.
I'm still curious how it happens at all, since NAV synchronisation
should prevent it at a much lower level?
johannes
^ permalink raw reply
* [PATCH] mac80211_hwsim: fix command documentation indentation
From: Johannes Berg @ 2017-03-02 8:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.h b/drivers/net/wireless/mac80211_hwsim.h
index 39f22467ca2a..3f5eda591dba 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -57,12 +57,12 @@ enum hwsim_tx_control_flags {
* @HWSIM_CMD_REGISTER: request to register and received all broadcasted
* frames by any mac80211_hwsim radio device.
* @HWSIM_CMD_FRAME: send/receive a broadcasted frame from/to kernel/user
- * space, uses:
+ * space, uses:
* %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_ADDR_RECEIVER,
* %HWSIM_ATTR_FRAME, %HWSIM_ATTR_FLAGS, %HWSIM_ATTR_RX_RATE,
* %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE, %HWSIM_ATTR_FREQ (optional)
* @HWSIM_CMD_TX_INFO_FRAME: Transmission info report from user space to
- * kernel, uses:
+ * kernel, uses:
* %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_FLAGS,
* %HWSIM_ATTR_TX_INFO, %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE
* @HWSIM_CMD_NEW_RADIO: create a new radio with the given parameters,
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-03-02 8:38 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <03ca5a0f-0ab0-76a4-06f3-ead61ab73c94@candelatech.com>
On Mon, 2017-02-27 at 12:48 -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.
> >
> > > + 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?
The control channel center_freq is already there so that should be the
full chandef. I guess center_freq2 should be conditional on being non-
zero.
johannes
^ permalink raw reply
* pull-request: wireless-drivers 2017-03-02
From: Kalle Valo @ 2017-03-02 9:15 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
only one patch this time, the new version of ath10k patch we reverted
earlier. I was supposed to send you this earlier but it got delayed
because I'm on vacation, so sorry about that. I'm hoping this is ok to
take also even the merge window is closed as the changes to the first
version of the patch are minimal.
Please let me know if there are any problems.
Kalle
The following changes since commit 8313064c2e75542201e557e2b496668811c2484a:
Merge tag 'nfsd-4.11' of git://linux-nfs.org/~bfields/linux (2017-02-28 15:39:09 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-03-02
for you to fetch changes up to 1657b8f84ed9fc1d2a100671f1d42d6286f20073:
ath10k: search SMBIOS for OEM board file extension (2017-03-02 10:48:41 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.11
Add back a fixed version of an ath10k patch which was reverted during
the merge window.
----------------------------------------------------------------
Waldemar Rymarkiewicz (1):
ath10k: search SMBIOS for OEM board file extension
drivers/net/wireless/ath/ath10k/core.c | 101 ++++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/core.h | 19 +++++++
2 files changed, 117 insertions(+), 3 deletions(-)
--
Kalle Valo
^ permalink raw reply
* Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X
From: Arend Van Spriel @ 2017-03-02 10:50 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Avraham Stern
In-Reply-To: <1488445144.8390.13.camel@sipsolutions.net>
On 2-3-2017 9:59, Johannes Berg wrote:
>
>>> + int (*del_pmk)(struct wiphy *wiphy, struct
>>> net_device *dev,
>>> + const u8 *aa);
>>
>> Minor nit, but prefer clr_pmk to clear the pmk.
>
> Why? You don't have "the PMK" that you can clear, you have "a PMK" (for
> the network) and after deleting it you don't have it anymore. You don't
> have a "cleared PMK" afterwards, you just don't have any. I think the
> delete makes more sense?
Ah. I just looked at set_pmk and felt its counter-part should therefor
be clr_pmk. Following your logic should it be add_pmk iso set_pmk?
>>> + 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?
>
> It's complicated... We've kinda naturally gravitated towards extended
> feature flags because they're so easy to handle now (only need to
> define the bit) - and with mac80211 in the picture, relying on the
> handlers only often didn't work, so it requires extra code in the CMD()
> advertising - and anyway it already requires extra code there unlike
> the feature flags...
>
> So overall - while this isn't stated policy (yet?) - I think we prefer
> the feature bits.
I see. Glad they worked out that way ;-)
Regards,
Arend
^ permalink raw reply
* pull-request: mac80211 2017-03-02
From: Johannes Berg @ 2017-03-02 10:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
As I mentioned in my other pull request, here's the change
for the average.h to make the precision easier to use.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 48cac18ecf1de82f76259a54402c3adb7839ad01:
ipv6: orphan skbs in reassembly unit (2017-03-01 20:55:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-03-02
for you to fetch changes up to eb1e011a14748a1d9df9a7d7df9a5711721a1bdb:
average: change to declare precision, not factor (2017-03-02 08:32:46 +0100)
----------------------------------------------------------------
This contains just the average.h change in order to get it
into the tree before adding new users through -next trees.
----------------------------------------------------------------
Johannes Berg (1):
average: change to declare precision, not factor
drivers/net/virtio_net.c | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 +-
include/linux/average.h | 61 +++++++++++++++++++----------
net/batman-adv/types.h | 2 +-
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/sta_info.h | 2 +-
7 files changed, 47 insertions(+), 26 deletions(-)
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Johannes Berg @ 2017-03-02 8:55 UTC (permalink / raw)
To: Oliver Freyermuth, linux-wireless
In-Reply-To: <6337fa40-adcc-b889-1842-16e0f316ea3e@googlemail.com>
> > 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!
[snip]
> 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?
Yes. Does it print something to that effect at resume time? I think it
should.
> At least, the suspend problem seems to be clearly related to some
> path only used if CONFIG_IWLWIFI_PCIE_RTPM is on.
Would you mind filing a bug on bugzilla.kernel.org (and adding linuxwif
i@intel.com as the assignee or at least in Cc)? I think we really ought
to sort out the issues with the RTPM stuff.
johannes
^ permalink raw reply
* RE: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Raja, Tamizh Chelvam @ 2017-03-02 11:48 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: ath10k@lists.infradead.org
In-Reply-To: <1488444659.8390.8.camel@sipsolutions.net>
PiBJcyB0aGVyZSBtdWNoIHBvaW50IGluIGhhdmluZyA0IHJhdGhlciB0aGFuIGp1c3QgMiBwYXRj
aGVzPw0KPg0KW1RhbWl6aF0gWWVzLCBJIGFncmVlIHRvIGl0LiANCj4gDQo+ID4gKwlpbnTCoMKg
wqDCoMKgKCpzZXRfYnRjb2V4KShzdHJ1Y3Qgd2lwaHkgKndpcGh5LCBib29sIGVuYWJsZWQsDQo+
ID4gKwkJCcKgwqDCoMKgwqDCoGludCBidGNvZXhfcHJpb3JpdHkpOw0KPiANCj4gU2hvdWxkbid0
IHRoYXQgYmUgdTMyIGFzIGEgYml0bWFwPw0KPiANCltUYW1pemhdIFllcy4NCg0KPiA+ICsJYm9v
bCBidGNvZXhfcHJpb3JpdHlfc3VwcG9ydDsNCj4gDQo+IFdoeSBub3QgdXNlIGFuIGV4dGVuZGVk
IG5sODAyMTEgZmVhdHVyZSBmbGFnIGRpcmVjdGx5Pw0KPiANCltUYW1pemhdIE9rIHN1cmUuIEkn
bGwgdXNlIGV4dGVuZGVkIG5sODAyMTEgZmVhdHVyZSBmbGFnLg0KDQo+ID4gKyAqIEBOTDgwMjEx
X0FUVFJfQlRDT0VYX1BSSU9SSVRZOiBUaGlzIGlzIGZvciB0aGUgZHJpdmVyIHdoaWNoDQo+ID4g
KyAqwqDCoMKgwqDCoHN1cHBvcnQgYnRjb2V4IHByaW9yaXR5IGZlYXR1cmUuIEl0IHVzZWQgd2l0
aA0KPiA+ICVOTDgwMjExX0NNRF9TRVRfQlRDT0VYLg0KPiA+ICsgKsKgwqDCoMKgwqBUaGlzIHdp
bGwgaGF2ZSB1MzIgQklUTUFQIHZhbHVlIHdoaWNoIHJlcHJlc2VudHMNCj4gPiArICrCoMKgwqDC
oMKgZnJhbWUoYmssIGJlLCB2aSwgdm8sIG1nbXQsIGJlYWNvbikgdHlwZSBhbmQgdGhhdCB3aWxs
IGhhdmUNCj4gPiBtb3JlDQo+ID4gKyAqwqDCoMKgwqDCoHByaW9yaXR5IHRoYW4gYSBCVCB0cmFm
ZmljLg0KPiANCj4gSSB0aGluayB5b3UgbmVlZCB0byBkZWZpbmUgdGhlIGJpdHMgc29tZXdoZXJl
IGluIGFuIGVudW0gLSBpLmUuIHdoaWNoIG9uZSBpcyBWTywNCj4gVkksIC4uLg0KPg0KW1RhbWl6
aF0gb2sgc3VyZS4gSXMgdGhpcyBmb3IgZG9jdW1lbnRhdGlvbiBwdXJwb3NlIG9yIGRvIHlvdSB3
YW50IG1lIHRvIHVzZSB0aGF0IA0KZW51bSBmb3Igc29tZXRoaW5nIGVsc2U/DQogDQo+ID4gKwlp
bnQgYnRjb2V4X3ByaW9yaXR5ID0gLTE7DQo+IA0KPiBUaGF0IC0xIGlzIHByZXR0eSB1c2VsZXNz
LCBpZiB0aGUgZHJpdmVyIGRvZXNuJ3Qgc3VwcG9ydCBpdCwgaG9wZWZ1bGx5IGl0IHdvbid0IGxv
b2sNCj4gYXQgdGhlIHZhbHVlIGF0IGFsbD8NCj4gDQpbVGFtaXpoXSBPayBzdXJlDQo=
^ permalink raw reply
* RE: [PATCHv2 1/4] cfg80211: Add support to enable or disable btcoex
From: Raja, Tamizh Chelvam @ 2017-03-02 11:49 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: ath10k@lists.infradead.org
In-Reply-To: <1488444301.8390.6.camel@sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQo+IFlvdSBuZWVkIHRv
IGZpeCB0aGUgYnVpbGQtYm90IHdhcm5pbmcsIGl0J3MgbGVnaXRpbWF0ZSAodGhvdWdoIGhhcmQg
dG8NCj4gc3BvdCk6DQo+IA0KPiA+ICsJVFBfcHJpbnRrKFdJUEhZX1BSX0ZNVCwgIiwgZW5hYmxl
ZD0lZCIsDQo+ID4gKwkJwqDCoFdJUEhZX1BSX0FSRywgX19lbnRyeS0+ZW5hYmxlZCkNCj4gPiAr
KTsNCj4gDQo+IFlvdSBoYXZlIGEgc3RyYXkgY29tbWEgdGhlcmUgYWZ0ZXIgV0lQSFlfUFJfRk1U
Lg0KPiANCltUYW1pemhdIFllczooIFdpbGwgZml4IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uDQo=
^ permalink raw reply
* Re: Hostapd de-auth connected clients
From: Arend Van Spriel @ 2017-03-02 12:37 UTC (permalink / raw)
To: ravin goyal; +Cc: Jouni Malinen, wpa_supplicant, linux-wireless
In-Reply-To: <CANU0Mn0yHhf+wjmTfo5-KPbqcWZMDOfs32ZWQndhftyQRFDBUw@mail.gmail.com>
+ linux-wireless
On 2-3-2017 10:28, ravin goyal wrote:
> Hi Arend
>
> Thanks, I will certainly try with brcmfmac if you say so.
> Currently I am testing hostapd on orange pi zero board running debian
> jessie and its wlan driver is xradio_wlan and it is working fine.
> I don't know why raspbian and debian have introduced bcmdhd for WLAN
> in their distros.
> I have filed bug on raspbian but received on response yet.
Now it gets confusing. From what I found xradio_wlan is for some
Allwinner flavor based on ST/Ericsson chipset with sdio id 0020:2281.
That would not be a device that bcmdhd would try to bind to.
Regards,
Arend
> Regards
> Ravin
>
> On 1 March 2017 at 18:59, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>> On 28-2-2017 23:28, Jouni Malinen wrote:
>>> On Tue, Feb 28, 2017 at 04:06:48PM +0530, ravin goyal wrote:
>>>> I am sharing link to recent debug log related to de-auth messages in
>>>> hostapd, I hope it might help to figure out what's really happening
>>>> and to know whether it is due to driver or hostapd.
>>>>
>>>> Please take a look at this.
>>>>
>>>> link to log file: https://clbin.com/0flGD
>>>
>>> It looks like number of the disconnections in the two logs are triggered
>>> by station inactivity check:
>>>
>>> 1488275056.529235: wlan0: Station 00:73:8d:43:87:2e has been inactive too long: 308 sec, max allowed: 300
>>> 1488275056.529389: Polling STA
>>> 1488275056.529457: nl80211: send_mlme - da= 00:73:8d:43:87:2e noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0x248 (WLAN_FC_STYPE_NULLFUNC) nlmode=3
>>> 1488275056.529574: nl80211: Use bss->freq=2442
>>> 1488275056.529634: nl80211: CMD_FRAME freq=2442 wait=0 no_cck=0 no_ack=0 offchanok=0
>>> 1488275056.529711: CMD_FRAME - hexdump(len=24): 48 02 00 00 00 73 8d 43 87 2e 02 1a 11 f5 47 06 02 1a 11 f5 47 06 00 00
>>> 1488275056.530129: nl80211: Frame command failed: ret=-22 (Invalid argument) (freq=2442 wait=0)
>>> 1488275056.530231: nl80211_send_null_frame: Failed to send poll frame
>>> 1488275056.530295: ap_handle_timer: register ap_handle_timer timeout for 00:73:8d:43:87:2e (1 seconds - AP_DISASSOC_DELAY)
>>>
>>>
>>> This code should not have been triggered at all if the driver reported
>>> activity in the expected way, so I'm assuming the driver does not
>>> support that.. And then it does not support sending out the poll frame
>>> to check whether the STA is still there.
>>>
>>> You might be able to work around this by setting a significantly larger
>>> ap_max_inactivity value in hostapd.conf, but for a proper fix, someone
>>> more familiar with the particular driver would need to take a look at
>>> what's happening and why the driver does not indicate station activity.
>>
>> I would suggest trying brcmfmac instead of bcmdhd. The bcmdhd is
>> specifically for Android and verification is done on Android targets.
>> Not saying your problems will be gone, but at least you can ask me for help.
>>
>> Regards,
>> Arend
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 12:15 UTC (permalink / raw)
To: Raja, Tamizh Chelvam, linux-wireless@vger.kernel.org
Cc: ath10k@lists.infradead.org
In-Reply-To: <b55e902d1a5445feb3058cee1118ae39@aphydexm01f.ap.qualcomm.com>
> > I think you need to define the bits somewhere in an enum - i.e.
> > which one is VO,
> > VI, ...
> >
>
> [Tamizh] ok sure. Is this for documentation purpose or do you want me
> to use that enum for something else?
Well I think you should check in cfg80211 that no bits not defined in
the enum are used, and then in the driver you need to use that enum to
translate to the firmware API, right?
johannes
^ permalink raw reply
* RE: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Raja, Tamizh Chelvam @ 2017-03-02 13:08 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: ath10k@lists.infradead.org
In-Reply-To: <1488456958.8390.15.camel@sipsolutions.net>
DQo+IA0KPiA+ID4gSSB0aGluayB5b3UgbmVlZCB0byBkZWZpbmUgdGhlIGJpdHMgc29tZXdoZXJl
IGluIGFuIGVudW0gLSBpLmUuDQo+ID4gPiB3aGljaCBvbmUgaXMgVk8sDQo+ID4gPiBWSSwgLi4u
DQo+ID4gPg0KPiA+DQo+ID4gW1RhbWl6aF0gb2sgc3VyZS4gSXMgdGhpcyBmb3IgZG9jdW1lbnRh
dGlvbiBwdXJwb3NlIG9yIGRvIHlvdSB3YW50IG1lDQo+ID4gdG8gdXNlIHRoYXTCoCBlbnVtIGZv
ciBzb21ldGhpbmcgZWxzZT8NCj4gDQo+IFdlbGwgSSB0aGluayB5b3Ugc2hvdWxkIGNoZWNrIGlu
IGNmZzgwMjExIHRoYXQgbm8gYml0cyBub3QgZGVmaW5lZCBpbiB0aGUgZW51bQ0KPiBhcmUgdXNl
ZCwgDQpbVGFtaXpoXSBJJ20gcGxhbm5pbmcgdG8gZG8gdGhpcyBjaGVjayBpbiBpdyBpdHNlbGYg
YW5kIGNvbnZlcnRpbmcgaW50byBhIHZhbHVlLCANCg0KaXcgY29tbWFuZCB3aWxsIGxvb2tzIGxp
a2UgYmVsb3cNCg0KaXcgYnRjb2V4IGVuYWJsZSBbPGJlPiA8Yms+IDx2bz4gPHZpPiA8bWdtdD48
YmVhY29uPl0NCg0KSWYgYW55dGhpbmcgb3RoZXIgdGhhbiB0aGlzIGdpdmVuIGJ5IHVzZXIgd2ls
bCBiZSByZWplY3RlZCBhbmQgd2lsbCBub3QgZm9yd2FyZCB0byBjZmc4MDIxMS4NCkRvIHlvdSBo
YXZlIGFueSBjb25jZXJuIG9uIHRoaXM/DQoNCj5hbmQgdGhlbiBpbiB0aGUgZHJpdmVyIHlvdSBu
ZWVkIHRvIHVzZSB0aGF0IGVudW0gdG8gdHJhbnNsYXRlIHRvIHRoZQ0KPiBmaXJtd2FyZSBBUEks
IHJpZ2h0Pw0KPiANCltUYW1pemhdIFllcywgd2UgY2FuIGhhdmUgdGhpcyBmb3IgY2hlY2tpbmcg
aW52YWxpZCBvciB0aGUgdmFsdWUgaXMgZ3JlYXRlciB0aGUgZHJpdmVyIHN1cHBvcnQgdmFsdWUN
Cg==
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Ben Greear @ 2017-03-02 14:26 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1488443884.8390.4.camel@sipsolutions.net>
On 03/02/2017 12:38 AM, Johannes Berg wrote:
> On Mon, 2017-02-27 at 12:48 -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.
>>>
>>>> + 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?
>
> The control channel center_freq is already there so that should be the
> full chandef. I guess center_freq2 should be conditional on being non-
> zero.
I posted a new patch series a day or two ago...please let me know
if that looks right to you. I un-conditionally included freq2, but
I think that is cleaner code all around. Still, I'll make it conditional
if that is important to you.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCHv2 3/4] cfg80211: Add Support set btcoex priority value
From: Johannes Berg @ 2017-03-02 13:43 UTC (permalink / raw)
To: Raja, Tamizh Chelvam, linux-wireless@vger.kernel.org
Cc: ath10k@lists.infradead.org
In-Reply-To: <b461827bad634932a8f0f3b3bfe5e6b4@aphydexm01f.ap.qualcomm.com>
>
> [Tamizh] I'm planning to do this check in iw itself and converting
> into a value,
>
> iw command will looks like below
>
> iw btcoex enable [<be> <bk> <vo> <vi> <mgmt><beacon>]
>
> If anything other than this given by user will be rejected and will
> not forward to cfg80211.
> Do you have any concern on this?
Yes, you really need to check it in cfg80211 and define the bits that
are valid in nl80211.
johannes
^ permalink raw reply
* [PATCH 1/3] Staging:wilc1000:host_interface: Removed unnecessary blank line
From: Georgios Emmanouil @ 2017-03-02 15:35 UTC (permalink / raw)
To: aditya.shankar, ganesh.krishna, gregkh
Cc: linux-wireless, devel, linux-kernel
Removed unnecessary blank line.
Signed-off-by: Georgios Emmanouil <geo.emmnl@gmail.com>
---
drivers/staging/wilc1000/host_interface.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
index c307cce..090fd43 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -287,7 +287,6 @@ static int wilc_enqueue_cmd(struct host_if_msg *msg)
return 0;
}
-
/* The u8IfIdx starts from 0 to NUM_CONCURRENT_IFC -1, but 0 index used as
* special purpose in wilc device, so we add 1 to the index to starts from 1.
* As a result, the returned index will be 1 to NUM_CONCURRENT_IFC.
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] Staging:wilc1000:host_interface: Fixed alignment to match open parenthesis
From: Georgios Emmanouil @ 2017-03-02 15:37 UTC (permalink / raw)
To: aditya.shankar, ganesh.krishna, gregkh
Cc: linux-wireless, devel, linux-kernel
In-Reply-To: <1488468905-8686-1-git-send-email-geo.emmnl@gmail.com>
Fixed alignment to match open parenthesis.
Signed-off-by: Georgios Emmanouil <geo.emmnl@gmail.com>
---
drivers/staging/wilc1000/host_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
index 090fd43..bbe1a09 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1349,7 +1349,7 @@ static s32 Handle_RcvdGnrlAsyncInfo(struct wilc_vif *vif,
if (u32RcvdAssocRespInfoLen != 0) {
s32Err = wilc_parse_assoc_resp_info(rcv_assoc_resp, u32RcvdAssocRespInfoLen,
- &pstrConnectRespInfo);
+ &pstrConnectRespInfo);
if (s32Err) {
netdev_err(vif->ndev, "wilc_parse_assoc_resp_info() returned error %d\n", s32Err);
} else {
--
2.1.4
^ permalink raw reply related
* [PATCH] Staging:wilc1000:linux_wlan: Modified the 'if-else' statement
From: Georgios Emmanouil @ 2017-03-02 16:14 UTC (permalink / raw)
To: aditya.shankar, ganesh.krishna, gregkh
Cc: linux-wireless, devel, linux-kernel
Modified the 'if-else' statement to make it more readable.
Signed-off-by: Georgios Emmanouil <geo.emmnl@gmail.com>
---
drivers/staging/wilc1000/linux_wlan.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index 2eebc62..d82f0ff 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -867,15 +867,10 @@ static int wilc_mac_open(struct net_device *ndev)
wilc_get_vif_idx(vif),
wl->open_ifcs);
} else {
- if (memcmp(wl->vif[i ^ 1]->bssid,
- wl->vif[i ^ 1]->src_addr, 6))
- wilc_set_wfi_drv_handler(vif,
- wilc_get_vif_idx(vif),
- 0);
+ if (memcmp(wl->vif[i ^ 1]->bssid, wl->vif[i ^ 1]->src_addr, 6))
+ wilc_set_wfi_drv_handler(vif, wilc_get_vif_idx(vif), 0);
else
- wilc_set_wfi_drv_handler(vif,
- wilc_get_vif_idx(vif),
- 1);
+ wilc_set_wfi_drv_handler(vif, wilc_get_vif_idx(vif), 1);
}
wilc_set_operation_mode(vif, vif->iftype);
--
2.1.4
^ permalink raw reply related
* ANNOUNCE: Netdev 2.1 New Gold Sponsor
From: Jamal Hadi Salim @ 2017-03-02 16:36 UTC (permalink / raw)
Cc: netfilter-devel, netfilter, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, people, Brenda Butler
We'd like to announce Mojatatu Networks as our second Gold Sponsor.
Thank you for the continued support!
cheers,
jamal
^ permalink raw reply
* [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN
From: Arnd Bergmann @ 2017-03-02 16:38 UTC (permalink / raw)
To: kasan-dev
Cc: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov, netdev,
linux-kernel, linux-media, linux-wireless, kernel-build-reports,
David S . Miller, Arnd Bergmann
In-Reply-To: <20170302163834.2273519-1-arnd@arndb.de>
When CONFIG_KASAN is set, inlining of functions with local variables
causes excessive stack usage:
drivers/media/i2c/ks0127.c: In function 'ks0127_s_routing':
drivers/media/i2c/ks0127.c:541:1: error: the frame size of 3136 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Marking one functions as noinline_for_kasan solves the problem in this
driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/media/i2c/ks0127.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ab536c4a7115..eb2fccdc0602 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -349,7 +349,7 @@ static void ks0127_write(struct v4l2_subdev *sd, u8 reg, u8 val)
/* generic bit-twiddling */
-static void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, u8 and_v, u8 or_v)
+static noinline_for_kasan void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, u8 and_v, u8 or_v)
{
struct ks0127 *ks = to_ks0127(sd);
--
2.9.0
^ 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