* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Johannes Berg @ 2016-12-16 9:25 UTC (permalink / raw)
To: Thiagarajan, Vasanthakumar, nbd@nbd.name; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <58537DA3.1090901@qti.qualcomm.com>
On Fri, 2016-12-16 at 05:37 +0000, Thiagarajan, Vasanthakumar wrote:
> QCA988X does not have capability to configure vif specific decap
> mode. Encap mode is configurable per packet for all the ath10k based
> chips so this part should be fine to support per vif configuration.
Ok, that's good.
> Newer QCA chips like QCA9984, QCA4019, QCA9888 and QCA99X0 supports
> decap mode configuration per vif.
Also good.
> To reduce the complexity, we can probably make per vif encap/decap
> configuration mandatory to enable ethernet frame format, not sure how
> this will work with non-QCA capable hardware.
I don't know either, nobody else has talked about it yet :-)
Anyway, if we (for now) we can assume that TX can be constant 802.3
encap mode once enabled, we don't have to deal with the messy dynamic
switching you had there.
RX can switch more dynamically independent of all the mac80211 code
since it basically just means the driver calls one function or the
other - if everything is offloaded correctly there shouldn't really be
a difference.
Then also things like IEEE80211_CONF_CHANGE_80211_HDR_OFFL etc. can go
away entirely because you don't have to switch anything dynamically at
a global level. That will simplify everything a lot.
johannes
^ permalink raw reply
* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
From: Johannes Berg @ 2016-12-16 9:13 UTC (permalink / raw)
To: Thiagarajan, Vasanthakumar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <58538DFA.1090808@qti.qualcomm.com>
> Ok. So it is mainly for encap there needs to be some capability
> advertisement from driver
Obviously, since mac80211 needs to pick the ndo struct to use.
> because for decap driver would use appropriate mac80211 Rx function
> to indicate?
That should be sufficient, no?
In fact, for RX, assuming that the relevant things are offloaded (and
we should ensure that in the RX function(s)), the driver could be
allowed to switch around as dynamically as it wants to (as long as it's
not mixing in _irqsafe calls or doing other things that might cause
reordering)
> > > + memset(&rx, 0, sizeof(rx));
> >
> > That seems a bit pointless?
>
> Hmmm, is it not that all member other than the ones initialized will
> be junk and might result in crash when accessing uninitialized
> pointer member like napi?
Oh, ok. I thought it was actually all filled.
You really should support NAPI though.
> > Yeah, that's not nice - perhaps we can provide the TID out of band?
>
> Right. This is possible with ath10k where 802.11 header is also
> available in Rx desc of the frame irrespective of the format of the
> Rx payload
We could go with that for now then. Leave a comment indicating that if
it can't be provided, we need to disable statistics for it?
> >
> > > + return;
> > > +
> > > +mic_fail:
> > > + cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> > > + (status->flag &
> > > RX_FLAG_MCAST)
> > > ?
> > > + NL80211_KEYTYPE_GROUP :
> > > + NL80211_KEYTYPE_PAIRWISE,
> > > + key ? key->conf.keyidx :
> > > -1,
> > > + NULL, GFP_ATOMIC);
> >
> > Do we really want to handle that inline here? The driver probably
> > has a different check to even set RX_FLAG_MMIC_ERROR, so we could
> > just ask it to call cfg80211_michael_mic_failure() [or a wrapper to
> > get sdata->dev] instead? I guess this works too though, and might
> > be easier to understand.
>
> Yeah, driver directly reporting MIC failure will be fine. I think a
> wrapper may be required rather than mac80211 based driver directly
> calling cfg80211 function?
It would be, because the driver can't get sdata->dev (although I think
there's now a hidden path to do this?)
johannes
^ permalink raw reply
* Re: [PATCH mac80211-next] rfkill: hide unused goto label
From: Johannes Berg @ 2016-12-16 9:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, João Paulo Rechi Vita,
Michał Kępień, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20161216084425.1692828-1-arnd@arndb.de>
On Fri, 2016-12-16 at 09:44 +0100, Arnd Bergmann wrote:
> A cleanup introduced a harmless warning in some configurations:
>
> net/rfkill/core.c: In function 'rfkill_init':
> net/rfkill/core.c:1350:1: warning: label 'error_input' defined but
> not used [-Wunused-label]
>
> This adds another #ifdef around the label to match that around the
> caller.
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH mac80211-next] rfkill: hide unused goto label
From: Arnd Bergmann @ 2016-12-16 8:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, David S. Miller, João Paulo Rechi Vita,
Michał Kępień, linux-wireless, netdev,
linux-kernel
A cleanup introduced a harmless warning in some configurations:
net/rfkill/core.c: In function 'rfkill_init':
net/rfkill/core.c:1350:1: warning: label 'error_input' defined but not used [-Wunused-label]
This adds another #ifdef around the label to match that around the
caller.
Fixes: 6124c53edeea ("rfkill: Cleanup error handling in rfkill_init()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/rfkill/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f6b01f3616e5..b7adaee69756 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1347,8 +1347,10 @@ static int __init rfkill_init(void)
return 0;
+#ifdef CONFIG_RFKILL_INPUT
error_input:
rfkill_any_led_trigger_unregister();
+#endif
error_led_trigger:
misc_deregister(&rfkill_miscdev);
error_misc:
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] mwifiex: change width of MAC control variable
From: Amitkumar Karwar @ 2016-12-16 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
Firmware has started making use of reserved field.
Accordingly change curr_pkt_filter from u16 to u32.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/fw.h | 18 ++++++++----------
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 4 ++--
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index ea45594..f48247c 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -434,14 +434,13 @@ enum mwifiex_channel_flags {
#define HostCmd_ACT_BITWISE_SET 0x0002
#define HostCmd_ACT_BITWISE_CLR 0x0003
#define HostCmd_RESULT_OK 0x0000
-
-#define HostCmd_ACT_MAC_RX_ON 0x0001
-#define HostCmd_ACT_MAC_TX_ON 0x0002
-#define HostCmd_ACT_MAC_WEP_ENABLE 0x0008
-#define HostCmd_ACT_MAC_ETHERNETII_ENABLE 0x0010
-#define HostCmd_ACT_MAC_PROMISCUOUS_ENABLE 0x0080
-#define HostCmd_ACT_MAC_ALL_MULTICAST_ENABLE 0x0100
-#define HostCmd_ACT_MAC_ADHOC_G_PROTECTION_ON 0x2000
+#define HostCmd_ACT_MAC_RX_ON BIT(0)
+#define HostCmd_ACT_MAC_TX_ON BIT(1)
+#define HostCmd_ACT_MAC_WEP_ENABLE BIT(3)
+#define HostCmd_ACT_MAC_ETHERNETII_ENABLE BIT(4)
+#define HostCmd_ACT_MAC_PROMISCUOUS_ENABLE BIT(7)
+#define HostCmd_ACT_MAC_ALL_MULTICAST_ENABLE BIT(8)
+#define HostCmd_ACT_MAC_ADHOC_G_PROTECTION_ON BIT(13)
#define HostCmd_BSS_MODE_IBSS 0x0002
#define HostCmd_BSS_MODE_ANY 0x0003
@@ -1084,8 +1083,7 @@ struct host_cmd_ds_802_11_mac_address {
};
struct host_cmd_ds_mac_control {
- __le16 action;
- __le16 reserved;
+ __le32 action;
};
struct host_cmd_ds_mac_multicast_adr {
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 5f7a010..5c82972 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -529,7 +529,7 @@ struct mwifiex_private {
u8 tx_timeout_cnt;
struct net_device *netdev;
struct net_device_stats stats;
- u16 curr_pkt_filter;
+ u32 curr_pkt_filter;
u32 bss_mode;
u32 pkt_tx_ctrl;
u16 tx_power_level;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index ad2dfd8..2f1f4d1 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -76,7 +76,7 @@
*/
static int mwifiex_cmd_mac_control(struct mwifiex_private *priv,
struct host_cmd_ds_command *cmd,
- u16 cmd_action, u16 *action)
+ u16 cmd_action, u32 *action)
{
struct host_cmd_ds_mac_control *mac_ctrl = &cmd->params.mac_ctrl;
@@ -89,7 +89,7 @@ static int mwifiex_cmd_mac_control(struct mwifiex_private *priv,
cmd->command = cpu_to_le16(HostCmd_CMD_MAC_CONTROL);
cmd->size =
cpu_to_le16(sizeof(struct host_cmd_ds_mac_control) + S_DS_GEN);
- mac_ctrl->action = cpu_to_le16(*action);
+ mac_ctrl->action = cpu_to_le32(*action);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] mwifiex: Enable dynamic bandwidth signalling
From: Amitkumar Karwar @ 2016-12-16 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1481873145-5381-1-git-send-email-akarwar@marvell.com>
Enable dynamic bandwidth signalling by setting the corresponding
bit in MAC control register.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/init.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index f48247c..55db158f 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -441,6 +441,7 @@ enum mwifiex_channel_flags {
#define HostCmd_ACT_MAC_PROMISCUOUS_ENABLE BIT(7)
#define HostCmd_ACT_MAC_ALL_MULTICAST_ENABLE BIT(8)
#define HostCmd_ACT_MAC_ADHOC_G_PROTECTION_ON BIT(13)
+#define HostCmd_ACT_MAC_DYNAMIC_BW_ENABLE BIT(16)
#define HostCmd_BSS_MODE_IBSS 0x0002
#define HostCmd_BSS_MODE_ANY 0x0003
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index 87cda4f..7569483 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -92,7 +92,8 @@ int mwifiex_init_priv(struct mwifiex_private *priv)
for (i = 0; i < ARRAY_SIZE(priv->wep_key); i++)
memset(&priv->wep_key[i], 0, sizeof(struct mwifiex_wep_key));
priv->wep_key_curr_index = 0;
- priv->curr_pkt_filter = HostCmd_ACT_MAC_RX_ON | HostCmd_ACT_MAC_TX_ON |
+ priv->curr_pkt_filter = HostCmd_ACT_MAC_DYNAMIC_BW_ENABLE |
+ HostCmd_ACT_MAC_RX_ON | HostCmd_ACT_MAC_TX_ON |
HostCmd_ACT_MAC_ETHERNETII_ENABLE;
priv->beacon_period = 100; /* beacon interval */
--
1.9.1
^ permalink raw reply related
* Re: wl1251 & mac address & calibration data
From: Daniel Wagner @ 2016-12-16 7:25 UTC (permalink / raw)
To: Luis R. Rodriguez, Arend Van Spriel, Tom Gundersen, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki
Cc: Pali Rohár, Kalle Valo, Sebastian Reichel, Pavel Machek,
Michal Kazior, Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren,
linux-wireless, Network Development, linux-kernel@vger.kernel.org,
David Woodhouse, Takashi Iwai, Josh Boyer, Dmitry Torokhov
In-Reply-To: <CAB=NE6VHF+U7DzapENvLMKtN4Dgi9J0qMoeUJ8o4vSwc2-rRFQ@mail.gmail.com>
On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> For the new API a solution for "fallback mechanisms" should be clean
> though and I am looking to stay as far as possible from the existing
> mess. A solution to help both the old API and new API is possible for
> the "fallback mechanism" though -- but for that I can only refer you
> at this point to some of Daniel Wagner and Tom Gunderson's firmwared
> deamon prospect. It should help pave the way for a clean solution and
> help address other stupid issues.
The firmwared project is hosted here
https://github.com/teg/firmwared
As Luis pointed out, firmwared relies on FW_LOADER_USER_HELPER_FALLBACK,
which is not enabled by default. I don't see any reason why firmwared
should not also support loading calibration data. If we find a sound way
to do this.
As you can see from the commit history it is a pretty young project and
more ore less reanimation of the old udev firmware loader feature. We
are getting int into shape, adding integration tests etc.
The main motivation for this project is the get movement back in stuck
discussion on the firmware loader API. Luis was very busy writing up all
the details on the current situation and purely from the amount of
documentation need to describe the API you can tell something is awry.
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
From: Thiagarajan, Vasanthakumar @ 2016-12-16 6:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481794695.31776.7.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMzowOCBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IFRoaXMgcnggcGF0aCBvbmx5IGNoZWNrcyBpZiB0aGUgZHJpdmVyIGhhcyBhZHZl
cnRpc2VkDQo+PiBpdCdzIHN1cHBvcnQgb2YgODAyLjExIGhlYWRlciBlbmNhcC9kZWNhcCBvZmZs
b2FkIGZvcg0KPj4gZGF0YSBmcmFtZXMuDQo+DQo+IEknbSBub3QgZXZlbiBzdXJlIEkgc2VlIHRo
ZSBwb2ludCBpbiB0aGF0PyBPdGhlciB0aGFuIHRoYXQgKGFuZCB0aGUNCj4gdmFyaW91cyBvdGhl
ciBvZmZsb2FkIHJlcXVpcmVtZW50cyksIGl0IHNlZW1zIHRoYXQgZW5jYXAvZGVjYXAgY291bGQg
YmUNCj4gY29uc2lkZXJlZCBvcnRob2dvbmFsLg0KDQpPay4gU28gaXQgaXMgbWFpbmx5IGZvciBl
bmNhcCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudA0KZnJv
bSBkcml2ZXIgYmVjYXVzZSBmb3IgZGVjYXAgZHJpdmVyIHdvdWxkIHVzZSBhcHByb3ByaWF0ZSBt
YWM4MDIxMSBSeCBmdW5jdGlvbg0KdG8gaW5kaWNhdGU/DQoNCj4NCj4+ICsJICogQWRob2MgaW50
ZXJmYWNlIGRlcGVuZHMgb24gYnNzaWQgdG8gdWRwYXRlIGxhc3RfcnguDQo+DQo+IHR5cGUgLSB1
cGRhdGUNCj4NCj4+ICsJaWYgKCEoc3RhdHVzLT5mbGFnICYgUlhfRkxBR19NQ0FTVCkpIHsNCj4+
ICsJCXN0YS0+cnhfc3RhdHMubGFzdF9yeCA9IGppZmZpZXM7DQo+PiArCQlzdGEtPnJ4X3N0YXRz
Lmxhc3RfcmF0ZSA9DQo+PiBzdGFfc3RhdHNfZW5jb2RlX3JhdGUoc3RhdHVzKTsNCj4+ICsJfQ0K
Pg0KPiBZb3Ugc2hvdWxkIHByb2JhYmx5IHJlbmFtZSB0aGF0IGZsYWcgdG8gc29tZXRoaW5nIGxp
a2UNCj4gUlhfRkxBR184MDIxMV9NQ0FTVCBzaW5jZSBvdGhlcndpc2UgaXQncyBjb25mdXNpbmcg
d2l0aCB0aGUgbmV4dA0KPiBtdWx0aWNhc3QgZXRoZXIgYWRkciBjaGVjazoNCg0KU3VyZS4NCg0K
Pg0KPj4gKwlpZiAoc2RhdGEtPnZpZi50eXBlID09IE5MODAyMTFfSUZUWVBFX1NUQVRJT04gJiYN
Cj4+ICsJICAgICFpc19tdWx0aWNhc3RfZXRoZXJfYWRkcihlaGRyLT5oX2Rlc3QpKQ0KPj4gKwkJ
aWVlZTgwMjExX3N0YV9yZXNldF9jb25uX21vbml0b3Ioc2RhdGEpOw0KPg0KPiBCdXQgdGhpcyBj
b3VsZCBqdXN0IGFsc28gdXNlIHRoZSBmbGFnLCBzaW5jZSBpbiBzdGF0aW9uIG1vZGUgdGhlIHR3
bw0KPiBhcmUgZXF1aXZhbGVudCwgYW5kIGl0J2QgYmUgZWFzaWVyIHRvIGZpZ3VyZSBvdXQgaWYg
dGhpcyB3YXMgImVsc2UgaWYNCj4gKHN0YXRpb24gbW9kZSkiPw0KDQpBaCwgY29ycmVjdC4NCg0K
Pg0KPj4gKwltZW1zZXQoJnJ4LCAwLCBzaXplb2YocngpKTsNCj4NCj4gVGhhdCBzZWVtcyBhIGJp
dCBwb2ludGxlc3M/DQoNCkhtbW0sIGlzIGl0IG5vdCB0aGF0IGFsbCBtZW1iZXIgb3RoZXIgdGhh
biB0aGUgb25lcyBpbml0aWFsaXplZCB3aWxsIGJlIGp1bmsgYW5kIG1pZ2h0DQpyZXN1bHQgaW4g
Y3Jhc2ggd2hlbiBhY2Nlc3NpbmcgdW5pbml0aWFsaXplZCBwb2ludGVyIG1lbWJlciBsaWtlIG5h
cGk/DQoNCj4NCj4+ICsJcnguc2tiID0gc2tiOw0KPj4gKwlyeC5zZGF0YSA9IHNkYXRhOw0KPj4g
KwlyeC5sb2NhbCA9IGxvY2FsOw0KPj4gKwlyeC5zdGEgPSBzdGE7DQo+PiArDQo+PiArCWlmICh2
aWYtPnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVfQVBfVkxBTiAmJiBzZGF0YS0+YnNzICYmDQo+PiAr
CSAgICB1bmxpa2VseShlaGRyLT5oX3Byb3RvID09IHNkYXRhLT5jb250cm9sX3BvcnRfcHJvdG9j
b2wpKQ0KPj4gew0KPj4gKwkJc2RhdGEgPSBjb250YWluZXJfb2Yoc2RhdGEtPmJzcywgc3RydWN0
DQo+PiBpZWVlODAyMTFfc3ViX2lmX2RhdGEsDQo+PiArCQkJCSAgICAgdS5hcCk7DQo+PiArCQlk
ZXYgPSBzZGF0YS0+ZGV2Ow0KPj4gKwkJcnguc2RhdGEgPSBzZGF0YTsNCj4+ICsJfQ0KPj4gKw0K
Pj4gKwlyeC5za2ItPmRldiA9IGRldjsNCj4+ICsNCj4+ICsJLyogWFhYOiBTaW5jZSByeC5zZXFu
b19pZHggaXMgbm90IGF2YWlsYWJsZSBmb3IgZGVjYXANCj4+IG9mZmxvYWRlZCBmcmFtZXMNCj4+
ICsJICogcnggbXNkdSBzdGF0cyB1cGRhdGUgYXQgdGhlIHNlcW5vX2lkeCBpbg0KPj4gaWVlZTgw
MjExX2RlbGl2ZXJfc2tiKCkNCj4+ICsJICogd2lsbCBhbHdheXMgYmUgdXBkYXRlZCBhdCBpbmRl
eCAwIGFuZCB3aWxsIG5vdCBiZSB2ZXJ5DQo+PiB1c2VmdWwuDQo+PiArCSAqLw0KPj4gKwlpZWVl
ODAyMTFfZGVsaXZlcl9za2IoJnJ4KTsNCj4NCj4gWWVhaCwgdGhhdCdzIG5vdCBuaWNlIC0gcGVy
aGFwcyB3ZSBjYW4gcHJvdmlkZSB0aGUgVElEIG91dCBvZiBiYW5kPw0KDQpSaWdodC4gVGhpcyBp
cyBwb3NzaWJsZSB3aXRoIGF0aDEwayB3aGVyZSA4MDIuMTEgaGVhZGVyIGlzIGFsc28gYXZhaWxh
YmxlIGluIFJ4DQpkZXNjIG9mIHRoZSBmcmFtZSBpcnJlc3BlY3RpdmUgb2YgdGhlIGZvcm1hdCBv
ZiB0aGUgUnggcGF5bG9hZA0KDQogIElmDQo+IG5vdCwgd2UnbGwgaGF2ZSB0byBkaXNhYmxlIHRo
b3NlIHN0YXRpc3RpY3MgKmFsbCB0aGUgd2F5KiwgaS5lLiBub3QNCj4gZXZlbiByZXBvcnQgdGhl
bSB0byB1c2Vyc3BhY2Ugd2hlbiBmaWxsaW5nIHNpbmZvLg0KDQpZZXMsIHRoaXMgbWF5IGJlIHRo
ZSBvcHRpb24gd2hlbiBkcml2ZXIgaXMgdW5hd2FyZSBvZiByeCBwYWNrZXQgdGlkLg0KDQo+DQo+
PiArCXJldHVybjsNCj4+ICsNCj4+ICttaWNfZmFpbDoNCj4+ICsJY2ZnODAyMTFfbWljaGFlbF9t
aWNfZmFpbHVyZShzZGF0YS0+ZGV2LCBzdGEtPmFkZHIsDQo+PiArCQkJCSAgICAgKHN0YXR1cy0+
ZmxhZyAmIFJYX0ZMQUdfTUNBU1QpDQo+PiA/DQo+PiArCQkJCSAgICAgTkw4MDIxMV9LRVlUWVBF
X0dST1VQIDoNCj4+ICsJCQkJICAgICBOTDgwMjExX0tFWVRZUEVfUEFJUldJU0UsDQo+PiArCQkJ
CSAgICAga2V5ID8ga2V5LT5jb25mLmtleWlkeCA6IC0xLA0KPj4gKwkJCQkgICAgIE5VTEwsIEdG
UF9BVE9NSUMpOw0KPg0KPiBEbyB3ZSByZWFsbHkgd2FudCB0byBoYW5kbGUgdGhhdCBpbmxpbmUg
aGVyZT8gVGhlIGRyaXZlciBwcm9iYWJseSBoYXMgYQ0KPiBkaWZmZXJlbnQgY2hlY2sgdG8gZXZl
biBzZXQgUlhfRkxBR19NTUlDX0VSUk9SLCBzbyB3ZSBjb3VsZCBqdXN0IGFzayBpdA0KPiB0byBj
YWxsIGNmZzgwMjExX21pY2hhZWxfbWljX2ZhaWx1cmUoKSBbb3IgYSB3cmFwcGVyIHRvIGdldCBz
ZGF0YS0+ZGV2XQ0KPiBpbnN0ZWFkPyBJIGd1ZXNzIHRoaXMgd29ya3MgdG9vIHRob3VnaCwgYW5k
IG1pZ2h0IGJlIGVhc2llciB0bw0KPiB1bmRlcnN0YW5kLg0KDQpZZWFoLCBkcml2ZXIgZGlyZWN0
bHkgcmVwb3J0aW5nIE1JQyBmYWlsdXJlIHdpbGwgYmUgZmluZS4gSSB0aGluayBhIHdyYXBwZXIN
Cm1heSBiZSByZXF1aXJlZCByYXRoZXIgdGhhbiBtYWM4MDIxMSBiYXNlZCBkcml2ZXIgZGlyZWN0
bHkgY2FsbGluZyBjZmc4MDIxMQ0KZnVuY3Rpb24/DQoNClZhc2FudGg=
^ permalink raw reply
* Re: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX
From: Tamizh chelvam @ 2016-12-16 5:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: c_traja, linux-wireless, ath10k
In-Reply-To: <1481645351.20412.34.camel@sipsolutions.net>
Hi Johannes,
Thanks for the comments
On 2016-12-13 21:39, Johannes Berg wrote:
>> > > /**
>> > > + * wiphy_btcoex_support_flags
>> > > + * This enum has the driver supported frame types for
>> > > BTCOEX.
>> > > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
>> > > + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
>> > > + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for
>> > > BTCOEX
>> > > + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
>> > > BTCOEX.
>> > > + */
>> >
>> > That's not making much sense to me?
>> >
>>
>> is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
>
> It's not really clear to me what you intend to do this - if it's really
> support flags then you really should name those better.
>
This is support flags and it used by the driver to intimate driver
supported frame type
for the BTCOEX to cfg like "wiphy_wowlan_support_flags" implementation.
Please suggest if this is ok ? I will be thankful if you can suggest a
better one if this is not ok
"WIPHY_BTCOEX_SUPPORTS_BE"
>> > > +/**
>> > > + * enum wiphy_btcoex_priority - BTCOEX priority level
>> > > + * This enum defines priority level for BTCOEX
>> > > + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT
>> > > traffic
>> > > + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT
>> > > traffic
>> > > + */
>> > > +
>> > > +enum wiphy_btcoex_priority {
>> > > + WIPHY_WLAN_PREFERRED_LOW = false,
>> > > + WIPHY_WLAN_PREFERRED_HIGH = true,
>> > > +};
>> >
>> > That false/true seems just strange.
>> >
>>
>> I will just use as a enum without assigning false/true.
>
> What do you even need this enum for though?
>
Ok. I will directly assign true for the flag.
>> > > +enum nl80211_btcoex_priority {
>> > > + __NL80211_WLAN_PREFERRED_INVALID,
>> > > + NL80211_WLAN_BE_PREFERRED,
>> > > + NL80211_WLAN_BK_PREFERRED,
>> > > + NL80211_WLAN_VI_PREFERRED,
>> > > + NL80211_WLAN_VO_PREFERRED,
>> > > + NL80211_WLAN_BEACON_PREFERRED,
>> > > + NL80211_WLAN_MGMT_PREFERRED,
>> > > + __NL80211_WLAN_PREFERRED_LAST,
>> > > + NL80211_WLAN_PREFERRED_MAX =
>> > > + __NL80211_WLAN_PREFERRED_LAST - 1,
>> > > +};
>> >
>> > Wouldn't a bitmap be easier?
>> >
>> since this is to distinguish between different btcoex priorities and
>> we
>> are not going to do any manipulations on these parameters.
>> It is just used as flag attribute.
>
> But why the (parsing) complexity, when a single bitmap would do?
>
Do you mean to say, sending a value from user space and parse that in
the driver?
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Thiagarajan, Vasanthakumar @ 2016-12-16 5:37 UTC (permalink / raw)
To: Johannes Berg, nbd@nbd.name; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481809984.2582.5.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwNzoyMyBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+PiBJIGFncmVlLiBEeW5hbWljIHN3aXRjaCBwYXJ0IGlzIGJ1Z2d5LCB3ZSBjYW4g
c3RhcnQgd2l0aCBub3QNCj4+PiBhbGxvd2luZyBpbnRlcmZhY2VzIHJlc3VsdGluZyBpbiBkeW5h
bWljIHN3aXRjaC4NCj4+DQo+PiBEb2VzIHRoaXMgbWVhbiB0aGF0IHdoZW4gYnJpbmdpbmcgdXAg
bXVsdGlwbGUgaW50ZXJmYWNlcywgdXNlcnMgd291bGQNCj4+IG5lZWQgdG8gZmlndXJlIG91dCB0
aGUgJ21hZ2ljJyBvcmRlciB0aGF0IHdvcmtzPw0KPg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gdGFs
ayBhYm91dCBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXQgdGhpcyBwb2ludC4NCg0KUUNBOTg4WCBk
b2VzIG5vdCBoYXZlIGNhcGFiaWxpdHkgdG8gY29uZmlndXJlIHZpZiBzcGVjaWZpYyBkZWNhcCBt
b2RlLiBFbmNhcCBtb2RlDQppcyBjb25maWd1cmFibGUgcGVyIHBhY2tldCBmb3IgYWxsIHRoZSBh
dGgxMGsgYmFzZWQgY2hpcHMgc28gdGhpcyBwYXJ0IHNob3VsZCBiZQ0KZmluZSB0byBzdXBwb3J0
IHBlciB2aWYgY29uZmlndXJhdGlvbi4gTmV3ZXIgUUNBIGNoaXBzIGxpa2UgUUNBOTk4NCwgUUNB
NDAxOSwgUUNBOTg4OA0KYW5kIFFDQTk5WDAgc3VwcG9ydHMgZGVjYXAgbW9kZSBjb25maWd1cmF0
aW9uIHBlciB2aWYuIFRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSwNCndlIGNhbiBwcm9iYWJseSBt
YWtlIHBlciB2aWYgZW5jYXAvZGVjYXAgY29uZmlndXJhdGlvbiBtYW5kYXRvcnkgdG8gZW5hYmxl
IGV0aGVybmV0DQpmcmFtZSBmb3JtYXQsIG5vdCBzdXJlIGhvdyB0aGlzIHdpbGwgd29yayB3aXRo
IG5vbi1RQ0EgY2FwYWJsZSBoYXJkd2FyZS4NCg0KPg0KPiBJIHdhcyBhc3N1bWluZyB0aGF0IGl0
IHdvdWxkIGFjdHVhbGx5IGJlIHBvc3NpYmxlIHRvIHJ1biB0d28gaW50ZXJmYWNlcw0KPiB3aXRo
IGRpZmZlcmVudCBwYXRocyBoZXJlIGNvbmN1cnJlbnRseSAtIGlzIHRoYXQgbm90IHRydWU/IElm
IHRoYXQncw0KPiBub3QgdHJ1ZSwgdGhlbiB3ZSBhYnNvbHV0ZWx5IF9uZWVkXyBkeW5hbWljIHN3
aXRjaGluZywgSSBhZ3JlZSB3aXRoDQo+IEZlbGl4LCBidXQgdGhlbiB3ZSBoYXZlIGEgcHJldHR5
IGJpZyBjb21wbGljYXRpb24gdG8gZmlndXJlIG91dC4gQnV0IHdlDQo+IGNhbid0IGxldCB0aGlz
IG9wdGltaXNhdGlvbiBhZmZlY3QgdXNlciBleHBlcmllbmNlLg0KDQpTdXJlLg0KDQpWYXNhbnRo
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-16 5:24 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <2970240.ih558OrmaK@debian64>
Hi Christian,
> On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> > I am also thinking, as of now there is not much use in appending
> > the extended peer stats (which gets periodically ) to the linked list
> > '&ar->debug.fw_stats.peers_extd)' and should we get rid of the below
> > (and the required cleanup as well)
> >
> > list_splice_tail_init(&stats.peers_extd,
> > &ar->debug.fw_stats.peers_extd);
> >
> >
> > since rx_duration is getting updated periodically to the per sta
> > information. Kindly let me know your thoughts about this.
>
> Yes, of course. I see what your are trying to do and I think it's much better
> to get rid of peers_extd and ath10k_fw_extd_stats_peers_free.
>
[shafi] Feel free to post the change and I can test the same for you(next week) !
Let me know if you are busy on something else, I can take this up.
As discussed, the fix to free 'extd stats' when number of peers exceeds the range
is definitely needed. Thank you for looking into this.
thanks,
shafi
^ permalink raw reply
* Re: [Patch] NFC: trf7970a:
From: Mark Greer @ 2016-12-16 4:52 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Justin Bronder
In-Reply-To: <20161214223123.GA10281@animalcreek.com>
On Wed, Dec 14, 2016 at 03:31:23PM -0700, Mark Greer wrote:
> I'll start on this
> tonight but won't likely get far until tomorrow. In the meantime,
> if you and/or your contractor make progress, please share.
Geoff,
Which version of neard are you using? 0.16?
Mark
--
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Luis R. Rodriguez @ 2016-12-16 2:03 UTC (permalink / raw)
To: Arend Van Spriel, Tom Gundersen, Daniel Wagner, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki
Cc: Pali Rohár, Kalle Valo, Sebastian Reichel, Pavel Machek,
Michal Kazior, Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren,
linux-wireless, Network Development, linux-kernel@vger.kernel.org,
David Woodhouse, Takashi Iwai, Josh Boyer, Dmitry Torokhov
In-Reply-To: <76365770-f5ba-9565-3fca-710518f64d81@broadcom.com>
On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
>> On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@codeaurora.org> wrote:
>>> (Adding Luis because he has been working on request_firmware() lately)
>>>
>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>
>>>>>> So no, there is no argument against... request_firmware() in
>>>>>> fallback mode with userspace helper is by design blocking and
>>>>>> waiting for userspace. But waiting for some change in DTS in
>>>>>> kernel is just nonsense.
>>>>>
>>>>> I would just mark the wlan device with status = "disabled" and
>>>>> enable it in the overlay together with adding the NVS & MAC info.
>>>>
>>>> So if you think that this solution make sense, we can wait what net
>>>> wireless maintainers say about it...
>>>>
>>>> For me it looks like that solution can be:
>>>>
>>>> extending request_firmware() to use only userspace helper
>>>
>>> I haven't followed the discussion very closely but this is my preference
>>> what drivers should do:
>>>
>>> 1) First the driver should do try to get the calibration data and mac
>>> address from the device tree.
>>>
>>
>> Ok, but there is no (dynamic, device specific) data in DTS for N900. So 1) is noop.
>
> Uhm. What do you mean? You can propose a patch to the DT bindings [1] to
> get it in there and create your N900 DTB or am I missing something here.
> Are there hardware restrictions that do not allow you to boot with your
> own DTB.
>
>>> 2) If they are not in DT the driver should retrieve the calibration data
>>> with request_firmware(). BUT with an option for user space to
>>> implement that with a helper script so that the data can be created
>>> dynamically, which I believe openwrt does with ath10k calibration
>>> data right now.
>>
>> Currently there is flag for request_firmware() that it should fallback to user helper if direct VFS access not find needed firmware.
>>
>> But this flag is not suitable as /lib/firmware already provides default (not device specific) calibration data.
>>
>> So I would suggest to add another flag/function which will primary use user helper.
> I recall Luis saying that user-mode helper (fallback) should be
> discouraged, because there is no assurance that there is a user-mode
> helper so you might just be pissing in the wind.
There's tons of issues with the current status quo of the so called
"firmware usermode helper". To start off with its a complete misnomer,
the kernel's usermode helper infrastructure is implemented in
lib/kmod.c and it provides an API to help call out to userspace some
helper for you. That's the real kernel usermode helper. In so far as
the firmware_class.c driver is concerned -- it only makes use of the
kernel user mode helper as an option if you have
CONFIG_UEVENT_HELPER_PATH set to help address kobject uevents. Most
distributions do not use this, and back in the day systemd udev, and
prior to that hotplug used to process firmware kobject uevents.
systemd udev is long gone. Gone. This kobject uevents really are a
"fallback mechanism" for firmware only -- if cached firmware, built-in
firmware, or direct filesystem lookup fails. These each are their own
beast. Finally kobject uevents are only one of the fallback
mechanisms, "custom fallback mechanisms" are the other option and its
what you and others seem to describe to want for these sorts of custom
things.
There are issues with the existing request_firmware() API in that
everyone and their mother keeps extending it with stupid small API
extensions to do yet-another-tweak, and then having to go and change
tons of drivers. Or a new API call added for just one custom knob.
Naturally this is all plain dumb, so yet-another-API call or new
argument is not going to help us. We don't have "flags" persi in this
API, that was one issue with the design of the API, but there are much
more. The entire change in mechanism of "firmware fallback mechanism"
depending on which kernel config options you have is another. Its a
big web of gum put together. All this needs to end.
I've recently proposed a new patch to first help with understanding
each of the individual items I've listed above with as much new
information as is possible. I myself need to re-read it to just keep
tabs on what the hell is going on at times. After this I have a new
API proposal which I've been working on for a long time now which adds
an extensible API with only 2 calls: sync, async, and lets us modify
attributes through a parameters struct. This is what we should use in
the future for further extensions.
For the new API a solution for "fallback mechanisms" should be clean
though and I am looking to stay as far as possible from the existing
mess. A solution to help both the old API and new API is possible for
the "fallback mechanism" though -- but for that I can only refer you
at this point to some of Daniel Wagner and Tom Gunderson's firmwared
deamon prospect. It should help pave the way for a clean solution and
help address other stupid issues.
I'll note -- the "custom fallback mechanism", part of the old API is
just a terrible idea for many reasons. I've documented issues in my
documentation revamp, I suggest to read that, refer to this thread:
https://lkml.kernel.org/r/20161213030828.17820-4-mcgrof@kernel.org
> The idea was to have a
> dedicated API call that explicitly does the request towards user-space.
In so far as this driver example that was mentioned in this thread my
recommendation is to use the default existing MAC address /
calibration data on /lib/firmware/ and then use another request to
help override for the custom thing. The only issue of course is that
the timeout for the custom thing is 60 seconds, but if your platforms
are controlled -- just reduce this to 1 second or so given that udev
is long gone and it would seem you'd only use a custom fw request to
depend on. You could also wrap this thing into a kconfig option for
now, and have the filename specified, if empty then no custom request
is sent. If set then you have it request it.
Please note the other patches in my series for the custom fallback
though. We have only 2 users upstream -- and from recent discussions
it would seem it might be possible to address what you need with
firmwared in a clean way without this custom old fallback crap thing.
Johannes at least has a similar requirement and is convinced a
"custom" thing can be done without even adding an extra custom kobject
uevent attribute as from what I recall he hinted, drivers have no
business to be involved in this. If you do end up using the custom
fallback mechanism be sure to add super crystal clear documentation
for it (see my other patches for the declarer for this documentation).
Since we have only 2 drivers using this custom thing its hard to get
folks to commit to writing the docs, write it now and be sure you
think of the future as well.
Oh also the "custom firmware fallback" was also broken on recent
kernels for many kernel revisions, it just did not work until recently
a fix which went in, so your users wills need this fix cherry picked.
Hey I tell you, the custom fw thing was a terrible incarnation. Only 2
drivers use it. There are good reasons to not like it (be sure to read
the suspend issue I documented).
> By the way, are we talking here about wl1251 device or driver as you
> also mentioned wl12xx? I did not read the entire thread.
Luis
^ permalink raw reply
* Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-16 1:18 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin,
Jaret Cantu
In-Reply-To: <1481841044-4314-3-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu@timesys.com>
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the curent state of the trf7970a is reading but
> a request has been made to send a command.
>
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
Maybe its just me but I find this description a little hard to grok.
Mind reworking it?
The patch itself looks fine.
Thanks,
Mark
--
^ permalink raw reply
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Mark Greer @ 2016-12-16 1:13 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <1481841044-4314-2-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
Missing commit description.
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 2d2a077..b4c37ab 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1048,6 +1049,11 @@ static int trf7970a_init(struct trf7970a *trf)
> if (ret)
> goto err_out;
>
> + ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
> + trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
s/l|T/l | T/
Otherwise, looks good.
Mark
--
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Mark Greer @ 2016-12-16 1:06 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
Hi Geoff.
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
Please add an informative commit description to all of your commits.
No matter how trivial this patch may seem to you now, it may not be
to others (or to you in a few years).
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 26c9dbb..2d2a077 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1181,27 +1180,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
> switch (tech) {
> case NFC_DIGITAL_RF_TECH_106A:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
nit: s/0xF8/0xf8/ please (for consistency with the rest of the file.).
Otherwise, it looks good.
Thanks,
Mark
^ permalink raw reply
* Re: ath10k firmware sends probes on DFS channels without radar detection
From: Jouni Malinen @ 2016-12-15 22:58 UTC (permalink / raw)
To: Jean-Pierre Tosoni; +Cc: 'Ben Greear', linux-wireless, ath10k
In-Reply-To: <00fd01d256fc$2f780db0$8e682910$@acksys.fr>
On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > Thanks for the suggestion, I already tried something like this in
> > > wmi.c, with the same result:
> > >
> > > - Before patching the firmware scans DFS channels actively (with
> > probes).
> > >
> > > - After patching, the firmware scans DFS channels passively *until*
> > > any beacon is received on the DFS channel. When *any* beacon is seen,
> > > the firmware decides to scan actively on its own, without any new
> > > IR/RADAR info from the driver.
> > >
> > > So, your patch is required but not sufficient.
> > >
> > > Somehow I was able to overcome this by reloading the regulation domain
> > > in the radio card before each scan request:
Interesting.. I'm not completely sure what could have changed the
behavior based on beacon hint. I thought it was cfg80211, but if the
simple change for doing NO_IR | RADAR is not sufficient, it would seem
to imply that something else can do this. Some more debugging to do, I
guess.
> The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> NO_IR appears only in the world regulatory domain so it's not relevant here.
NO_IR is a combination of not allowing AP, IBSS, or active scanning
without having somehow been enabled by another device. RADAR has that
same impact and in addition, requirement for doing radar detection and
DFS by a master device.
> I'd say
> "the CHAN_RADAR flag should always make the firmware never do IR when
> probing"
> ...maybe, except if the channel is the operating channel. (this should
> exclude
> unassociated stations)
For most cases, I'd agree that active scanning should not be used on DFS
channels. That said, unicast Probe Request frame to the current AP while
associated could be a reasonable exception. In addition, WPS with PBC
depends on Probe Request frames to allow PBC session overlap detection,
so there might be sufficient justification to allow Probe Request frame
to be sent out for a very short duration (couple of seconds) after
seeing a Beacon frame on the channel for such special cases.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Jaret Cantu,
Geoff Lansberry
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
From: Jaret Cantu <jaret.cantu@timesys.com>
Repeated polling attempts cause a NULL dereference error to occur.
This is because the curent state of the trf7970a is reading but
a request has been made to send a command.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
---
drivers/nfc/trf7970a.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index b4c37ab..f96a321 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1493,6 +1493,10 @@ static int trf7970a_send_cmd(struct nfc_digital_dev *ddev,
(trf->state != TRF7970A_ST_IDLE_RX_BLOCKED)) {
dev_err(trf->dev, "%s - Bogus state: %d\n", __func__,
trf->state);
+ if (trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA ||
+ trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA_CONT)
+ trf->ignore_timeout =
+ !cancel_delayed_work(&trf->timeout_work);
ret = -EIO;
goto out_err;
}
--
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
^ permalink raw reply related
* [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
From: Geoff Lansberry <geoff@kuvee.com>
---
Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 9dda879..208f045 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- vdd_io_1v8: Set to specify that the trf7970a io voltage should be set to 1.8V
- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
@@ -45,6 +46,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ vdd_io_1v8;
crystal_27mhz;
status = "okay";
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 2d2a077..b4c37ab 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -441,6 +441,7 @@ struct trf7970a {
u8 iso_ctrl_tech;
u8 modulator_sys_clk_ctrl;
u8 special_fcn_reg1;
+ u8 io_ctrl;
unsigned int guard_time;
int technology;
int framing;
@@ -1048,6 +1049,11 @@ static int trf7970a_init(struct trf7970a *trf)
if (ret)
goto err_out;
+ ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
+ trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
+ if (ret)
+ goto err_out;
+
ret = trf7970a_write(trf, TRF7970A_NFC_TARGET_LEVEL, 0);
if (ret)
goto err_out;
@@ -1764,7 +1770,7 @@ static int _trf7970a_tg_listen(struct nfc_digital_dev *ddev, u16 timeout,
goto out_err;
ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
- TRF7970A_REG_IO_CTRL_VRS(0x1));
+ trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
if (ret)
goto out_err;
@@ -2058,6 +2064,11 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ if (of_property_read_bool(np, "vdd_io_1v8")) {
+ trf->io_ctrl = TRF7970A_REG_IO_CTRL_IO_LOW;
+ dev_dbg(trf->dev, "trf7970a config vdd_io_1v8\n");
+ }
+
if (of_property_read_bool(np, "crystal_27mhz")) {
trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
dev_dbg(trf->dev, "trf7970a configure crystal_27mhz\n");
--
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
^ permalink raw reply related
* [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
From: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
drivers/nfc/trf7970a.c | 42 ++++++++++++++++------
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..9dda879 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,8 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
+
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ crystal_27mhz;
status = "okay";
};
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..2d2a077 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1056,12 +1056,11 @@ static int trf7970a_init(struct trf7970a *trf)
trf->chip_status_ctrl &= ~TRF7970A_CHIP_STATUS_RF_ON;
- ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL, 0);
+ ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL,
+ trf->modulator_sys_clk_ctrl);
if (ret)
goto err_out;
- trf->modulator_sys_clk_ctrl = 0;
-
ret = trf7970a_write(trf, TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS,
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLH_96 |
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLL_32);
@@ -1181,27 +1180,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
switch (tech) {
case NFC_DIGITAL_RF_TECH_106A:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_NFCA;
break;
case NFC_DIGITAL_RF_TECH_106B:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443B_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCB;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_ISO15693:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_15693_SGL_1OF4_2648;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_15693;
break;
default:
@@ -1571,17 +1580,23 @@ static int trf7970a_tg_config_rf_tech(struct trf7970a *trf, int tech)
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_CE |
TRF7970A_ISO_CTRL_NFC_CE_14443A;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
default:
dev_dbg(trf->dev, "Unsupported rf technology: %d\n", tech);
@@ -2043,6 +2058,11 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ if (of_property_read_bool(np, "crystal_27mhz")) {
+ trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
+ dev_dbg(trf->dev, "trf7970a configure crystal_27mhz\n");
+ }
+
if (of_property_read_bool(np, "en2-rf-quirk"))
trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
--
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
^ permalink raw reply related
* Re: [RFC v2 11/11] ath10k: Added sdio support
From: Erik Stromdahl @ 2016-12-15 20:52 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87oa0duow8.fsf@kamboji.qca.qualcomm.com>
On 12/15/2016 05:40 PM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>
>> Initial HIF sdio/mailbox implementation.
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/Kconfig | 6 +
>> drivers/net/wireless/ath/ath10k/Makefile | 3 +
>> drivers/net/wireless/ath/ath10k/sdio.c | 1860 ++++++++++++++++++++++++++++++
>> drivers/net/wireless/ath/ath10k/sdio.h | 276 +++++
>> 4 files changed, 2145 insertions(+)
>> create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
>> create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h
>
> AFAIK the sdio firmware binary is different from pci and usb. And as all
> the firmware images need to coexist in the same repository I suspect we
> can't continue to use firmware-N.bin for both pcie and sdio (and in
> future usb). So should we somehow rename the sdio firmware filename to
> something else, like firmware-sdio-N.bin?
>
I suppose you are right. I would be surprised if the firmware images
were the same for sdio, usb and pci. Hopefully all sdio chipsets sharing
the same device id and BMI version will use the same firmware image.
Currently, these two params are the only two that are used when
selecting firmware.
struct bmi_target_info also has a type parameter, but I can't see it
being used anywhere in the code.
If it turns out that several sdio chipsets uses the same BMI version and
device id, this parameter might be used (together with the other two) to
select hw params.
^ permalink raw reply
* Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Arend Van Spriel @ 2016-12-15 20:15 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Wolfgang Grandegger, Marc Kleine-Budde, Vince Bridgers,
Jay Cliburn, Chris Snook, Luis R. Rodriguez, Kalle Valo,
Maya Erez, Franky Lin, Hante Meuleman, Stanislaw Gruszka,
Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Jakub Kicinski, Larry Finger, Chaoming Li,
Greg Kroah-Hartman, David S. Miller, Alexander Aring,
Stefan Schmidt, Matthias Brugger, linux-bluetooth, linux-can,
netdev, nios2-dev, linux-wireless, wil6210,
brcm80211-dev-list.pdl, devel, linux-wpan, linux-arm-kernel,
linux-mediatek
In-Reply-To: <1481778865-27667-9-git-send-email-mst@redhat.com>
On 15-12-2016 6:15, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
For brcm80211 drivers:
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Regards,
Arend
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Arend Van Spriel @ 2016-12-15 20:12 UTC (permalink / raw)
To: Pali Rohár, Kalle Valo
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel, Luis R. Rodriguez
In-Reply-To: <1481816017.2090.2.camel@Pali-Nokia-N900>
On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@codeaurora.org> wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár <pali.rohar@gmail.com> writes:
>>
>>>>> So no, there is no argument against... request_firmware() in
>>>>> fallback mode with userspace helper is by design blocking and
>>>>> waiting for userspace. But waiting for some change in DTS in
>>>>> kernel is just nonsense.
>>>>
>>>> I would just mark the wlan device with status = "disabled" and
>>>> enable it in the overlay together with adding the NVS & MAC info.
>>>
>>> So if you think that this solution make sense, we can wait what net
>>> wireless maintainers say about it...
>>>
>>> For me it looks like that solution can be:
>>>
>>> extending request_firmware() to use only userspace helper
>>
>> I haven't followed the discussion very closely but this is my preference
>> what drivers should do:
>>
>> 1) First the driver should do try to get the calibration data and mac
>> address from the device tree.
>>
>
> Ok, but there is no (dynamic, device specific) data in DTS for N900. So 1) is noop.
Uhm. What do you mean? You can propose a patch to the DT bindings [1] to
get it in there and create your N900 DTB or am I missing something here.
Are there hardware restrictions that do not allow you to boot with your
own DTB.
>> 2) If they are not in DT the driver should retrieve the calibration data
>> with request_firmware(). BUT with an option for user space to
>> implement that with a helper script so that the data can be created
>> dynamically, which I believe openwrt does with ath10k calibration
>> data right now.
>
> Currently there is flag for request_firmware() that it should fallback to user helper if direct VFS access not find needed firmware.
>
> But this flag is not suitable as /lib/firmware already provides default (not device specific) calibration data.
>
> So I would suggest to add another flag/function which will primary use user helper.
I recall Luis saying that user-mode helper (fallback) should be
discouraged, because there is no assurance that there is a user-mode
helper so you might just be pissing in the wind. The idea was to have a
dedicated API call that explicitly does the request towards user-space.
By the way, are we talking here about wl1251 device or driver as you
also mentioned wl12xx? I did not read the entire thread.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Lee Duncan @ 2016-12-15 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Russell King, Alasdair Kergon, Mike Snitzer, dm-devel, Shaohua Li,
Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, Greg Kroah-Hartman, Jiri Slaby,
Chris Leech, James E.J. Bottomley, Martin K. Petersen,
Nicholas A. Bellinger, Jason Wang, Alexander Aring,
Stefan Schmidt, David S. Miller, linux-arm-kernel,
linux-samsung-soc, linux-raid, netdev, linux-wireless, linux-mm,
open-iscsi, linux-scsi, target-devel, virtualization, linux-wpan
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On 12/14/2016 09:15 PM, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> index 21391fa..e55d1f5 100644
> --- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> +++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> @@ -26,7 +26,7 @@
>
> #include <linux/types.h>
>
> -typedef unsigned int __bitwise__ samsung_gpio_pull_t;
> +typedef unsigned int __bitwise samsung_gpio_pull_t;
>
> /* forward declaration if gpio-core.h hasn't been included */
> struct samsung_gpio_chip;
> diff --git a/drivers/md/dm-cache-block-types.h b/drivers/md/dm-cache-block-types.h
> index bed4ad4..389c9e8 100644
> --- a/drivers/md/dm-cache-block-types.h
> +++ b/drivers/md/dm-cache-block-types.h
> @@ -17,9 +17,9 @@
> * discard bitset.
> */
>
> -typedef dm_block_t __bitwise__ dm_oblock_t;
> -typedef uint32_t __bitwise__ dm_cblock_t;
> -typedef dm_block_t __bitwise__ dm_dblock_t;
> +typedef dm_block_t __bitwise dm_oblock_t;
> +typedef uint32_t __bitwise dm_cblock_t;
> +typedef dm_block_t __bitwise dm_dblock_t;
>
> static inline dm_oblock_t to_oblock(dm_block_t b)
> {
> diff --git a/drivers/net/ethernet/sun/sunhme.h b/drivers/net/ethernet/sun/sunhme.h
> index f430765..4a8d5b1 100644
> --- a/drivers/net/ethernet/sun/sunhme.h
> +++ b/drivers/net/ethernet/sun/sunhme.h
> @@ -302,7 +302,7 @@
> * Always write the address first before setting the ownership
> * bits to avoid races with the hardware scanning the ring.
> */
> -typedef u32 __bitwise__ hme32;
> +typedef u32 __bitwise hme32;
>
> struct happy_meal_rxd {
> hme32 rx_flags;
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> index 1ad0ec1..84813b5 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
> @@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
> IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
> };
>
> -typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
> +typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
>
> /**
> * enum iwl_ucode_tlv_api - ucode api
> @@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
> #endif
> };
>
> -typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
> +typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
>
> /**
> * enum iwl_ucode_tlv_capa - ucode capabilities
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0f088f3..36d9896 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -246,7 +246,7 @@ struct lruvec {
> #define ISOLATE_UNEVICTABLE ((__force isolate_mode_t)0x8)
>
> /* LRU Isolation modes. */
> -typedef unsigned __bitwise__ isolate_mode_t;
> +typedef unsigned __bitwise isolate_mode_t;
>
> enum zone_watermarks {
> WMARK_MIN,
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 5d49488..5def8e8 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -111,8 +111,8 @@ struct uart_icount {
> __u32 buf_overrun;
> };
>
> -typedef unsigned int __bitwise__ upf_t;
> -typedef unsigned int __bitwise__ upstat_t;
> +typedef unsigned int __bitwise upf_t;
> +typedef unsigned int __bitwise upstat_t;
>
> struct uart_port {
> spinlock_t lock; /* port lock */
> diff --git a/include/linux/types.h b/include/linux/types.h
> index baf7183..d501ad3 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
> typedef u32 dma_addr_t;
> #endif
>
> -typedef unsigned __bitwise__ gfp_t;
> -typedef unsigned __bitwise__ fmode_t;
> +typedef unsigned __bitwise gfp_t;
> +typedef unsigned __bitwise fmode_t;
>
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> typedef u64 phys_addr_t;
> diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
> index c1260d8..df156f1 100644
> --- a/include/scsi/iscsi_proto.h
> +++ b/include/scsi/iscsi_proto.h
> @@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
> #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
>
> /* initiator tags; opaque for target */
> -typedef uint32_t __bitwise__ itt_t;
> +typedef uint32_t __bitwise itt_t;
> /* below makes sense only for initiator that created this tag */
> #define build_itt(itt, age) ((__force itt_t)\
> ((itt) | ((age) << ISCSI_AGE_SHIFT)))
> diff --git a/include/target/target_core_base.h b/include/target/target_core_base.h
> index c211900..0055828 100644
> --- a/include/target/target_core_base.h
> +++ b/include/target/target_core_base.h
> @@ -149,7 +149,7 @@ enum se_cmd_flags_table {
> * Used by transport_send_check_condition_and_sense()
> * to signal which ASC/ASCQ sense payload should be built.
> */
> -typedef unsigned __bitwise__ sense_reason_t;
> +typedef unsigned __bitwise sense_reason_t;
>
> enum tcm_sense_reason_table {
> #define R(x) (__force sense_reason_t )(x)
> diff --git a/include/uapi/linux/virtio_types.h b/include/uapi/linux/virtio_types.h
> index e845e8c..55c3b73 100644
> --- a/include/uapi/linux/virtio_types.h
> +++ b/include/uapi/linux/virtio_types.h
> @@ -39,8 +39,8 @@
> * - __le{16,32,64} for standard-compliant virtio devices
> */
>
> -typedef __u16 __bitwise__ __virtio16;
> -typedef __u32 __bitwise__ __virtio32;
> -typedef __u64 __bitwise__ __virtio64;
> +typedef __u16 __bitwise __virtio16;
> +typedef __u32 __bitwise __virtio32;
> +typedef __u64 __bitwise __virtio64;
>
> #endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
> diff --git a/net/ieee802154/6lowpan/6lowpan_i.h b/net/ieee802154/6lowpan/6lowpan_i.h
> index 5ac7789..ac7c96b 100644
> --- a/net/ieee802154/6lowpan/6lowpan_i.h
> +++ b/net/ieee802154/6lowpan/6lowpan_i.h
> @@ -7,7 +7,7 @@
> #include <net/inet_frag.h>
> #include <net/6lowpan.h>
>
> -typedef unsigned __bitwise__ lowpan_rx_result;
> +typedef unsigned __bitwise lowpan_rx_result;
> #define RX_CONTINUE ((__force lowpan_rx_result) 0u)
> #define RX_DROP_UNUSABLE ((__force lowpan_rx_result) 1u)
> #define RX_DROP ((__force lowpan_rx_result) 2u)
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index d37a577..b2069fb 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -159,7 +159,7 @@ enum ieee80211_bss_valid_data_flags {
> IEEE80211_BSS_VALID_ERP = BIT(3)
> };
>
> -typedef unsigned __bitwise__ ieee80211_tx_result;
> +typedef unsigned __bitwise ieee80211_tx_result;
> #define TX_CONTINUE ((__force ieee80211_tx_result) 0u)
> #define TX_DROP ((__force ieee80211_tx_result) 1u)
> #define TX_QUEUED ((__force ieee80211_tx_result) 2u)
> @@ -180,7 +180,7 @@ struct ieee80211_tx_data {
> };
>
>
> -typedef unsigned __bitwise__ ieee80211_rx_result;
> +typedef unsigned __bitwise ieee80211_rx_result;
> #define RX_CONTINUE ((__force ieee80211_rx_result) 0u)
> #define RX_DROP_UNUSABLE ((__force ieee80211_rx_result) 1u)
> #define RX_DROP_MONITOR ((__force ieee80211_rx_result) 2u)
>
For iscsi initiator, looks good.
Akced-by: Lee Duncan <lduncan@suse.com>
--
Lee Duncan
^ permalink raw reply
* [PATCH 12/14 V2] rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG
From: Larry Finger @ 2016-12-15 18:23 UTC (permalink / raw)
To: kvalo; +Cc: devel, linux-wireless, Larry Finger, Ping-Ke Shih
In-Reply-To: <20161215182310.13713-1-Larry.Finger@lwfinger.net>
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
---
V2 - eliminate some files that should not have been sent.
---
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 33 ++++++----------------
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 13 ++++-----
2 files changed, 15 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
index 4a49e66..e739e56 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -145,10 +145,8 @@ static void _rtl92c_write_fw(struct ieee80211_hw *hw,
pageNums = size / FW_8192C_PAGE_SIZE;
remainsize = size % FW_8192C_PAGE_SIZE;
- if (pageNums > 4) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Page numbers should not greater then 4\n");
- }
+ if (pageNums > 4)
+ pr_err("Page numbers should not greater then 4\n");
for (page = 0; page < pageNums; page++) {
offset = page * FW_8192C_PAGE_SIZE;
@@ -180,15 +178,10 @@ static int _rtl92c_fw_free_to_go(struct ieee80211_hw *hw)
(!(value32 & FWDL_ChkSum_rpt)));
if (counter >= FW_8192C_POLLING_TIMEOUT_COUNT) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "chksum report faill ! REG_MCUFWDL:0x%08x .\n",
- value32);
+ pr_err("chksum report fail! REG_MCUFWDL:0x%08x .\n",
+ value32);
goto exit;
}
-
- RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE,
- "Checksum report OK ! REG_MCUFWDL:0x%08x .\n", value32);
-
value32 = rtl_read_dword(rtlpriv, REG_MCUFWDL);
value32 |= MCUFWDL_RDY;
value32 &= ~WINTINI_RDY;
@@ -198,20 +191,15 @@ static int _rtl92c_fw_free_to_go(struct ieee80211_hw *hw)
do {
value32 = rtl_read_dword(rtlpriv, REG_MCUFWDL);
- if (value32 & WINTINI_RDY) {
- RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE,
- "Polling FW ready success!! REG_MCUFWDL:0x%08x .\n",
- value32);
- err = 0;
- goto exit;
- }
+ if (value32 & WINTINI_RDY)
+ return 0;
mdelay(FW_8192C_POLLING_DELAY);
} while (counter++ < FW_8192C_POLLING_TIMEOUT_COUNT);
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Polling FW ready fail!! REG_MCUFWDL:0x%08x .\n", value32);
+ pr_err("Polling FW ready fail! REG_MCUFWDL:0x%08x.\n",
+ value32);
exit:
return err;
@@ -251,8 +238,7 @@ int rtl92c_download_fw(struct ieee80211_hw *hw)
err = _rtl92c_fw_free_to_go(hw);
if (err) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Firmware is not ready to run!\n");
+ pr_err("Firmware is not ready to run!\n");
} else {
RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE,
"Firmware is ready to run!\n");
@@ -327,8 +313,7 @@ static void _rtl92c_fill_h2c_command(struct ieee80211_hw *hw,
while (!bwrite_sucess) {
wait_writeh2c_limmit--;
if (wait_writeh2c_limmit == 0) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Write H2C fail because no trigger for FW INT!\n");
+ pr_err("Write H2C fail because no trigger for FW INT!\n");
break;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 30c2d12..5f8fa4a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -104,7 +104,7 @@ u32 _rtl92c_phy_rf_serial_read(struct ieee80211_hw *hw,
offset &= 0x3f;
newoffset = offset;
if (RT_CANNOT_IO(hw)) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "return all one\n");
+ pr_err("return all one\n");
return 0xFFFFFFFF;
}
tmplong = rtl_get_bbreg(hw, RFPGA0_XA_HSSIPARAMETER2, MASKDWORD);
@@ -152,7 +152,7 @@ void _rtl92c_phy_rf_serial_write(struct ieee80211_hw *hw,
struct bb_reg_def *pphyreg = &rtlphy->phyreg_def[rfpath];
if (RT_CANNOT_IO(hw)) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "stop\n");
+ pr_err("stop\n");
return;
}
offset &= 0x3f;
@@ -209,7 +209,7 @@ bool _rtl92c_phy_bb8192c_config_parafile(struct ieee80211_hw *hw)
rtstatus = rtlpriv->cfg->ops->config_bb_with_headerfile(hw,
BASEBAND_CONFIG_PHY_REG);
if (!rtstatus) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Write BB Reg Fail!!\n");
+ pr_err("Write BB Reg Fail!!\n");
return false;
}
if (rtlphy->rf_type == RF_1T2R) {
@@ -222,13 +222,13 @@ bool _rtl92c_phy_bb8192c_config_parafile(struct ieee80211_hw *hw)
BASEBAND_CONFIG_PHY_REG);
}
if (!rtstatus) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "BB_PG Reg Fail!!\n");
+ pr_err("BB_PG Reg Fail!!\n");
return false;
}
rtstatus = rtlpriv->cfg->ops->config_bb_with_headerfile(hw,
BASEBAND_CONFIG_AGC_TAB);
if (!rtstatus) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "AGC Table Fail\n");
+ pr_err("AGC Table Fail\n");
return false;
}
rtlphy->cck_high_power =
@@ -860,8 +860,8 @@ bool _rtl92c_phy_sw_chnl_step_by_step(struct ieee80211_hw *hw,
currentcmd = &postcommoncmd[*step];
break;
default:
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Invalid 'stage' = %d, Check it!\n", *stage);
+ pr_err("Invalid 'stage' = %d, Check it!\n",
+ *stage);
return true;
}
--
2.10.2
^ 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