[PATCH 1/2] mwifiex: change width of MAC control variable

[Amitkumar Karwar]

Firmware has started making use of reserved field.
Accordingly change curr_pkt_filter from u16 to u32.

Signed-off-by: Amitkumar Karwar 
---
 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 0x
-
-#define HostCmd_ACT_MAC_RX_ON 0x0001
-#define HostCmd_ACT_MAC_TX_ON 0x0002
-#define HostCmd_ACT_MAC_WEP_ENABLE0x0008
-#define HostCmd_ACT_MAC_ETHERNETII_ENABLE 0x0010
-#define HostCmd_ACT_MAC_PROMISCUOUS_ENABLE0x0080
-#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_ENABLEBIT(3)
+#define HostCmd_ACT_MAC_ETHERNETII_ENABLE BIT(4)
+#define HostCmd_ACT_MAC_PROMISCUOUS_ENABLEBIT(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_ANY0x0003
@@ -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 = >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

[PATCH 2/2] mwifiex: Enable dynamic bandwidth signalling

[Amitkumar Karwar]

Enable dynamic bandwidth signalling by setting the corresponding
bit in MAC control register.

Signed-off-by: Amitkumar Karwar 
---
 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_ENABLEBIT(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_ANY0x0003
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(>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

Re: wl1251 & mac address & calibration data

[Daniel Wagner]

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

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

[Thiagarajan, Vasanthakumar]

On Thursday 15 December 2016 03:08 PM, Johannes Berg wrote:
>
>> This rx path only checks if the driver has advertised
>> it's support of 802.11 header encap/decap offload for
>> data frames.
>
> I'm not even sure I see the point in that? Other than that (and the
> various other offload requirements), it seems that encap/decap could be
> considered orthogonal.

Ok. So it is mainly for encap there needs to be some capability advertisement
from driver because for decap driver would use appropriate mac80211 Rx function
to indicate?

>
>> + * Adhoc interface depends on bssid to udpate last_rx.
>
> type - update
>
>> +if (!(status->flag & RX_FLAG_MCAST)) {
>> +sta->rx_stats.last_rx = jiffies;
>> +sta->rx_stats.last_rate =
>> sta_stats_encode_rate(status);
>> +}
>
> You should probably rename that flag to something like
> RX_FLAG_80211_MCAST since otherwise it's confusing with the next
> multicast ether addr check:

Sure.

>
>> +if (sdata->vif.type == NL80211_IFTYPE_STATION &&
>> +!is_multicast_ether_addr(ehdr->h_dest))
>> +ieee80211_sta_reset_conn_monitor(sdata);
>
> But this could just also use the flag, since in station mode the two
> are equivalent, and it'd be easier to figure out if this was "else if
> (station mode)"?

Ah, correct.

>
>> +memset(, 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?

>
>> +rx.skb = skb;
>> +rx.sdata = sdata;
>> +rx.local = local;
>> +rx.sta = sta;
>> +
>> +if (vif->type == NL80211_IFTYPE_AP_VLAN && sdata->bss &&
>> +unlikely(ehdr->h_proto == sdata->control_port_protocol))
>> {
>> +sdata = container_of(sdata->bss, struct
>> ieee80211_sub_if_data,
>> + u.ap);
>> +dev = sdata->dev;
>> +rx.sdata = sdata;
>> +}
>> +
>> +rx.skb->dev = dev;
>> +
>> +/* XXX: Since rx.seqno_idx is not available for decap
>> offloaded frames
>> + * rx msdu stats update at the seqno_idx in
>> ieee80211_deliver_skb()
>> + * will always be updated at index 0 and will not be very
>> useful.
>> + */
>> +ieee80211_deliver_skb();
>
> 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

  If
> not, we'll have to disable those statistics *all the way*, i.e. not
> even report them to userspace when filling sinfo.

Yes, this may be the option when driver is unaware of rx packet tid.

>
>> +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?

Vasanth

Re: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX

[Tamizh chelvam]

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?

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

[Thiagarajan, Vasanthakumar]

On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote:
>
>>> I agree. Dynamic switch part is buggy, we can start with not
>>> allowing interfaces resulting in dynamic switch.
>>
>> Does this mean that when bringing up multiple interfaces, users would
>> need to figure out the 'magic' order that works?
>
> I think we need to talk about hardware capabilities at this point.

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. Newer QCA chips like QCA9984, QCA4019, 
QCA9888
and QCA99X0 supports decap mode configuration per vif. 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 was assuming that it would actually be possible to run two interfaces
> with different paths here concurrently - is that not true? If that's
> not true, then we absolutely _need_ dynamic switching, I agree with
> Felix, but then we have a pretty big complication to figure out. But we
> can't let this optimisation affect user experience.

Sure.

Vasanth

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

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
> > '>debug.fw_stats.peers_extd)'  and should we get rid of the below
> > (and the required cleanup as well) 
> > 
> > list_splice_tail_init(_extd,
> > >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

Re: [Patch] NFC: trf7970a:

[Mark Greer]

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
--

Re: wl1251 & mac address & calibration data

[Luis R. Rodriguez]

On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
 wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
>> On Thu Dec 15 09:18:44 2016 Kalle Valo  wrote:
>>> (Adding Luis because he has been working on request_firmware() lately)
>>>
>>> Pali Rohár  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 

Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

[Mark Greer]

On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu 
> 
> 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
--

Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

[Mark Greer]

On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry 

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
--

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

[Mark Greer]

Hi Geoff.

On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry 

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

Re: ath10k firmware sends probes on DFS channels without radar detection

[Jouni Malinen]

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 MalinenPGP id EFC895FA

[PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

[Geoff Lansberry]

From: Geoff Lansberry 

---
 .../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 = 

[PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

[Geoff Lansberry]

From: Jaret Cantu 

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(>timeout_work);
ret = -EIO;
goto out_err;
}
-- 
Signed-off-by: Geoff Lansberry 

[PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

[Geoff Lansberry]

From: Geoff Lansberry 

---
 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 intguard_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 

Re: [RFC v2 11/11] ath10k: Added sdio support

[Erik Stromdahl]

On 12/15/2016 05:40 PM, Valo, Kalle wrote:
> Erik Stromdahl  writes:
> 
>> Initial HIF sdio/mailbox implementation.
>>
>> Signed-off-by: Erik Stromdahl 
>> ---
>>  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.

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

[Arend Van Spriel]

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 
> ---
>  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 

Regards,
Arend

Re: wl1251 & mac address & calibration data

[Arend Van Spriel]

On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo  wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár  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

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Lee Duncan]

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 
> ---
>  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 
>  
> -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 

[PATCH 02/14 V2] rtlwifi: Remove RT_TRACE messages that use DBG_EMERG

[Larry Finger]

These messages are always logged and represent error conditions, thus
we can use pr_err().

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 drivers/net/wireless/realtek/rtlwifi/base.c  | 14 +++--
 drivers/net/wireless/realtek/rtlwifi/cam.c   | 14 +++--
 drivers/net/wireless/realtek/rtlwifi/core.c  | 20 +---
 drivers/net/wireless/realtek/rtlwifi/efuse.c |  3 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c   | 36 --
 drivers/net/wireless/realtek/rtlwifi/ps.c|  3 +-
 drivers/net/wireless/realtek/rtlwifi/rc.c|  3 +-
 drivers/net/wireless/realtek/rtlwifi/usb.c   | 46 +---
 8 files changed, 47 insertions(+), 92 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 4ac928b..0a8553e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -207,8 +207,7 @@ static void _rtl_init_hw_ht_capab(struct ieee80211_hw *hw,
 *highest supported RX rate
 */
if (rtlpriv->dm.supp_phymode_switch) {
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
-"Support phy mode switch\n");
+   pr_info("Support phy mode switch\n");
 
ht_cap->mcs.rx_mask[0] = 0xFF;
ht_cap->mcs.rx_mask[1] = 0xFF;
@@ -389,8 +388,8 @@ static void _rtl_init_mac80211(struct ieee80211_hw *hw)
/* <4> set mac->sband to wiphy->sband */
hw->wiphy->bands[NL80211_BAND_5GHZ] = sband;
} else {
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG, "Err BAND %d\n",
-rtlhal->current_bandtype);
+   pr_err("Err BAND %d\n",
+  rtlhal->current_bandtype);
}
}
/* <5> set hw caps */
@@ -544,7 +542,7 @@ int rtl_init_core(struct ieee80211_hw *hw)
 * mac80211 hw  in _rtl_init_mac80211.
 */
if (rtl_regd_init(hw, rtl_reg_notifier)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "REGD init failed\n");
+   pr_err("REGD init failed\n");
return 1;
}
 
@@ -1694,8 +1692,7 @@ void rtl_watchdog_wq_callback(void *data)
 * we should reconnect this AP
 */
if (rtlpriv->link_info.roam_times >= 5) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"AP off, try to reconnect now\n");
+   pr_err("AP off, try to reconnect now\n");
rtlpriv->link_info.roam_times = 0;
ieee80211_connection_loss(
rtlpriv->mac80211.vif);
@@ -1886,8 +1883,7 @@ void rtl_phy_scan_operation_backup(struct ieee80211_hw 
*hw, u8 operation)
  (u8 *));
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Unknown Scan Backup operation.\n");
+   pr_err("Unknown Scan Backup operation.\n");
break;
}
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/cam.c 
b/drivers/net/wireless/realtek/rtlwifi/cam.c
index 8fe8b4c..a0605d8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/cam.c
+++ b/drivers/net/wireless/realtek/rtlwifi/cam.c
@@ -285,8 +285,7 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw, u8 
*sta_addr)
u8 i, *addr;
 
if (NULL == sta_addr) {
-   RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
-"sta_addr is NULL.\n");
+   pr_err("sta_addr is NULL.\n");
return TOTAL_CAM_ENTRY;
}
/* Does STA already exist? */
@@ -298,9 +297,8 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw, u8 
*sta_addr)
/* Get a free CAM entry. */
for (entry_idx = 4; entry_idx < TOTAL_CAM_ENTRY; entry_idx++) {
if ((bitmap & BIT(0)) == 0) {
-   RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
-"-hwsec_cam_bitmap: 0x%x entry_idx=%d\n",
-rtlpriv->sec.hwsec_cam_bitmap, entry_idx);
+   pr_err("-hwsec_cam_bitmap: 0x%x entry_idx=%d\n",
+  rtlpriv->sec.hwsec_cam_bitmap, entry_idx);
rtlpriv->sec.hwsec_cam_bitmap |= BIT(0) << entry_idx;
memcpy(rtlpriv->sec.hwsec_cam_sta_addr[entry_idx],
   sta_addr, ETH_ALEN);
@@ -319,14 +317,12 @@ void 

[PATCH 12/14 V2] rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
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 0x;
}
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 = >phyreg_def[rfpath];
 
if (RT_CANNOT_IO(hw)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "stop\n");
+   

[PATCH 14/14 V2] rtlwifi: Remove some redundant code

[Larry Finger]

The symbol DBG_EMERG is no longer used and is removed.

In a number of places, the code has redundant messages. For example, if
the failure for the firmware to run is logged, it is not necessary to
log that the firmware has been started. In addition, extraneous braces are
removed.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent.
---
 drivers/net/wireless/realtek/rtlwifi/debug.h  |  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c   |  6 +-
 .../net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c |  6 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c   | 10 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c   | 19 ++-
 .../wireless/realtek/rtlwifi/rtl8723com/fw_common.c   |  9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c   | 15 +++
 7 files changed, 11 insertions(+), 56 deletions(-)

Index: wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/debug.h
===
--- wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/debug.h
+++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/debug.h
@@ -36,7 +36,7 @@
  *unexpected HW behavior, HW BUG
  *and so on.
  */
-#define DBG_EMERG  0
+/*#define DBG_EMERG0 */
 
 /*
  *Abnormal, rare, or unexpeted cases.
Index: wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
===
--- 
wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
+++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
@@ -222,12 +222,8 @@ int rtl88e_download_fw(struct ieee80211_
_rtl88e_enable_fw_download(hw, false);
 
err = _rtl88e_fw_free_to_go(hw);
-   if (err) {
+   if (err)
pr_err("Firmware is not ready to run!\n");
-   } else {
-   RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD,
-"Firmware is ready to run!\n");
-   }
 
return 0;
 }
Index: 
wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
===
--- 
wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ 
wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -238,12 +238,8 @@ int rtl92c_download_fw(struct ieee80211_
_rtl92c_enable_fw_download(hw, false);
 
err = _rtl92c_fw_free_to_go(hw);
-   if (err) {
+   if (err)
pr_err("Firmware is not ready to run!\n");
-   } else {
-   RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE,
-"Firmware is ready to run!\n");
-   }
 
return 0;
 }
Index: wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
===
--- 
wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -125,9 +125,8 @@ static void _rtl92d_write_fw(struct ieee
_rtl92d_fill_dummy(bufferPtr, );
pagenums = size / FW_8192D_PAGE_SIZE;
remainSize = size % FW_8192D_PAGE_SIZE;
-   if (pagenums > 8) {
+   if (pagenums > 8)
pr_err("Page numbers should not greater then 8\n");
-   }
for (page = 0; page < pagenums; page++) {
offset = page * FW_8192D_PAGE_SIZE;
_rtl92d_fw_page_write(hw, page, (bufferPtr + offset),
@@ -156,8 +155,6 @@ static int _rtl92d_fw_free_to_go(struct
   value32);
return -EIO;
}
-   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;
rtl_write_dword(rtlpriv, REG_MCUFWDL, value32);
@@ -324,12 +321,9 @@ int rtl92d_download_fw(struct ieee80211_
value &= (~BIT(5));
rtl_write_byte(rtlpriv, 0x1f, value);
spin_unlock_irqrestore(_for_fwdownload, flags);
-   if (err) {
+   if (err)
pr_err("fw is not ready to run!\n");
goto exit;
-   } else {
-   RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE, "fw is ready to run!\n");
-   }
 exit:
err = _rtl92d_fw_init(hw);
return err;
Index: wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
===
--- 
wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
+++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
@@ -157,10 +157,6 @@ static int 

[PATCH 04/14 V2] rtlwifi: rtl8723be: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c  |  9 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c  | 16 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/led.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 18 +++---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/rf.c  |  3 +--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c  |  8 +++-
 6 files changed, 22 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c
index f9a2c8b..89bba11 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.c
@@ -97,8 +97,7 @@ static void _rtl8723be_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
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;
}
 
@@ -121,8 +120,8 @@ static void _rtl8723be_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
box_extreg = REG_HMEBOX_EXT_3;
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", boxnum);
+   pr_err("switch case %#x not processed\n",
+  boxnum);
break;
}
 
@@ -194,8 +192,8 @@ static void _rtl8723be_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
}
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", cmd_len);
+   pr_err("switch case %#x not processed\n",
+  cmd_len);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 0ae5562..2fb39f6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -747,9 +747,8 @@ static bool _rtl8723be_llt_write(struct ieee80211_hw *hw, 
u32 address, u32 data)
break;
 
if (count > POLLING_LLT_THRESHOLD) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to polling write LLT done at address 
%d!\n",
-address);
+   pr_err("Failed to polling write LLT done at address 
%d!\n",
+  address);
status = false;
break;
}
@@ -1383,7 +1382,7 @@ int rtl8723be_hw_init(struct ieee80211_hw *hw)
}
rtstatus = _rtl8723be_init_mac(hw);
if (!rtstatus) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
+   pr_err("Init MAC failed\n");
err = 1;
goto exit;
}
@@ -1532,8 +1531,7 @@ static int _rtl8723be_set_media_status(struct 
ieee80211_hw *hw,
 "Set Network type to AP!\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Network type %d not support!\n", type);
+   pr_err("Network type %d not support!\n", type);
return 1;
}
 
@@ -2247,7 +2245,7 @@ void rtl8723be_read_eeprom_info(struct ieee80211_hw *hw)
rtlefuse->autoload_failflag = false;
_rtl8723be_read_adapter_info(hw, false);
} else {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Autoload ERR!!\n");
+   pr_err("Autoload ERR!!\n");
}
_rtl8723be_hal_customized_behavior(hw);
 }
@@ -2584,9 +2582,7 @@ void rtl8723be_set_key(struct ieee80211_hw *hw, u32 
key_index,
entry_id = rtl_cam_get_free_entry(hw,
p_macaddr);
if (entry_id >=  TOTAL_CAM_ENTRY) {
-  

[PATCH 11/14 V2] rtlwifi: rtl8192ce: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c| 36 --
 .../net/wireless/realtek/rtlwifi/rtl8192ce/led.c   |  6 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c   | 13 +++-
 .../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c|  8 ++---
 5 files changed, 24 insertions(+), 42 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index ce07e5c..410d48bf 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -140,8 +140,7 @@ void rtl92ce_get_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
case HAL_DEF_WOWLAN:
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", variable);
+   pr_err("switch case %#x not processed\n", variable);
break;
}
 }
@@ -364,9 +363,8 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
acm_ctrl &= (~AcmHw_VoqEn);
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not 
processed\n",
-e_aci);
+   pr_err("switch case %#x not 
processed\n",
+  e_aci);
break;
}
}
@@ -551,8 +549,7 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
rtl92c_fill_h2c_cmd(hw, H2C_92C_KEEP_ALIVE_CTRL, 2, array);
break; }
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %d not processed\n", variable);
+   pr_err("switch case %d not processed\n", variable);
break;
}
 }
@@ -573,9 +570,8 @@ static bool _rtl92ce_llt_write(struct ieee80211_hw *hw, u32 
address, u32 data)
break;
 
if (count > POLLING_LLT_THRESHOLD) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to polling write LLT done at address 
%d!\n",
-address);
+   pr_err("Failed to polling write LLT done at address 
%d!\n",
+  address);
status = false;
break;
}
@@ -963,7 +959,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl92ce_init_mac(hw);
if (!rtstatus) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
+   pr_err("Init MAC failed\n");
err = 1;
goto exit;
}
@@ -1128,8 +1124,7 @@ static enum version_8192c 
_rtl92ce_read_chip_version(struct ieee80211_hw *hw)
break;
}
 
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
-"Chip Version ID: %s\n", versionid);
+   pr_info("Chip Version ID: %s\n", versionid);
 
switch (version & 0x3) {
case CHIP_88C:
@@ -1143,8 +1138,7 @@ static enum version_8192c 
_rtl92ce_read_chip_version(struct ieee80211_hw *hw)
break;
default:
rtlphy->rf_type = RF_1T1R;
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"ERROR RF_Type is set!!\n");
+   pr_err("ERROR RF_Type is set!!\n");
break;
}
 
@@ -1193,8 +1187,7 @@ static int _rtl92ce_set_media_status(struct ieee80211_hw 
*hw,
 "Set Network type to Mesh Point!\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Network type %d not supported!\n", type);
+   pr_err("Network type %d not supported!\n", type);
return 1;
 
}
@@ -1780,7 +1773,7 @@ void rtl92ce_read_eeprom_info(struct ieee80211_hw *hw)
rtlefuse->autoload_failflag = false;
_rtl92ce_read_adapter_info(hw);
} else {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Autoload 

[PATCH 09/14 V2] rtlwifi: rtl8192de: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8192de/fw.c| 19 
 .../net/wireless/realtek/rtlwifi/rtl8192de/hw.c| 34 --
 .../net/wireless/realtek/rtlwifi/rtl8192de/led.c   |  6 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192de/phy.c   | 31 
 .../net/wireless/realtek/rtlwifi/rtl8192de/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192de/sw.c|  8 ++---
 6 files changed, 36 insertions(+), 65 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index ddbb7e8..ed6aba0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -126,8 +126,7 @@ static void _rtl92d_write_fw(struct ieee80211_hw *hw,
pagenums = size / FW_8192D_PAGE_SIZE;
remainSize = size % FW_8192D_PAGE_SIZE;
if (pagenums > 8) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Page numbers should not greater then 8\n");
+   pr_err("Page numbers should not greater then 8\n");
}
for (page = 0; page < pagenums; page++) {
offset = page * FW_8192D_PAGE_SIZE;
@@ -153,9 +152,8 @@ static int _rtl92d_fw_free_to_go(struct ieee80211_hw *hw)
} while ((counter++ < FW_8192D_POLLING_TIMEOUT_COUNT) &&
 (!(value32 & FWDL_ChkSum_rpt)));
if (counter >= FW_8192D_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);
return -EIO;
}
RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE,
@@ -327,8 +324,7 @@ int rtl92d_download_fw(struct ieee80211_hw *hw)
rtl_write_byte(rtlpriv, 0x1f, value);
spin_unlock_irqrestore(_for_fwdownload, flags);
if (err) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"fw is not ready to run!\n");
+   pr_err("fw is not ready to run!\n");
goto exit;
} else {
RT_TRACE(rtlpriv, COMP_FW, DBG_TRACE, "fw is ready to run!\n");
@@ -407,8 +403,7 @@ static void _rtl92d_fill_h2c_command(struct ieee80211_hw 
*hw,
while (!bwrite_success) {
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;
}
boxnum = rtlhal->last_hmeboxnum;
@@ -430,8 +425,8 @@ static void _rtl92d_fill_h2c_command(struct ieee80211_hw 
*hw,
box_extreg = REG_HMEBOX_EXT_3;
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", boxnum);
+   pr_err("switch case %#x not processed\n",
+  boxnum);
break;
}
isfw_read = _rtl92d_check_fw_read_last_h2c(hw, boxnum);
@@ -507,8 +501,8 @@ static void _rtl92d_fill_h2c_command(struct ieee80211_hw 
*hw,
   boxcontent[idx]);
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", cmd_len);
+   pr_err("switch case %#x not processed\n",
+  cmd_len);
break;
}
bwrite_success = true;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
index fcb14c5..2c92c33 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
@@ -163,8 +163,7 @@ void rtl92de_get_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
case HAL_DEF_WOWLAN:
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", variable);
+   pr_err("switch case %#x not processed\n", 

[PATCH 08/14] rtlwifi: rtl8192se: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8192se/fw.c| 46 --
 .../net/wireless/realtek/rtlwifi/rtl8192se/hw.c| 40 +++
 .../net/wireless/realtek/rtlwifi/rtl8192se/led.c   |  6 +--
 .../net/wireless/realtek/rtlwifi/rtl8192se/phy.c   | 36 ++---
 .../net/wireless/realtek/rtlwifi/rtl8192se/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192se/sw.c|  8 ++--
 6 files changed, 51 insertions(+), 88 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c
index 32f9207..1922e78 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.c
@@ -113,8 +113,7 @@ static u8 _rtl92s_firmware_header_map_rftype(struct 
ieee80211_hw *hw)
case RF_2T2R:
return 0x22;
default:
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG, "Unknown RF type(%x)\n",
-rtlphy->rf_type);
+   pr_err("Unknown RF type(%x)\n", rtlphy->rf_type);
break;
}
return 0x22;
@@ -168,9 +167,7 @@ static bool _rtl92s_firmware_downloadcode(struct 
ieee80211_hw *hw,
_rtl92s_fw_set_rqpn(hw);
 
if (buffer_len >= MAX_FIRMWARE_CODE_SIZE) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Size over FIRMWARE_CODE_SIZE!\n");
-
+   pr_err("Size over FIRMWARE_CODE_SIZE!\n");
return false;
}
 
@@ -239,9 +236,8 @@ static bool _rtl92s_firmware_checkready(struct ieee80211_hw 
*hw,
} while (pollingcnt--);
 
if (!(cpustatus & IMEM_CHK_RPT) || (pollingcnt <= 0)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"FW_STATUS_LOAD_IMEM FAIL CPU, Status=%x\n",
-cpustatus);
+   pr_err("FW_STATUS_LOAD_IMEM FAIL CPU, Status=%x\n",
+  cpustatus);
goto status_check_fail;
}
break;
@@ -257,17 +253,15 @@ static bool _rtl92s_firmware_checkready(struct 
ieee80211_hw *hw,
} while (pollingcnt--);
 
if (!(cpustatus & EMEM_CHK_RPT) || (pollingcnt <= 0)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"FW_STATUS_LOAD_EMEM FAIL CPU, Status=%x\n",
-cpustatus);
+   pr_err("FW_STATUS_LOAD_EMEM FAIL CPU, Status=%x\n",
+  cpustatus);
goto status_check_fail;
}
 
/* Turn On CPU */
rtstatus = _rtl92s_firmware_enable_cpu(hw);
if (!rtstatus) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Enable CPU fail!\n");
+   pr_err("Enable CPU fail!\n");
goto status_check_fail;
}
break;
@@ -282,9 +276,8 @@ static bool _rtl92s_firmware_checkready(struct ieee80211_hw 
*hw,
} while (pollingcnt--);
 
if (!(cpustatus & DMEM_CODE_DONE) || (pollingcnt <= 0)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Polling DMEM code done fail ! 
cpustatus(%#x)\n",
-cpustatus);
+   pr_err("Polling DMEM code done fail ! cpustatus(%#x)\n",
+  cpustatus);
goto status_check_fail;
}
 
@@ -308,9 +301,8 @@ static bool _rtl92s_firmware_checkready(struct ieee80211_hw 
*hw,
 
if (((cpustatus & LOAD_FW_READY) != LOAD_FW_READY) ||
(pollingcnt <= 0)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Polling Load Firmware ready fail ! 
cpustatus(%x)\n",
-cpustatus);
+   pr_err("Polling Load Firmware ready fail ! 
cpustatus(%x)\n",
+  cpustatus);
goto status_check_fail;
}
 
@@ -331,8 +323,7 @@ static bool _rtl92s_firmware_checkready(struct ieee80211_hw 
*hw,
break;
 
default:
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
-"Unknown status check!\n");
+   pr_err("Unknown status check!\n");
 

[PATCH 05/14 V2] rtlwifi: rtl8723ae: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent.
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c  |  9 +++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c  | 19 +++
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/led.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 18 +++---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rf.c  |  3 +--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c  |  8 +++-
 6 files changed, 23 insertions(+), 40 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c
index 2f398da..9136fb3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c
@@ -99,8 +99,7 @@ static void _rtl8723e_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
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;
}
 
@@ -123,8 +122,8 @@ static void _rtl8723e_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
box_extreg = REG_HMEBOX_EXT_3;
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", boxnum);
+   pr_err("switch case %#x not processed\n",
+  boxnum);
break;
}
 
@@ -229,8 +227,8 @@ static void _rtl8723e_fill_h2c_command(struct ieee80211_hw 
*hw, u8 element_id,
}
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", cmd_len);
+   pr_err("switch case %#x not processed\n",
+  cmd_len);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index 6c51483..dff9ebb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -570,9 +570,8 @@ static bool _rtl8723e_llt_write(struct ieee80211_hw *hw, 
u32 address, u32 data)
break;
 
if (count > POLLING_LLT_THRESHOLD) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to polling write LLT done at address 
%d!\n",
-address);
+   pr_err("Failed to polling write LLT done at address 
%d!\n",
+  address);
status = false;
break;
}
@@ -961,7 +960,7 @@ int rtl8723e_hw_init(struct ieee80211_hw *hw)
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl8712e_init_mac(hw);
if (rtstatus != true) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
+   pr_err("Init MAC failed\n");
err = 1;
goto exit;
}
@@ -1107,8 +1106,7 @@ static enum version_8723e 
_rtl8723e_read_chip_version(struct ieee80211_hw *hw)
 "Chip Version ID: 
VERSION_NORMAL_UMC_CHIP_8723_1T1R_B_CUT.\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Chip Version ID: Unknown. Bug?\n");
+   pr_err("Chip Version ID: Unknown. Bug?\n");
break;
}
 
@@ -1157,8 +1155,7 @@ static int _rtl8723e_set_media_status(struct ieee80211_hw 
*hw,
"Set Network type to AP!\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-   "Network type %d not support!\n", type);
+   pr_err("Network type %d not support!\n", type);
return 1;
break;
}
@@ -1852,7 +1849,7 @@ void rtl8723e_read_eeprom_info(struct ieee80211_hw *hw)
} else {
rtlefuse->autoload_failflag = true;
_rtl8723e_read_adapter_info(hw, false);
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Autoload ERR!!\n");
+   

[PATCH 13/14 V2] rtlwifi: rtl8188ee: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c| 33 ++
 .../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c| 30 
 .../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 22 ++-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c|  8 ++
 5 files changed, 33 insertions(+), 63 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
index c34cde2..009fd3b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c
@@ -125,10 +125,8 @@ static void _rtl88e_write_fw(struct ieee80211_hw *hw,
pagenums = size / FW_8192C_PAGE_SIZE;
remainsize = size % FW_8192C_PAGE_SIZE;
 
-   if (pagenums > 8) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Page numbers should not greater then 8\n");
-   }
+   if (pagenums > 8)
+   pr_err("Page numbers should not greater then 8\n");
 
for (page = 0; page < pagenums; page++) {
offset = page * FW_8192C_PAGE_SIZE;
@@ -157,15 +155,10 @@ static int _rtl88e_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;
@@ -176,20 +169,15 @@ static int _rtl88e_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;
 
udelay(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;
@@ -235,8 +222,7 @@ int rtl88e_download_fw(struct ieee80211_hw *hw,
 
err = _rtl88e_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_LOUD,
 "Firmware is ready to run!\n");
@@ -309,8 +295,7 @@ static void _rtl88e_fill_h2c_command(struct ieee80211_hw 
*hw,
while (!write_sucess) {
wait_writeh2c_limit--;
if (wait_writeh2c_limit == 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/rtl8188ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index d85fa67..6aa593d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -358,8 +358,7 @@ void rtl88ee_get_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
case HAL_DEF_WOWLAN:
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"switch case %#x not processed\n", variable);
+   pr_err("switch case %#x not processed\n", variable);
break;
}
 }
@@ -572,9 +571,8 @@ void rtl88ee_set_hw_reg(struct ieee80211_hw *hw, u8 
variable, u8 *val)
   

[PATCH 07/14 V2] rtlwifi: rtl8723-common: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c  | 16 ++--
 .../net/wireless/realtek/rtlwifi/rtl8723com/phy_common.c |  4 ++--
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
index 108475e..a9cc67e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c
@@ -129,8 +129,8 @@ void rtl8723_write_fw(struct ieee80211_hw *hw,
remain_size = size % FW_8192C_PAGE_SIZE;
 
if (page_nums > max_page) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Page numbers should not greater than %d\n", max_page);
+   pr_err("Page numbers should not greater than %d\n",
+  max_page);
}
for (page = 0; page < page_nums; page++) {
offset = page * FW_8192C_PAGE_SIZE;
@@ -209,9 +208,8 @@ int rtl8723_fw_free_to_go(struct ieee80211_hw *hw, bool 
is_8723be,
 (!(value32 & FWDL_CHKSUM_RPT)));
 
if (counter >= max_count) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"chksum report fail ! 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,
@@ -239,9 +237,8 @@ int rtl8723_fw_free_to_go(struct ieee80211_hw *hw, bool 
is_8723be,
 
} while (counter++ < max_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;
@@ -294,8 +291,7 @@ int rtl8723_download_fw(struct ieee80211_hw *hw,
 
err = rtl8723_fw_free_to_go(hw, is_8723be, max_count);
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");
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/phy_common.c
index 0adae58..91a1ef0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/phy_common.c
@@ -99,7 +99,7 @@ u32 rtl8723_phy_rf_serial_read(struct ieee80211_hw *hw,
offset &= 0xff;
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 0x;
}
tmplong = rtl_get_bbreg(hw, RFPGA0_XA_HSSIPARAMETER2, MASKDWORD);
@@ -147,7 +147,7 @@ void rtl8723_phy_rf_serial_write(struct ieee80211_hw *hw,
struct bb_reg_def *pphyreg = >phyreg_def[rfpath];
 
if (RT_CANNOT_IO(hw)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "stop\n");
+   pr_err("stop\n");
return;
}
offset &= 0xff;
-- 
2.10.2

[PATCH 10/14 V2] rtlwifi: rtl8192cu: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent.
---
 .../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c| 33 --
 .../net/wireless/realtek/rtlwifi/rtl8192cu/led.c   |  6 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c   | 12 +++-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c   | 12 +++-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c|  5 ++--
 6 files changed, 24 insertions(+), 47 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index aa3d559..dce13d6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -452,8 +452,7 @@ static int _rtl92cu_init_power_on(struct ieee80211_hw *hw)
break;
}
if (pollingCount++ > 100) {
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
-"Failed to polling REG_APS_FSMCO[PFM_ALDN] 
done!\n");
+   pr_err("Failed to polling REG_APS_FSMCO[PFM_ALDN] 
done!\n");
return -ENODEV;
}
} while (true);
@@ -486,8 +485,7 @@ static int _rtl92cu_init_power_on(struct ieee80211_hw *hw)
break;
}
if (pollingCount++ > 1000) {
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG,
-"Failed to polling REG_APS_FSMCO[APFM_ONMAC] 
done!\n");
+   pr_err("Failed to polling REG_APS_FSMCO[APFM_ONMAC] 
done!\n");
return -ENODEV;
}
} while (true);
@@ -687,7 +685,6 @@ static void 
_rtl92cu_init_chipN_three_out_ep_priority(struct ieee80211_hw *hw,
  u8 queue_sel)
 {
u16 beQ, bkQ, viQ, voQ, mgtQ, hiQ;
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
 
if (!wmm_enable) { /* typical setting */
beQ = QUEUE_LOW;
@@ -705,8 +702,7 @@ static void 
_rtl92cu_init_chipN_three_out_ep_priority(struct ieee80211_hw *hw,
hiQ = QUEUE_HIGH;
}
_rtl92c_init_chipN_reg_priority(hw, beQ, bkQ, viQ, voQ, mgtQ, hiQ);
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG, "Tx queue select :0x%02x..\n",
-queue_sel);
+   pr_info("Tx queue select :0x%02x..\n", queue_sel);
 }
 
 static void _rtl92cu_init_chipN_queue_priority(struct ieee80211_hw *hw,
@@ -765,8 +761,7 @@ static void _rtl92cu_init_chipT_queue_priority(struct 
ieee80211_hw *hw,
break;
}
rtl_write_byte(rtlpriv, (REG_TRXDMA_CTRL+1), hq_sele);
-   RT_TRACE(rtlpriv, COMP_INIT, DBG_EMERG, "Tx queue select :0x%02x..\n",
-hq_sele);
+   pr_info("Tx queue select :0x%02x..\n", hq_sele);
 }
 
 static void _rtl92cu_init_queue_priority(struct ieee80211_hw *hw,
@@ -848,8 +843,7 @@ static int _rtl92cu_init_mac(struct ieee80211_hw *hw)
err = _rtl92cu_init_power_on(hw);
 
if (err) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to init power on!\n");
+   pr_err("Failed to init power on!\n");
return err;
}
if (!wmm_enable) {
@@ -860,8 +854,7 @@ static int _rtl92cu_init_mac(struct ieee80211_hw *hw)
: WMM_CHIP_A_TX_PAGE_BOUNDARY;
}
if (false == rtl92c_init_llt_table(hw, boundary)) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to init LLT Table!\n");
+   pr_err("Failed to init LLT Table!\n");
return -EINVAL;
}
_rtl92cu_init_queue_reserved_page(hw, wmm_enable, out_ep_nums,
@@ -986,7 +979,7 @@ int rtl92cu_hw_init(struct ieee80211_hw *hw)
rtlhal->hw_type = HARDWARE_TYPE_RTL8192CU;
err = _rtl92cu_init_mac(hw);
if (err) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "init mac failed!\n");
+   pr_err("init mac failed!\n");
goto exit;
}
err = rtl92c_download_fw(hw);
@@ -1099,8 +1092,7 @@ static void  _ResetDigitalProcedure1(struct ieee80211_hw 
*hw, bool bWithoutHWSM)
udelay(50);
}
if (retry_cnts >= 100) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"#=> 8051 reset 
failed!.\n");
+   pr_err("8051 reset 

[PATCH 06/14 V2] rtlwifi: rtl8192ee: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c| 21 -
 .../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c| 11 ---
 .../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 22 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c|  3 +--
 .../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c|  8 +++-
 5 files changed, 25 insertions(+), 40 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
index c2dc26d..27f9608 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/fw.c
@@ -122,10 +122,8 @@ static void _rtl92ee_write_fw(struct ieee80211_hw *hw,
pagenums = size / FW_8192C_PAGE_SIZE;
remainsize = size % FW_8192C_PAGE_SIZE;
 
-   if (pagenums > 8) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Page numbers should not greater then 8\n");
-   }
+   if (pagenums > 8)
+   pr_err("Page numbers should not greater then 8\n");
 
for (page = 0; page < pagenums; page++) {
offset = page * FW_8192C_PAGE_SIZE;
@@ -155,14 +153,13 @@ static int _rtl92ee_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);
+"Checksum report OK! REG_MCUFWDL:0x%08x\n", value32);
 
value32 = rtl_read_dword(rtlpriv, REG_MCUFWDL);
value32 |= MCUFWDL_RDY;
@@ -186,9 +183,8 @@ static int _rtl92ee_fw_free_to_go(struct ieee80211_hw *hw)
 
} while (counter++ < FW_8192C_POLLING_TIMEOUT_COUNT);
 
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Polling FW ready fail!! REG_MCUFWDL:0x%08x. count = %d\n",
-value32, counter);
+   pr_err("Polling FW ready fail!! REG_MCUFWDL:0x%08x. count = %d\n",
+  value32, counter);
 
 exit:
return err;
@@ -241,8 +237,7 @@ int rtl92ee_download_fw(struct ieee80211_hw *hw, bool 
buse_wake_on_wlan_fw)
 
err = _rtl92ee_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_LOUD ,
 "Firmware is ready to run!\n");
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
index bd416b8..c2a7666 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
@@ -1320,7 +1320,7 @@ int rtl92ee_hw_init(struct ieee80211_hw *hw)
rtl_write_byte(rtlpriv, 0x65, 1);
}
if (!rtstatus) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
+   pr_err("Init MAC failed\n");
err = 1;
return err;
}
@@ -1485,8 +1485,7 @@ static int _rtl92ee_set_media_status(struct ieee80211_hw 
*hw,
 "Set Network type to AP!\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Network type %d not support!\n", type);
+   pr_err("Network type %d not support!\n", type);
return 1;
}
 
@@ -2206,7 +2205,7 @@ void rtl92ee_read_eeprom_info(struct ieee80211_hw *hw)
rtlefuse->autoload_failflag = false;
_rtl92ee_read_adapter_info(hw);
} else {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Autoload ERR!!\n");
+   pr_err("Autoload ERR!!\n");
}
_rtl92ee_hal_customized_behavior(hw);
 
@@ -2484,9 +2483,7 @@ void rtl92ee_set_key(struct ieee80211_hw *hw, u32 
key_index,
entry_id = rtl_cam_get_free_entry(hw,
 p_macaddr);
if 

[PATCH 03/14 V2] rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG

[Larry Finger]

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 
Cc: Ping-Ke Shih 
---
V2 - eliminate some files that should not have been sent, and remove the
 module name from the format. It is already specified by a pr_fmt().
---
 .../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c| 11 ++
 .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c| 15 +++-
 .../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c   | 43 --
 .../net/wireless/realtek/rtlwifi/rtl8821ae/rf.c|  5 +--
 .../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c| 14 +++
 6 files changed, 33 insertions(+), 58 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
index bdfd444..32900c5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
@@ -604,8 +604,7 @@ static void rtl8821ae_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
if ((mac->link_state < MAC80211_LINKED) &&
(rtlpriv->dm.entry_min_undec_sm_pwdb == 0)) {
rtl_dm_dig->min_undec_pwdb_for_dm = 0;
-   RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"Not connected to any\n");
+   pr_debug("rtl8821ae: Not connected to any AP\n");
}
if (mac->link_state >= MAC80211_LINKED) {
if (mac->opmode == NL80211_IFTYPE_AP ||
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
index c70face..602ac86 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
@@ -125,8 +125,7 @@ static void _rtl8821ae_write_fw(struct ieee80211_hw *hw,
remainsize = size % FW_8821AE_PAGE_SIZE;
 
if (pagenums > 8) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Page numbers should not greater then 8\n");
+   pr_err("Page numbers should not greater then 8\n");
}
 
for (page = 0; page < pagenums; page++) {
@@ -162,8 +161,8 @@ static int _rtl8821ae_fw_free_to_go(struct ieee80211_hw *hw)
goto exit;
}
 
-   RT_TRACE(rtlpriv, COMP_FW, DBG_EMERG,
-"Checksum report OK ! REG_MCUFWDL:0x%08x .\n", value32);
+   pr_err("Checksum report OK! REG_MCUFWDL:0x%08x\n",
+  value32);
 
value32 = rtl_read_dword(rtlpriv, REG_MCUFWDL);
value32 |= MCUFWDL_RDY;
@@ -186,9 +184,8 @@ static int _rtl8821ae_fw_free_to_go(struct ieee80211_hw *hw)
udelay(FW_8821AE_POLLING_DELAY);
} while (counter++ < FW_8821AE_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;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index b6dc2f3..3932a5d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -822,9 +822,8 @@ static bool _rtl8821ae_llt_write(struct ieee80211_hw *hw, 
u32 address, u32 data)
break;
 
if (count > POLLING_LLT_THRESHOLD) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Failed to polling write LLT done at address 
%d!\n",
-address);
+   pr_err("Failed to polling write LLT done at address 
%d!\n",
+  address);
status = false;
break;
}
@@ -1927,7 +1926,7 @@ int rtl8821ae_hw_init(struct ieee80211_hw *hw)
 
rtstatus = _rtl8821ae_init_mac(hw);
if (rtstatus != true) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
+   pr_err("Init MAC failed\n");
err = 1;
return err;
}
@@ -2174,8 +2173,7 @@ static int _rtl8821ae_set_media_status(struct 
ieee80211_hw *hw,
 "Set Network type to AP!\n");
break;
default:
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Network type %d not support!\n", type);
+   pr_err("Network type %d not support!\n", type);
return 1;
}
 
@@ -3274,7 +3272,7 @@ void rtl8821ae_read_eeprom_info(struct ieee80211_hw *hw)
rtlefuse->autoload_failflag = false;

[PATCH 00/14 V2] rtlwifi: Start reworking of debug system

[Larry Finger]

Following the discussion regarding the patch entitled "rtlwifi: Add
BTC_TRACE_STRING to new btcoex", we are reworking the entire debug
system. This set of patches does the following:

1. Replaces every invocation of RT_ASSERT with WARN_ON. With this
   change, triggering these conditions with now give a stack dump.
   Note that the logical condition between RT_ASSERT and WARN_ON
   is inverted. In making these changes, 6 logic errors were found.
2. Replaces every call of RT_TRACE with the level set to DBG_EMERG
   with the equivalent pr_err() call. Future plans call for using
   the COMP_xxx portion of the macro as a debug mask. If these changes
   are not made, these error conditions might not be logged.
3. Removes some redundant logged conditions. For example, when the
   failure of firmware to start is logged, it is not necessary to
   log that the firmware did start.

The previous two patch sequences "[PATCH 00/14] rtlwifi: Various updates"
and "[PATCH 0/7] rtlwifi: btcoexist: Rewrite BT coexistence routines"
should be discarded. That material will be resubmitted later.

V2 removes those files that had rtlwifi_new in the subject. They should
not have been sent. It also removes the module name from the format as
it is specified by the pr_fmt macro in wifi.h as noted by Joe Perches.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 

Larry Finger (14):
  rtlwifi: Replace local debug macro RT_ASSERT
  rtlwifi_new: Remove RT_TRACE messages that use DBG_EMERG
  rtlwifi_new: rtl8821ae: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8723be: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8723ae: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192ee: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8723-common: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192se: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192de: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192cu: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192ce: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8192c-common: Remove all instances of DBG_EMERG
  rtlwifi_new: rtl8188ee: Remove all instances of DBG_EMERG
  rtlwifi: Remove some redundant code

 drivers/net/wireless/realtek/rtlwifi/base.c| 15 +++
 drivers/net/wireless/realtek/rtlwifi/cam.c | 14 +++---
 drivers/net/wireless/realtek/rtlwifi/core.c| 29 +---
 drivers/net/wireless/realtek/rtlwifi/debug.c   |  9 ++--
 drivers/net/wireless/realtek/rtlwifi/debug.h   | 18 +---
 drivers/net/wireless/realtek/rtlwifi/efuse.c   |  3 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c | 48 
 drivers/net/wireless/realtek/rtlwifi/ps.c  |  3 +-
 drivers/net/wireless/realtek/rtlwifi/rc.c  |  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c| 43 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c| 32 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 32 ++
 .../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c|  8 ++--
 .../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c   |  8 ++--
 .../wireless/realtek/rtlwifi/rtl8192c/fw_common.c  | 45 ++-
 .../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 27 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c| 38 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192ce/led.c   |  6 +--
 .../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c   | 13 +++---
 .../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c|  8 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c   |  8 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c| 35 +--
 .../net/wireless/realtek/rtlwifi/rtl8192cu/led.c   |  6 +--
 .../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c   | 12 ++---
 .../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c   | 12 ++---
 .../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c|  5 +--
 .../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c   |  2 +-
 .../net/wireless/realtek/rtlwifi/rtl8192de/fw.c| 31 -
 .../net/wireless/realtek/rtlwifi/rtl8192de/hw.c| 34 +--
 .../net/wireless/realtek/rtlwifi/rtl8192de/led.c   |  6 +--
 .../net/wireless/realtek/rtlwifi/rtl8192de/phy.c   | 41 -
 .../net/wireless/realtek/rtlwifi/rtl8192de/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192de/sw.c| 10 ++---
 .../net/wireless/realtek/rtlwifi/rtl8192de/trx.c   |  8 ++--
 .../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c| 40 +
 .../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c| 13 +++---
 .../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 36 +++
 .../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c|  3 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c|  8 ++--
 

RE: ath10k firmware sends probes on DFS channels without radar detection

[Jean-Pierre Tosoni]

> -Message d'origine-
> De : Ben Greear [mailto:gree...@candelatech.com]
> Envoyé : jeudi 15 décembre 2016 17:33
> À : Jean-Pierre Tosoni; 'Jouni Malinen'
> Cc : linux-wireless@vger.kernel.org; ath...@lists.infradead.org
> Objet : Re: ath10k firmware sends probes on DFS channels without radar
> detection
> 
> On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:
> > Jouni,
> >
> > 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:
> >
> > // awful patch ahead 
> >
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
> > ch->chan_radar =
> > !!(channel->flags & IEEE80211_CHAN_RADAR);
> >
> > -   passive = channel->flags & IEEE80211_CHAN_NO_IR;
> > +   passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> > +   IEEE80211_CHAN_RADAR);
> 
> So, should we add a new flag in firmware and driver that means 'really-no-
> IR', or should the NO_IR flag here just always make the firmware never do
> IR when probing regardless of whether it has seen beacons or not?

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.

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)

I am out of office for the next week.
Regards,
Jean-Pierre
> 
> Thanks,
> Ben
> 
> > +
> > ch->passive = passive;
> >
> > ch->freq = channel->center_freq;
> > @@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
> >
> > lockdep_assert_held(>conf_mutex);
> >
> > +   if (ar->state == ATH10K_STATE_ON)
> > +   ath10k_regd_update(ar);
> > +
> > ret = ath10k_wmi_start_scan(ar, arg);
> > if (ret)
> > return ret;
> >
> > 
> >
> > ...But this sets a terrible penalty on performance when applied to
> > background scan.
> >
> >
> > On 12/14/16 20:58 Jouni Malinen wrote:
> >>
> >> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> >>> This follows on the previous discussion
> >>>   "Client station sends probes on DFS channels"
> >>>
> >>> Problem:
> >>> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> >>> wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> >>> 4.7; because they can send probes for 600s when no AP is around.
> >>>
> >>> Analysis:
> >>> The problem seems to lie in the firmware, which regards the presence
> >>> of *any* beacon as a proof that the channel is radar-clean for 600s.
> >>
> >> I don't think this is really firmware, but cfg80211 regulatory code
> >> and how it interacts with ath10k..
> >>
> >>> - there is no obvious fix working in ath10k.
> >>> - the issue does not show up with other mac80211 devices like ath9k.
> >>> - wpa_supplicant considers this is a kernel issue [2]
> >>
> >> There seems to be a difference between ath9k (mac80211-based Probe
> >> Request frame sending) and ath10k (firmware) in this area for active
> scanning.
> >> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while
> >> ath10k uses IEEE80211_CHAN_NO_IR. I'd assume this difference results
> >> in ath10k using cfg80211 beacon hints (etc.) to update the NO_IR flag
> >> and that might be behind the difference you see.
> >>
> >> Could you check whether the following change gets you the behavior
> >> you want to see here? I have not had a chance to test this yet, but
> >> based on code review, it looks like something that brings the same
> >> behavior to ath10k that ath9k has for this through mac80211.
> >>
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> >> b/drivers/net/wireless/ath/ath10k/mac.c
> >> index aa545a1..758dbbd 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct
> >> ath10k
> >> *ar)
> >>ch->chan_radar =
> >>!!(channel->flags & IEEE80211_CHAN_RADAR);
> >>
> >> -  passive = channel->flags & IEEE80211_CHAN_NO_IR;
> >> +  passive = 

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Krzysztof Kozlowski]

On Thu, Dec 15, 2016 at 07:15:20AM +0200, 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 
> ---
>  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 
>  
> -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;

For plat-samsung:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Christian Lamparter]

Hello Shafi,

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
> '>debug.fw_stats.peers_extd)'  and should we get rid of the below
> (and the required cleanup as well) 
> 
> list_splice_tail_init(_extd,
>   >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.

Regards,
Christian

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hi Christian,

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
'>debug.fw_stats.peers_extd)'  and should we get rid of the below
(and the required cleanup as well) 

list_splice_tail_init(_extd,
>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.

regards,
shafi

On Thu, Dec 15, 2016 at 09:56:59PM +0530, Mohammed Shafi Shajakhan wrote:
> Hello Christian,
> 
> On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan 
> > wrote:
> > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan 
> > > > wrote:
> > > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct 
> > > > > > ath10k *ar, struct sk_buff *skb)
> > > > > > goto free;
> > > > > > }
> > > > > >  
> > > > > > +   if (!list_empty())
> > > > > 
> > > > > [shafi] sorry please correct me if i am wrong, for 'extended peer 
> > > > > stats' we are checking
> > > > > for normal 'peer stats' ? Is this the fix intended, i had started a 
> > > > > build to
> > > > > check your change and we will keep you posted, does this fix 
> > > > > displaying
> > > > > 'rx_duration' in ath10k fw_stats.
> > > > The idea is not to queue any "extended peer stats" when there where no 
> > > > "peer stats" to
> > > > begin with. Because otherwise, the function is still vulnerable to OOM 
> > > > since the 
> > > > extended peers stats will be queued unchecked (not that this is 
> > > > currently a problem).
> > > 
> > > [shafi] list_splice_tail_init should still check for non-empty 
> > > 'peers_extd' list
> > > and append if required ? please let me know if i am still missing 
> > > something
> > Well, you can also count the entries in peers_extd and delete the old 
> > entries
> > if they start to overflow. If you want to do it differently, please go 
> > ahead.
> >
> [shafi] sorry for the delay (got stuck up with something else), I will add 
> some prints explicitly
> and keep you posted ASAP. Since the extended peer stats gets updated 
> periodically I
> would like to confirm the debug linked list associated to the extended peer
> stats does not overflows and potentially cause OOM.
> 
> regards,
> shafi

Re: [RFC v2 11/11] ath10k: Added sdio support

[Valo, Kalle]

Erik Stromdahl  writes:

> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl 
> ---
>  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?

-- 
Kalle Valo

Re: ath10k firmware sends probes on DFS channels without radar detection

[Ben Greear]

On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:

Jouni,

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:

// awful patch ahead 

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
ch->chan_radar =
!!(channel->flags & IEEE80211_CHAN_RADAR);

-   passive = channel->flags & IEEE80211_CHAN_NO_IR;
+   passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+   IEEE80211_CHAN_RADAR);


So, should we add a new flag in firmware and driver that means 'really-no-IR', 
or
should the NO_IR flag here just always make the firmware never do IR when 
probing
regardless of whether it has seen beacons or not?

Thanks,
Ben


+
ch->passive = passive;

ch->freq = channel->center_freq;
@@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1

lockdep_assert_held(>conf_mutex);

+   if (ar->state == ATH10K_STATE_ON)
+   ath10k_regd_update(ar);
+
ret = ath10k_wmi_start_scan(ar, arg);
if (ret)
return ret;



...But this sets a terrible penalty on performance when applied to
background scan.


On 12/14/16 20:58 Jouni Malinen wrote:


On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:

This follows on the previous discussion
"Client station sends probes on DFS channels"

Problem:
The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
4.7; because they can send probes for 600s when no AP is around.

Analysis:
The problem seems to lie in the firmware, which regards the presence
of *any* beacon as a proof that the channel is radar-clean for 600s.


I don't think this is really firmware, but cfg80211 regulatory code and
how it interacts with ath10k..


- there is no obvious fix working in ath10k.
- the issue does not show up with other mac80211 devices like ath9k.
- wpa_supplicant considers this is a kernel issue [2]


There seems to be a difference between ath9k (mac80211-based Probe Request
frame sending) and ath10k (firmware) in this area for active scanning.
mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
be behind the difference you see.

Could you check whether the following change gets you the behavior you
want to see here? I have not had a chance to test this yet, but based on
code review, it looks like something that brings the same behavior to
ath10k that ath9k has for this through mac80211.


diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..758dbbd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
*ar)
ch->chan_radar =
!!(channel->flags & IEEE80211_CHAN_RADAR);

-   passive = channel->flags & IEEE80211_CHAN_NO_IR;
+   passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+   IEEE80211_CHAN_RADAR);
ch->passive = passive;

ch->freq = channel->center_freq;

--
Jouni MalinenPGP id EFC895FA

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k





--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

[Mohammed Shafi Shajakhan]

Hello Christian,

On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan 
> > > wrote:
> > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct 
> > > > > ath10k *ar, struct sk_buff *skb)
> > > > >   goto free;
> > > > >   }
> > > > >  
> > > > > + if (!list_empty())
> > > > 
> > > > [shafi] sorry please correct me if i am wrong, for 'extended peer 
> > > > stats' we are checking
> > > > for normal 'peer stats' ? Is this the fix intended, i had started a 
> > > > build to
> > > > check your change and we will keep you posted, does this fix displaying
> > > > 'rx_duration' in ath10k fw_stats.
> > > The idea is not to queue any "extended peer stats" when there where no 
> > > "peer stats" to
> > > begin with. Because otherwise, the function is still vulnerable to OOM 
> > > since the 
> > > extended peers stats will be queued unchecked (not that this is currently 
> > > a problem).
> > 
> > [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' 
> > list
> > and append if required ? please let me know if i am still missing something
> Well, you can also count the entries in peers_extd and delete the old entries
> if they start to overflow. If you want to do it differently, please go ahead.
>
[shafi] sorry for the delay (got stuck up with something else), I will add some 
prints explicitly
and keep you posted ASAP. Since the extended peer stats gets updated 
periodically I
would like to confirm the debug linked list associated to the extended peer
stats does not overflows and potentially cause OOM.

regards,
shafi

Re: wl1251 & mac address & calibration data

[Pali Rohár]

On Thu Dec 15 09:18:44 2016 Kalle Valo  wrote:
> (Adding Luis because he has been working on request_firmware() lately)
> 
> Pali Rohár  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.

> 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.

> > and load mac address also via request_firmware() either by appending
> > it   into NVS data or via separate call
> 
> I'm not really fan of the idea providing permanent mac address through
> request_firmware(). For example, how to handle multiple devices on the
> same host, would there be a need for some kind of bus ids encoded to the
> filename? And what about devices with multiple mac addresses?

For N900 there is only one wl1251 device. And... wl12xx is already using 
appended MAC address in calibration data read by request firmware. So reason 
why I prefer similar usage also for wl1251.

> I wish there would be a better way than request_firmware() to provide
> the permanent mac addresses from user space (if device tree is not
> available), I just don't know what that could be :) But if we would
> start to use request_firmware() for this at least there should be a
> wider concensus about that and it should be properly documented, just
> like the device tree bindings.
> 
> -- 
> Kalle Valo

I do not know about any other, so reason why I'm asking :-) and there are my 
proposed solutions. If you (or any other) came up with better we can discuss 
about it :-)

-- 
Pali Rohár
pali.ro...@gmail.com

RE: ath10k firmware sends probes on DFS channels without radar detection

[Jean-Pierre Tosoni]

Jouni,

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:

// awful patch ahead 

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
ch->chan_radar =
!!(channel->flags & IEEE80211_CHAN_RADAR);
 
-   passive = channel->flags & IEEE80211_CHAN_NO_IR;
+   passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+   IEEE80211_CHAN_RADAR);
+
ch->passive = passive;
 
ch->freq = channel->center_freq;
@@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
 
lockdep_assert_held(>conf_mutex);
 
+   if (ar->state == ATH10K_STATE_ON)
+   ath10k_regd_update(ar);
+
ret = ath10k_wmi_start_scan(ar, arg);
if (ret)
return ret;



...But this sets a terrible penalty on performance when applied to
background scan.


On 12/14/16 20:58 Jouni Malinen wrote:
> 
> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> > This follows on the previous discussion
> > "Client station sends probes on DFS channels"
> >
> > Problem:
> > The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> > wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> > 4.7; because they can send probes for 600s when no AP is around.
> >
> > Analysis:
> > The problem seems to lie in the firmware, which regards the presence
> > of *any* beacon as a proof that the channel is radar-clean for 600s.
> 
> I don't think this is really firmware, but cfg80211 regulatory code and
> how it interacts with ath10k..
> 
> > - there is no obvious fix working in ath10k.
> > - the issue does not show up with other mac80211 devices like ath9k.
> > - wpa_supplicant considers this is a kernel issue [2]
> 
> There seems to be a difference between ath9k (mac80211-based Probe Request
> frame sending) and ath10k (firmware) in this area for active scanning.
> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
> uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
> using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
> be behind the difference you see.
> 
> Could you check whether the following change gets you the behavior you
> want to see here? I have not had a chance to test this yet, but based on
> code review, it looks like something that brings the same behavior to
> ath10k that ath9k has for this through mac80211.
> 
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index aa545a1..758dbbd 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
> *ar)
>   ch->chan_radar =
>   !!(channel->flags & IEEE80211_CHAN_RADAR);
> 
> - passive = channel->flags & IEEE80211_CHAN_NO_IR;
> + passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> + IEEE80211_CHAN_RADAR);
>   ch->passive = passive;
> 
>   ch->freq = channel->center_freq;
> 
> --
> Jouni MalinenPGP id EFC895FA
> 
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include

[Corentin Labbe]

drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.

Signed-off-by: Corentin Labbe 
---
 drivers/nfc/nxp-nci/i2c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e5..0356515 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.10.2

[PATCH 2/3] nfc: pn544: Remove unneeded linux/miscdevice.h include

[Corentin Labbe]

drivers/nfc/pn544/i2c.c does not use any miscdevice, so this
patch remove this unnecessary inclusion.

Signed-off-by: Corentin Labbe 
---
 drivers/nfc/pn544/i2c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index f837c39..7030a47 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.10.2

[PATCH 3/3] nfc: st21nfca: Remove unneeded linux/miscdevice.h include

[Corentin Labbe]

drivers/nfc/st21nfca/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.

Signed-off-by: Corentin Labbe 
---
 drivers/nfc/st21nfca/i2c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index 5a82f55..d16f58a 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.10.2

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

> > I agree. Dynamic switch part is buggy, we can start with not
> > allowing interfaces resulting in dynamic switch.
> 
> Does this mean that when bringing up multiple interfaces, users would
> need to figure out the 'magic' order that works?

I think we need to talk about hardware capabilities at this point.

I was assuming that it would actually be possible to run two interfaces
with different paths here concurrently - is that not true? If that's
not true, then we absolutely _need_ dynamic switching, I agree with
Felix, but then we have a pretty big complication to figure out. But we
can't let this optimisation affect user experience.

johannes

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

[Felix Fietkau]

On 2016-12-15 13:01, Thiagarajan, Vasanthakumar wrote:
> On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
>>> + * implementing 802.11 encap/decap for data frames changed.
>>>*/
>>>   enum ieee80211_conf_changed {
>>> IEEE80211_CONF_CHANGE_SMPS  = BIT(1),
>>> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>>> IEEE80211_CONF_CHANGE_CHANNEL   = BIT(6),
>>> IEEE80211_CONF_CHANGE_RETRY_LIMITS  = BIT(7),
>>> IEEE80211_CONF_CHANGE_IDLE  = BIT(8),
>>> +   IEEE80211_CONF_CHANGE_80211_HDR_OFFL= BIT(9),
>>>   };
>>
>> Given the requirements (PN check, etc.) I'm not sure how this can
>> change dynamically?
> 
> I agree. Dynamic switch part is buggy, we can start with not allowing
> interfaces resulting in dynamic switch.
Does this mean that when bringing up multiple interfaces, users would
need to figure out the 'magic' order that works?

- Felix

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Greg Kroah-Hartman]

On Thu, Dec 15, 2016 at 07:15:20AM +0200, 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 
> ---
>  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(-)

for include/linux/serial_core.h:

Acked-by: Greg Kroah-Hartman 

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

[Thiagarajan, Vasanthakumar]

On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>
>> There is a field, no_80211_encap, added to ieee80211_tx_info:control
>> to mark if the 802.11 encapsulation is offloaded to driver.
>> There is also a new callback for tx completion status indication
>> to handle data frames using 802.11 encap offload.
>
> I'm not sure I see the need for this? Maybe I'll find out in this patch
> :)
>

I think we may not need this if we make the design in such a way that all
the interfaces will use uniform encap/decap mode for the data packet.

>> +/* XXX: This frame is not encaptulated with
>> 802.11
>> + * header. Should this be added to
>> %IEEE80211_TX_CTRL_*
>> + * flags?.
>> + */
>> +bool no_80211_encap;
>> +/* 3 bytes free */
>>  } control;
>
> probably - just to preserve more space.

Correct.

>
>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
>> + *  implementing 802.11 encap/decap for data frames changed.
>>*/
>>   enum ieee80211_conf_changed {
>>  IEEE80211_CONF_CHANGE_SMPS  = BIT(1),
>> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>>  IEEE80211_CONF_CHANGE_CHANNEL   = BIT(6),
>>  IEEE80211_CONF_CHANGE_RETRY_LIMITS  = BIT(7),
>>  IEEE80211_CONF_CHANGE_IDLE  = BIT(8),
>> +IEEE80211_CONF_CHANGE_80211_HDR_OFFL= BIT(9),
>>   };
>
> Given the requirements (PN check, etc.) I'm not sure how this can
> change dynamically?

I agree. Dynamic switch part is buggy, we can start with not allowing
interfaces resulting in dynamic switch.

>
>> + * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap
>> offload
>> + *  is enabled
>>*/
>>   struct ieee80211_conf {
>>  u32 flags;
>> @@ -1346,6 +1357,7 @@ struct ieee80211_conf {
>>  struct cfg80211_chan_def chandef;
>>  bool radar_enabled;
>>  enum ieee80211_smps_mode smps_mode;
>> +bool encap_decap_80211_offloaded;
>
> Please don't add anything here that's interface specific.

Ok, this is mainly hw configuration of encap/decap mode, not
vif specific per say. Any pointers where this should belong to?

>
>> --- a/net/mac80211/cfg.c
>> +++ b/net/mac80211/cfg.c
>> @@ -107,6 +107,10 @@ static int ieee80211_change_iface(struct wiphy
>> *wiphy,
>>  }
>>  }
>>
>> +ieee80211_if_check_80211_hdr_offl(sdata,
>> +  params ? params->use_4addr
>> : false,
>> +  true);
>> +
>>  return 0;
>>   }
>
> Wouldn't it be better to simply prohibit changing this while the
> interface is up, and re-init it later when it goes up?

I agree.

>
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -1373,6 +1373,8 @@ struct ieee80211_local {
>>  /* TDLS channel switch */
>>  struct work_struct tdls_chsw_work;
>>  struct sk_buff_head skb_queue_tdls_chsw;
>> +
>> +bool data_80211_hdr_offloaded;
>
> Again, don't put interface specific things into device structures.

Ok, this is also current hw configuration of encap/decap mode, not vif
specific.

>
>> +int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
>> +struct sk_buff *skb,
>> +struct sta_info **sta_out);
>
> Return the sta_info pointer, and ERR_PTR() if needed.

Correct, sta_out is checked for ERR_PTR() as well before using it.

>
>> +++ b/net/mac80211/iface.c
>> @@ -698,6 +698,11 @@ int ieee80211_do_open(struct wireless_dev *wdev,
>> bool coming_up)
>>  rcu_assign_pointer(local->p2p_sdata, sdata);
>>  }
>>
>> +if (local->open_count == 0 && local-
>>> data_80211_hdr_offloaded) {
>> +local->hw.conf.encap_decap_80211_offloaded = true;
>> +hw_reconf_flags |=
>> IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
>> +}
>
> I don't see how this helps anything, I think you should remove it.

Yeah, I think this was added for dynamic switch.

>
>> +void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local
>> *local,
>> +bool enable_80211_hdr_offl)
>> +{
>> +struct ieee80211_sub_if_data *sdata;
>> +unsigned long flags;
>> +int n_acs = IEEE80211_NUM_ACS;
>> +int ac;
>> +
>> +ASSERT_RTNL();
>> +
>> +if (!ieee80211_hw_check(>hw,
>> SUPPORTS_80211_ENCAP_DECAP) ||
>> +!(ieee80211_hw_check(>hw, HAS_RATE_CONTROL)))
>> +return;
>> +
>> +if (local->hw.wiphy->frag_threshold != (u32)-1 &&
>> +!local->ops->set_frag_threshold)
>> +return;
>> +
>> +mutex_lock(>iflist_mtx);
>> +
>> +list_for_each_entry(sdata, >interfaces, list) {
>> +if (!sdata->dev)
>> +continue;
>> +
>> +netif_tx_stop_all_queues(sdata->dev);
>> +
>> +if (enable_80211_hdr_offl)
>> +sdata->dev->netdev_ops =
>> _dataif_8023_ops;
>> +else
>> + 

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

[Greg Kroah-Hartman]

On Thu, Dec 15, 2016 at 07:15:30AM +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  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 -
>  drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
>  drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
>  drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
>  drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
>  drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
>  drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
>  drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
>  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
>  drivers/net/wireless/ti/wl1251/Makefile   | 2 --
>  drivers/net/wireless/ti/wlcore/Makefile   | 2 --
>  drivers/staging/rtl8188eu/Makefile| 2 +-
>  drivers/staging/rtl8192e/Makefile | 2 --
>  drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
>  net/bluetooth/Makefile| 2 --
>  net/ieee802154/Makefile   | 2 --
>  net/mac80211/Makefile | 2 +-
>  net/mac802154/Makefile| 2 --
>  net/wireless/Makefile | 2 --
>  38 files changed, 5 insertions(+), 68 deletions(-)

For drivers/staging:

Acked-by: Greg Kroah-Hartman 

Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

[Malinen, Jouni]

On Tue, Dec 13, 2016 at 04:56:55PM +0100, Johannes Berg wrote:
> Regarding reusing attributes, we have (for the BSS selection thing) the
> attribute NL80211_BSS_SELECT_ATTR_RSSI_ADJUST, which is really quite
> similar to your new NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since
> while connected (which BSS_SELECT_ATTR_* assumes) the current BSS is
> always part of the considered BSSes, I'd think.

It seems to have somewhat similar meaning, but it looks more generic by
not being tied to just two bands (2.4 and 5). And now that I actually
looked again at this, it does not look like
NL80211_BSS_SELECT_ATTR_RSSI_ADJUST actually allows more than a single
band,delta pair to be provided and as such, it actually would not work
very well with more than two bands even if it might be a bit more
generic by allowing band to be set to something else than 2.4 or 5. By
the way, nl80211.h does not seem to document what values struct
nl82011_bss_select_rssi_adjust band uses..  Is this enum nl80211_band?
Neither does it say that delta is in dB (is it?).

> OTOH, the new NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF doesn't
> make this quite clear - is the current BSS to be adjusted before
> comparing, if it's 5 GHz? If so, the semantics are equivalent. If not,
> it doesn't actually make much sense ;-)

Maybe the nl80211.h description was not clear enough, but the comments
in cfg80211.h should be quite clear on how this was designed to work at
the implementation level:

"If the current connected BSS is in the 2.4 GHz band, other BSSs in the
2.4 GHz band to be reported should have better RSSI by @relative_rssi
and other BSSs in the 5 GHz band to be reported should have better RSSI
by (@relative_rssi - @relative_rssi_5g_pref).
If the current connected BSS is in the 5 GHz band, other BSSs in the
2.4 GHz band to be reported should have better RSSI by
(@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
band to be reported should have better RSSI by by @relative_rssi."

I'm not sure I'd describe this as adjusting the current BSS RSSI, but
more like adjusting the RSSI threshold value if roaming would be from
one band to another and doing that adjustment by adding or decrementing
based on whether the roam would be from 2.4 to 5 or from 5 to 2.4.

> So assuming that it is in fact taken into account after the same
> adjustment, the two attributes are equivalent, and then perhaps it
> would make sense to use struct nl80211_bss_select_rssi_adjust for the
> new attribute. If a driver doesn't support arbitrary bands, but just 5
> GHz as in your example, it can just flip it around to 2.4 GHz by
> switching the sign.
> 
> Perhaps we should even consider doing that in cfg80211 and adjusting
> the internal API for both that way?

I'm not completely sure I understood. One thing to note about
differences here is that NL80211_BSS_SELECT_ATTR_* seems to be defining
some preferences for BSS selection based on RSSI with an additional band
preference, but it does not seem to define the threshold by how many dB
the new candidate BSS should be better.

At minimum, we would need to clearly document struct
nl80211_bss_select_rssi_adjust, but even if we do, I'm not sure it
really is ideal mechanism to move to now that I realized it is not an
array, but a single band,delta pair.

Arend:
> > I am not saying it should be avoided. Just looking at it conceptually
> > the scheduled scan request holds so-called matchsets that specify the
> > constraints to determine whether a BSS was found that is worth
> > notifying the host/user-space about. As such I would expect the
> > relative RSSI attribute(s) to be part of the matchset. That way you
> > can specify it together with the currently connected SSID in a single
> > matchset.
> 
> I think this makes a lot of sense.

If we are talking only about roaming within an ESS (a single SSID), that
would sound clear, but which relative RSSI rules would apply if there
are match sets for both the currently connected SSID and another SSID
that the candidate BSS is for?

> We already have NL80211_SCHED_SCAN_MATCH_ATTR_RSSI, which asks to be
> reporting only networks that have an *absolute* RSSI value above the
> value of the attribute - a new attribute to make it relative to the
> current network instead would make sense.

When you say "current network", do you mean the current BSS? This gets
complex when thinking about multiple SSIDs (which some call "networks")
and there being NL80211_SCHED_SCAN_MATCH_ATTR_SSID and multiple
match sets..

> That would indeed be equivalent to NL80211_BSS_SELECT_ATTR_RSSI then.

NL80211_BSS_SELECT_ATTR_RSSI is a flag attribute.. BSS select mechanism
does not provide an absolute RSSI value or threshold; it just seems to
indicate use of RSSI-based selection mechanism without defining what
exactly is better. There is NL80211_BSS_SELECT_ATTR_BAND_PREF that gives
a preference to a specific band (without defining what that preference
is) and then the 

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

[Thiagarajan, Vasanthakumar]

On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote:
>
>> Drivers advertising this capability should also implement other
>> functionalities which deal with 802.11 frame format like below
>
>>  - ADDBA/DELBA offload
>
> This shouldn't be necessary.

Ok. Since driver/hw needs to implement Tx/Rx aggregation related functionalities
I thought ADDBA/DELBA processing will be little important to mac80211. May be 
I'm
missing something.

>
>>  - Hardware rate control
>
> Neither is this, if we find some API to do sampling. The existing rate
> table API already allows setting the rates out of band, so the only
> thing that you'd have to support out of band is sampling.

Ok.

>
>>  - Powersave offload
>
> That's ambiguous - you do need to handle sleeping stations (and PS-
> Poll/U-APSD) in AP mode in the device with this,

I did not dig deep into PS requirement with ethernet frame format because
frame control is not available to mac80211, so I thought to mention PS offload
is a requirement. May be there is already an infrastructure in mac80211 to
learn PS state of client which was notified in the current data frame (other
than 802.11 frame control).

  but I don't see a deep
> technical reason to require it for client mode. OTOH, client mode is
> almost always offloaded anyway.

Ok.

>
> I think you may have forgotten one important item,
>
>   - control port handling

Hmmm, I'm getting WPA-PSK working with this. May be there are other
control port handling which will not work with ethernet frame format?

>
> ?
>
>> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver
>> supports 802.11
>> + *  encap/decap for data frames. Supporting driver have to
>> implement
>> + *  get_vif_80211_encap_decap_offload() to pass if 802.11
>> encap/decap
>> + *  offload is supported for the vif.
>
> I don't see why you need this, when you have the method - you can just
> assume that the method returns false when it's not implemented.

Ok, I was trying define an interface for driver to return vif type based
encap/decap capability so that in 4-addr and Mesh type 802.11 frame format
is used.

>
>>   struct ieee80211_ops {
>>  void (*tx)(struct ieee80211_hw *hw,
>> @@ -3639,6 +3651,10 @@ struct ieee80211_ops {
>>  void (*wake_tx_queue)(struct ieee80211_hw *hw,
>>struct ieee80211_txq *txq);
>>  void (*sync_rx_queues)(struct ieee80211_hw *hw);
>> +
>> +int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
>> + struct ieee80211_vif *vif,
>> + bool is_4addr, bool
>> *supported);
>
> Why are you not simply returning "supported"?
>
> I don't like passing the vif pointer here. At this point, the vif
> pointer isn't known to the driver yet (through drv_add_interface) so
> it's a dead pointer as far as the sequencing is concerned.
>
> Is there a possibility that drivers need to switch off ethernet format
> handling entirely when an incompatible interface is added? For example,
> if you add a mesh interface, is there a chance that the AP interface
> might no longer be able to handle this?
 >
 > I'd hope this doesn't happen because I think that would be extremely
 > complicated to handle safely.

Unfortunately "[RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload"
tries to implement this but more likely buggy :(. You are right, it is very
complex to get that right. May be we should not allow interface needing
dynamic switch?

Vasanth

Hello Beautiful

[Bentley]

How you doing today? I hope you are doing well. My name is Bentley, from the 
US. I'm in Syria right now fighting ISIS. I want to get to know you better, if 
I may be so bold. I consider myself an easy-going man, and I am currently 
looking for a relationship in which I feel loved. Please tell me more about 
yourself, if you don't mind.

Hope to hear from you soon.

Regards,
Bentley.

Re: [RFC 0/3] Add new data path for ethernet frame format

[Thiagarajan, Vasanthakumar]

On Thursday 15 December 2016 02:38 PM, Johannes Berg wrote:
> On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote:
>> This patch set adds a new data path to offload 802.11 header
>> encap/decap to driver or hardware. Drivers having support
>> for ieee80211 header encap/decap and other offload functionalities
>> which can't be done before encap or after decap can make use of
>> this new data path. Currently it is implemented for STA and AP
>> interface type, this can be extend other interface types like
>> adhoc.
>
> Thanks for posting this!
>
>> With ath10k driver changes using this new Tx/Rx path, 10 - 15%
>> CPU usage and upto ~20Mbps TCP performance improvements are
>> observed with this ethernet data path.
>
> I'm sure that's because your CPU is severely limited :-)

Right, most of the time I was observing max CPU usage.

>
>> This patch set is
>> prepared on a older mac80211 code base on top of
>> commit 7d27a0ba7adc ("cfg80211: Add mesh peer AID setting API").
>> Sorry, I could not get a chance to rework it on top of latest
>> mac80211 code base.
>
> Ok. I guess that doesn't matter much for review now.
>
>>  - Consider ieee8011 header and cipher header size also while
>> updating tx/rx stats for
>>ethernet frame format.
>
> I wonder if we really shouldn't be going the other way around instead,
> to be closer to what Ethernet and likely other drivers do.

Ok. I captured that because rx/tx bytes stats will be inconsistent between 
ethernet
and 802.11 frame format.

Vasanth

Re: [PATCH 01/10] mac80211: minstrel_ht: move supported bitrate mask out of group data

[Johannes Berg]

That all looks good, applied.

johannes

Re: [PATCH] mac80211: only alloc mem if a station doesnt exist yet

[Johannes Berg]

On Wed, 2016-12-14 at 17:28 +0100, Koen Vandeputte wrote:
> This speeds up the function in case a station already exists by
> avoiding
> calling an expensive kzalloc just to free it again after the next
> check.

It's not like this is called often, but yeah - still makes sense.

Applied.

johannes

Re: [PATCH v2] mac80211: fix legacy and invalid rx-rate rpt

[Johannes Berg]

On Wed, 2016-12-14 at 11:30 -0800, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This fixes obtaining the rate info via sta_set_sinfo
> when the rx rate is invalid (for instance, on IBSS
> interface that has received no frames from one of its
> peers).
> 
> This also fixes a more general issue with rinfo->flags
> not being properly initialized for legacy rates.

I'd say this is a bug in the ethtool code - everything assumes (and
everything else makes sure) the whole sinfo struct is initialized to 0
before getting passed to this function.

> +static int sta_set_rate_info_rx(struct sta_info *sta, struct
> rate_info *rinfo)
>  {
>   u16 rate = ACCESS_ONCE(sta_get_last_rx_stats(sta)-
> >last_rate);
> -
> - if (rate == STA_STATS_RATE_INVALID)
> - rinfo->flags = 0;
> - else
> + if (rate == STA_STATS_RATE_INVALID) {
> + return -EINVAL;
> + } else {
>   sta_stats_decode_rate(sta->local, rate, rinfo);
> + return 0;
> + }

That's weird, I'll fix it.

Applied, with some fixupse.

johannes

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

[Johannes Berg]

> This rx path only checks if the driver has advertised
> it's support of 802.11 header encap/decap offload for
> data frames. 

I'm not even sure I see the point in that? Other than that (and the
various other offload requirements), it seems that encap/decap could be
considered orthogonal.

> +  * Adhoc interface depends on bssid to udpate last_rx.

type - update

> + if (!(status->flag & RX_FLAG_MCAST)) {
> + sta->rx_stats.last_rx = jiffies;
> + sta->rx_stats.last_rate =
> sta_stats_encode_rate(status);
> + }

You should probably rename that flag to something like
RX_FLAG_80211_MCAST since otherwise it's confusing with the next
multicast ether addr check:

> + if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> + !is_multicast_ether_addr(ehdr->h_dest))
> + ieee80211_sta_reset_conn_monitor(sdata);

But this could just also use the flag, since in station mode the two
are equivalent, and it'd be easier to figure out if this was "else if
(station mode)"?

> + memset(, 0, sizeof(rx));

That seems a bit pointless?

> + rx.skb = skb;
> + rx.sdata = sdata;
> + rx.local = local;
> + rx.sta = sta;
> +
> + if (vif->type == NL80211_IFTYPE_AP_VLAN && sdata->bss &&
> + unlikely(ehdr->h_proto == sdata->control_port_protocol)) 
> {
> + sdata = container_of(sdata->bss, struct
> ieee80211_sub_if_data,
> +  u.ap);
> + dev = sdata->dev;
> + rx.sdata = sdata;
> + }
> +
> + rx.skb->dev = dev;
> +
> + /* XXX: Since rx.seqno_idx is not available for decap
> offloaded frames
> +  * rx msdu stats update at the seqno_idx in
> ieee80211_deliver_skb()
> +  * will always be updated at index 0 and will not be very
> useful.
> +  */
> + ieee80211_deliver_skb();

Yeah, that's not nice - perhaps we can provide the TID out of band? If
not, we'll have to disable those statistics *all the way*, i.e. not
even report them to userspace when filling sinfo.

> + 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.

johannes

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

[Johannes Berg]

> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.
> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.

I'm not sure I see the need for this? Maybe I'll find out in this patch
:)

> + /* XXX: This frame is not encaptulated with
> 802.11
> +  * header. Should this be added to
> %IEEE80211_TX_CTRL_*
> +  * flags?.
> +  */
> + bool no_80211_encap;
> + /* 3 bytes free */
>   } control;

probably - just to preserve more space.

> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
> + *   implementing 802.11 encap/decap for data frames changed.
>   */
>  enum ieee80211_conf_changed {
>   IEEE80211_CONF_CHANGE_SMPS  = BIT(1),
> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>   IEEE80211_CONF_CHANGE_CHANNEL   = BIT(6),
>   IEEE80211_CONF_CHANGE_RETRY_LIMITS  = BIT(7),
>   IEEE80211_CONF_CHANGE_IDLE  = BIT(8),
> + IEEE80211_CONF_CHANGE_80211_HDR_OFFL= BIT(9),
>  };

Given the requirements (PN check, etc.) I'm not sure how this can
change dynamically?

> + * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap
> offload
> + *   is enabled
>   */
>  struct ieee80211_conf {
>   u32 flags;
> @@ -1346,6 +1357,7 @@ struct ieee80211_conf {
>   struct cfg80211_chan_def chandef;
>   bool radar_enabled;
>   enum ieee80211_smps_mode smps_mode;
> + bool encap_decap_80211_offloaded;

Please don't add anything here that's interface specific.

> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -107,6 +107,10 @@ static int ieee80211_change_iface(struct wiphy
> *wiphy,
>   }
>   }
>  
> + ieee80211_if_check_80211_hdr_offl(sdata,
> +   params ? params->use_4addr 
> : false,
> +   true);
> +
>   return 0;
>  }

Wouldn't it be better to simply prohibit changing this while the
interface is up, and re-init it later when it goes up?

> +++ b/net/mac80211/ieee80211_i.h
> @@ -1373,6 +1373,8 @@ struct ieee80211_local {
>   /* TDLS channel switch */
>   struct work_struct tdls_chsw_work;
>   struct sk_buff_head skb_queue_tdls_chsw;
> +
> + bool data_80211_hdr_offloaded;

Again, don't put interface specific things into device structures.

> +int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
> + struct sk_buff *skb,
> + struct sta_info **sta_out);

Return the sta_info pointer, and ERR_PTR() if needed.

> +++ b/net/mac80211/iface.c
> @@ -698,6 +698,11 @@ int ieee80211_do_open(struct wireless_dev *wdev,
> bool coming_up)
>   rcu_assign_pointer(local->p2p_sdata, sdata);
>   }
>  
> + if (local->open_count == 0 && local-
> >data_80211_hdr_offloaded) {
> + local->hw.conf.encap_decap_80211_offloaded = true;
> + hw_reconf_flags |=
> IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
> + }

I don't see how this helps anything, I think you should remove it.

> +void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local
> *local,
> + bool enable_80211_hdr_offl)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + unsigned long flags;
> + int n_acs = IEEE80211_NUM_ACS;
> + int ac;
> +
> + ASSERT_RTNL();
> +
> + if (!ieee80211_hw_check(>hw,
> SUPPORTS_80211_ENCAP_DECAP) ||
> + !(ieee80211_hw_check(>hw, HAS_RATE_CONTROL)))
> + return;
> +
> + if (local->hw.wiphy->frag_threshold != (u32)-1 &&
> + !local->ops->set_frag_threshold)
> + return;
> +
> + mutex_lock(>iflist_mtx);
> +
> + list_for_each_entry(sdata, >interfaces, list) {
> + if (!sdata->dev)
> + continue;
> +
> + netif_tx_stop_all_queues(sdata->dev);
> +
> + if (enable_80211_hdr_offl)
> + sdata->dev->netdev_ops =
> _dataif_8023_ops;
> + else
> + sdata->dev->netdev_ops =
> _dataif_ops;
> + }
> +
> + mutex_unlock(>iflist_mtx);
> +
> + local->data_80211_hdr_offloaded = enable_80211_hdr_offl;
> +
> + if (local->started) {
> + if (enable_80211_hdr_offl)
> + local->hw.conf.encap_decap_80211_offloaded =
> true;
> + else
> + local->hw.conf.encap_decap_80211_offloaded =
> false;
> + ieee80211_hw_config(local,
> + IEEE80211_CONF_CHANGE_80211_HDR_
> OFFL);
> + }
> +
> + mutex_lock(>iflist_mtx);
> +
> + list_for_each_entry(sdata, >interfaces, list) {
> + if (!sdata->dev)
> + continue;
> +
> + if (local->hw.queues < 

Re: ath10k: Avoid potential page alloc BUG_ON in tx free path

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
> have NULL pointer checks to avoid crash if they are called twice
> but this is as of now not sufficient as these pointers are not assigned
> to NULL once the contiguous DMA memory allocation is freed, fix this.
> Though this may not be hit with the explicity check of state variable
> 'tx_mem_allocated' check, good to have this addressed as well.
> 
> Below BUG_ON is hit when the above scenario is simulated
> with kernel debugging enabled
> 
>  page:f6d09a00 count:0 mapcount:-127 mapping:  (null)
> index:0x0
>  flags: 0x4000()
>  page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
> == 0)
>  [ cut here ]
>  kernel BUG at ./include/linux/mm.h:445!
>  invalid opcode:  [#1] SMP DEBUG_PAGEALLOC
>  EIP is at put_page_testzero.part.88+0xd/0xf
>  Call Trace:
>   [] __free_pages+0x3c/0x40
>   [] free_pages+0x3e/0x50
>   [] dma_generic_free_coherent+0x24/0x30
>   [] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140
> 
>   [] ath10k_htt_tx_destroy+0x29/0xa0
> 
>   [] ath10k_core_destroy+0x60/0x80 [ath10k_core]
>   [] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
>   [] pci_device_remove+0x38/0xb0
>   [] __device_release_driver+0x72/0x100
>   [] driver_detach+0x97/0xa0
>   [] bus_remove_driver+0x40/0x80
>   [] driver_unregister+0x2a/0x60
>   [] pci_unregister_driver+0x18/0x70
>   [] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
>   [] SyS_delete_module+0x158/0x210
>   [] ? __might_fault+0x41/0xa0
>   [] ? __might_fault+0x8b/0xa0
>   [] do_fast_syscall_32+0x9b/0x1c0
>   [] sysenter_past_esp+0x45/0x74
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

02a9e08d7374 ath10k: Avoid potential page alloc BUG_ON in tx free path

-- 
https://patchwork.kernel.org/patch/9463923/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

[Johannes Berg]

> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below

>   - ADDBA/DELBA offload

This shouldn't be necessary.

>   - Hardware rate control

Neither is this, if we find some API to do sampling. The existing rate
table API already allows setting the rates out of band, so the only
thing that you'd have to support out of band is sampling.

>   - Powersave offload

That's ambiguous - you do need to handle sleeping stations (and PS-
Poll/U-APSD) in AP mode in the device with this, but I don't see a deep
technical reason to require it for client mode. OTOH, client mode is
almost always offloaded anyway.

I think you may have forgotten one important item,

- control port handling

?

> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver
> supports 802.11
> + *   encap/decap for data frames. Supporting driver have to
> implement
> + *   get_vif_80211_encap_decap_offload() to pass if 802.11
> encap/decap
> + *   offload is supported for the vif.

I don't see why you need this, when you have the method - you can just
assume that the method returns false when it's not implemented.

>  struct ieee80211_ops {
>   void (*tx)(struct ieee80211_hw *hw,
> @@ -3639,6 +3651,10 @@ struct ieee80211_ops {
>   void (*wake_tx_queue)(struct ieee80211_hw *hw,
>     struct ieee80211_txq *txq);
>   void (*sync_rx_queues)(struct ieee80211_hw *hw);
> +
> + int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
> +  struct ieee80211_vif *vif,
> +  bool is_4addr, bool
> *supported);

Why are you not simply returning "supported"?

I don't like passing the vif pointer here. At this point, the vif
pointer isn't known to the driver yet (through drv_add_interface) so
it's a dead pointer as far as the sequencing is concerned.

Is there a possibility that drivers need to switch off ethernet format
handling entirely when an incompatible interface is added? For example,
if you add a mesh interface, is there a chance that the AP interface
might no longer be able to handle this?

I'd hope this doesn't happen because I think that would be extremely
complicated to handle safely.

johannes

Re: [RFC 0/3] Add new data path for ethernet frame format

[Johannes Berg]

On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote:
> This patch set adds a new data path to offload 802.11 header
> encap/decap to driver or hardware. Drivers having support
> for ieee80211 header encap/decap and other offload functionalities
> which can't be done before encap or after decap can make use of
> this new data path. Currently it is implemented for STA and AP
> interface type, this can be extend other interface types like
> adhoc.  

Thanks for posting this!

> With ath10k driver changes using this new Tx/Rx path, 10 - 15%
> CPU usage and upto ~20Mbps TCP performance improvements are
> observed with this ethernet data path. 

I'm sure that's because your CPU is severely limited :-)

> This patch set is
> prepared on a older mac80211 code base on top of
> commit 7d27a0ba7adc ("cfg80211: Add mesh peer AID setting API").
> Sorry, I could not get a chance to rework it on top of latest
> mac80211 code base.

Ok. I guess that doesn't matter much for review now.

>   - Consider ieee8011 header and cipher header size also while
> updating tx/rx stats for
>     ethernet frame format.

I wonder if we really shouldn't be going the other way around instead,
to be closer to what Ethernet and likely other drivers do.

johannes

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Stefan Schmidt]

Hello.

On 15/12/16 06:15, 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 
---
 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 

-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;

Re: ath9k: Turn ath_txq_lock/unlock() into static inlines.

[Kalle Valo]

Toke Høiland-Jørgensen wrote:
> These are one-line functions that just call spin_lock/unlock_bh(); turn
> them into static inlines to avoid the function call overhead.
> 
> Signed-off-by: Toke Høiland-Jørgensen 

Patch applied to ath-next branch of ath.git, thanks.

5c4607ebaabe ath9k: Turn ath_txq_lock/unlock() into static inlines.

-- 
https://patchwork.kernel.org/patch/9449285/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v3] ath9k: Introduce airtime fairness scheduling between stations

[Kalle Valo]

Toke Høiland-Jørgensen wrote:
> This reworks the ath9k driver to schedule transmissions to connected
> stations in a way that enforces airtime fairness between them. It
> accomplishes this by measuring the time spent transmitting to or
> receiving from a station at TX and RX completion, and accounting this to
> a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based
> deficit scheduler is employed at packet dequeue time, to control which
> station gets the next transmission opportunity.
> 
> Airtime fairness can significantly improve the efficiency of the network
> when station rates vary. The following throughput values are from a
> simple three-station test scenario, where two stations operate at the
> highest HT20 rate, and one station at the lowest, and the scheduler is
> employed at the access point:
> 
>   Before   /   After
> Fast station 1:19.17   /   25.09 Mbps
> Fast station 2:19.83   /   25.21 Mbps
> Slow station:   2.58   /1.77 Mbps
> Total: 41.58   /   52.07 Mbps
> 
> The benefit of airtime fairness goes up the more stations are present.
> In a 30-station test with one station artificially limited to 1 Mbps,
> we have seen aggregate throughput go from 2.14 to 17.76 Mbps.
> 
> Signed-off-by: Toke Høiland-Jørgensen 

Patch applied to ath-next branch of ath.git, thanks.

63fefa050477 ath9k: Introduce airtime fairness scheduling between stations

-- 
https://patchwork.kernel.org/patch/9449275/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

[Valo, Kalle]

Martin Blumenstingl  writes:

> There are two types of swapping the EEPROM data in the ath9k driver.
> Before this series one type of swapping could not be used without the
> other.
>
> The first type of swapping looks at the "magic bytes" at the start of
> the EEPROM data and performs swab16 on the EEPROM contents if needed.
> The second type of swapping is EEPROM format specific and swaps
> specific fields within the EEPROM itself (swab16, swab32 - depends on
> the EEPROM format).
>
> With this series the second part now looks at the EEPMISC register
> inside the EEPROM, which uses a bit to indicate if the EEPROM data
> is Big Endian (this is also done by the FreeBSD kernel).
> This has a nice advantage: currently there are some out-of-tree hacks
> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
> Big Endian system (= no swab16 is performed) but the EEPROM itself
> indicates that it's data is Little Endian. Until now the out-of-tree
> code simply did a swab16 before passing the data to ath9k, so ath9k
> first did the swab16 - this also enabled the format specific swapping.
> These out-of-tree hacks are still working with the new logic, but it
> is recommended to remove them. This implementation is based on a
> discussion with Arnd Bergmann who raised concerns about the
> robustness and portability of the swapping logic in the original OF
> support patch review, see [0].
>
> After a second round of patches (= v1 of this series) neither Arnd
> Bergmann nor I were really happy with the complexity of the EEPROM
> swapping logic. Based on a discussion (see [1] and [2]) we decided
> that ath9k should use a defined format (specifying the endianness
> of the data - I went with __le16 and __le32) when accessing the
> EEPROM fields. A benefit of this is that we enable the EEPMISC based
> swapping logic by default, just like the FreeBSD driver, see [3]. On
> the devices which I have tested (see below) ath9k now works without
> having to specify the "endian_check" field in ath9k_platform_data (or
> a similar logic which could provide this via devicetree) as ath9k now
> detects the endianness automatically. Only EEPROMs which are mangled
> by some out-of-tree code still need the endian_check flag (or one can
> simply remove that mangling from the out-of-tree code).
>
> Testing:
> - tested by myself on AR9287 with Big Endian EEPROM
> - tested by myself on AR9227 with Little Endian EEPROM
> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
>   which did not suffer from this whole problem)
> - how do we proceed with testing? maybe we could keep this in a
>   feature-branch and add these patches to LEDE once we have an ACK to
>   get more people to test this
>
> This series depends on my other series (v7):
> "add devicetree support to ath9k" - see [4]
>
> Changes since v1:
> - reworked description in the cover-letter to describe the reasons
>   behind the new patch 7
> - reworked patch "Set the "big endian" bit of the AR9003 EEPROM
>   templates" as ar9003_eeprom.c sets all values as Little Endian, thus
>   the Big Endian bit should never be set (the new patch makes this
>   clear)
> - dropped "ath9k: Make EEPROM endianness swapping configurable via
>   devicetree" as it is not needed anymore with the new logic from
>   patch 7
> - added patches 4 and 5 as small cleanup (this made it easier to
>   implement the le{16,32}_to_cpu() changes where needed)
>
>
> [0] http://www.spinics.net/lists/linux-wireless/msg152634.html
> [1] https://marc.info/?l=linux-wireless=147250597503174=2
> [2] https://marc.info/?l=linux-wireless=147254388611344=2
> [3] 
> https://github.com/freebsd/freebsd/blob/50719b56d9ce8d7d4beb53b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351
> [4] https://marc.info/?l=linux-wireless=147544488619822=2
>
> Martin Blumenstingl (7):
>   ath9k: Add a #define for the EEPROM "eepmisc" endianness bit
>   ath9k: indicate that the AR9003 EEPROM template values are little
> endian
>   ath9k: Add an eeprom_ops callback for retrieving the eepmisc value
>   ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev
>   ath9k: consistently use get_eeprom_rev(ah)
>   ath9k: Make the EEPROM swapping check use the eepmisc register
>   ath9k: define all EEPROM fields in Little Endian format

Applied to ath-next on ath.git, thanks.

(My automatic "accepted" email failed, so had to send this manually.)

-- 
Kalle Valo

Re: wl1251 & mac address & calibration data

[Kalle Valo]

(Adding Luis because he has been working on request_firmware() lately)

Pali Rohár  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.

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.

> and load mac address also via request_firmware() either by appending it 
> into NVS data or via separate call

I'm not really fan of the idea providing permanent mac address through
request_firmware(). For example, how to handle multiple devices on the
same host, would there be a need for some kind of bus ids encoded to the
filename? And what about devices with multiple mac addresses?

I wish there would be a better way than request_firmware() to provide
the permanent mac addresses from user space (if device tree is not
available), I just don't know what that could be :) But if we would
start to use request_firmware() for this at least there should be a
wider concensus about that and it should be properly documented, just
like the device tree bindings.

-- 
Kalle Valo

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

[Marc Kleine-Budde]

On 12/15/2016 06:15 AM, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
[...]
>  drivers/net/can/Makefile  | 1 -

For drivers/net/can/Makefile:

Acked-by: Marc Kleine-Budde 

regards,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature