* RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Machani, Yaniv @ 2016-07-19 13:17 UTC (permalink / raw)
To: Johannes Berg, Bob Copeland
Cc: linux-kernel@vger.kernel.org, Kama, Meirav, David S. Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1468867942.2944.0.camel@sipsolutions.net>
T24gTW9uLCBKdWwgMTgsIDIwMTYgYXQgMjE6NTI6MjIsIEpvaGFubmVzIEJlcmcgd3JvdGU6DQo+
IGxpbnV4LSB3aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzNdIG1hYzgwMjExOiBtZXNoOiBmaXhlZCBIVCBpZXMg
aW4gYmVhY29uIA0KPiB0ZW1wbGF0ZQ0KPiANCj4gT24gTW9uLCAyMDE2LTA3LTE4IGF0IDA5OjM4
IC0wNDAwLCBCb2IgQ29wZWxhbmQgd3JvdGU6DQo+ID4gT24gV2VkLCBKdWwgMTMsIDIwMTYgYXQg
MDI6NDU6NDBQTSArMDMwMCwgWWFuaXYgTWFjaGFuaSB3cm90ZToNCj4gPiA+IFRoZSBIVCBjYXBh
YiBpbmZvIGZpZWxkIGluc2lkZSB0aGUgSFQgY2FwYWIgSUUgb2YgdGhlIG1lc2ggYmVhY29uIA0K
PiA+ID4gaXMgaW5jb3JyZWN0IChpbiB0aGUgY2FzZSBvZiAyME1IeiBjaGFubmVsIHdpZHRoKS4N
Cj4gPiA+IFRvIGZpeCB0aGlzIGRyaXZlciB3aWxsIGNoZWNrIGNvbmZpZ3VyYXRpb24gZnJvbSBj
ZmcgYW5kIHdpbGwgDQo+ID4gPiBidWlsZCBpdCBhY2NvcmRpbmdseS4NCj4gPg0KPiA+ID4gK8Kg
wqDCoMKgLyogZGV0ZXJtaW5lIGNhcGFiaWxpdHkgZmxhZ3MgKi8NCj4gPiA+ICsJY2FwID0gc2Jh
bmQtPmh0X2NhcC5jYXA7DQo+ID4gPiArDQo+ID4gPiArwqDCoMKgwqAvKiBpZiBjaGFubmVsIHdp
ZHRoIGlzIDIwTUh6IC0gY29uZmlndXJlIEhUIGNhcGFiDQo+ID4gPiBhY2NvcmRpbmdseSovDQo+
ID4gPiArCWlmIChzZGF0YS0+dmlmLmJzc19jb25mLmNoYW5kZWYud2lkdGggPT0NCj4gPiA+IE5M
ODAyMTFfQ0hBTl9XSURUSF8yMCkgew0KPiA+ID4gKwkJY2FwICY9IH5JRUVFODAyMTFfSFRfQ0FQ
X1NVUF9XSURUSF8yMF80MDsNCj4gPiA+ICsJCWNhcCAmPSB+SUVFRTgwMjExX0hUX0NBUF9EU1NT
Q0NLNDA7DQo+ID4gPiArCX0NCj4gPg0KPiA+IElzIGl0IHJlcXVpcmVkIHRoYXQgSFQgY2FwYWJp
bGl0eSBtYXRjaCB0aGUgSFQgb3BlcmF0aW9uIGluIHRoaXMgY2FzZT8NCj4gPg0KPiANCj4gSXMg
dGhlcmUgZXZlciBhIGNhc2UgdGhhdCBIVCAqY2FwYWJpbGl0eSogc2hvdWxkIGJlIHJlc3RyaWN0
ZWQgDQo+IGFydGlmaWNpYWxseSBsaWtlIHRoYXQ/IEkgY2FuJ3QgcmVtZW1iZXIgYW55IGNhc2Vz
IC0gd2UgZG8gc29tZXRoaW5nIA0KPiBsaWtlIHRoYXQgdG8gd29yayBhcm91bmQgYnJva2VuIEFQ
cyBpbiBzb21lIGNhc2VzLCBidXQgaGVyZT8NCj4gDQoNCkl0IHdhcyBkb25lIHRvIG92ZXJjb21l
IGFub3RoZXIgbWlzbWF0Y2ggd2l0aCB0aGUgZGVmYXVsdHMgb2YgdGhlIGhvc3RhcCBjb25maWd1
cmF0aW9uLA0KV2UnbGwgaGF2ZSBhbm90aGVyIGxvb2sgb24gaXQuDQoNClRoZXJlIGlzIGFuIElP
UCBxdWVzdGlvbiBoZXJlLCBob3cgdG8gaGFuZGxlIGEgY2FzZSB3aGVyZSB5b3UgaGF2ZSBtaXhl
ZCBjYXBhYmlsaXRpZXMgb2YgcGVlcnMuDQppcyBpdCBwb3NzaWJsZSB0byBkeW5hbWljYWxseSBj
aGFuZ2UgdGhlIGNoYW5uZWwgYmFuZHdpZHRoIHRvIGFsbG93IG5ldyBwZWVycyB0byBqb2luID8N
Cg0KWWFuaXYNCg0K
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Michal Kazior @ 2016-07-19 13:13 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Toke Høiland-Jørgensen
In-Reply-To: <11fa6d16-21e2-2169-8d18-940f6dc11dca@nbd.name>
On 12 July 2016 at 12:09, Felix Fietkau <nbd@nbd.name> wrote:
> Hi,
>
> With Toke's ath9k txq patch I've noticed a pretty nasty performance
> regression when running local iperf on an AP (running the txq stuff) to
> a wireless client.
>
> Here's some things that I found:
> - when I use only one TCP stream I get around 90-110 Mbit/s
> - when running multiple TCP streams, I get only 35-40 Mbit/s total
What is the baseline here (i.e. without fq/txq stuff)? Is it ~100mbps?
Did you try running multiple streams, each on separate tids (matching
the same AC perhaps) or different clients?
Michał
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Michal Kazior @ 2016-07-19 13:10 UTC (permalink / raw)
To: Dave Taht
Cc: Felix Fietkau, make-wifi-fast, linux-wireless,
Toke Høiland-Jørgensen
In-Reply-To: <CAA93jw4GQknawtp6Lo3ZM8=qW=p2eTnZ_krC7AvnNbKwp8R5SQ@mail.gmail.com>
On 12 July 2016 at 16:02, Dave Taht <dave.taht@gmail.com> wrote:
[...]
>>> tcp_limit_output_bytes is?
>> 262144
>
> I keep hoping to be able to reduce this to something saner like 4096
> one day. It got bumped to 64k based on bad wifi performance once, and
> then to it's current size to make the Xen folk happier.
Not sure if it's possible. You do need this to be at least as big as a
single A-MPDU can get. In extreme 11ac cases it can be pretty big.
I recall a discussion from a long time ago and the tcp limit output
logic was/is coupled with the assumption that tx-completions always
come max 1ms after tx submission. This is rather tricky to *guarantee*
on wifi, especially with firmware blobs, big aggregates, lots of
stations and retries.
Michał
^ permalink raw reply
* RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Machani, Yaniv @ 2016-07-19 13:02 UTC (permalink / raw)
To: Bob Copeland
Cc: linux-wireless@vger.kernel.org, Hahn, Maital, Johannes Berg,
Chun-Yeow Yeoh
In-Reply-To: <20160719124456.GD11996@localhost>
On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> Chun-Yeow Yeoh
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> time
>
> On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote:
> > > To improve that, added an 'immediate' flag to be used when the
> > > path needs
> to be resolved.
> > > Once set, a PREQ frame will be send w/o considering the
> > > MinInterval
> parameter.
> >
> > Suggest that you try to reduce the mesh_hwmp_preq_min_interval to
> > your desired value instead of introducing a new patch specific to
> > your use case.
> >
> > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute
> > to specify the minimum interval of time during which a mesh STA can
> > send only one Action frame containing a PREQ element. This is to
> > avoid flooding of broadcast PREQ frame especially when the number of
> > mesh STA is increased.
>
> Good point, according to 13.10.9.3, conditions for sending PREQ include:
>
> "The mesh STA has not sent a PREQ element for the target mesh STAs
> less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case,
> the transmission of the PREQ has to be postponed until this condition becomes true."
>
As I see it, the key point here is "for the target meh STA",
Today, the code will not send a PREQ to ANY target if dot11MeshHWMPpreqMinInterval didn't passed.
The information is saved in the 'ifmsh->last_preq', and not per path.
Another point is, that this is a case where we had a valid path, but lost it due to our next hop peer disconnect.
Reducing the dot11MeshHWMPpreqMinInterval will just flood the network,
Our goal is to improve the healing time, it's not a specific use case, it will improve network performance.
Thanks,
Yaniv
^ permalink raw reply
* [RFC] ath10k: silence firmware file probing warnings
From: Michal Kazior @ 2016-07-19 13:00 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, Michal Kazior
Firmware files are versioned to prevent older
driver instances to load unsupported firmware
blobs. This is reflected with a fallback logic
which attempts to load several firmware files.
This however produced a lot of unnecessary
warnings sometimes confusing users and leading
them to rename firmware files making things even
more confusing.
Hence use request_firmware_direct() which does not
produce extra warnings. This shouldn't really
break anything because most modern systems don't
rely on udev/hotplug helpers to load firmware
files anymore.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.c | 11 +++++------
drivers/net/wireless/ath/ath10k/testmode.c | 5 ++++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..81bfb71fe876 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -431,7 +431,10 @@ static const struct firmware *ath10k_fetch_fw_file(struct ath10k *ar,
dir = ".";
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
- ret = request_firmware(&fw, filename, ar->dev);
+ ret = request_firmware_direct(&fw, filename, ar->dev);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
+ filename, ret);
+
if (ret)
return ERR_PTR(ret);
@@ -1089,12 +1092,8 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
name);
- if (IS_ERR(fw_file->firmware)) {
- ath10k_err(ar, "could not fetch firmware file '%s/%s': %ld\n",
- ar->hw_params.fw.dir, name,
- PTR_ERR(fw_file->firmware));
+ if (IS_ERR(fw_file->firmware))
return PTR_ERR(fw_file->firmware);
- }
data = fw_file->firmware->data;
len = fw_file->firmware->size;
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 120f4234d3b0..fe49e7a83d00 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -149,7 +149,10 @@ static int ath10k_tm_fetch_utf_firmware_api_1(struct ath10k *ar,
ar->hw_params.fw.dir, ATH10K_FW_UTF_FILE);
/* load utf firmware image */
- ret = request_firmware(&fw_file->firmware, filename, ar->dev);
+ ret = request_firmware_direct(&fw_file->firmware, filename, ar->dev);
+ ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode fw request '%s': %d\n",
+ filename, ret);
+
if (ret) {
ath10k_warn(ar, "failed to retrieve utf firmware '%s': %d\n",
filename, ret);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Bob Copeland @ 2016-07-19 12:44 UTC (permalink / raw)
To: Yaniv Machani
Cc: linux-wireless@vger.kernel.org, Maital Hahn, Johannes Berg,
Chun-Yeow Yeoh
In-Reply-To: <CAEFj987X26u59K32Mt-bKBSTmy3cWvOiNNBG7K4wbdQBAdR97Q@mail.gmail.com>
On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote:
> > To improve that, added an 'immediate' flag to be used when the path needs to be resolved.
> > Once set, a PREQ frame will be send w/o considering the MinInterval parameter.
>
> Suggest that you try to reduce the mesh_hwmp_preq_min_interval to your
> desired value instead of introducing a new patch specific to your use
> case.
>
> IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute to
> specify the minimum interval of time during which a mesh STA can send
> only one Action frame containing a PREQ element. This is to avoid
> flooding of broadcast PREQ frame especially when the number of mesh
> STA is increased.
Good point, according to 13.10.9.3, conditions for sending PREQ include:
"The mesh STA has not sent a PREQ element for the target mesh STAs less
than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case, the
transmission of the PREQ has to be postponed until this condition becomes
true."
Adopting this patch would violate that, so please disregard my suggested
rewrites; we should just skip this one.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
From: Kalle Valo @ 2016-07-19 12:40 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Florian Fainelli, brcm80211-dev-list.pdl, linux-wireless,
pieterpg, hante.meuleman
In-Reply-To: <685abc5d-2e3d-cdce-4849-f7e5beb3309d@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
> On 19-7-2016 1:24, Florian Fainelli wrote:
>> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2
>> * ETH_ALEN, which will potentially overrun the destination buffer.
>
> NACK - this is intentional. Have to admit it is a bit of trickery.
> struct ieee80211_rts is mapped over struct d11txh which is sent to
> hardware. The struct is used for both RTS and CTS. Transmitting CTS will
> only fill 802.11 addr2 in struct ieee80211_rts::ra. Transmitting RTS
> fills 802.11 addr1 in ra and 802.11 addr2 in ta using single memcpy().
> Not very clear, but your change is not the way to go here.
Maybe add a comment explaining that?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Bob Copeland @ 2016-07-19 12:36 UTC (permalink / raw)
To: Yaniv Machani
Cc: linux-kernel, Maital Hahn, Johannes Berg, David S. Miller,
linux-wireless, netdev
In-Reply-To: <20160713114528.24835-1-yanivma@ti.com>
On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
> When a packet is received for transmission,
> a PREQ frame is sent to resolve the appropriate path to the desired destination.
> After path was established, any sequential PREQ will be sent only after
> dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
>
> This implementation has an impact in cases where we would like to
> resolve the path quickly.
> A clear example is when a peer was disconnected from us,
> while he acted as a hop to our destination.
> Although the path table will be cleared, the next PREQ frame will be sent only after reaching the MinInterval.
> This will cause unwanted delay, possibly of few seconds until the traffic will resume.
>
> if (!(mpath->flags & MESH_PATH_RESOLVING))
> - mesh_queue_preq(mpath, PREQ_Q_F_START);
> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
What about something like this here instead:
if (!(mpath->flags & MESH_PATH_RESOLVING)) {
/* force next preq to be sent without delay */
ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
Maybe a little more magic, but it has a comment explaining it and doesn't
add a bool parameter everywhere. Or, maybe even just do it inside
mesh_queue_preq() based on having PREQ_Q_F_START && !PREQ_Q_F_REFRESH (if
those are the only cases where "true" is passed).
Generally I try to avoid bool parameters where possible because when you
look at a callsite, you don't know immediately what "true" and "false"
mean, and also each one you add doubles the code paths through a given
function.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* [PATCH] nl80211: Expand max value of NL80211_MESHCONF_HT_OPMODE command
From: Masashi Honma @ 2016-07-19 11:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, j, me, Masashi Honma
Previously, the max value of NL80211_MESHCONF_HT_OPMODE was 16.
But it causes EINVAL when IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED
and IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT bit is enabled.
So this patch expands the max value.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/wireless/nl80211.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46417f9..8a00e50 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5471,7 +5471,10 @@ do { \
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, rssi_threshold, -255, 0,
mask, NL80211_MESHCONF_RSSI_THRESHOLD,
nl80211_check_s32);
- FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0, 16,
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0,
+ IEEE80211_HT_OP_MODE_PROTECTION |
+ IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT,
mask, NL80211_MESHCONF_HT_OPMODE,
nl80211_check_u16);
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshHWMPactivePathToRootTimeout,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Bob Copeland @ 2016-07-19 10:40 UTC (permalink / raw)
To: Masashi Honma; +Cc: johannes, linux-wireless, j
In-Reply-To: <3ad771da-f4db-e29d-7b44-7e8a0865e3da@gmail.com>
On Tue, Jul 19, 2016 at 11:16:24AM +0900, Masashi Honma wrote:
> This patch does not fix starting MPSP, this patch fixes ending of MPSP.
> Without this patch, local peer continues MPSP even if we lost opposite peer
> accidentally.
OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in
ieee80211_mps_sta_status_update(), or does the node completely repeer?
ISTR running into a problem where rebooted peer (previously in power-save)
would send popen but we would buffer the response due to stale PS sta
flag.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
From: Arend Van Spriel @ 2016-07-19 10:38 UTC (permalink / raw)
To: Florian Fainelli, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <1468884277-18606-4-git-send-email-f.fainelli@gmail.com>
On 19-7-2016 1:24, Florian Fainelli wrote:
> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2
> * ETH_ALEN, which will potentially overrun the destination buffer.
NACK - this is intentional. Have to admit it is a bit of trickery.
struct ieee80211_rts is mapped over struct d11txh which is sent to
hardware. The struct is used for both RTS and CTS. Transmitting CTS will
only fill 802.11 addr2 in struct ieee80211_rts::ra. Transmitting RTS
fills 802.11 addr1 in ra and 802.11 addr2 in ta using single memcpy().
Not very clear, but your change is not the way to go here.
Regards,
Arend
> Reported-by: coverity (CID 145657)
> Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
> index c2a938b59044..59813a3666eb 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
> @@ -6671,7 +6671,7 @@ brcms_c_d11hdrs_mac80211(struct brcms_c_info *wlc, struct ieee80211_hw *hw,
> rts->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL |
> IEEE80211_STYPE_RTS);
>
> - memcpy(&rts->ra, &h->addr1, 2 * ETH_ALEN);
> + memcpy(&rts->ra, &h->addr1, ETH_ALEN);
> }
>
> /* mainrate
>
^ permalink raw reply
* [PATCH 4/4] ath10k: fix spurious tx/rx during boot
From: Michal Kazior @ 2016-07-19 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, marek.puzyniak, Michal Kazior
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
HW Rx filters and masks are not configured
properly by firmware during boot sequences. The
MAC_PCU_ADDR1 is set to 0s instead of 1s which
allows the HW to ACK any frame that passes through
MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself
is misconfigured on boot as well.
The combination of these bugs ended up with the
following manifestations:
- "no channel configured; ignoring frame(s)!"
warnings in the driver
- spurious ACKs (transmission) on the air during
firmware bootup sequences
The former was a long standing and known bug
originally though mostly harmless.
However Marek recently discovered that this
problem also involves ACKing *all* frames the HW
receives (including beacons ;). Such frames
are delivered to host and generate the former
warning as well.
This could be a problem with regulatory compliance
in some rare cases (e.g. Taiwan which forbids
transmissions on channel 36 which is the default
bootup channel on 5Ghz band cards). The good news
is that it'd require someone else to violate
regulatory first to coerce our device to generate
and transmit an ACK.
The problem could be reproduced in a rather busy
environment that has a lot of APs. The likelihood
could be increased by injecting an msleep() of
5000 or longer immediately after
ath10k_htt_setup() in ath10k_core_start().
The reason why the former warnings were only
showing up seldom is because the device was either
quickly reset again (i.e. during firmware probing)
or wmi vdev was created (which fixes hw and fw
states).
It is technically possible for host driver to
override adequate hw registers however this can't
work reliably because the bug root cause lies in
incorrect firmware state on boot (internal
structure used to program MAC_PCU_ADDR1 is not
properly initialized) and only vdev create/delete
events can fix it. This is why the patch takes
dummy vdev approach.
This could be fixed in firmware as well but having
this fixed in driver is more robust, most notably
when thinking of users of older firmware such as
999.999.0.636.
Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.c | 68 ++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..d2e255418d1b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1705,6 +1705,55 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
return 0;
}
+static int ath10k_core_reset_rx_filter(struct ath10k *ar)
+{
+ int ret;
+ int vdev_id;
+ int vdev_type;
+ int vdev_subtype;
+ const u8 *vdev_addr;
+
+ vdev_id = 0;
+ vdev_type = WMI_VDEV_TYPE_STA;
+ vdev_subtype = ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);
+ vdev_addr = ar->mac_addr;
+
+ ret = ath10k_wmi_vdev_create(ar, vdev_id, vdev_type, vdev_subtype,
+ vdev_addr);
+ if (ret) {
+ ath10k_err(ar, "failed to create dummy vdev: %d\n", ret);
+ return ret;
+ }
+
+ ret = ath10k_wmi_vdev_delete(ar, vdev_id);
+ if (ret) {
+ ath10k_err(ar, "failed to delete dummy vdev: %d\n", ret);
+ return ret;
+ }
+
+ /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
+ * serialized properly implicitly.
+ *
+ * Moreover (most) WMI commands have no explicit acknowledges. It is
+ * possible to infer it implicitly by poking firmware with echo
+ * command - getting a reply means all preceding comments have been
+ * (mostly) processed.
+ *
+ * In case of vdev create/delete this is sufficient.
+ *
+ * Without this it's possible to end up with a race when HTT Rx ring is
+ * started before vdev create/delete hack is complete allowing a short
+ * window of opportunity to receive (and Tx ACK) a bunch of frames.
+ */
+ ret = ath10k_wmi_barrier(ar);
+ if (ret) {
+ ath10k_err(ar, "failed to ping firmware: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
const struct ath10k_fw_components *fw)
{
@@ -1872,6 +1921,25 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
goto err_hif_stop;
}
+ /* Some firmware revisions do not properly set up hardware rx filter
+ * registers.
+ *
+ * A known example from QCA9880 and 10.2.4 is that MAC_PCU_ADDR1_MASK
+ * is filled with 0s instead of 1s allowing HW to respond with ACKs to
+ * any frames that matches MAC_PCU_RX_FILTER which is also
+ * misconfigured to accept anything.
+ *
+ * The ADDR1 is programmed using internal firmware structure field and
+ * can't be (easily/sanely) reached from the driver explicitly. It is
+ * possible to implicitly make it correct by creating a dummy vdev and
+ * then deleting it.
+ */
+ status = ath10k_core_reset_rx_filter(ar);
+ if (status) {
+ ath10k_err(ar, "failed to reset rx filter: %d\n", status);
+ goto err_hif_stop;
+ }
+
/* If firmware indicates Full Rx Reorder support it must be used in a
* slightly different manner. Let HTT code know.
*/
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] ath10k: add wmi command barrier utility
From: Michal Kazior @ 2016-07-19 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, marek.puzyniak, Michal Kazior
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
This allows placing command barriers for explicit
serializing and synchronizing state.
Useful for future driver development.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 31 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
3 files changed, 33 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 9374bcde3d35..bf385052b168 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -142,6 +142,7 @@ struct ath10k_wmi {
enum ath10k_htc_ep_id eid;
struct completion service_ready;
struct completion unified_ready;
+ struct completion barrier;
wait_queue_head_t tx_credits_wq;
DECLARE_BITMAP(svc_map, WMI_SERVICE_MAX);
struct wmi_cmd_map *cmd;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 8ca76ecd7e9b..2bd9f2d0f186 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -29,6 +29,9 @@
#include "p2p.h"
#include "hw.h"
+#define ATH10K_WMI_BARRIER_ECHO_ID 0xBA991E9
+#define ATH10K_WMI_BARRIER_TIMEOUT_HZ (3 * HZ)
+
/* MAIN WMI cmd track */
static struct wmi_cmd_map wmi_cmd_map = {
.init_cmdid = WMI_INIT_CMDID,
@@ -2507,6 +2510,9 @@ void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
ath10k_dbg(ar, ATH10K_DBG_WMI,
"wmi event echo value 0x%08x\n",
le32_to_cpu(arg.value));
+
+ if (le32_to_cpu(arg.value) == ATH10K_WMI_BARRIER_ECHO_ID)
+ complete(&ar->wmi.barrier);
}
int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
@@ -7689,6 +7695,30 @@ ath10k_wmi_op_gen_echo(struct ath10k *ar, u32 value)
return skb;
}
+int
+ath10k_wmi_barrier(struct ath10k *ar)
+{
+ int ret;
+ int time_left;
+
+ spin_lock_bh(&ar->data_lock);
+ reinit_completion(&ar->wmi.barrier);
+ spin_unlock_bh(&ar->data_lock);
+
+ ret = ath10k_wmi_echo(ar, ATH10K_WMI_BARRIER_ECHO_ID);
+ if (ret) {
+ ath10k_warn(ar, "failed to submit wmi echo: %d\n", ret);
+ return ret;
+ }
+
+ time_left = wait_for_completion_timeout(&ar->wmi.barrier,
+ ATH10K_WMI_BARRIER_TIMEOUT_HZ);
+ if (!time_left)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
static const struct wmi_ops wmi_ops = {
.rx = ath10k_wmi_op_rx,
.map_svc = wmi_main_svc_map,
@@ -8086,6 +8116,7 @@ int ath10k_wmi_attach(struct ath10k *ar)
init_completion(&ar->wmi.service_ready);
init_completion(&ar->wmi.unified_ready);
+ init_completion(&ar->wmi.barrier);
INIT_WORK(&ar->svc_rdy_work, ath10k_wmi_event_service_ready_work);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 086d78807d2f..89adfa90ee8d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6628,5 +6628,6 @@ void ath10k_wmi_10_4_op_fw_stats_fill(struct ath10k *ar,
char *buf);
int ath10k_wmi_op_get_vdev_subtype(struct ath10k *ar,
enum wmi_vdev_subtype subtype);
+int ath10k_wmi_barrier(struct ath10k *ar);
#endif /* _WMI_H_ */
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] ath10k: implement wmi echo command
From: Michal Kazior @ 2016-07-19 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, marek.puzyniak, Michal Kazior
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Will be useful for implementing command barriers.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/wmi-ops.h | 17 +++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 29 +++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 23 +++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 64ebd304f907..b1d88fa60d11 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -194,6 +194,7 @@ struct wmi_ops {
struct sk_buff *(*gen_pdev_bss_chan_info_req)
(struct ath10k *ar,
enum wmi_bss_survey_req_type type);
+ struct sk_buff *(*gen_echo)(struct ath10k *ar, u32 value);
};
int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1382,4 +1383,20 @@ ath10k_wmi_pdev_bss_chan_info_request(struct ath10k *ar,
wmi->cmd->pdev_bss_chan_info_request_cmdid);
}
+static inline int
+ath10k_wmi_echo(struct ath10k *ar, u32 value)
+{
+ struct ath10k_wmi *wmi = &ar->wmi;
+ struct sk_buff *skb;
+
+ if (!wmi->ops->gen_echo)
+ return -EOPNOTSUPP;
+
+ skb = wmi->ops->gen_echo(ar, value);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ return ath10k_wmi_cmd_send(ar, skb, wmi->cmd->echo_cmdid);
+}
+
#endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e09337ee7c96..cd595855af36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3081,6 +3081,34 @@ ath10k_wmi_tlv_op_gen_adaptive_qcs(struct ath10k *ar, bool enable)
return skb;
}
+static struct sk_buff *
+ath10k_wmi_tlv_op_gen_echo(struct ath10k *ar, u32 value)
+{
+ struct wmi_echo_cmd *cmd;
+ struct wmi_tlv *tlv;
+ struct sk_buff *skb;
+ void *ptr;
+ size_t len;
+
+ len = sizeof(*tlv) + sizeof(*cmd);
+ skb = ath10k_wmi_alloc_skb(ar, len);
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ ptr = (void *)skb->data;
+ tlv = ptr;
+ tlv->tag = __cpu_to_le16(WMI_TLV_TAG_STRUCT_ECHO_CMD);
+ tlv->len = __cpu_to_le16(sizeof(*cmd));
+ cmd = (void *)tlv->value;
+ cmd->value = cpu_to_le32(value);
+
+ ptr += sizeof(*tlv);
+ ptr += sizeof(*cmd);
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi tlv echo value 0x%08x\n", value);
+ return skb;
+}
+
/****************/
/* TLV mappings */
/****************/
@@ -3485,6 +3513,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.gen_adaptive_qcs = ath10k_wmi_tlv_op_gen_adaptive_qcs,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+ .gen_echo = ath10k_wmi_tlv_op_gen_echo,
};
static const struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..9ae4aacadb38 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7649,6 +7649,24 @@ ath10k_wmi_10_4_ext_resource_config(struct ath10k *ar,
return skb;
}
+static struct sk_buff *
+ath10k_wmi_op_gen_echo(struct ath10k *ar, u32 value)
+{
+ struct wmi_echo_cmd *cmd;
+ struct sk_buff *skb;
+
+ skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
+
+ cmd = (struct wmi_echo_cmd *)skb->data;
+ cmd->value = cpu_to_le32(value);
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "wmi echo value 0x%08x\n", value);
+ return skb;
+}
+
static const struct wmi_ops wmi_ops = {
.rx = ath10k_wmi_op_rx,
.map_svc = wmi_main_svc_map,
@@ -7709,6 +7727,7 @@ static const struct wmi_ops wmi_ops = {
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+ .gen_echo = ath10k_wmi_op_gen_echo,
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
@@ -7777,6 +7796,7 @@ static const struct wmi_ops wmi_10_1_ops = {
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_10x_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+ .gen_echo = ath10k_wmi_op_gen_echo,
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
@@ -7796,6 +7816,7 @@ static const struct wmi_ops wmi_10_2_ops = {
.pull_svc_rdy = ath10k_wmi_10x_op_pull_svc_rdy_ev,
.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
.gen_start_scan = ath10k_wmi_10x_op_gen_start_scan,
+ .gen_echo = ath10k_wmi_op_gen_echo,
.pull_scan = ath10k_wmi_op_pull_scan_ev,
.pull_mgmt_rx = ath10k_wmi_op_pull_mgmt_rx_ev,
@@ -7862,6 +7883,7 @@ static const struct wmi_ops wmi_10_2_4_ops = {
.pull_svc_rdy = ath10k_wmi_10x_op_pull_svc_rdy_ev,
.gen_pdev_set_rd = ath10k_wmi_10x_op_gen_pdev_set_rd,
.gen_start_scan = ath10k_wmi_10x_op_gen_start_scan,
+ .gen_echo = ath10k_wmi_op_gen_echo,
.pull_scan = ath10k_wmi_op_pull_scan_ev,
.pull_mgmt_rx = ath10k_wmi_op_pull_mgmt_rx_ev,
@@ -7984,6 +8006,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
.get_vdev_subtype = ath10k_wmi_10_4_op_get_vdev_subtype,
.gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
+ .gen_echo = ath10k_wmi_op_gen_echo,
};
int ath10k_wmi_attach(struct ath10k *ar)
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] ath10k: implement wmi echo event
From: Michal Kazior @ 2016-07-19 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, marek.puzyniak, Michal Kazior
In-Reply-To: <1468924452-23877-1-git-send-email-michal.kazior@tieto.com>
Will be useful for implementing command barriers.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/wmi-ops.h | 12 ++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 28 ++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 29 ++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 4 ++++
4 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index b1d88fa60d11..c67eda78b69e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -51,6 +51,8 @@ struct wmi_ops {
struct wmi_roam_ev_arg *arg);
int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
struct wmi_wow_ev_arg *arg);
+ int (*pull_echo_ev)(struct ath10k *ar, struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg);
enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
struct sk_buff *(*gen_pdev_suspend)(struct ath10k *ar, u32 suspend_opt);
@@ -350,6 +352,16 @@ ath10k_wmi_pull_wow_event(struct ath10k *ar, struct sk_buff *skb,
return ar->wmi.ops->pull_wow_event(ar, skb, arg);
}
+static inline int
+ath10k_wmi_pull_echo_ev(struct ath10k *ar, struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg)
+{
+ if (!ar->wmi.ops->pull_echo_ev)
+ return -EOPNOTSUPP;
+
+ return ar->wmi.ops->pull_echo_ev(ar, skb, arg);
+}
+
static inline enum wmi_txbf_conf
ath10k_wmi_get_txbf_conf_scheme(struct ath10k *ar)
{
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index cd595855af36..a42f52dd9a36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1223,6 +1223,33 @@ ath10k_wmi_tlv_op_pull_wow_ev(struct ath10k *ar, struct sk_buff *skb,
return 0;
}
+static int ath10k_wmi_tlv_op_pull_echo_ev(struct ath10k *ar,
+ struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg)
+{
+ const void **tb;
+ const struct wmi_echo_event *ev;
+ int ret;
+
+ tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+ if (IS_ERR(tb)) {
+ ret = PTR_ERR(tb);
+ ath10k_warn(ar, "failed to parse tlv: %d\n", ret);
+ return ret;
+ }
+
+ ev = tb[WMI_TLV_TAG_STRUCT_ECHO_EVENT];
+ if (!ev) {
+ kfree(tb);
+ return -EPROTO;
+ }
+
+ arg->value = ev->value;
+
+ kfree(tb);
+ return 0;
+}
+
static struct sk_buff *
ath10k_wmi_tlv_op_gen_pdev_suspend(struct ath10k *ar, u32 opt)
{
@@ -3457,6 +3484,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.pull_fw_stats = ath10k_wmi_tlv_op_pull_fw_stats,
.pull_roam_ev = ath10k_wmi_tlv_op_pull_roam_ev,
.pull_wow_event = ath10k_wmi_tlv_op_pull_wow_ev,
+ .pull_echo_ev = ath10k_wmi_tlv_op_pull_echo_ev,
.get_txbf_conf_scheme = ath10k_wmi_tlv_txbf_conf_scheme,
.gen_pdev_suspend = ath10k_wmi_tlv_op_gen_pdev_suspend,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 9ae4aacadb38..8ca76ecd7e9b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2495,7 +2495,18 @@ exit:
void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
{
- ath10k_dbg(ar, ATH10K_DBG_WMI, "WMI_ECHO_EVENTID\n");
+ struct wmi_echo_ev_arg arg = {};
+ int ret;
+
+ ret = ath10k_wmi_pull_echo_ev(ar, skb, &arg);
+ if (ret) {
+ ath10k_warn(ar, "failed to parse echo: %d\n", ret);
+ return;
+ }
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "wmi event echo value 0x%08x\n",
+ le32_to_cpu(arg.value));
}
int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
@@ -4792,6 +4803,17 @@ static int ath10k_wmi_op_pull_roam_ev(struct ath10k *ar, struct sk_buff *skb,
return 0;
}
+static int ath10k_wmi_op_pull_echo_ev(struct ath10k *ar,
+ struct sk_buff *skb,
+ struct wmi_echo_ev_arg *arg)
+{
+ struct wmi_echo_event *ev = (void *)skb->data;
+
+ arg->value = ev->value;
+
+ return 0;
+}
+
int ath10k_wmi_event_ready(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_rdy_ev_arg arg = {};
@@ -7683,6 +7705,7 @@ static const struct wmi_ops wmi_ops = {
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
.pull_fw_stats = ath10k_wmi_main_op_pull_fw_stats,
.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+ .pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7757,6 +7780,7 @@ static const struct wmi_ops wmi_10_1_ops = {
.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+ .pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7828,6 +7852,7 @@ static const struct wmi_ops wmi_10_2_ops = {
.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+ .pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -7895,6 +7920,7 @@ static const struct wmi_ops wmi_10_2_4_ops = {
.pull_phyerr = ath10k_wmi_op_pull_phyerr_ev,
.pull_rdy = ath10k_wmi_op_pull_rdy_ev,
.pull_roam_ev = ath10k_wmi_op_pull_roam_ev,
+ .pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
.gen_pdev_suspend = ath10k_wmi_op_gen_pdev_suspend,
.gen_pdev_resume = ath10k_wmi_op_gen_pdev_resume,
@@ -8002,6 +8028,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.ext_resource_config = ath10k_wmi_10_4_ext_resource_config,
/* shared with 10.2 */
+ .pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
.gen_request_stats = ath10k_wmi_op_gen_request_stats,
.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
.get_vdev_subtype = ath10k_wmi_10_4_op_get_vdev_subtype,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 3ef468893b3f..086d78807d2f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6296,6 +6296,10 @@ struct wmi_roam_ev_arg {
__le32 rssi;
};
+struct wmi_echo_ev_arg {
+ __le32 value;
+};
+
struct wmi_pdev_temperature_event {
/* temperature value in Celcius degree */
__le32 temperature;
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] ath10k: fix spurious tx/rx during boot
From: Michal Kazior @ 2016-07-19 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, marek.puzyniak, Michal Kazior
Hi,
Recently Marek discovered the device transmits
"stuff" during device/driver boot.
The problem is related with the long known "no
channel" warning and it's a consequence of the
same bug - rx filters not being programmed
properly by firmware.
See last patch for more details.
I didn't do extensive testing but I can confirm
that I am no longer able to reroduce "no channel"
warnings and Marek tells me he no longer sees any
signal bumps on oscilloscope with his QCA9882.
Michal Kazior (4):
ath10k: implement wmi echo command
ath10k: implement wmi echo event
ath10k: add wmi command barrier utility
ath10k: fix spurious tx/rx during boot
drivers/net/wireless/ath/ath10k/core.c | 68 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/wmi-ops.h | 29 +++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 57 +++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 83 ++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 5 ++
6 files changed, 242 insertions(+), 1 deletion(-)
--
2.1.4
^ permalink raw reply
* Re: [PATCH 4/4] brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
From: Arend Van Spriel @ 2016-07-19 10:26 UTC (permalink / raw)
To: Florian Fainelli, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <1468884277-18606-5-git-send-email-f.fainelli@gmail.com>
On 19-7-2016 1:24, Florian Fainelli wrote:
> wlc_phy_txpower_get_current() does a logical OR of power->flags, which
> presumes that power.flags was initiliazed earlier by the caller,
> unfortunately, this is not the case, so make sure we zero out the struct
> tx_power before calling into wlc_phy_txpower_get_current().
>
> Reported-by: coverity (CID 146011)
> Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
> index dd9162722495..0ab865de1491 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
> @@ -87,7 +87,7 @@ void
> brcms_c_stf_ss_algo_channel_get(struct brcms_c_info *wlc, u16 *ss_algo_channel,
> u16 chanspec)
> {
> - struct tx_power power;
> + struct tx_power power = { };
> u8 siso_mcs_id, cdd_mcs_id, stbc_mcs_id;
>
> /* Clear previous settings */
>
^ permalink raw reply
* Re: [PATCH 1/4] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
From: Arend Van Spriel @ 2016-07-19 10:19 UTC (permalink / raw)
To: Florian Fainelli, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <1468884277-18606-2-git-send-email-f.fainelli@gmail.com>
On 19-7-2016 1:24, Florian Fainelli wrote:
> In case brcmf_sdiod_recv_chain() cannot complete a succeful call to
> brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we
> should, fix this.
>
> Reported-by: coverity (CID 1164856)
> Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index c4b89d27e2e8..f549c25608d6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -726,8 +726,10 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
> return -ENOMEM;
> err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
> glom_skb);
> - if (err)
> + if (err) {
> + brcmu_pkt_buf_free_skb(glom_skb);
> goto done;
> + }
>
> skb_queue_walk(pktq, skb) {
> memcpy(skb->data, glom_skb->data, skb->len);
>
^ permalink raw reply
* Re: [PATCH 2/4] brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill
From: Arend Van Spriel @ 2016-07-19 9:25 UTC (permalink / raw)
To: Florian Fainelli, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <1468884277-18606-3-git-send-email-f.fainelli@gmail.com>
On 19-7-2016 1:24, Florian Fainelli wrote:
> In case dma_mapping_error() returns an error in dma_rxfill, we would be
> leaking a packet that we allocated with brcmu_pkt_buf_get_skb().
>
> Reported-by: coverity (CID 1081819)
> Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()")
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
> index 796f5f9d5d5a..b7df576bb84d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
> @@ -1079,8 +1079,10 @@ bool dma_rxfill(struct dma_pub *pub)
>
> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> DMA_FROM_DEVICE);
> - if (dma_mapping_error(di->dmadev, pa))
> + if (dma_mapping_error(di->dmadev, pa)) {
> + brcmu_pkt_buf_free_skb(p);
> return false;
> + }
>
> /* save the free packet pointer */
> di->rxp[rxout] = p;
>
^ permalink raw reply
* Re: [PATCH 0/4] brcm80211: Misc coverity fixes
From: Arend Van Spriel @ 2016-07-19 9:20 UTC (permalink / raw)
To: Florian Fainelli, brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, hante.meuleman
In-Reply-To: <1468884277-18606-1-git-send-email-f.fainelli@gmail.com>
+ Bob
On 19-7-2016 1:24, Florian Fainelli wrote:
> Hi,
>
> This patch series addresses several coverity issues, they all seemed relevant
> to me.
Hi Florian,
Been a while so nice to see coverity fixes popping up. Actually
something that I have on my todo list to add our brcm80211 to coverity
within Broadcom. So being curious as to whether this comes from a public
coverity server like scan.coverity.com. Maybe bit redundant to setup
internally if there is a good coverity analysis publicly available.
> There is also a ton of warnings in Coverity caused by brcmf_fil_iovar_int_get()
> and friends because of the initial access:
>
> __le32 data_le = cpu_to_le32(*data) which can utilize unitialized memory. I am
> not sure if we actually care about any kind of initial, value, but if we don't,
> then the fix should be fairly obvious.
If we are talking only about "get" variant than we mostly don't care.
Some getters support filter variables to be passed towards firmware. I
have not looked at the analysis to give any judgement here.
Regards,
Arend
> Thanks!
>
>
> Florian Fainelli (4):
> brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
> brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill
> brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
> brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 4 +++-
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 2 +-
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c | 2 +-
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* RE: [v8] Add new mac80211 driver mwlwifi.
From: David Lin @ 2016-07-19 7:54 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Chor Teck Law,
Pete Hsieh
In-Reply-To: <20160719074152.73F776043B@smtp.codeaurora.org>
S2FsbGUgVmFsbyBbbWFpbHRvOmt2YWxvQGNvZGVhdXJvcmEub3JnXSB3cm90ZTouDQo+IA0KPiBE
YXZpZCBMaW4gPGRsaW5AbWFydmVsbC5jb20+IHdyb3RlOg0KPiA+IFRoaXMgcGF0Y2ggcHJvdmlk
ZXMgdGhlIG13bHdpZmkgZHJpdmVyIGZvciBNYXJ2ZWxsIDg4NjMsIDg4NjQgYW5kIDg4OTcNCj4g
PiBjaGlwc2V0cy4NCj4gPiBUaGlzIGRyaXZlciB3YXMgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhl
IG9wZW53cnQub3JnIHByb2plY3QgdG8NCj4gPiBzdXBwb3J0IExpbmtzeXMgV1JUMTkwMEFDIGFu
ZCBpcyBtYWludGFpbmVkIG9uDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9rYWxvei9td2x3aWZpLg0K
PiA+DQo+ID4gVGhlIG13bHdpZmkgZHJpdmVyIGRpZmZlcnMgZnJvbSBleGlzdGluZyBtd2lmaWV4
IGRyaXZlcjoNCj4gPiBvIG13bHdpZmkgaXMgYSAic29mdG1hYyBkcml2ZXIiIHVzaW5nIHRoZSBr
ZXJuZWwgbWFjODAyLjExIHN1YnN5c3RlbQ0KPiA+IHRvIHByb3ZpZGUgZnVsbCBBUC9XaXJlbGVz
cyBCcmlkZ2UgZnVuY3Rpb25hbGl0eSAocm91dGVycykuDQo+ID4gbyBtd2lmaWV4IGlzIGEgImZ1
bGxtYWMgZHJpdmVyIiB3aGljaCBwcm92aWRlcyBhIGNvbXByZWhlbnNpdmUgc2V0IG9mDQo+ID4g
Y2xpZW50IGZ1bmN0aW9ucyAobGFwdG9wcy9lbWJlZGRlZCBkZXZpY2VzKSBvIG9ubHkgbXdsd2lm
aSBzdXBwb3J0cw0KPiA+IE1hcnZlbGwgQVAgY2hpcCA4ODZYIHNlcmllcw0KPiA+DQo+ID4gTk9U
RTogVXNlcnMgd2l0aCBNYXJ2ZWxsIDg4Vzg4OTcgY2hpcHNldHMgY3VycmVudGx5IHNob3VsZCBl
bmFibGUNCj4gPiAoQ09ORklHPVkgb3IgTSkgZWl0aGVyIENPTkZJR19NV0lGSUVYIG9yIENPTkZJ
R19NV0xXSUZJLCBOT1QNCj4gQk9USC4NCj4gPg0KPiA+IG13bHdpZmkgZHJpdmVyIGxldmVyYWdl
ZCBjb2RlIGZyb20gZXhpc3RpbmcgTVdMOEsgZHJpdmVyIGluIHRoZQ0KPiA+IGZvbGxvd2luZyBh
cmVhczoNCj4gPiAtIDgwMi4xMW4gc2V0dGluZyBmb3IgbWFjODAyMTENCj4gPiAtIEZ1bmN0aW9u
cyBuZWVkZWQgdG8gaG9vayB1cCB0byBtYWM4MDIxMQ0KPiA+IC0gSW50ZXJhY3Rpb25zIHdpdGgg
bWFjODAyMTEgdG8gZXN0YWJsaXNoIEJBIHN0cmVhbXMNCj4gPiAtIFBhcnRpYWwgZmlybXdhcmUg
QVBJcywgc29tZSBkYXRhIGZpZWxkcw0KPiA+IC0gTWV0aG9kIHRvIHBhc3MgUnggcGFja2V0cyB0
byBtYWM4MDIxMSBleGNlcHQgMTFhYyByYXRlcw0KPiA+DQo+ID4gSW4gYWRkaXRpb24sIG13bHdp
ZmkgZHJpdmVyIHN1cHBvcnRzOg0KPiA+IC0gZnV0dXJlIHNjYWxhYmlsaXR5IGFuZCBmdXR1cmUg
ZGV2ZWxvcG1lbnQgKHJlZmFjdG9yZWQgc291cmNlIGNvZGUpDQo+ID4gLSBNYXJ2ZWxsIDgwMi4x
MWFjIGNoaXBzZXRzLCBpbmNsdWRpbmcgY29tYm8gQlQgZGV2aWNlcw0KPiA+IC0gODAyLjExYWMg
cmVsYXRlZCBzZXR0aW5ncyBhbmQgZnVuY3Rpb25zDQo+ID4gLSBjb25jdXJyZW50IEFQK1NUQSBm
dW5jdGlvbmFsaXRpZXMgd2l0aCBzaW5nbGUgZmlybXdhcmUgcGVyIGNoaXANCj4gPiAtIGZpcm13
YXJlIEFQSXMgZm9yIHRoZSBzdXBwb3J0ZWQgY2hpcHNldA0KPiA+IC0gY29tbXVuaWNhdGluZyBu
ZXcgbWFjODAyMTEgc2V0dGluZ3MgdG8gZmlybXdhcmUNCj4gPiAtIERpZmZlcmVudCBUWC9SWCBk
YXRhcGF0aCB3aGVyZSBhcHBsaWNhYmxlDQo+ID4gLSBBLU1TRFUgYW5kIEEtTVBEVQ0KPiA+IC0g
UmVmaW5lZCB0aGUgY29kZSB0byBlc3RhYmxpc2ggQkEgc3RyZWFtcw0KPiA+DQo+ID4gU2lnbmVk
LW9mZi1ieTogRGF2aWQgTGluIDxkbGluQG1hcnZlbGwuY29tPg0KPiANCj4gSSBhcHBsaWVkIHRo
aXMgdG8gdGhlIHBlbmRpbmcgYnJhbmNoIGZvciBrYnVpbGQgYm90IHRvIHJ1biBpdCdzIHRlc3Rz
Lg0KPiANCg0KVGhhbmtzLg0KDQo+IC0tDQo+IFNlbnQgYnkgcHdjbGkNCj4gaHR0cHM6Ly9wYXRj
aHdvcmsua2VybmVsLm9yZy9wYXRjaC85MjAxNjYzLw0KDQo=
^ permalink raw reply
* Re: [v8] Add new mac80211 driver mwlwifi.
From: Kalle Valo @ 2016-07-19 7:41 UTC (permalink / raw)
To: David Lin
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Chor Teck Law,
Pete Hsieh
In-Reply-To: <72b910b6cca843daaaac0dc8d9fa138e@SC-EXCH02.marvell.com>
David Lin <dlin@marvell.com> wrote:
> This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897
> chipsets.
> This driver was developed as part of the openwrt.org project to support
> Linksys WRT1900AC and is maintained on https://github.com/kaloz/mwlwifi.
>
> The mwlwifi driver differs from existing mwifiex driver:
> o mwlwifi is a "softmac driver" using the kernel mac802.11 subsystem
> to provide full AP/Wireless Bridge functionality (routers).
> o mwifiex is a "fullmac driver" which provides a comprehensive set of
> client functions (laptops/embedded devices)
> o only mwlwifi supports Marvell AP chip 886X series
>
> NOTE: Users with Marvell 88W8897 chipsets currently should enable
> (CONFIG=Y or M) either CONFIG_MWIFIEX or CONFIG_MWLWIFI, NOT BOTH.
>
> mwlwifi driver leveraged code from existing MWL8K driver in the
> following areas:
> - 802.11n setting for mac80211
> - Functions needed to hook up to mac80211
> - Interactions with mac80211 to establish BA streams
> - Partial firmware APIs, some data fields
> - Method to pass Rx packets to mac80211 except 11ac rates
>
> In addition, mwlwifi driver supports:
> - future scalability and future development (refactored source code)
> - Marvell 802.11ac chipsets, including combo BT devices
> - 802.11ac related settings and functions
> - concurrent AP+STA functionalities with single firmware per chip
> - firmware APIs for the supported chipset
> - communicating new mac80211 settings to firmware
> - Different TX/RX datapath where applicable
> - A-MSDU and A-MPDU
> - Refined the code to establish BA streams
>
> Signed-off-by: David Lin <dlin@marvell.com>
I applied this to the pending branch for kbuild bot to run it's tests.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9201663/
^ permalink raw reply
* Re: [v2, RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-07-19 7:39 UTC (permalink / raw)
To: Igor Mitsyanko
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath, Igor Mitsyanko
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> From: Avinash Patil <avinashp@quantenna.com>
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
I applied this to the pending branch so that kbuild bot can run build tests on
it. Let's see what it finds.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9188969/
^ permalink raw reply
* Re: [PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol
From: Brian Norris @ 2016-07-19 7:26 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless, David Woodhouse,
open list:MEMORY TECHNOLOGY DEVICES (MTD), open list
In-Reply-To: <1468912123-14899-1-git-send-email-zajec5@gmail.com>
On Tue, Jul 19, 2016 at 09:08:32AM +0200, Rafał Miłecki wrote:
> We dropped strict MIPS dependency for bcm47xxsflash driver in:
> commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of
> KSEG0ADDR()") but using ioremap_cache still limits building it to few
> selected architectures only.
>
> A recent commit 57d8f7dd2132 ("bcma: allow enabling serial flash support
> on non-MIPS SoCs") automatically dropped MIPS dependency for
> MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.
>
> The bcma change is alright as it doesn't break building bcma code in any
> way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
> which need it and can build it (by providing ioremap_cache).
>
> Fixes: 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> Cc: Brian Norris <computersforpeace@gmail.com>
While I might prefer we have a better consistent set of portable I/O
accessors (it's really a mess), it seems quite reasonable to restrict
the damage to ARM and MIPS here if it saves some short-term hassle:
Acked-by: Brian Norris <computersforpeace@gmail.com>
> ---
> That bcma commit breaking building landed in the wireless-drivers-next.
> Is that possible to get this patch through the same tree?
That's fine with me.
Regards,
Brian
> ---
> drivers/mtd/devices/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
> index f73c416..64a2485 100644
> --- a/drivers/mtd/devices/Kconfig
> +++ b/drivers/mtd/devices/Kconfig
> @@ -114,7 +114,7 @@ config MTD_SST25L
>
> config MTD_BCM47XXSFLASH
> tristate "R/O support for serial flash on BCMA bus"
> - depends on BCMA_SFLASH
> + depends on BCMA_SFLASH && (MIPS || ARM)
> help
> BCMA bus can have various flash memories attached, they are
> registered by bcma as platform devices. This enables driver for
> --
> 1.8.4.5
>
^ permalink raw reply
* RE: [PATCH v7] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-07-19 7:25 UTC (permalink / raw)
To: Kalle Valo, Eyal Reizer
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-spi@vger.kernel.org, robh@kernel.org
In-Reply-To: <87poqaum6t.fsf@kamboji.qca.qualcomm.com>
> > From: Eyal Reizer <eyalreizer@gmail.com>
> >
> > Add support for using with both wl12xx and wl18xx.
> >
> > - all wilink family needs special init command for entering wspi mode.
> > extra clock cycles should be sent after the spi init command while the
> > cs pin is high.
> > - Use inverted chip select for sending a dummy 4 bytes command that
> > completes the init stage.
> >
> > Signed-off-by: Eyal Reizer <eyalr@ti.com>
> > Acked-by: Rob Herring <robh@kernel.org>
>
> This looks ok in patchwork:
>
> https://patchwork.kernel.org/patch/9235983/
>
> Because you used ti.com in S-o-b I assume From should also use ti.com. I can
> fix that before I apply but please confirm that's really the case?
>
Yes, S-o-b is eyalr@ti.com.
Thank you!
--
Eyal Reizer
^ 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