[PATCH v2] ath10k: support for multicast rate control

2018-05-07 Thread Pradeep Kumar Chitrapu
Issues wmi command to firmwre when multicast rate change is received
with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got
introduced with addition of ath10k_rates_rev2 enum.

Tested on QCA9984 with firmware ver 10.4-3.6-00104

Signed-off-by: Pradeep Kumar Chitrapu 
---
v2:
 - fixed the CCK rates setting for mcast_rate and fixed_rate paths.
 - set broadcast rate along with multicast rate setting.

 drivers/net/wireless/ath/ath10k/mac.c | 54 ---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 3d7119a..70a0563 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -101,6 +101,8 @@
 #define ath10k_g_rates_rev2 (ath10k_rates_rev2 + 0)
 #define ath10k_g_rates_rev2_size (ARRAY_SIZE(ath10k_rates_rev2))
 
+#define ath10k_wmi_legacy_rates ath10k_rates
+
 static bool ath10k_mac_bitrate_is_cck(int bitrate)
 {
switch (bitrate) {
@@ -5426,8 +5428,12 @@ static void ath10k_bss_info_changed(struct ieee80211_hw 
*hw,
 {
struct ath10k *ar = hw->priv;
struct ath10k_vif *arvif = (void *)vif->drv_priv;
-   int ret = 0;
+   struct cfg80211_chan_def def;
u32 vdev_param, pdev_param, slottime, preamble;
+   u16 bitrate, hw_value;
+   u8 rate;
+   int rateidx, ret = 0;
+   enum nl80211_band band;
 
mutex_lock(&ar->conf_mutex);
 
@@ -5595,6 +5601,44 @@ static void ath10k_bss_info_changed(struct ieee80211_hw 
*hw,
arvif->vdev_id, ret);
}
 
+   if (changed & BSS_CHANGED_MCAST_RATE &&
+   !WARN_ON(ath10k_mac_vif_chan(arvif->vif, &def))) {
+   band = def.chan->band;
+   rateidx = vif->bss_conf.mcast_rate[band] - 1;
+
+   if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
+   rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
+
+   bitrate = ath10k_wmi_legacy_rates[rateidx].bitrate;
+   hw_value = ath10k_wmi_legacy_rates[rateidx].hw_value;
+   if (ath10k_mac_bitrate_is_cck(bitrate))
+   preamble = WMI_RATE_PREAMBLE_CCK;
+   else
+   preamble = WMI_RATE_PREAMBLE_OFDM;
+
+   rate = ATH10K_HW_RATECODE(hw_value, 0, preamble);
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC,
+  "mac vdev %d mcast_rate %x\n",
+  arvif->vdev_id, rate);
+
+   vdev_param = ar->wmi.vdev_param->mcast_data_rate;
+   ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+   vdev_param, rate);
+   if (ret)
+   ath10k_warn(ar,
+   "failed to set mcast rate on vdev %i: %d\n",
+   arvif->vdev_id,  ret);
+
+   vdev_param = ar->wmi.vdev_param->bcast_data_rate;
+   ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+   vdev_param, rate);
+   if (ret)
+   ath10k_warn(ar,
+   "failed to set bcast rate on vdev %i: %d\n",
+   arvif->vdev_id,  ret);
+   }
+
mutex_unlock(&ar->conf_mutex);
 }
 
@@ -6895,7 +6939,6 @@ ath10k_mac_bitrate_mask_get_single_rate(
const struct cfg80211_bitrate_mask 
*mask,
u8 *rate, u8 *nss)
 {
-   struct ieee80211_supported_band *sband = &ar->mac.sbands[band];
int rate_idx;
int i;
u16 bitrate;
@@ -6905,8 +6948,11 @@ ath10k_mac_bitrate_mask_get_single_rate(
if (hweight32(mask->control[band].legacy) == 1) {
rate_idx = ffs(mask->control[band].legacy) - 1;
 
-   hw_rate = sband->bitrates[rate_idx].hw_value;
-   bitrate = sband->bitrates[rate_idx].bitrate;
+   if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
+   rate_idx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
+
+   hw_rate = ath10k_wmi_legacy_rates[rate_idx].hw_value;
+   bitrate = ath10k_wmi_legacy_rates[rate_idx].bitrate;
 
if (ath10k_mac_bitrate_is_cck(bitrate))
preamble = WMI_RATE_PREAMBLE_CCK;
-- 
1.9.1



Re: [PATCH 6/9] firmware: print firmware name on fallback path

2018-05-07 Thread Luis R. Rodriguez
On Fri, May 04, 2018 at 10:57:26PM -0400, Andres Rodriguez wrote:
> On 2018-05-03 07:42 PM, Luis R. Rodriguez wrote:
> > On Mon, Apr 23, 2018 at 04:12:02PM -0400, Andres Rodriguez wrote:
> > > Previously, one could assume the firmware name from the preceding
> > > message: "Direct firmware load for {name} failed with error %d".
> > > 
> > > However, with the new firmware_request_nowarn() entrypoint, the message
> > > outlined above will not always be printed.
> > 
> > I though the whole point was to not print an error message. What if
> > we want later to disable this error message? This would prove a bit
> > pointless.
> > 
> > Let's discuss the exact semantics desired here. Why would only the
> > fallback be desirable here?
> > 
> > Andres, Kalle?
> > 
> > After we address this I'll address resubmitting this lat patch
> > along with the last one. For now I'll skip it.
> 
> You are correct. I initially thought it would be useful to know that the
> usermode fallback was being triggered. And for that message to be useful we
> would need a fw name.
> 
> But now that you point it out, this behaviour is inconsistent with the
> _nowarn() definition. We shouldn't have a message in the first place.
> 
> So it might be better to instead have:
> 
> if (!(opt_flags & FW_OPT_NO_WARN) )
> dev_warn(device, "Falling back to user helper\n");
> 
> No need to add the firmware name, cause we either:
> a) FW_OPT_NO_WARN is set and no messages are printed, or
> b) FW_OPT_NO_WARN is not set and we get both messages.
> 
> Yay, nay?

I welcome such a new warning but not for any of the reasons stated.

It make sense if FW_OPT_NO_WARN is not set and only because the fallback
mechanism can fail for a slew of different firmware files, and just getting
informed a failure with a fallback occurred does not tell us for which file it
failed for.

I'll add such a patch to my queue and send it off soon prior to your own
new API nowarn call.

  Luis


[mac80211-next:master 11/11] htmldocs: net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info'

2018-05-07 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   cc60dbbfed8ff0bd4c530ee48e9e915333a35470
commit: cc60dbbfed8ff0bd4c530ee48e9e915333a35470 [11/11] mac80211: average ack 
rssi support for data frames
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/net/mac80211.h:955: warning: Function parameter or member 
'control.skip_table' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.jiffies' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.vif' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.hw_key' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.flags' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.enqueue_time' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 'ack' not 
described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'ack.cookie' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.ack_signal' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.ampdu_ack_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.ampdu_len' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.antenna' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.tx_time' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.is_valid_ack_signal' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.status_driver_data' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'driver_rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 'pad' not 
described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'rate_driver_data' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warnin

Re: RTL8723BE performance regression

2018-05-07 Thread João Paulo Rechi Vita
On Tue, May 1, 2018 at 10:58 PM, Pkshih  wrote:
> On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
>>
>> > -Original Message-
>> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
>> > Sent: Wednesday, May 02, 2018 6:41 AM
>> > To: Larry Finger
>> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
>> > Chaoming_Li; Kalle Valo;
>> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
>> > Vita; linux@endlessm.c
>> om
>> > Subject: Re: RTL8723BE performance regression
>> >
>> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger  
>> > wrote:
>> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
>> > >>
>> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
>> > >> wrote:
>> > >>
>> > >> (...)
>> > >>
>> > >>> As the antenna selection code changes affected your first bisection, do
>> > >>> you
>> > >>> have one of those HP laptops with only one antenna and the incorrect
>> > >>> coding
>> > >>> in the FUSE?
>> > >>
>> > >>
>> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
>> > >> was needed to achieve a good performance in the past, before this
>> > >> regression. I've also opened the laptop chassis and confirmed the
>> > >> antenna cable is plugged to the connector labeled with "1" on the
>> > >> card.
>> > >>
>> > >>> If so, please make sure that you still have the same signal
>> > >>> strength for good and bad cases. I have tried to keep the driver and 
>> > >>> the
>> > >>> btcoex code in sync, but there may be some combinations of antenna
>> > >>> configuration and FUSE contents that cause the code to fail.
>> > >>>
>> > >>
>> > >> What is the recommended way to monitor the signal strength?
>> > >
>> > >
>> > > The btcoex code is developed for multiple platforms by a different group
>> > > than the Linux driver. I think they made a change that caused ant_sel to
>> > > switch from 1 to 2. At least numerous comments at
>> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
>> > >
>> > > Mhy recommended method is to verify the wifi device name with "iw dev". 
>> > > Then
>> > > using that device
>> > >
>> > > sudo iw dev  scan | egrep "SSID|signal"
>> > >
>> >
>> > I have confirmed that the performance regression is indeed tied to
>> > signal strength: on the good cases signal was between -16 and -8 dBm,
>> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
>> > also switched to testing bandwidth in controlled LAN environment using
>> > iperf3, as suggested by Steve deRosier, with the DUT being the only
>> > machine connected to the 2.4 GHz radio and the machine running the
>> > iperf3 server connected via ethernet.
>> >
>>
>> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
>> 8723be ant_sel definition"). You can use the above commit and do the same
>> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
>> results.
>> Since performance is tied to signal strength, you can only share signal 
>> strength.
>>
>
> Please pay attention to cold reboot once ant_sel is changed.
>

I've tested the commit mentioned above and it fixes the problem on top
of v4.16 (in addition to the latest wireless-drivers-next also been
fixed as it already contains such commit). On v4.15, we also need the
following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
definition" to have a good performance again:

  874e837d67d0 rtlwifi: fill FW version and subversion
  a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
  40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex

Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
these machines, as the shown by the numbers bellow (ant_sel=0 means
that actually no parameter was passed to the module). I have powered
off the machine and done a cold boot for every test. It seems
something have changed in the antenna auto-selection code since v4.11,
the latest point where I could confirm we definitely need to force
ant_sel=1. I've been trying to understand what causes this difference,
but haven't made progress on that so far, so any suggestions are
appreciated (we are trying to decide if we can confidently drop the
downstream DMI quirks for these specific machines).

  w-d-n ant_sel=0: -14.00 dBm,  69.5 Mbps -> good
  w-d-n ant_sel=1: -10.00 dBm,  41.1 Mbps -> good
  w-d-n ant_sel=2: -44.00 dBm,   607 kbps -> bad

  v4.16 ant_sel=0: -12.00 dBm,  63.0 Mbps -> good
  v4.16 ant_sel=1: - 8.00 dBm,  69.0 Mbps -> good
  v4.16 ant_sel=2: -50.00 dBm,   224 kbps -> bad

  v4.15 ant_sel=0: - 8.00 dBm,  33.0 Mbps -> good
  v4.15 ant_sel=1: -10.00 dBm,  38.1 Mbps -> good
  v4.15 ant_sel=2: -48.00 dBm,   206 kbps -> bad

--
João Paulo Rechi Vita
http://about.me/jprvita


Re: [PATCH 2/3] iw: Print TXQ statistics for stations and interfaces

2018-05-07 Thread Toke Høiland-Jørgensen


On 7 May 2018 23:21:30 CEST, Johannes Berg  wrote:
>On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
>> 
>> +if (header && tid >= 0)
>> +pos += snprintf(buf, buflen, "\n\t\tTID\tqsz-byt\t"
>> +"qsz-pkt\tflows\tdrops\tmarks\toverlmt\t"
>> +"hashcol\ttx-bytes\ttx-packets");
>> +else if (header)
>> +pos += snprintf(buf, buflen, "\n\t\tqsz-byt\t"
>> +"qsz-pkt\tflows\tdrops\tmarks\toverlmt\t"
>> +"hashcol\ttx-bytes\ttx-packets");
>> +
>> +if (tid >= 0)
>> +pos += snprintf(pos, buflen - (pos - buf), "\n\t\t%d", tid);
>> +else
>> +pos += snprintf(pos, buflen - (pos - buf), "\n\t");
>> +
>> +txqinfo = txqstats_info[NL80211_TXQ_STATS_BACKLOG_BYTES];
>> +if (txqinfo)
>> +pos += snprintf(pos, buflen - (pos - buf), "\t%u",
>> +nla_get_u32(txqinfo));
>
>since the header is fixed, shouldn't all of these get an else branch
>that just prints a tab or so?

Ah, right, good point. Didn't think about what would happen if any of the 
fields were actually omitted. Will fix that as well :)

-Toke


Re: [PATCH 2/3] iw: Print TXQ statistics for stations and interfaces

2018-05-07 Thread Johannes Berg
On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
> 
> + if (header && tid >= 0)
> + pos += snprintf(buf, buflen, "\n\t\tTID\tqsz-byt\t"
> + "qsz-pkt\tflows\tdrops\tmarks\toverlmt\t"
> + "hashcol\ttx-bytes\ttx-packets");
> + else if (header)
> + pos += snprintf(buf, buflen, "\n\t\tqsz-byt\t"
> + "qsz-pkt\tflows\tdrops\tmarks\toverlmt\t"
> + "hashcol\ttx-bytes\ttx-packets");
> +
> + if (tid >= 0)
> + pos += snprintf(pos, buflen - (pos - buf), "\n\t\t%d", tid);
> + else
> + pos += snprintf(pos, buflen - (pos - buf), "\n\t");
> +
> + txqinfo = txqstats_info[NL80211_TXQ_STATS_BACKLOG_BYTES];
> + if (txqinfo)
> + pos += snprintf(pos, buflen - (pos - buf), "\t%u",
> + nla_get_u32(txqinfo));

since the header is fixed, shouldn't all of these get an else branch
that just prints a tab or so?

johannes


Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 23:19 +0200, Toke Høiland-Jørgensen wrote:
> 
> On 7 May 2018 21:13:04 CEST, Johannes Berg  wrote:
> > On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
> > > This adds support for exporting the mac80211 TXQ stats via nl80211 by
> > > way of a nested TXQ stats attribute, as well as for configuring the
> > > quantum and limits that were previously only changeable through
> > 
> > debugfs.
> > 
> > So I finally (sorry) decided to apply this, but I get a few issues with
> > it (aside from trivial rebase issues). If you're not able to fix them
> > now let me know and I can:
> 
> Great! I'll rebase and fix those and resend :)
> 
> Is the iw patch fine as-is?

Good question, let me review it :-)

johannes


Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

2018-05-07 Thread Toke Høiland-Jørgensen


On 7 May 2018 21:13:04 CEST, Johannes Berg  wrote:
>On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
>> This adds support for exporting the mac80211 TXQ stats via nl80211 by
>> way of a nested TXQ stats attribute, as well as for configuring the
>> quantum and limits that were previously only changeable through
>debugfs.
>
>So I finally (sorry) decided to apply this, but I get a few issues with
>it (aside from trivial rebase issues). If you're not able to fix them
>now let me know and I can:

Great! I'll rebase and fix those and resend :)

Is the iw patch fine as-is?

-Toke


Re: [PATCH 06/12] firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface

2018-05-07 Thread Bjorn Andersson
On Sun 25 Mar 22:40 PDT 2018, Govind Singh wrote:

> Add WLAN related VMID's to support wlan driver to set up
> the remote's permissions call via TrustZone.
> 
> Signed-off-by: Govind Singh 

Please use ./scripts/get_maintainer.pl for each patch to get a hint
about whom to send your patches to.

While I think it's okay that Kalle picks it through his tree Andy should
give his ack first.


Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  include/linux/qcom_scm.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> index b401b96..da63d84 100644
> --- a/include/linux/qcom_scm.h
> +++ b/include/linux/qcom_scm.h
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2010-2015, The Linux Foundation. All rights reserved.
> +/* Copyright (c) 2010-2015, 2018, The Linux Foundation. All rights reserved.
>   * Copyright (C) 2015 Linaro Ltd.
>   *
>   * This program is free software; you can redistribute it and/or modify
> @@ -33,6 +33,8 @@ struct qcom_scm_vmperm {
>  
>  #define QCOM_SCM_VMID_HLOS   0x3
>  #define QCOM_SCM_VMID_MSS_MSA0xF
> +#define QCOM_SCM_VMID_WLAN   0x18
> +#define QCOM_SCM_VMID_WLAN_CE0x19
>  #define QCOM_SCM_PERM_READ   0x4
>  #define QCOM_SCM_PERM_WRITE  0x2
>  #define QCOM_SCM_PERM_EXEC   0x1
> -- 
> 1.9.1
> 


Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

2018-05-07 Thread Peter Oh



On 05/07/2018 01:06 PM, Johannes Berg wrote:

On Mon, 2018-05-07 at 13:04 -0700, Peter Oh wrote:

On 05/07/2018 12:44 PM, Johannes Berg wrote:

On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:

From: Peter Oh 

There is no meaning to call ieee80211_mesh_process_chnswitch
without CSA IE provided, since the function will always return error.

I'm not convinced, an extended channel switch element might be present
instead?

I expected the comment. Yes, extended channel switch element could be
present instead of channel switch element which I missed to take care
of. So you can ignore the patch for now and I'll get back with right
patch for it.

Heh. Well, but then why bother at all? I mean, the inner function will
do the check and fail, and nothing will happen, so why bother?

My real concern is that ieee80211_mesh_process_chnswitch function could 
process at certain level of channel switch procedure although mesh 
channel switch parameter element is not given which is mandatory of CSA 
for mesh.
However the reason I didn't use mesh_chansw_params_ie to check is 
because even though it is correct for standard, I'm not sure if it's 
practically right. IMPO, sending CSA means devices (ap or mesh) detected 
radar, so the ultimate goal to achieve is to evacuate the channel 
although there is something missed in frames.


Peter


Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 13:04 -0700, Peter Oh wrote:
> 
> On 05/07/2018 12:44 PM, Johannes Berg wrote:
> > On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:
> > > From: Peter Oh 
> > > 
> > > There is no meaning to call ieee80211_mesh_process_chnswitch
> > > without CSA IE provided, since the function will always return error.
> > 
> > I'm not convinced, an extended channel switch element might be present
> > instead?
> 
> I expected the comment. Yes, extended channel switch element could be 
> present instead of channel switch element which I missed to take care 
> of. So you can ignore the patch for now and I'll get back with right 
> patch for it.

Heh. Well, but then why bother at all? I mean, the inner function will
do the check and fail, and nothing will happen, so why bother?

johannes


Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

2018-05-07 Thread Peter Oh



On 05/07/2018 12:44 PM, Johannes Berg wrote:

On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:

From: Peter Oh 

There is no meaning to call ieee80211_mesh_process_chnswitch
without CSA IE provided, since the function will always return error.

I'm not convinced, an extended channel switch element might be present
instead?
I expected the comment. Yes, extended channel switch element could be 
present instead of channel switch element which I missed to take care 
of. So you can ignore the patch for now and I'll get back with right 
patch for it.


Thanks,
Peter


Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

2018-05-07 Thread Johannes Berg
On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:
> From: Peter Oh 
> 
> There is no meaning to call ieee80211_mesh_process_chnswitch
> without CSA IE provided, since the function will always return error.

I'm not convinced, an extended channel switch element might be present
instead?

johannes


Re: Regression caused by commit 882164a4a928

2018-05-07 Thread Michael Büsch
On Mon, 07 May 2018 22:03:58 +0300
Kalle Valo  wrote:

> Michael Büsch  writes:
> 
> > On Mon, 7 May 2018 10:44:34 -0500
> > Larry Finger  wrote:
> >  
> >> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in 
> >> module") appeared to be harmless, it leads to complete failure of drivers 
> >> b43.   
> >  
> >>   config SSB_DRIVER_PCICORE_POSSIBLE
> >>  bool
> >> -   depends on SSB_PCIHOST && SSB = y
> >> +   depends on SSB_PCIHOST && (SSB = y || !MIPS)
> >>  default y
> >> 
> >>   config SSB_DRIVER_PCICORE  
> >
> >
> > https://patchwork.kernel.org/patch/10161131/
> >
> > Could we _please_ switch to not applying patches to ssb or b43, if
> > nobody acked (or better reviewed) a patch?
> >
> > We had multiple changes to ssb and b43 in the recent past that did not
> > have a review at all and broke something. I don't think such software
> > quality is acceptable at all.
> > So please revert 882164a4a928.  
> 
> Yes, someone please send a revert so that this can be fixed quickly for
> v4.17.

Uhm, can you just type git revert 882164a4a928? :)
Or do I have to send you a pull request?

> > I'm sorry that this patch slipped through the cracks of my inbox.
> > But the reaction to that shall not be to just apply the patch. It
> > shall be to resubmit it for review.  
> 
> The thing is that in general I do not have time to ping people for every
> patch, I get enough of emails as is. If there are no review comments I
> have to assume the patch is ok to apply.

Yes, I understand that pinging people can be annoying and time
consuming. But we have tools like patchwork. Why isn't pinging
(semi)automated? Patchwork should really track the review status of a
patch.
I think the concept of no-comments = everything-ok is
fundamentally broken. But it has always been that way for wireless and
lots of other subsystems.

> But as ssb has had two major regressions recently I'm going to
> significantly raise the bar for ssb patches, and will refuse to apply
> random patches if they have not been tested with b43/b44.

Thanks.

-- 
Michael


pgpx8JVQIFwMB.pgp
Description: OpenPGP digital signature


Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

2018-05-07 Thread Johannes Berg
On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
> On 28 April 2018 at 15:07, Kalle Valo  wrote:
> > Andrew Zaborowski  writes:
> > > Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
> > > NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
> > > from clients other than the connection owner set in the connect,
> > > authenticate or associate commands, if it was set.
> > > 
> > > The main point of this check is to prevent chaos when two processes
> > > try to use nl80211 at the same time, it's not a security measure.
> > > The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
> > > START_AP/STOP_AP.
> > 
> > s-o-b missing.
> 
> True, thanks.  Also I was going to send this as an RFC.
> 
Looks fine to me, please resend if you want it in :)

johannes


Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

2018-05-07 Thread Johannes Berg
On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
> This adds support for exporting the mac80211 TXQ stats via nl80211 by
> way of a nested TXQ stats attribute, as well as for configuring the
> quantum and limits that were previously only changeable through debugfs.

So I finally (sorry) decided to apply this, but I get a few issues with
it (aside from trivial rebase issues). If you're not able to fix them
now let me know and I can:

1) Lots of places put the sinfo on the stack, but it's now way bigger,
so we get warnings like

net/mac80211/ethtool.c: In function ‘ieee80211_get_stats’:
net/mac80211/ethtool.c:204:1: warning: the frame size of 1752 bytes is larger 
than 1024 bytes [-Wframe-larger-than=]
net/mac80211/ethtool.c:74 ieee80211_get_stats() warn: 'sinfo' puts 1672 bytes 
on stack

I guess we need to pull those out to dynamic allocations.

net/mac80211/cfg.c:3762:12: warning: context imbalance in 
'ieee80211_get_txq_stats' - different lock contexts for basic block
net/mac80211/tx.c: In function ‘ieee80211_txq_set_params’:
net/mac80211/tx.c:1478:1: warning: control reaches end of non-void function 
[-Wreturn-type]

also show up.

johannes




Re: Regression caused by commit 882164a4a928

2018-05-07 Thread Kalle Valo
Michael Büsch  writes:

> On Mon, 7 May 2018 10:44:34 -0500
> Larry Finger  wrote:
>
>> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in 
>> module") appeared to be harmless, it leads to complete failure of drivers 
>> b43. 
>
>>   config SSB_DRIVER_PCICORE_POSSIBLE
>>  bool
>> -   depends on SSB_PCIHOST && SSB = y
>> +   depends on SSB_PCIHOST && (SSB = y || !MIPS)
>>  default y
>> 
>>   config SSB_DRIVER_PCICORE
>
>
> https://patchwork.kernel.org/patch/10161131/
>
> Could we _please_ switch to not applying patches to ssb or b43, if
> nobody acked (or better reviewed) a patch?
>
> We had multiple changes to ssb and b43 in the recent past that did not
> have a review at all and broke something. I don't think such software
> quality is acceptable at all.
> So please revert 882164a4a928.

Yes, someone please send a revert so that this can be fixed quickly for
v4.17.

> I'm sorry that this patch slipped through the cracks of my inbox.
> But the reaction to that shall not be to just apply the patch. It
> shall be to resubmit it for review.

The thing is that in general I do not have time to ping people for every
patch, I get enough of emails as is. If there are no review comments I
have to assume the patch is ok to apply.

But as ssb has had two major regressions recently I'm going to
significantly raise the bar for ssb patches, and will refuse to apply
random patches if they have not been tested with b43/b44.

-- 
Kalle Valo


Re: Possible Regression in Wireless Driver Affecting Intel Corporation Wireless 7265 (rev 59)

2018-05-07 Thread Jape Person
On 05/02/2018 03:58 AM, Luca Coelho wrote:
> On Mon, 2018-04-30 at 18:01 -0400, Jape Person wrote:
>> Two recent kernel upgrades seem to have both affected the
>> Intel Corporation Wireless 7265 (rev 59) adapters on our
>> systems in a manner which causes their network transfer rates
>> to be reduced dramatically. File transfers which normally
>> require a few minutes are now taking several hours.
>> 
>> These systems are running the Debian testing distribution with 
>> the iwilwifi drivers from Debian's testing/contrib. The
>> altered behavior came when the Debian linux-image version
>> advanced to 4.15.*.
>> 
>> I looked online for similar reports and didn't find anything 
>> that seemed directly applicably. I finally got lucky when I 
>> experimented with the net.ipv4.tcp_congestion_control setting.
>> 
>> I understand that in version 4.15 of the kernel the default
>> was changed from cubic to bbr. I used
>> 
>> # sysctl net.ipv4.tcp_congestion_control=cubic
>> 
>> to revert to the previous default on all of the systems. This 
>> has caused all of the systems to return to their normal file 
>> transfer speeds.
>> 
>> Please let me know by direct reply (I'm not subscribed.) if I 
>> can supply more information.
> 
> Do you see anything in dmesg? SYSASSERT messages or something?
> Please send your dmesg so we can take a look.
> 
> Are you by any chance using NFS? Emmanuel has recently fixed a
> problem that was occurring with NFS (but probably happens with
> other protocols too).  Can you apply the patch included in the
> following bugzilla report and see if it helps?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=199209#c18
> 
> -- Cheers, Luca.
> 

I must apologize for sending you noise instead of data, and for my
delay in replying. I felt the need to do further research before
responding.

I was not seeing any indicators whatsoever in dmesg, just very slow
file transfers. (And, no, no NFS on this network.)

I mistakenly thought my "clever" change in the
net.ipv4.tcp_congestion_control setting had "fixed" the issue
because our periodic large file transfers went without a hitch after
I applied it. The improvement was temporary.

When the next cycle of transfers was attempted a few days ago I saw
the slowdown recur.

The recurrence plus the lack of local indicators in any of the
systems' logs clued me in to the probability that this issue was
caused by network infrastructure. (I work from home and hardly ever
see it.) The router this LAN uses has always been connected to the
Internet through a DMZ on an edge router. An examination of that
edge router proved that someone had switched the LAN router
connection on the edge router from DMZ to regular client status.
This happened on the day that a field service rep from Verizon
replaced an ONT. Whether it was the rep or one of our guys, I'll be
standing there with a hammer in my hand the next time anyone works
on the infrastructure.

So, this (probably) was one of those abominable intermittent routing
issues caused by someone hooking up a router in
dumb-but-semi-workable way.

I'm back from cubic to bbr, and no slowdowns on some really big file
transfers running all day yesterday and overnight.

Again, sorry for the noise.

Best,
JP


Re: Regression caused by commit 882164a4a928

2018-05-07 Thread Michael Büsch
On Mon, 7 May 2018 10:44:34 -0500
Larry Finger  wrote:

> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in 
> module") appeared to be harmless, it leads to complete failure of drivers 
> b43. 

>   config SSB_DRIVER_PCICORE_POSSIBLE
>  bool
> -   depends on SSB_PCIHOST && SSB = y
> +   depends on SSB_PCIHOST && (SSB = y || !MIPS)
>  default y
> 
>   config SSB_DRIVER_PCICORE


https://patchwork.kernel.org/patch/10161131/

Could we _please_ switch to not applying patches to ssb or b43, if
nobody acked (or better reviewed) a patch?

We had multiple changes to ssb and b43 in the recent past that did not
have a review at all and broke something. I don't think such software
quality is acceptable at all.
So please revert 882164a4a928.

I'm sorry that this patch slipped through the cracks of my inbox.
But the reaction to that shall not be to just apply the patch. It
shall be to resubmit it for review.



But back to the technical topic.
I don't remember why SSB_DRIVER_PCICORE_POSSIBLE depends on SSB_PCIHOST.
But that looks and feels wrong.

I would say it should rather look like

config SSB_DRIVER_PCICORE_POSSIBLE
depends on SSB && (PCI = y || PCI = SSB)

completely untested, though.

-- 
Michael


pgpqzKxv24XQl.pgp
Description: OpenPGP digital signature


[PATCH] mwifiex: increase TX threashold to avoid TX timeout during ED MAC test

2018-05-07 Thread Ganapathi Bhat
While carrying energy detection(ED) tests, the chip will stop
transmission upon detecting an energy in the connected channel.
As a feedback, driver will stop dequeuing TX packets and due to
which wmm_tx_pending keep incremeting. Once wmm_tx_pending
reaches 100, driver calls netif_tx_stop_queue(). If TX ques is
not restarted within 5(watchdog_timeo) seconds, it will result in
TX timeout.

The ED test is carried out for one minute and the current
threshold of 100 is easily overcome by the traffic, cuasing TX
timeouts. To fix this increase the threshold to 400.

Signed-off-by: Cathy Luo 
Signed-off-by: Ganapathi Bhat 
---
 drivers/net/wireless/marvell/mwifiex/main.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index b2a94b8..c5478c8 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -84,8 +84,8 @@ enum {
 #define MWIFIEX_TIMER_10S  1
 #define MWIFIEX_TIMER_1S   1000
 
-#define MAX_TX_PENDING  100
-#define LOW_TX_PENDING  80
+#define MAX_TX_PENDING  400
+#define LOW_TX_PENDING  380
 
 #define HIGH_RX_PENDING 50
 #define LOW_RX_PENDING  20
-- 
1.9.1



Regression caused by commit 882164a4a928

2018-05-07 Thread Larry Finger

Matt,

Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in 
module") appeared to be harmless, it leads to complete failure of drivers b43. 
and b43legacy, and likely affects b44 as well. The problem is that 
CONFIG_SSB_PCIHOST is undefined, which prevents the compilation of the code that 
controls the PCI cores of the device. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1572349 for details.


As the underlying errors ("pcibios_enable_device" undefined, and 
"register_pci_controller" undefined) do not appear on the architectures that I 
have tested (x86_64, x86, and ppc), I suspect something in the arch-specific 
code for your setup (MIPS?). As I have no idea on how to fix that problem, would 
the following patch work for you?


diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 9371651d8017..3743533c8057 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -117,7 +117,7 @@ config SSB_SERIAL

 config SSB_DRIVER_PCICORE_POSSIBLE
bool
-   depends on SSB_PCIHOST && SSB = y
+   depends on SSB_PCIHOST && (SSB = y || !MIPS)
default y

 config SSB_DRIVER_PCICORE

Thanks,

Larry


Re: pull-request mwifiex-firmware 2018-05-07

2018-05-07 Thread Josh Boyer
On Mon, May 7, 2018 at 8:31 AM Ganapathi Bhat  wrote:

> The following changes since commit
5446916b53de395245d89400dea566055ec4502c:

>linux-firmware: update Marvell PCIe-USB8897/8997 firmware image to add
WPA2 vulnerability fix (2018-01-16 01:45:00 -0800)

> are available in the git repository at:

>git://git.marvell.com/mwifiex-firmware.git

> for you to fetch changes up to e1abab618308110789a4c27db543d132fd62e89f:

>linux-firmware: update Marvell USB8997 firmware image to add WPA2
vulnerability fix (2018-05-07 17:54:42 +0530)

> 
> Ganapathi Bhat (2):
>linux-firmware: update Marvell SD8897-B0 firmware image to add WPA2
vulnerability fix
>linux-firmware: update Marvell USB8997 firmware image to add WPA2
vulnerability fix

>   WHENCE   |   4 ++--
>   mrvl/sd8897_uapsta.bin   | Bin 814048 -> 821024 bytes
>   mrvl/usbusb8997_combo_v4.bin | Bin 602100 -> 604536 bytes
>   3 files changed, 2 insertions(+), 2 deletions(-)

Thanks.  Pulled and pushed out.

josh


Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote:
> Mauro Carvalho Chehab  writes:
> 
> > Sphinx produces a lot of errors like this:
> > ./include/net/mac80211.h:2083: warning: bad line:  >
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> Randy already submitted a similar patch:
> 
> https://patchwork.kernel.org/patch/10367275/
> 
> But it seems Johannes has not applied that yet.

Yeah, I've been super busy preparing for the plugfest.

I'll make a pass over all the patches as soon as I can, hopefully today
or tomorrow.

johannes


Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

2018-05-07 Thread Kalle Valo
Mauro Carvalho Chehab  writes:

> Sphinx produces a lot of errors like this:
>   ./include/net/mac80211.h:2083: warning: bad line:  >
>
> Signed-off-by: Mauro Carvalho Chehab 

Randy already submitted a similar patch:

https://patchwork.kernel.org/patch/10367275/

But it seems Johannes has not applied that yet.

-- 
Kalle Valo


pull-request mwifiex-firmware 2018-05-07

2018-05-07 Thread Ganapathi Bhat
The following changes since commit 5446916b53de395245d89400dea566055ec4502c:

  linux-firmware: update Marvell PCIe-USB8897/8997 firmware image to add WPA2 
vulnerability fix (2018-01-16 01:45:00 -0800)

are available in the git repository at:

  git://git.marvell.com/mwifiex-firmware.git

for you to fetch changes up to e1abab618308110789a4c27db543d132fd62e89f:

  linux-firmware: update Marvell USB8997 firmware image to add WPA2 
vulnerability fix (2018-05-07 17:54:42 +0530)


Ganapathi Bhat (2):
  linux-firmware: update Marvell SD8897-B0 firmware image to add WPA2 
vulnerability fix
  linux-firmware: update Marvell USB8997 firmware image to add WPA2 
vulnerability fix

 WHENCE   |   4 ++--
 mrvl/sd8897_uapsta.bin   | Bin 814048 -> 821024 bytes
 mrvl/usbusb8997_combo_v4.bin | Bin 602100 -> 604536 bytes
 3 files changed, 2 insertions(+), 2 deletions(-)


RE: [EXT] Re: pull-request mwifiex-firmware 2018-05-04

2018-05-07 Thread Ganapathi Bhat
Hi Josh,

> --
> On Fri, May 4, 2018 at 3:34 AM Ganapathi Bhat  wrote:
>
> > The following changes since commit
> 5446916b53de395245d89400dea566055ec4502c:
>
> >linux-firmware: update Marvell PCIe-USB8897/8997 firmware image to
> > add
> WPA2 vulnerability fix (2018-01-16 01:45:00 -0800)
>
> > are available in the git repository at:
>
> >git://git.marvell.com/mwifiex-firmware.git
>
> > for you to fetch changes up to
> 8b2f89bba6e8330c484f9ad39367d8efd42d23b4:
>
> >linux-firmware: update Marvell USB8997 firmware image to add WPA2
> vulnerability fix (2018-05-04 12:51:40 +0530)
>
> > 
> > Ganapathi Bhat (2):
> >linux-firmware: update Marvell SD8897-B0 firmware image to add
> > WPA2
> vulnerability fix
> >linux-firmware: update Marvell USB8997 firmware image to add
> > WPA2
> vulnerability fix
>
> Both of those commits are missing the Signed-off-by: tag.  Can you add it
> please?
Sure, will send another pull request.
>
> josh
>
>
> > WHENCE   |   4 ++--
> > mrvl/sd8897_uapsta.bin   | Bin 814048 -> 821024 bytes
> > mrvl/usbusb8997_combo_v4.bin | Bin 602100 -> 604536 bytes
> > 3 files changed, 2 insertions(+), 2 deletions(-)
Thanks,
Ganapathi


Re: pull-request mwifiex-firmware 2018-05-04

2018-05-07 Thread Josh Boyer
On Fri, May 4, 2018 at 3:34 AM Ganapathi Bhat  wrote:

> The following changes since commit
5446916b53de395245d89400dea566055ec4502c:

>linux-firmware: update Marvell PCIe-USB8897/8997 firmware image to add
WPA2 vulnerability fix (2018-01-16 01:45:00 -0800)

> are available in the git repository at:

>git://git.marvell.com/mwifiex-firmware.git

> for you to fetch changes up to 8b2f89bba6e8330c484f9ad39367d8efd42d23b4:

>linux-firmware: update Marvell USB8997 firmware image to add WPA2
vulnerability fix (2018-05-04 12:51:40 +0530)

> 
> Ganapathi Bhat (2):
>linux-firmware: update Marvell SD8897-B0 firmware image to add WPA2
vulnerability fix
>linux-firmware: update Marvell USB8997 firmware image to add WPA2
vulnerability fix

Both of those commits are missing the Signed-off-by: tag.  Can you add it
please?

josh


> WHENCE   |   4 ++--
> mrvl/sd8897_uapsta.bin   | Bin 814048 -> 821024 bytes
> mrvl/usbusb8997_combo_v4.bin | Bin 602100 -> 604536 bytes
> 3 files changed, 2 insertions(+), 2 deletions(-)


Re: WARNING in add_uevent_var

2018-05-07 Thread Tetsuo Handa
On 2018/04/03 21:34, Johannes Berg wrote:
> On Sun, 2018-04-01 at 23:01 -0700, syzbot wrote:
> 
>> So far this crash happened 5 times on net-next, upstream.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128
>>
> 
> Huh, fun. Looks like you're basically creating a new HWSIM radio with an
> insanely long name (4k!) and nothing stops you, until we try to generate
> an rfkill instance which sends a uevent and only has a 2k buffer for the
> environment variables, where we put the name ...
> 
> But yeah, we should probably limit the phy name to something sane, I'll
> pick 128 and send a patch.
> 

I think it should be NAME_MAX.


#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
const int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
static struct {
struct nlmsghdr hdr;
char data[4120 - sizeof(struct nlmsghdr)];
} buf = { };
struct sockaddr_nl addr = { .nl_family = AF_NETLINK };
struct iovec iov = { &buf, sizeof(buf) };
struct msghdr msg = {
.msg_name = &addr,
.msg_namelen = sizeof(addr),
.msg_iov = &iov,
.msg_iovlen = 1,
};
buf.hdr.nlmsg_len = 0x1018;
buf.hdr.nlmsg_type = 0x22;
buf.hdr.nlmsg_flags = 0x109;
*(uint8_t*) buf.data = 4;
*(uint8_t*) (buf.data + 1) = 0;
*(uint16_t*) (buf.data + 2) = 0;
*(uint16_t*) (buf.data + 4) = 0x1004;
*(uint16_t*) (buf.data + 6) = 0x11;
memset(buf.data + 8, 'A', 4096); /* strlen() > NAME_MAX */
sendmsg(fd, &msg, 0);
return 0;
}




>From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Mon, 7 May 2018 15:58:37 +0900
Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc().

syzbot is hitting WARN() at kobject_uevent_env() [1].
This is because the test case is requesting too long name.
Since the name is used as part of pathname under /sys/devices/virtual/ ,
this name parameter must obey the limitations of a filename.
Fix this by applying name validity test to rfkill_alloc().

[1] 
https://syzkaller.appspot.com/bug?id=c1e1ab1d042b637ee9e25c64b107d51630b9d9ec

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Johannes Berg 
---
 net/rfkill/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 59d0eb9..d8beebc 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -933,6 +933,10 @@ struct rfkill * __must_check rfkill_alloc(const char *name,
if (WARN_ON(type == RFKILL_TYPE_ALL || type >= NUM_RFKILL_TYPES))
return NULL;
 
+   if (strlen(name) > NAME_MAX || strchr(name, '/') ||
+   !strcmp(name, ".") || !strcmp(name, ".."))
+   return NULL;
+
rfkill = kzalloc(sizeof(*rfkill) + strlen(name) + 1, GFP_KERNEL);
if (!rfkill)
return NULL;
-- 
1.8.3.1




Re: WARNING in kernfs_add_one

2018-05-07 Thread Tetsuo Handa
On 2018/05/06 7:07, Greg KH wrote:
>> More likely wireless territory
> 
> Ugh, that's what I get for writing emails before coffee in the
> morning...
> 
> Yes, you are right, this looks like a wireless issue.
> 
> Now cc: linux-wireless.
> 
Nope, if you look at previous fault injection messages...



>From 7ddcaa3d4327d4f29d11053bd2011bf77ecf72af Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Mon, 7 May 2018 14:19:50 +0900
Subject: [PATCH] driver core: Don't ignore class_dir_create_and_add() failure.

syzbot is hitting WARN() at kernfs_add_one() [1].
This is because kernfs_create_link() is confused by previous device_add()
call which continued without setting dev->kobj.parent field when
get_device_parent() failed by memory allocation fault injection.
Fix this by propagating the error from class_dir_create_and_add() to
the calllers of get_device_parent().

[1] 
https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Greg Kroah-Hartman 
---
 drivers/base/core.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index b610816..d680fd0 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1467,7 +1467,7 @@ class_dir_create_and_add(struct class *class, struct 
kobject *parent_kobj)
 
dir = kzalloc(sizeof(*dir), GFP_KERNEL);
if (!dir)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
dir->class = class;
kobject_init(&dir->kobj, &class_dir_ktype);
@@ -1477,7 +1477,7 @@ class_dir_create_and_add(struct class *class, struct 
kobject *parent_kobj)
retval = kobject_add(&dir->kobj, parent_kobj, "%s", class->name);
if (retval < 0) {
kobject_put(&dir->kobj);
-   return NULL;
+   return ERR_PTR(retval);
}
return &dir->kobj;
 }
@@ -1784,6 +1784,10 @@ int device_add(struct device *dev)
 
parent = get_device(dev->parent);
kobj = get_device_parent(dev, parent);
+   if (IS_ERR(kobj)) {
+   error = PTR_ERR(kobj);
+   goto parent_error;
+   }
if (kobj)
dev->kobj.parent = kobj;
 
@@ -1882,6 +1886,7 @@ int device_add(struct device *dev)
kobject_del(&dev->kobj);
  Error:
cleanup_glue_dir(dev, glue_dir);
+parent_error:
put_device(parent);
 name_error:
kfree(dev->p);
@@ -2701,6 +2706,11 @@ int device_move(struct device *dev, struct device 
*new_parent,
device_pm_lock();
new_parent = get_device(new_parent);
new_parent_kobj = get_device_parent(dev, new_parent);
+   if (IS_ERR(new_parent_kobj)) {
+   error = PTR_ERR(new_parent_kobj);
+   put_device(new_parent);
+   goto out;
+   }
 
pr_debug("device: '%s': %s: moving to '%s'\n", dev_name(dev),
 __func__, new_parent ? dev_name(new_parent) : "");
-- 
1.8.3.1



Re: WARNING in kernfs_add_one

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 11:33 +0200, Dmitry Vyukov wrote:
> On Mon, May 7, 2018 at 10:43 AM, Johannes Berg
>  wrote:
> > On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote:
> > 
> > > > > > syzbot found the following crash on:
> > 
> > Maybe it should learn to differentiate warnings, if it's going to set
> > panic_on_warn :-)
> 
> How?
> Note that this is not specific to syzbot. If you see WARNINGs in a
> subsystem that you have no idea about (or you just a normal user),
> what do you do? Right, you report it to maintainers.

Yeah, no problem with that. Just some people seem to get so much more
upset about crashes ... but then again I get bug reports about WARN_ON
all the time anyway that say "my kernel crashed" so I guess it doesn't
really matter :-)

> > I get why, but still, at least differentiating in the emails wouldn't be
> > bad.
> 
> Well, the subject says "WARNING".
> But note there are _very_ bad WARNINGs too. Generally, a WARNING means
> a kernel bug just that kernel can tolerate without bringing the system
> down (as opposed to BUG).

Yeah, fair point. I sort of missed the subject I guess.

johannes


[PATCH v2] ath10k: remove variables which set but not used

2018-05-07 Thread Kenneth Lu
Variable buf_len and num_vdev_stats are bging assigned but never read.
These are redundant and can be remove.

Signed-off-by: Kenneth Lu 
---
Changes in v2:
Fixed compile failed in function 'ath10k_wmi_10_4_op_pull_fw_stats'
error: 'num_vdev_stats' undeclared
---
 drivers/net/wireless/ath/ath10k/wmi.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index bb8e9e2..46fb96e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2318,7 +2318,6 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
u32 phy_mode;
u32 snr;
u32 rate;
-   u32 buf_len;
u16 fc;
int ret;
 
@@ -2330,7 +2329,6 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
}
 
channel = __le32_to_cpu(arg.channel);
-   buf_len = __le32_to_cpu(arg.buf_len);
rx_status = __le32_to_cpu(arg.status);
snr = __le32_to_cpu(arg.snr);
phy_mode = __le32_to_cpu(arg.phy_mode);
@@ -2740,14 +2738,13 @@ static int ath10k_wmi_main_op_pull_fw_stats(struct 
ath10k *ar,
struct ath10k_fw_stats *stats)
 {
const struct wmi_stats_event *ev = (void *)skb->data;
-   u32 num_pdev_stats, num_vdev_stats, num_peer_stats;
+   u32 num_pdev_stats, num_peer_stats;
int i;
 
if (!skb_pull(skb, sizeof(*ev)))
return -EPROTO;
 
num_pdev_stats = __le32_to_cpu(ev->num_pdev_stats);
-   num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
 
for (i = 0; i < num_pdev_stats; i++) {
@@ -2795,14 +2792,13 @@ static int ath10k_wmi_10x_op_pull_fw_stats(struct 
ath10k *ar,
   struct ath10k_fw_stats *stats)
 {
const struct wmi_stats_event *ev = (void *)skb->data;
-   u32 num_pdev_stats, num_vdev_stats, num_peer_stats;
+   u32 num_pdev_stats, num_peer_stats;
int i;
 
if (!skb_pull(skb, sizeof(*ev)))
return -EPROTO;
 
num_pdev_stats = __le32_to_cpu(ev->num_pdev_stats);
-   num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
 
for (i = 0; i < num_pdev_stats; i++) {
@@ -2856,7 +2852,6 @@ static int ath10k_wmi_10_2_op_pull_fw_stats(struct ath10k 
*ar,
const struct wmi_10_2_stats_event *ev = (void *)skb->data;
u32 num_pdev_stats;
u32 num_pdev_ext_stats;
-   u32 num_vdev_stats;
u32 num_peer_stats;
int i;
 
@@ -2865,7 +2860,6 @@ static int ath10k_wmi_10_2_op_pull_fw_stats(struct ath10k 
*ar,
 
num_pdev_stats = __le32_to_cpu(ev->num_pdev_stats);
num_pdev_ext_stats = __le32_to_cpu(ev->num_pdev_ext_stats);
-   num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
 
for (i = 0; i < num_pdev_stats; i++) {
@@ -2935,7 +2929,6 @@ static int ath10k_wmi_10_2_4_op_pull_fw_stats(struct 
ath10k *ar,
const struct wmi_10_2_stats_event *ev = (void *)skb->data;
u32 num_pdev_stats;
u32 num_pdev_ext_stats;
-   u32 num_vdev_stats;
u32 num_peer_stats;
int i;
 
@@ -2944,7 +2937,6 @@ static int ath10k_wmi_10_2_4_op_pull_fw_stats(struct 
ath10k *ar,
 
num_pdev_stats = __le32_to_cpu(ev->num_pdev_stats);
num_pdev_ext_stats = __le32_to_cpu(ev->num_pdev_ext_stats);
-   num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
 
for (i = 0; i < num_pdev_stats; i++) {
-- 
2.7.4



[PATCH 00/18] Fix some build warnings/errors with Sphinx

2018-05-07 Thread Mauro Carvalho Chehab
I decided to give a try with Sphinx last stable version
(1.17.4), and noticed several issues. The worse one was
with the networking book: a non-standard footnote there
with [*] instead of a number causes it to break PDF building.

So, I took some spare time to address some warnings all over
the tree, and moved a few text documents to a book. I with
I had more time to move the other ones and to solve other
warnings.

Mauro Carvalho Chehab (18):
  docs: can.rst: fix a footnote reference
  docs: fix location of request_firmware & friends
  docs: */index.rst: Add newer documents to their respective index.rst
  docs: admin-guide: add bcache documentation
  docs: core-api: add cachetlb documentation
  docs: core-api: add cgroup-v2 documentation
  docs: core-api: add circular-buffers documentation
  docs: driver-api: add clk documentation
  net: mac80211.h: fix a bad comment line
  rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()
  docs: crypto_engine.rst: Fix two parse warnings
  time: timer.c: adjust a kernel-doc comment
  wait: wait.h: Get rid of a kernel-doc/Sphinx warnings
  fbdev: modedb.c: fix a kernel-doc markup
  iio: iio.h: use nested struct support on kernel-doc markup
  mtd: rawnand.h: use nested union kernel-doc markups
  docs: uio-howto.rst: use a code block to solve a warning
  w1: w1_io.c: fix a kernel-doc warning

 Documentation/00-INDEX| 10 ---
 .../{bcache.txt => admin-guide/bcache.rst}|  0
 .../cgroup-v2.rst}|  0
 Documentation/admin-guide/index.rst   |  2 ++
 .../admin-guide/kernel-parameters.txt |  2 +-
 .../{cachetlb.txt => core-api/cachetlb.rst}   |  0
 .../circular-buffers.rst} |  0
 Documentation/core-api/index.rst  |  2 ++
 Documentation/crypto/crypto_engine.rst|  8 +++---
 Documentation/crypto/index.rst|  1 +
 Documentation/dell_rbu.txt|  4 +--
 Documentation/{clk.txt => driver-api/clk.rst} |  0
 .../firmware/fallback-mechanisms.rst  |  2 +-
 .../driver-api/firmware/request_firmware.rst  | 17 +++-
 Documentation/driver-api/index.rst|  2 ++
 Documentation/driver-api/infrastructure.rst   |  2 +-
 Documentation/driver-api/uio-howto.rst|  3 ++-
 Documentation/memory-barriers.txt |  4 +--
 Documentation/networking/can.rst  |  4 +--
 .../power/suspend-and-cpuhotplug.txt  |  2 +-
 Documentation/process/index.rst   |  1 +
 Documentation/security/index.rst  |  2 ++
 .../translations/ko_KR/memory-barriers.txt|  4 +--
 drivers/video/fbdev/core/modedb.c | 22 
 drivers/w1/w1_io.c|  1 +
 include/linux/iio/iio.h   | 24 -
 include/linux/mtd/rawnand.h   | 26 +--
 include/linux/rcupdate.h  |  5 ++--
 include/linux/wait.h  |  2 +-
 include/net/mac80211.h|  2 +-
 kernel/time/timer.c   | 14 +-
 31 files changed, 93 insertions(+), 75 deletions(-)
 rename Documentation/{bcache.txt => admin-guide/bcache.rst} (100%)
 rename Documentation/{cgroup-v2.txt => admin-guide/cgroup-v2.rst} (100%)
 rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
 rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} 
(100%)
 rename Documentation/{clk.txt => driver-api/clk.rst} (100%)

-- 
2.17.0




[PATCH 09/18] net: mac80211.h: fix a bad comment line

2018-05-07 Thread Mauro Carvalho Chehab
Sphinx produces a lot of errors like this:
./include/net/mac80211.h:2083: warning: bad line:  >

Signed-off-by: Mauro Carvalho Chehab 
---
 include/net/mac80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d2279b2d61aa..b2f3a0c018e7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2080,7 +2080,7 @@ struct ieee80211_txq {
  * virtual interface might not be given air time for the transmission of
  * the frame, as it is not synced with the AP/P2P GO yet, and thus the
  * deauthentication frame might not be transmitted.
- >
+ *
  * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
  * support QoS NDP for AP probing - that's most likely a driver bug.
  *
-- 
2.17.0



Re: WARNING in kernfs_add_one

2018-05-07 Thread Dmitry Vyukov
On Mon, May 7, 2018 at 10:43 AM, Johannes Berg
 wrote:
> On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote:
>
>> > > > syzbot found the following crash on:
>
> Maybe it should learn to differentiate warnings, if it's going to set
> panic_on_warn :-)

How?
Note that this is not specific to syzbot. If you see WARNINGs in a
subsystem that you have no idea about (or you just a normal user),
what do you do? Right, you report it to maintainers.


> I get why, but still, at least differentiating in the emails wouldn't be
> bad.

Well, the subject says "WARNING".
But note there are _very_ bad WARNINGs too. Generally, a WARNING means
a kernel bug just that kernel can tolerate without bringing the system
down (as opposed to BUG).


>> > > > kernfs: ns required in 'ieee80211' for 'phy3'
>
> Huh. What does that even mean?
>
>> > > > RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
>> > > > RSP: 0018:8801ca9eece0 EFLAGS: 00010286
>> > > > RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
>> > > > RDX:  RSI: 81610731 RDI: 8801ca9ee840
>> > > > RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
>> > > > R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
>> > > > R13: 885da640 R14: 0020 R15: 
>> > > >  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
>> > > >  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
>> > > >  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
>> > > >  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
>> > > >  device_add_class_symlinks drivers/base/core.c:1612 [inline]
>> > > >  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
>> > > >  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
>> > > >  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
>> > > >  mac80211_hwsim_new_radio+0x1d9b/0x3410
>> > > > drivers/net/wireless/mac80211_hwsim.c:2772
>> > > >  hwsim_new_radio_nl+0x7a7/0xa60 
>> > > > drivers/net/wireless/mac80211_hwsim.c:3246
>> > > >  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
>
> Basically we're creating a new virtual radio, which in turn creates a
> new device, which we have to register.
>
> Something is going on with the context here that makes sysfs unhappy,
> but TBH I have no idea what.
>
> johannes
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/1525682589.6049.4.camel%40sipsolutions.net.
> For more options, visit https://groups.google.com/d/optout.


[PATCH 30/30] staging: wilc1000: rename s8idxarray to avoid datatype in variable name

2018-05-07 Thread Ajay Singh
Cleanup patch to have variable names as per linux coding style.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index ad9270e..e27010c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1543,7 +1543,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
struct wid wid;
struct wid wid_list[5];
u8 *key_buf;
-   s8 s8idxarray[1];
+   s8 idxarray[1];
struct host_if_drv *hif_drv = vif->hif_drv;
 
switch (hif_key->type) {
@@ -1610,8 +1610,8 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
wid.id = (u16)WID_REMOVE_WEP_KEY;
wid.type = WID_STR;
 
-   s8idxarray[0] = (s8)hif_key->attr.wep.index;
-   wid.val = s8idxarray;
+   idxarray[0] = (s8)hif_key->attr.wep.index;
+   wid.val = idxarray;
wid.size = 1;
 
result = wilc_send_config_pkt(vif, SET_CFG,
-- 
2.7.4



[PATCH 28/30] staging: wilc1000: added comments for mutex and spinlock_t

2018-05-07 Thread Ajay Singh
Added comments for mutex and spinlock_t to avoid checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.h | 2 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.h 
b/drivers/staging/wilc1000/host_interface.h
index 7a26f34..5e00dde 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -271,7 +271,7 @@ struct host_if_drv {
 
u8 assoc_bssid[ETH_ALEN];
struct cfg_param_attr cfg_values;
-
+/*lock to protect concurrent setting of cfg params*/
struct mutex cfg_values_lock;
struct completion comp_test_key_block;
struct completion comp_test_disconn_block;
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 607dae0..e517768 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -131,10 +131,11 @@ struct wilc {
u8 vif_num;
struct wilc_vif *vif[NUM_CONCURRENT_IFC];
u8 open_ifcs;
-
+/*protect head of transmit queue*/
struct mutex txq_add_to_head_cs;
+/*protect txq_entry_t transmit queue*/
spinlock_t txq_spinlock;
-
+/*protect rxq_entry_t receiver queue*/
struct mutex rxq_cs;
struct mutex hif_cs;
 
-- 
2.7.4



[PATCH 23/30] staging: wilc1000: rename u8security to avoid datatype in variable name

2018-05-07 Thread Ajay Singh
Cleanup patch to avoid use of datatype in variable name to follow as
per linux coding style.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 00381c9..4600f4a 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -674,7 +674,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
s32 ret = 0;
u32 i;
u32 sel_bssi_idx = UINT_MAX;
-   u8 u8security = NO_ENCRYPT;
+   u8 security = NO_ENCRYPT;
enum AUTHTYPE auth_type = ANY;
u32 cipher_group;
struct wilc_priv *priv;
@@ -727,7 +727,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
cipher_group = sme->crypto.cipher_group;
if (cipher_group != NO_ENCRYPT) {
if (cipher_group == WLAN_CIPHER_SUITE_WEP40) {
-   u8security = ENCRYPT_ENABLED | WEP;
+   security = ENCRYPT_ENABLED | WEP;
 
priv->wep_key_len[sme->key_idx] = sme->key_len;
memcpy(priv->wep_key[sme->key_idx], sme->key,
@@ -737,7 +737,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
wilc_add_wep_key_bss_sta(vif, sme->key, sme->key_len,
 sme->key_idx);
} else if (cipher_group == WLAN_CIPHER_SUITE_WEP104) {
-   u8security = ENCRYPT_ENABLED | WEP | WEP_EXTENDED;
+   security = ENCRYPT_ENABLED | WEP | WEP_EXTENDED;
 
priv->wep_key_len[sme->key_idx] = sme->key_len;
memcpy(priv->wep_key[sme->key_idx], sme->key,
@@ -748,14 +748,14 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
 sme->key_idx);
} else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_2) {
if (cipher_group == WLAN_CIPHER_SUITE_TKIP)
-   u8security = ENCRYPT_ENABLED | WPA2 | TKIP;
+   security = ENCRYPT_ENABLED | WPA2 | TKIP;
else
-   u8security = ENCRYPT_ENABLED | WPA2 | AES;
+   security = ENCRYPT_ENABLED | WPA2 | AES;
} else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_1) {
if (cipher_group == WLAN_CIPHER_SUITE_TKIP)
-   u8security = ENCRYPT_ENABLED | WPA | TKIP;
+   security = ENCRYPT_ENABLED | WPA | TKIP;
else
-   u8security = ENCRYPT_ENABLED | WPA | AES;
+   security = ENCRYPT_ENABLED | WPA | AES;
} else {
ret = -ENOTSUPP;
netdev_err(dev, "Not supported cipher\n");
@@ -770,9 +770,9 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
u32 ciphers_pairwise = sme->crypto.ciphers_pairwise[i];
 
if (ciphers_pairwise == WLAN_CIPHER_SUITE_TKIP)
-   u8security = u8security | TKIP;
+   security = security | TKIP;
else
-   u8security = u8security | AES;
+   security = security | AES;
}
}
 
@@ -804,7 +804,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
ret = wilc_set_join_req(vif, nw_info->bssid, sme->ssid,
sme->ssid_len, sme->ie, sme->ie_len,
cfg_connect_result, (void *)priv,
-   u8security, auth_type,
+   security, auth_type,
nw_info->ch,
nw_info->join_params);
if (ret != 0) {
-- 
2.7.4



[PATCH 27/30] staging: wilc1000: remove 'flag' argument from wilc_mac_indicate()

2018-05-07 Thread Ajay Singh
Remove 'flag' function parameter in wilc_mac_indicate() as only one
condition was handled using that parameter. Also removed unnecessary
call to wilc_mac_indicate() as no operation was performed in that
function call.
After above changes below macro are not required.

This changes also helped in resolving the line over 80 chars issue
found by checkatpch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_wlan.c | 17 +++--
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |  2 +-
 drivers/staging/wilc1000/wilc_wlan.c  |  7 +--
 drivers/staging/wilc1000/wilc_wlan_if.h   |  3 ---
 4 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 7b883c0..02e6b13 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -176,19 +176,16 @@ static void deinit_irq(struct net_device *dev)
}
 }
 
-void wilc_mac_indicate(struct wilc *wilc, int flag)
+void wilc_mac_indicate(struct wilc *wilc)
 {
int status;
 
-   if (flag == WILC_MAC_INDICATE_STATUS) {
-   wilc_wlan_cfg_get_val(WID_STATUS,
- (unsigned char *)&status, 4);
-   if (wilc->mac_status == MAC_STATUS_INIT) {
-   wilc->mac_status = status;
-   complete(&wilc->sync_event);
-   } else {
-   wilc->mac_status = status;
-   }
+   wilc_wlan_cfg_get_val(WID_STATUS, (unsigned char *)&status, 4);
+   if (wilc->mac_status == MAC_STATUS_INIT) {
+   wilc->mac_status = status;
+   complete(&wilc->sync_event);
+   } else {
+   wilc->mac_status = status;
}
 }
 
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 8849924..607dae0 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -182,7 +182,7 @@ struct wilc_wfi_mon_priv {
 };
 
 void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 size, u32 pkt_offset);
-void wilc_mac_indicate(struct wilc *wilc, int flag);
+void wilc_mac_indicate(struct wilc *wilc);
 void wilc_netdev_cleanup(struct wilc *wilc);
 int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type,
 int gpio, const struct wilc_hif_func *ops);
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 7147e0c..d4ebbf6 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -816,12 +816,7 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8 
*buffer, int size)
if (wilc->cfg_seq_no == rsp.seq_no)
complete(&wilc->cfg_event);
} else if (rsp.type == WILC_CFG_RSP_STATUS) {
-   wilc_mac_indicate(wilc,
- 
WILC_MAC_INDICATE_STATUS);
-
-   } else if (rsp.type == WILC_CFG_RSP_SCAN) {
-   wilc_mac_indicate(wilc,
- 
WILC_MAC_INDICATE_SCAN);
+   wilc_mac_indicate(wilc);
}
}
}
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h 
b/drivers/staging/wilc1000/wilc_wlan_if.h
index aa0731e..e4a7bf5 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -47,9 +47,6 @@ struct sdio_cmd53 {
u32 block_size;
 };
 
-#define WILC_MAC_INDICATE_STATUS   0x1
-#define WILC_MAC_INDICATE_SCAN 0x2
-
 #define MAC_STATUS_INIT-1
 #define MAC_STATUS_CONNECTED   1
 #define MAC_STATUS_DISCONNECTED0
-- 
2.7.4



[PATCH 26/30] staging: wilc1000: added #define for setting radiotap header

2018-05-07 Thread Ajay Singh
Added new macro to resolve below checkpatch issues in linux_mon.

"Lines should not end with a '('"

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_mon.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_mon.c 
b/drivers/staging/wilc1000/linux_mon.c
index c372e0f..1c7e6e1 100644
--- a/drivers/staging/wilc1000/linux_mon.c
+++ b/drivers/staging/wilc1000/linux_mon.c
@@ -22,6 +22,9 @@ static u8 bssid[6];
 #define IEEE80211_RADIOTAP_F_TX_FAIL   0x0001  /* failed due to excessive*/
 #define GET_PKT_OFFSET(a) (((a) >> 22) & 0x1ff)
 
+#define TX_RADIOTAP_PRESENT ((1 << IEEE80211_RADIOTAP_RATE) |  \
+(1 << IEEE80211_RADIOTAP_TX_FLAGS))
+
 void wilc_wfi_monitor_rx(u8 *buff, u32 size)
 {
u32 header, pkt_offset;
@@ -59,9 +62,7 @@ void wilc_wfi_monitor_rx(u8 *buff, u32 size)
 
cb_hdr->hdr.it_len = cpu_to_le16(sizeof(*cb_hdr));
 
-   cb_hdr->hdr.it_present = cpu_to_le32(
-   (1 << IEEE80211_RADIOTAP_RATE) |
-   (1 << IEEE80211_RADIOTAP_TX_FLAGS));
+   cb_hdr->hdr.it_present = cpu_to_le32(TX_RADIOTAP_PRESENT);
 
cb_hdr->rate = 5; /* txrate->bitrate / 5; */
 
@@ -177,9 +178,7 @@ static netdev_tx_t wilc_wfi_mon_xmit(struct sk_buff *skb,
 
cb_hdr->hdr.it_len = cpu_to_le16(sizeof(*cb_hdr));
 
-   cb_hdr->hdr.it_present = cpu_to_le32(
-   (1 << IEEE80211_RADIOTAP_RATE) |
-   (1 << IEEE80211_RADIOTAP_TX_FLAGS));
+   cb_hdr->hdr.it_present = cpu_to_le32(TX_RADIOTAP_PRESENT);
 
cb_hdr->rate = 5; /* txrate->bitrate / 5; */
cb_hdr->tx_flags = 0x0004;
-- 
2.7.4



[PATCH 25/30] staging: wilc1000: fix line over 80 chars in wilc_sdio struct

2018-05-07 Thread Ajay Singh
Fix line over 80 chars issue found by checkpatch.pl script by placing
the comment message above the macro preprocessor.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_sdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 211be73..4ab43f9 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -26,7 +26,8 @@ struct wilc_sdio {
bool irq_gpio;
u32 block_size;
int nint;
-#define MAX_NUN_INT_THRPT_ENH2 (5) /* Max num interrupts allowed in registers 
0xf7, 0xf8 */
+/* Max num interrupts allowed in registers 0xf7, 0xf8 */
+#define MAX_NUN_INT_THRPT_ENH2 (5)
int has_thrpt_enh3;
 };
 
-- 
2.7.4



[PATCH 29/30] staging: wilc1000: remove unused 'lock' varible in 'wilc_priv' structure

2018-05-07 Thread Ajay Singh
Cleanup patch to remove the unused variable from 'wilc_priv' structure.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index e517768..3875065 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -78,7 +78,6 @@ struct wilc_priv {
u8 monitor_flag;
int status;
struct sk_buff *skb;
-   spinlock_t lock;
struct net_device *dev;
struct host_if_drv *hif_drv;
struct host_if_pmkid_attr pmkid_list;
-- 
2.7.4



[PATCH 19/30] staging: wilc1000: fix line over 80 chars in wilc_create_wiphy() declaration

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issue found by checkpatch.pl script in
function declaration.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.h 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.h
index c1a2421..a69103b 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.h
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.h
@@ -3,7 +3,8 @@
 #define NM_WFI_CFGOPERATIONS
 #include "wilc_wfi_netdevice.h"
 
-struct wireless_dev *wilc_create_wiphy(struct net_device *net, struct device 
*dev);
+struct wireless_dev *wilc_create_wiphy(struct net_device *net,
+  struct device *dev);
 void wilc_free_wiphy(struct net_device *net);
 int wilc_deinit_host_int(struct net_device *net);
 int wilc_init_host_int(struct net_device *net);
-- 
2.7.4



[PATCH 24/30] staging: wilc1000: refactor del_station() to avoid parenthesis misalignment

2018-05-07 Thread Ajay Singh
Refactor the code to fix open parenthesis alignment issue reported by
checkpatch.pl script in del_station().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 4600f4a..7f49d60 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1997,6 +1997,7 @@ static int del_station(struct wiphy *wiphy, struct 
net_device *dev,
s32 ret = 0;
struct wilc_priv *priv;
struct wilc_vif *vif;
+   struct sta_info *info;
 
if (!wiphy)
return -EFAULT;
@@ -2004,16 +2005,17 @@ static int del_station(struct wiphy *wiphy, struct 
net_device *dev,
priv = wiphy_priv(wiphy);
vif = netdev_priv(dev);
 
-   if (vif->iftype == AP_MODE || vif->iftype == GO_MODE) {
-   if (!mac)
-   ret = wilc_del_allstation(vif,
-priv->assoc_stainfo.sta_associated_bss);
+   if (!(vif->iftype == AP_MODE || vif->iftype == GO_MODE))
+   return ret;
 
-   ret = wilc_del_station(vif, mac);
+   info = &priv->assoc_stainfo;
 
-   if (ret)
-   netdev_err(dev, "Host delete station fail\n");
-   }
+   if (!mac)
+   ret = wilc_del_allstation(vif, info->sta_associated_bss);
+
+   ret = wilc_del_station(vif, mac);
+   if (ret)
+   netdev_err(dev, "Host delete station fail\n");
return ret;
 }
 
-- 
2.7.4



[PATCH 22/30] staging: wilc1000: fix line over 80 chars issue in connect()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters in connect() by using temporary variables.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 29 +--
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index ec4fa1c..00381c9 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -676,7 +676,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
u32 sel_bssi_idx = UINT_MAX;
u8 u8security = NO_ENCRYPT;
enum AUTHTYPE auth_type = ANY;
-
+   u32 cipher_group;
struct wilc_priv *priv;
struct host_if_drv *wfi_drv;
struct network_info *nw_info = NULL;
@@ -724,32 +724,35 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
memset(priv->wep_key, 0, sizeof(priv->wep_key));
memset(priv->wep_key_len, 0, sizeof(priv->wep_key_len));
 
-   if (sme->crypto.cipher_group != NO_ENCRYPT) {
-   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_WEP40) {
+   cipher_group = sme->crypto.cipher_group;
+   if (cipher_group != NO_ENCRYPT) {
+   if (cipher_group == WLAN_CIPHER_SUITE_WEP40) {
u8security = ENCRYPT_ENABLED | WEP;
 
priv->wep_key_len[sme->key_idx] = sme->key_len;
-   memcpy(priv->wep_key[sme->key_idx], sme->key, 
sme->key_len);
+   memcpy(priv->wep_key[sme->key_idx], sme->key,
+  sme->key_len);
 
wilc_set_wep_default_keyid(vif, sme->key_idx);
wilc_add_wep_key_bss_sta(vif, sme->key, sme->key_len,
 sme->key_idx);
-   } else if (sme->crypto.cipher_group == 
WLAN_CIPHER_SUITE_WEP104)   {
+   } else if (cipher_group == WLAN_CIPHER_SUITE_WEP104) {
u8security = ENCRYPT_ENABLED | WEP | WEP_EXTENDED;
 
priv->wep_key_len[sme->key_idx] = sme->key_len;
-   memcpy(priv->wep_key[sme->key_idx], sme->key, 
sme->key_len);
+   memcpy(priv->wep_key[sme->key_idx], sme->key,
+  sme->key_len);
 
wilc_set_wep_default_keyid(vif, sme->key_idx);
wilc_add_wep_key_bss_sta(vif, sme->key, sme->key_len,
 sme->key_idx);
-   } else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_2)   {
-   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP)
+   } else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_2) {
+   if (cipher_group == WLAN_CIPHER_SUITE_TKIP)
u8security = ENCRYPT_ENABLED | WPA2 | TKIP;
else
u8security = ENCRYPT_ENABLED | WPA2 | AES;
-   } else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_1)   {
-   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP)
+   } else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_1) {
+   if (cipher_group == WLAN_CIPHER_SUITE_TKIP)
u8security = ENCRYPT_ENABLED | WPA | TKIP;
else
u8security = ENCRYPT_ENABLED | WPA | AES;
@@ -764,14 +767,16 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
if ((sme->crypto.wpa_versions & NL80211_WPA_VERSION_1) ||
(sme->crypto.wpa_versions & NL80211_WPA_VERSION_2)) {
for (i = 0; i < sme->crypto.n_ciphers_pairwise; i++) {
-   if (sme->crypto.ciphers_pairwise[i] == 
WLAN_CIPHER_SUITE_TKIP)
+   u32 ciphers_pairwise = sme->crypto.ciphers_pairwise[i];
+
+   if (ciphers_pairwise == WLAN_CIPHER_SUITE_TKIP)
u8security = u8security | TKIP;
else
u8security = u8security | AES;
}
}
 
-   switch (sme->auth_type) {
+   switch (sme->auth_type) {
case NL80211_AUTHTYPE_OPEN_SYSTEM:
auth_type = OPEN_SYSTEM;
break;
-- 
2.7.4



[PATCH 21/30] staging: wilc1000: fix line over 80 chars in scan()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issues found by checkpatch.pl script with
the help of local variable.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 20ba9cc..ec4fa1c 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -633,8 +633,11 @@ static int scan(struct wiphy *wiphy, struct 
cfg80211_scan_request *request)
 
priv->cfg_scanning = true;
if (request->n_channels <= MAX_NUM_SCANNED_NETWORKS) {
-   for (i = 0; i < request->n_channels; i++)
-   scan_ch_list[i] = 
(u8)ieee80211_frequency_to_channel(request->channels[i]->center_freq);
+   for (i = 0; i < request->n_channels; i++) {
+   u16 freq = request->channels[i]->center_freq;
+
+   scan_ch_list[i] = ieee80211_frequency_to_channel(freq);
+   }
 
if (request->n_ssids >= 1) {
if (wilc_wfi_cfg_alloc_fill_ssid(request,
-- 
2.7.4



[PATCH 20/30] staging: wilc1000: fix line over 80 characters in add_key()

2018-05-07 Thread Ajay Singh
Fix line over 80 character issue found by checkpatch.pl script in
add_key().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 3deef5b..20ba9cc 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -905,8 +905,7 @@ static int wilc_wfi_cfg_copy_wpa_info(struct wilc_wfi_key 
*key_info,
 }
 
 static int add_key(struct wiphy *wiphy, struct net_device *netdev, u8 
key_index,
-  bool pairwise,
-  const u8 *mac_addr, struct key_params *params)
+  bool pairwise, const u8 *mac_addr, struct key_params *params)
 
 {
s32 ret = 0, keylen = params->key_len;
@@ -954,6 +953,8 @@ static int add_key(struct wiphy *wiphy, struct net_device 
*netdev, u8 key_index,
case WLAN_CIPHER_SUITE_CCMP:
if (priv->wdev->iftype == NL80211_IFTYPE_AP ||
priv->wdev->iftype == NL80211_IFTYPE_P2P_GO) {
+   struct wilc_wfi_key *key;
+
ret = wilc_wfi_cfg_allocate_wpa_entry(priv, key_index);
if (ret)
return -ENOMEM;
@@ -973,21 +974,19 @@ static int add_key(struct wiphy *wiphy, struct net_device 
*netdev, u8 key_index,
 
priv->wilc_groupkey = mode;
 
-   ret = 
wilc_wfi_cfg_copy_wpa_info(priv->wilc_gtk[key_index],
-params);
-   if (ret)
-   return -ENOMEM;
+   key = priv->wilc_gtk[key_index];
} else {
if (params->cipher == WLAN_CIPHER_SUITE_TKIP)
mode = ENCRYPT_ENABLED | WPA | TKIP;
else
mode = priv->wilc_groupkey | AES;
 
-   ret = 
wilc_wfi_cfg_copy_wpa_info(priv->wilc_ptk[key_index],
-params);
-   if (ret)
-   return -ENOMEM;
+   key = priv->wilc_ptk[key_index];
}
+   ret = wilc_wfi_cfg_copy_wpa_info(key, params);
+   if (ret)
+   return -ENOMEM;
+
op_mode = AP_MODE;
} else {
if (params->key_len > 16 &&
-- 
2.7.4



Re: WARNING in kernfs_add_one

2018-05-07 Thread Johannes Berg
On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote:

> > > > syzbot found the following crash on:

Maybe it should learn to differentiate warnings, if it's going to set
panic_on_warn :-)

I get why, but still, at least differentiating in the emails wouldn't be
bad.

> > > > kernfs: ns required in 'ieee80211' for 'phy3'

Huh. What does that even mean?

> > > > RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> > > > RSP: 0018:8801ca9eece0 EFLAGS: 00010286
> > > > RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
> > > > RDX:  RSI: 81610731 RDI: 8801ca9ee840
> > > > RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
> > > > R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
> > > > R13: 885da640 R14: 0020 R15: 
> > > >  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
> > > >  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
> > > >  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
> > > >  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
> > > >  device_add_class_symlinks drivers/base/core.c:1612 [inline]
> > > >  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
> > > >  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
> > > >  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
> > > >  mac80211_hwsim_new_radio+0x1d9b/0x3410
> > > > drivers/net/wireless/mac80211_hwsim.c:2772
> > > >  hwsim_new_radio_nl+0x7a7/0xa60 
> > > > drivers/net/wireless/mac80211_hwsim.c:3246
> > > >  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599

Basically we're creating a new virtual radio, which in turn creates a
new device, which we have to register.

Something is going on with the context here that makes sysfs unhappy,
but TBH I have no idea what.

johannes


[PATCH 13/30] staging: wilc1000: rename clear_duringIP() to avoid camelCase issue

2018-05-07 Thread Ajay Singh
Rename clear_duringIP() function to avoid camelCase issue reported by
checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index d0fb31a..f1ebaea 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -269,7 +269,7 @@ static void remove_network_from_shadow(struct timer_list 
*unused)
mod_timer(&aging_timer, jiffies + msecs_to_jiffies(AGING_TIME));
 }
 
-static void clear_duringIP(struct timer_list *unused)
+static void clear_duringip(struct timer_list *unused)
 {
wilc_optaining_ip = false;
 }
@@ -2272,7 +2272,7 @@ int wilc_init_host_int(struct net_device *net)
priv = wdev_priv(net->ieee80211_ptr);
if (op_ifcs == 0) {
timer_setup(&aging_timer, remove_network_from_shadow, 0);
-   timer_setup(&wilc_during_ip_timer, clear_duringIP, 0);
+   timer_setup(&wilc_during_ip_timer, clear_duringip, 0);
}
op_ifcs++;
 
-- 
2.7.4



[PATCH 08/30] staging: wilc1000: fix line over 80 chars in host_int_parse_assoc_resp_info()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issue in host_int_parse_assoc_resp_info() by
using shorter name for the local variable.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c9c5d352..b1f67a7 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1320,18 +1320,19 @@ static inline void 
host_int_parse_assoc_resp_info(struct wilc_vif *vif,
memset(&conn_info, 0, sizeof(struct connect_info));
 
if (mac_status == MAC_STATUS_CONNECTED) {
-   u32 rcvd_assoc_resp_info_len;
+   u32 assoc_resp_info_len;
 
memset(rcv_assoc_resp, 0, MAX_ASSOC_RESP_FRAME_SIZE);
 
host_int_get_assoc_res_info(vif, rcv_assoc_resp,
MAX_ASSOC_RESP_FRAME_SIZE,
-   &rcvd_assoc_resp_info_len);
+   &assoc_resp_info_len);
 
-   if (rcvd_assoc_resp_info_len != 0) {
+   if (assoc_resp_info_len != 0) {
s32 err = 0;
 
-   err = wilc_parse_assoc_resp_info(rcv_assoc_resp, 
rcvd_assoc_resp_info_len,
+   err = wilc_parse_assoc_resp_info(rcv_assoc_resp,
+assoc_resp_info_len,
 &connect_resp_info);
if (err)
netdev_err(vif->ndev,
-- 
2.7.4



[PATCH 16/30] staging: wilc1000: fix line over 80 charas in wilc_wfi_remain_on_channel_expired()

2018-05-07 Thread Ajay Singh
Refactor wilc_wfi_remain_on_channel_expired() to avoid line over 80
character issue reported by checkpatch.pl script. Also assigned value in the
variable at the time of declaration.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index ca221f1..4f35178 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1490,18 +1490,16 @@ static void wilc_wfi_remain_on_channel_ready(void 
*priv_data)
 
 static void wilc_wfi_remain_on_channel_expired(void *data, u32 session_id)
 {
-   struct wilc_priv *priv;
+   struct wilc_priv *priv = data;
+   struct wilc_wfi_p2p_listen_params *params = &priv->remain_on_ch_params;
 
-   priv = data;
+   if (session_id != params->listen_session_id)
+   return;
 
-   if (session_id == priv->remain_on_ch_params.listen_session_id) {
-   priv->p2p_listen_state = false;
+   priv->p2p_listen_state = false;
 
-   cfg80211_remain_on_channel_expired(priv->wdev,
-  
priv->remain_on_ch_params.listen_cookie,
-  
priv->remain_on_ch_params.listen_ch,
-  GFP_KERNEL);
-   }
+   cfg80211_remain_on_channel_expired(priv->wdev, params->listen_cookie,
+  params->listen_ch, GFP_KERNEL);
 }
 
 static int remain_on_channel(struct wiphy *wiphy,
-- 
2.7.4



[PATCH 12/30] staging: wilc1000: use kmalloc(sizeof(*mgmt_tx)...) in mgmt_tx()

2018-05-07 Thread Ajay Singh
Fix below checkpatch issue found in mgmt_tx()

Prefer kmalloc(sizeof(*mgmt_tx)...) over kmalloc(sizeof(struct
p2p_mgmt_data)...)

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 102facd..d0fb31a 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1628,7 +1628,7 @@ static int mgmt_tx(struct wiphy *wiphy,
if (!ieee80211_is_mgmt(mgmt->frame_control))
goto out;
 
-   mgmt_tx = kmalloc(sizeof(struct p2p_mgmt_data), GFP_KERNEL);
+   mgmt_tx = kmalloc(sizeof(*mgmt_tx), GFP_KERNEL);
if (!mgmt_tx) {
ret = -ENOMEM;
goto out;
-- 
2.7.4



[PATCH 14/30] staging: wilc1000: fix line over 80 chars in add_network_to_shadow()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issue reported by checkpatch in
add_network_to_shadow() by using temporary variable.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 52 +++
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f1ebaea..0ae2065 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -300,6 +300,7 @@ static void add_network_to_shadow(struct network_info 
*nw_info,
int ap_found = is_network_in_shadow(nw_info, user_void);
u32 ap_index = 0;
u8 rssi_index = 0;
+   struct network_info *shadow_nw_info;
 
if (last_scanned_cnt >= MAX_NUM_SCANNED_NETWORKS_SHADOW)
return;
@@ -310,37 +311,34 @@ static void add_network_to_shadow(struct network_info 
*nw_info,
} else {
ap_index = ap_found;
}
-   rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
-   last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] = 
nw_info->rssi;
+   shadow_nw_info = &last_scanned_shadow[ap_index];
+   rssi_index = shadow_nw_info->rssi_history.index;
+   shadow_nw_info->rssi_history.samples[rssi_index++] = nw_info->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
-   last_scanned_shadow[ap_index].rssi_history.full = true;
-   }
-   last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
-   last_scanned_shadow[ap_index].rssi = nw_info->rssi;
-   last_scanned_shadow[ap_index].cap_info = nw_info->cap_info;
-   last_scanned_shadow[ap_index].ssid_len = nw_info->ssid_len;
-   memcpy(last_scanned_shadow[ap_index].ssid,
-  nw_info->ssid, nw_info->ssid_len);
-   memcpy(last_scanned_shadow[ap_index].bssid,
-  nw_info->bssid, ETH_ALEN);
-   last_scanned_shadow[ap_index].beacon_period = nw_info->beacon_period;
-   last_scanned_shadow[ap_index].dtim_period = nw_info->dtim_period;
-   last_scanned_shadow[ap_index].ch = nw_info->ch;
-   last_scanned_shadow[ap_index].ies_len = nw_info->ies_len;
-   last_scanned_shadow[ap_index].tsf_hi = nw_info->tsf_hi;
+   shadow_nw_info->rssi_history.full = true;
+   }
+   shadow_nw_info->rssi_history.index = rssi_index;
+   shadow_nw_info->rssi = nw_info->rssi;
+   shadow_nw_info->cap_info = nw_info->cap_info;
+   shadow_nw_info->ssid_len = nw_info->ssid_len;
+   memcpy(shadow_nw_info->ssid, nw_info->ssid, nw_info->ssid_len);
+   memcpy(shadow_nw_info->bssid, nw_info->bssid, ETH_ALEN);
+   shadow_nw_info->beacon_period = nw_info->beacon_period;
+   shadow_nw_info->dtim_period = nw_info->dtim_period;
+   shadow_nw_info->ch = nw_info->ch;
+   shadow_nw_info->ies_len = nw_info->ies_len;
+   shadow_nw_info->tsf_hi = nw_info->tsf_hi;
if (ap_found != -1)
-   kfree(last_scanned_shadow[ap_index].ies);
-   last_scanned_shadow[ap_index].ies = kmalloc(nw_info->ies_len,
-   GFP_KERNEL);
-   memcpy(last_scanned_shadow[ap_index].ies,
-  nw_info->ies, nw_info->ies_len);
-   last_scanned_shadow[ap_index].time_scan = jiffies;
-   last_scanned_shadow[ap_index].time_scan_cached = jiffies;
-   last_scanned_shadow[ap_index].found = 1;
+   kfree(shadow_nw_info->ies);
+   shadow_nw_info->ies = kmalloc(nw_info->ies_len, GFP_KERNEL);
+   memcpy(shadow_nw_info->ies, nw_info->ies, nw_info->ies_len);
+   shadow_nw_info->time_scan = jiffies;
+   shadow_nw_info->time_scan_cached = jiffies;
+   shadow_nw_info->found = 1;
if (ap_found != -1)
-   kfree(last_scanned_shadow[ap_index].join_params);
-   last_scanned_shadow[ap_index].join_params = join_params;
+   kfree(shadow_nw_info->join_params);
+   shadow_nw_info->join_params = join_params;
 }
 
 static void cfg_scan_result(enum scan_event scan_event,
-- 
2.7.4



[PATCH 18/30] staging: wilc1000: fix line over 80 chars in get_station()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issue in get_station().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 8dea414..3deef5b 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1124,7 +1124,9 @@ static int get_station(struct wiphy *wiphy, struct 
net_device *dev,
 
if (vif->iftype == AP_MODE || vif->iftype == GO_MODE) {
for (i = 0; i < NUM_STA_ASSOCIATED; i++) {
-   if (!(memcmp(mac, 
priv->assoc_stainfo.sta_associated_bss[i], ETH_ALEN))) {
+   if (!(memcmp(mac,
+priv->assoc_stainfo.sta_associated_bss[i],
+ETH_ALEN))) {
associatedsta = i;
break;
}
-- 
2.7.4



[PATCH 15/30] staging: wilc1000: use kmemdup instead of kmalloc in add_network_to_shadow()

2018-05-07 Thread Ajay Singh
Use kmemdup instead of kmalloc & memcpy in add_network_to_shadow().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 0ae2065..ca221f1 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -331,8 +331,8 @@ static void add_network_to_shadow(struct network_info 
*nw_info,
shadow_nw_info->tsf_hi = nw_info->tsf_hi;
if (ap_found != -1)
kfree(shadow_nw_info->ies);
-   shadow_nw_info->ies = kmalloc(nw_info->ies_len, GFP_KERNEL);
-   memcpy(shadow_nw_info->ies, nw_info->ies, nw_info->ies_len);
+   shadow_nw_info->ies = kmemdup(nw_info->ies, nw_info->ies_len,
+ GFP_KERNEL);
shadow_nw_info->time_scan = jiffies;
shadow_nw_info->time_scan_cached = jiffies;
shadow_nw_info->found = 1;
-- 
2.7.4



[PATCH 09/30] staging: wilc1000: rename kmalloc with kmemdup() in handle_connect_timeout()

2018-05-07 Thread Ajay Singh
Instead of kmalloc and memcpy use kmemdup in handle_connect_timeout().
Also return -ENOMEM incase of failure to allocate the memory.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index b1f67a7..ad9270e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1166,10 +1166,11 @@ static s32 handle_connect_timeout(struct wilc_vif *vif)
 
if (hif_drv->usr_conn_req.ies) {
info.req_ies_len = hif_drv->usr_conn_req.ies_len;
-   info.req_ies = kmalloc(hif_drv->usr_conn_req.ies_len, 
GFP_KERNEL);
-   memcpy(info.req_ies,
-  hif_drv->usr_conn_req.ies,
-  hif_drv->usr_conn_req.ies_len);
+   info.req_ies = kmemdup(hif_drv->usr_conn_req.ies,
+  hif_drv->usr_conn_req.ies_len,
+  GFP_KERNEL);
+   if (!info.req_ies)
+   return -ENOMEM;
}
 
hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_CONN_RESP,
-- 
2.7.4



[PATCH 07/30] staging: wilc1000: fix line over 80 characters in host_int_parse_join_bss_param()

2018-05-07 Thread Ajay Singh
Split host_int_parse_join_bss_param() to avoid the line over 80
character issue reported by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 247 --
 1 file changed, 131 insertions(+), 116 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0d84af9..c9c5d352 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3856,150 +3856,165 @@ int wilc_setup_multicast_filter(struct wilc_vif *vif, 
bool enabled,
return result;
 }
 
-static void *host_int_parse_join_bss_param(struct network_info *info)
+static void host_int_fill_join_bss_param(struct join_bss_param *param, u8 *ies,
+u16 *out_index, u8 *pcipher_tc,
+u8 *auth_total_cnt, u32 tsf_lo)
 {
-   struct join_bss_param *param = NULL;
-   u8 *ies;
-   u16 ies_len;
-   u16 index = 0;
u8 rates_no = 0;
u8 ext_rates_no;
u16 offset;
u8 pcipher_cnt;
u8 auth_cnt;
-   u8 pcipher_total_cnt = 0;
-   u8 auth_total_cnt = 0;
u8 i, j;
+   u16 index = *out_index;
 
-   ies = info->ies;
-   ies_len = info->ies_len;
+   if (ies[index] == SUPP_RATES_IE) {
+   rates_no = ies[index + 1];
+   param->supp_rates[0] = rates_no;
+   index += 2;
 
-   param = kzalloc(sizeof(*param), GFP_KERNEL);
-   if (!param)
-   return NULL;
+   for (i = 0; i < rates_no; i++)
+   param->supp_rates[i + 1] = ies[index + i];
 
-   param->dtim_period = info->dtim_period;
-   param->beacon_period = info->beacon_period;
-   param->cap_info = info->cap_info;
-   memcpy(param->bssid, info->bssid, 6);
-   memcpy((u8 *)param->ssid, info->ssid, info->ssid_len + 1);
-   param->ssid_len = info->ssid_len;
-   memset(param->rsn_pcip_policy, 0xFF, 3);
-   memset(param->rsn_auth_policy, 0xFF, 3);
+   index += rates_no;
+   } else if (ies[index] == EXT_SUPP_RATES_IE) {
+   ext_rates_no = ies[index + 1];
+   if (ext_rates_no > (MAX_RATES_SUPPORTED - rates_no))
+   param->supp_rates[0] = MAX_RATES_SUPPORTED;
+   else
+   param->supp_rates[0] += ext_rates_no;
+   index += 2;
+   for (i = 0; i < (param->supp_rates[0] - rates_no); i++)
+   param->supp_rates[rates_no + i + 1] = ies[index + i];
+
+   index += ext_rates_no;
+   } else if (ies[index] == HT_CAPABILITY_IE) {
+   param->ht_capable = true;
+   index += ies[index + 1] + 2;
+   } else if ((ies[index] == WMM_IE) &&
+  (ies[index + 2] == 0x00) && (ies[index + 3] == 0x50) &&
+  (ies[index + 4] == 0xF2) && (ies[index + 5] == 0x02) &&
+  ((ies[index + 6] == 0x00) || (ies[index + 6] == 0x01)) &&
+  (ies[index + 7] == 0x01)) {
+   param->wmm_cap = true;
+
+   if (ies[index + 8] & BIT(7))
+   param->uapsd_cap = true;
+   index += ies[index + 1] + 2;
+   } else if ((ies[index] == P2P_IE) &&
+(ies[index + 2] == 0x50) && (ies[index + 3] == 0x6f) &&
+(ies[index + 4] == 0x9a) &&
+(ies[index + 5] == 0x09) && (ies[index + 6] == 0x0c)) {
+   u16 p2p_cnt;
+
+   param->tsf = tsf_lo;
+   param->noa_enabled = 1;
+   param->idx = ies[index + 9];
+
+   if (ies[index + 10] & BIT(7)) {
+   param->opp_enabled = 1;
+   param->ct_window = ies[index + 10];
+   } else {
+   param->opp_enabled = 0;
+   }
 
-   while (index < ies_len) {
-   if (ies[index] == SUPP_RATES_IE) {
-   rates_no = ies[index + 1];
-   param->supp_rates[0] = rates_no;
-   index += 2;
+   param->cnt = ies[index + 11];
+   p2p_cnt = index + 12;
 
-   for (i = 0; i < rates_no; i++)
-   param->supp_rates[i + 1] = ies[index + i];
+   memcpy(param->duration, ies + p2p_cnt, 4);
+   p2p_cnt += 4;
 
-   index += rates_no;
-   } else if (ies[index] == EXT_SUPP_RATES_IE) {
-   ext_rates_no = ies[index + 1];
-   if (ext_rates_no > (MAX_RATES_SUPPORTED - rates_no))
-   param->supp_rates[0] = MAX_RATES_SUPPORTED;
-   else
-   param->supp_rates[0] += ext_rates_no;
-   index += 2;
-   for (i = 0; i < (param->supp_rate

[PATCH 17/30] staging: wilc1000: fix line over 80 chars in wilc_wfi_cfg_tx_vendor_spec()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issues reported by checkpatch.pl script in
wilc_wfi_cfg_tx_vendor_spec() by using temporary variable. Simplified
'if else' condition with 'if'.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 4f35178..8dea414 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1573,14 +1573,14 @@ static void wilc_wfi_cfg_tx_vendor_spec(struct 
p2p_mgmt_data *mgmt_tx,
for (i = P2P_PUB_ACTION_SUBTYPE + 2; i < len; i++) {
if (buf[i] == P2PELEM_ATTR_ID &&
!memcmp(p2p_oui, &buf[i + 2], 4)) {
+   bool oper_ch = false;
+   u8 *tx_buff = &mgmt_tx->buff[i + 6];
+
if (subtype == P2P_INV_REQ || subtype == P2P_INV_RSP)
-   wilc_wfi_cfg_parse_tx_action(&mgmt_tx->buff[i + 
6],
-len - (i + 6),
-true, iftype);
-   else
-   wilc_wfi_cfg_parse_tx_action(&mgmt_tx->buff[i + 
6],
-len - (i + 6),
-false, iftype);
+   oper_ch = true;
+
+   wilc_wfi_cfg_parse_tx_action(tx_buff, len - (i + 6),
+oper_ch, iftype);
 
break;
}
-- 
2.7.4



[PATCH 10/30] staging: wilc1000: fix line over 80 chars in linux_mon

2018-05-07 Thread Ajay Singh
Fix line over 80 char issue reported by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_mon.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_mon.c 
b/drivers/staging/wilc1000/linux_mon.c
index 2f4b3f5..c372e0f 100644
--- a/drivers/staging/wilc1000/linux_mon.c
+++ b/drivers/staging/wilc1000/linux_mon.c
@@ -46,18 +46,18 @@ void wilc_wfi_monitor_rx(u8 *buff, u32 size)
if (pkt_offset & IS_MANAGMEMENT_CALLBACK) {
/* hostapd callback mgmt frame */
 
-   skb = dev_alloc_skb(size + sizeof(struct 
wilc_wfi_radiotap_cb_hdr));
+   skb = dev_alloc_skb(size + sizeof(*cb_hdr));
if (!skb)
return;
 
skb_put_data(skb, buff, size);
 
cb_hdr = skb_push(skb, sizeof(*cb_hdr));
-   memset(cb_hdr, 0, sizeof(struct wilc_wfi_radiotap_cb_hdr));
+   memset(cb_hdr, 0, sizeof(*cb_hdr));
 
cb_hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
 
-   cb_hdr->hdr.it_len = cpu_to_le16(sizeof(struct 
wilc_wfi_radiotap_cb_hdr));
+   cb_hdr->hdr.it_len = cpu_to_le16(sizeof(*cb_hdr));
 
cb_hdr->hdr.it_present = cpu_to_le32(
(1 << IEEE80211_RADIOTAP_RATE) |
@@ -73,7 +73,7 @@ void wilc_wfi_monitor_rx(u8 *buff, u32 size)
}
 
} else {
-   skb = dev_alloc_skb(size + sizeof(struct 
wilc_wfi_radiotap_hdr));
+   skb = dev_alloc_skb(size + sizeof(*hdr));
 
if (!skb)
return;
@@ -82,7 +82,7 @@ void wilc_wfi_monitor_rx(u8 *buff, u32 size)
hdr = skb_push(skb, sizeof(*hdr));
memset(hdr, 0, sizeof(struct wilc_wfi_radiotap_hdr));
hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
-   hdr->hdr.it_len = cpu_to_le16(sizeof(struct 
wilc_wfi_radiotap_hdr));
+   hdr->hdr.it_len = cpu_to_le16(sizeof(*hdr));
hdr->hdr.it_present = cpu_to_le32
(1 << IEEE80211_RADIOTAP_RATE); /* | */
hdr->rate = 5; /* txrate->bitrate / 5; */
@@ -164,7 +164,7 @@ static netdev_tx_t wilc_wfi_mon_xmit(struct sk_buff *skb,
skb_pull(skb, rtap_len);
 
if (skb->data[0] == 0xc0 && is_broadcast_ether_addr(&skb->data[4])) {
-   skb2 = dev_alloc_skb(skb->len + sizeof(struct 
wilc_wfi_radiotap_cb_hdr));
+   skb2 = dev_alloc_skb(skb->len + sizeof(*cb_hdr));
if (!skb2)
return -ENOMEM;
 
@@ -175,7 +175,7 @@ static netdev_tx_t wilc_wfi_mon_xmit(struct sk_buff *skb,
 
cb_hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
 
-   cb_hdr->hdr.it_len = cpu_to_le16(sizeof(struct 
wilc_wfi_radiotap_cb_hdr));
+   cb_hdr->hdr.it_len = cpu_to_le16(sizeof(*cb_hdr));
 
cb_hdr->hdr.it_present = cpu_to_le32(
(1 << IEEE80211_RADIOTAP_RATE) |
-- 
2.7.4



[PATCH 11/30] staging: wilc1000: use sizeof(*wdev) to allocate memory in wilc_wfi_cfg_alloc()

2018-05-07 Thread Ajay Singh
Fix below reported checkpatch issues in wilc_wfi_cfg_alloc().
kzalloc(sizeof(*wdev)...) over kzalloc(sizeof(struct wireless_dev)

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 8be3c4c..102facd 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -2194,7 +2194,7 @@ static struct wireless_dev *wilc_wfi_cfg_alloc(void)
 {
struct wireless_dev *wdev;
 
-   wdev = kzalloc(sizeof(struct wireless_dev), GFP_KERNEL);
+   wdev = kzalloc(sizeof(*wdev), GFP_KERNEL);
if (!wdev)
goto _fail_;
 
-- 
2.7.4



[PATCH 03/30] staging: wilc1000: fix line over 80 chars in handle_key()

2018-05-07 Thread Ajay Singh
Fix checkpatch reported issue of line over 80 char in handle_key().
Introduced new functions by spliting existing function to address the
checkpatch issue.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 59 +++
 1 file changed, 37 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 4ba868c..29f9907 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1498,12 +1498,45 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
return result;
 }
 
+static int wilc_pmksa_key_copy(struct wilc_vif *vif, struct key_attr *hif_key)
+{
+   int i;
+   int ret;
+   struct wid wid;
+   u8 *key_buf;
+
+   key_buf = kmalloc((hif_key->attr.pmkid.numpmkid * PMKSA_KEY_LEN) + 1,
+ GFP_KERNEL);
+   if (!key_buf)
+   return -ENOMEM;
+
+   key_buf[0] = hif_key->attr.pmkid.numpmkid;
+
+   for (i = 0; i < hif_key->attr.pmkid.numpmkid; i++) {
+   memcpy(key_buf + ((PMKSA_KEY_LEN * i) + 1),
+  hif_key->attr.pmkid.pmkidlist[i].bssid, ETH_ALEN);
+   memcpy(key_buf + ((PMKSA_KEY_LEN * i) + ETH_ALEN + 1),
+  hif_key->attr.pmkid.pmkidlist[i].pmkid, PMKID_LEN);
+   }
+
+   wid.id = (u16)WID_PMKID_INFO;
+   wid.type = WID_STR;
+   wid.val = (s8 *)key_buf;
+   wid.size = (hif_key->attr.pmkid.numpmkid * PMKSA_KEY_LEN) + 1;
+
+   ret = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
+  wilc_get_vif_idx(vif));
+
+   kfree(key_buf);
+
+   return ret;
+}
+
 static int handle_key(struct wilc_vif *vif, struct key_attr *hif_key)
 {
int result = 0;
struct wid wid;
struct wid wid_list[5];
-   u8 i;
u8 *key_buf;
s8 s8idxarray[1];
struct host_if_drv *hif_drv = vif->hif_drv;
@@ -1547,7 +1580,8 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  wilc_get_vif_idx(vif));
kfree(key_buf);
} else if (hif_key->action & ADDKEY) {
-   key_buf = kmalloc(hif_key->attr.wep.key_len + 2, 
GFP_KERNEL);
+   key_buf = kmalloc(hif_key->attr.wep.key_len + 2,
+ GFP_KERNEL);
if (!key_buf) {
result = -ENOMEM;
goto out_wep;
@@ -1715,26 +1749,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
break;
 
case PMKSA:
-   key_buf = kmalloc((hif_key->attr.pmkid.numpmkid * 
PMKSA_KEY_LEN) + 1, GFP_KERNEL);
-   if (!key_buf)
-   return -ENOMEM;
-
-   key_buf[0] = hif_key->attr.pmkid.numpmkid;
-
-   for (i = 0; i < hif_key->attr.pmkid.numpmkid; i++) {
-   memcpy(key_buf + ((PMKSA_KEY_LEN * i) + 1), 
hif_key->attr.pmkid.pmkidlist[i].bssid, ETH_ALEN);
-   memcpy(key_buf + ((PMKSA_KEY_LEN * i) + ETH_ALEN + 1), 
hif_key->attr.pmkid.pmkidlist[i].pmkid, PMKID_LEN);
-   }
-
-   wid.id = (u16)WID_PMKID_INFO;
-   wid.type = WID_STR;
-   wid.val = (s8 *)key_buf;
-   wid.size = (hif_key->attr.pmkid.numpmkid * PMKSA_KEY_LEN) + 1;
-
-   result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
- wilc_get_vif_idx(vif));
-
-   kfree(key_buf);
+   result = wilc_pmksa_key_copy(vif, hif_key);
break;
}
 
-- 
2.7.4



[PATCH 05/30] staging: wilc1000: fix line over 80 chars in host_int_parse_assoc_resp_info()

2018-05-07 Thread Ajay Singh
Fix line over 80 characters issue reported by checkpatch.pl in
host_int_parse_assoc_resp_info().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 37 ++-
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 55a61d5..a341ff1 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1293,6 +1293,23 @@ static inline void host_int_free_user_conn_req(struct 
host_if_drv *hif_drv)
hif_drv->usr_conn_req.ies = NULL;
 }
 
+static void host_int_copy_conn_info(struct connect_resp_info *conn_resp_info,
+   struct connect_info *conn_info)
+{
+   conn_info->status = conn_resp_info->status;
+
+   if (conn_info->status == SUCCESSFUL_STATUSCODE && conn_resp_info->ies) {
+   conn_info->resp_ies = kmemdup(conn_resp_info->ies,
+ conn_resp_info->ies_len,
+ GFP_KERNEL);
+   if (conn_info->resp_ies)
+   conn_info->resp_ies_len = conn_resp_info->ies_len;
+   }
+
+   kfree(conn_resp_info->ies);
+   kfree(conn_resp_info);
+}
+
 static inline void host_int_parse_assoc_resp_info(struct wilc_vif *vif,
  u8 mac_status)
 {
@@ -1316,25 +1333,13 @@ static inline void 
host_int_parse_assoc_resp_info(struct wilc_vif *vif,
 
err = wilc_parse_assoc_resp_info(rcv_assoc_resp, 
rcvd_assoc_resp_info_len,
 &connect_resp_info);
-   if (err) {
+   if (err)
netdev_err(vif->ndev,
   "wilc_parse_assoc_resp_info() 
returned error %d\n",
   err);
-   } else {
-   conn_info.status = connect_resp_info->status;
-
-   if (conn_info.status == SUCCESSFUL_STATUSCODE &&
-   connect_resp_info->ies) {
-   conn_info.resp_ies = 
kmemdup(connect_resp_info->ies,
-
connect_resp_info->ies_len,
-
GFP_KERNEL);
-   if (conn_info.resp_ies)
-   conn_info.resp_ies_len = 
connect_resp_info->ies_len;
-   }
-
-   kfree(connect_resp_info->ies);
-   kfree(connect_resp_info);
-   }
+   else
+   host_int_copy_conn_info(connect_resp_info,
+   &conn_info);
}
}
 
-- 
2.7.4



[PATCH 02/30] staging: wilc1000: remove 'ret' variable in handle_key()

2018-05-07 Thread Ajay Singh
Remove the use of unnecessary 'ret' variable and use existing 'result'
variable to hold the status. Also changed type of 'result' from s32 to
int to confirm with the function return type.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index d903ae5..4ba868c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1500,13 +1500,12 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
 
 static int handle_key(struct wilc_vif *vif, struct key_attr *hif_key)
 {
-   s32 result = 0;
+   int result = 0;
struct wid wid;
struct wid wid_list[5];
u8 i;
u8 *key_buf;
s8 s8idxarray[1];
-   s8 ret = 0;
struct host_if_drv *hif_drv = vif->hif_drv;
 
switch (hif_key->type) {
@@ -1597,7 +1596,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
if (hif_key->action & ADDKEY_AP) {
key_buf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!key_buf) {
-   ret = -ENOMEM;
+   result = -ENOMEM;
goto out_wpa_rx_gtk;
}
 
@@ -1627,7 +1626,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
} else if (hif_key->action & ADDKEY) {
key_buf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!key_buf) {
-   ret = -ENOMEM;
+   result = -ENOMEM;
goto out_wpa_rx_gtk;
}
 
@@ -1657,16 +1656,13 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
complete(&hif_drv->comp_test_key_block);
kfree(hif_key->attr.wpa.key);
kfree(hif_key->attr.wpa.seq);
-   if (ret)
-   return ret;
-
break;
 
case WPA_PTK:
if (hif_key->action & ADDKEY_AP) {
key_buf = kmalloc(PTK_KEY_MSG_LEN + 1, GFP_KERNEL);
if (!key_buf) {
-   ret = -ENOMEM;
+   result = -ENOMEM;
goto out_wpa_ptk;
}
 
@@ -1693,7 +1689,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
} else if (hif_key->action & ADDKEY) {
key_buf = kmalloc(PTK_KEY_MSG_LEN, GFP_KERNEL);
if (!key_buf) {
-   ret = -ENOMEM;
+   result = -ENOMEM;
goto out_wpa_ptk;
}
 
@@ -1716,9 +1712,6 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
 out_wpa_ptk:
complete(&hif_drv->comp_test_key_block);
kfree(hif_key->attr.wpa.key);
-   if (ret)
-   return ret;
-
break;
 
case PMKSA:
-- 
2.7.4



[PATCH 01/30] staging: wilc1000: added complete() call for error scenario in handle_key()

2018-05-07 Thread Ajay Singh
During memory allocation failure in handle_key() the complete() was not
called for comp_test_key_block event. So now added the code to call
complete() for event during error scenario.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 28edd90..d903ae5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1525,8 +1525,10 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
 
key_buf = kmalloc(hif_key->attr.wep.key_len + 2,
  GFP_KERNEL);
-   if (!key_buf)
-   return -ENOMEM;
+   if (!key_buf) {
+   result = -ENOMEM;
+   goto out_wep;
+   }
 
key_buf[0] = hif_key->attr.wep.index;
key_buf[1] = hif_key->attr.wep.key_len;
@@ -1547,8 +1549,10 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
kfree(key_buf);
} else if (hif_key->action & ADDKEY) {
key_buf = kmalloc(hif_key->attr.wep.key_len + 2, 
GFP_KERNEL);
-   if (!key_buf)
-   return -ENOMEM;
+   if (!key_buf) {
+   result = -ENOMEM;
+   goto out_wep;
+   }
key_buf[0] = hif_key->attr.wep.index;
memcpy(key_buf + 1, &hif_key->attr.wep.key_len, 1);
memcpy(key_buf + 2, hif_key->attr.wep.key,
@@ -1585,6 +1589,7 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  &wid, 1,
  wilc_get_vif_idx(vif));
}
+out_wep:
complete(&hif_drv->comp_test_key_block);
break;
 
@@ -1619,7 +1624,6 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  wilc_get_vif_idx(vif));
 
kfree(key_buf);
-   complete(&hif_drv->comp_test_key_block);
} else if (hif_key->action & ADDKEY) {
key_buf = kzalloc(RX_MIC_KEY_MSG_LEN, GFP_KERNEL);
if (!key_buf) {
@@ -1648,9 +1652,9 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  wilc_get_vif_idx(vif));
 
kfree(key_buf);
-   complete(&hif_drv->comp_test_key_block);
}
 out_wpa_rx_gtk:
+   complete(&hif_drv->comp_test_key_block);
kfree(hif_key->attr.wpa.key);
kfree(hif_key->attr.wpa.seq);
if (ret)
@@ -1686,7 +1690,6 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  wid_list, 2,
  wilc_get_vif_idx(vif));
kfree(key_buf);
-   complete(&hif_drv->comp_test_key_block);
} else if (hif_key->action & ADDKEY) {
key_buf = kmalloc(PTK_KEY_MSG_LEN, GFP_KERNEL);
if (!key_buf) {
@@ -1708,10 +1711,10 @@ static int handle_key(struct wilc_vif *vif, struct 
key_attr *hif_key)
  &wid, 1,
  wilc_get_vif_idx(vif));
kfree(key_buf);
-   complete(&hif_drv->comp_test_key_block);
}
 
 out_wpa_ptk:
+   complete(&hif_drv->comp_test_key_block);
kfree(hif_key->attr.wpa.key);
if (ret)
return ret;
-- 
2.7.4



[PATCH 00/30] staging: wilc1000: checkpatch fixes and code cleanup

2018-05-07 Thread Ajay Singh
This patch series contains modification to remove checkpatch related issues,
mainly related to 'line over 80 chars'.

We are left with around '5' checkpatch warnings in WILC1000.

Also code cleanup related change to follow as per linux coding style are
included in this patch series.

Ajay Singh (30):
  staging: wilc1000: added complete() call for error scenario in
handle_key()
  staging: wilc1000: remove 'ret' variable in handle_key()
  staging: wilc1000: fix line over 80 chars in handle_key()
  staging: wilc1000: fix line over 80 characters issue in
handle_connect()
  staging: wilc1000: fix line over 80 chars in
host_int_parse_assoc_resp_info()
  staging: wilc1000: fix line over 80 chars issue in
host_int_handle_disconnect()
  staging: wilc1000: fix line over 80 characters in
host_int_parse_join_bss_param()
  staging: wilc1000: fix line over 80 chars in
host_int_parse_assoc_resp_info()
  staging: wilc1000: rename kmalloc with kmemdup() in
handle_connect_timeout()
  staging: wilc1000: fix line over 80 chars in linux_mon
  staging: wilc1000: use sizeof(*wdev) to allocate memory in
wilc_wfi_cfg_alloc()
  staging: wilc1000: use kmalloc(sizeof(*mgmt_tx)...) in mgmt_tx()
  staging: wilc1000: rename clear_duringIP() to avoid camelCase issue
  staging: wilc1000: fix line over 80 chars in add_network_to_shadow()
  staging: wilc1000: use kmemdup instead of kmalloc in
add_network_to_shadow()
  staging: wilc1000: fix line over 80 charas in
wilc_wfi_remain_on_channel_expired()
  staging: wilc1000: fix line over 80 chars in
wilc_wfi_cfg_tx_vendor_spec()
  staging: wilc1000: fix line over 80 chars in get_station()
  staging: wilc1000: fix line over 80 chars in wilc_create_wiphy()
declaration
  staging: wilc1000: fix line over 80 characters in add_key()
  staging: wilc1000: fix line over 80 chars in scan()
  staging: wilc1000: fix line over 80 chars issue in connect()
  staging: wilc1000: rename u8security to avoid datatype in variable
name
  staging: wilc1000: refactor del_station() to avoid parenthesis
misalignment
  staging: wilc1000: fix line over 80 chars in wilc_sdio struct
  staging: wilc1000: added #define for setting radiotap header
  staging: wilc1000: remove 'flag' argument from wilc_mac_indicate()
  staging: wilc1000: added comments for mutex and spinlock_t
  staging: wilc1000: remove unused 'lock' varible in 'wilc_priv'
structure
  staging: wilc1000: rename s8idxarray to avoid datatype in variable
name

 drivers/staging/wilc1000/host_interface.c | 417 --
 drivers/staging/wilc1000/host_interface.h |   2 +-
 drivers/staging/wilc1000/linux_mon.c  |  25 +-
 drivers/staging/wilc1000/linux_wlan.c |  17 +-
 drivers/staging/wilc1000/wilc_sdio.c  |   3 +-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 187 +-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.h |   3 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |   8 +-
 drivers/staging/wilc1000/wilc_wlan.c  |   7 +-
 drivers/staging/wilc1000/wilc_wlan_if.h   |   3 -
 10 files changed, 350 insertions(+), 322 deletions(-)

-- 
2.7.4



[PATCH 04/30] staging: wilc1000: fix line over 80 characters issue in handle_connect()

2018-05-07 Thread Ajay Singh
Fix line over 80 character issue found by checkpatch.pl script by
aligning the input argument in function call.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 29f9907..55a61d5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1117,10 +1117,8 @@ static s32 handle_connect(struct wilc_vif *vif,
}
 
conn_attr->result(CONN_DISCONN_EVENT_CONN_RESP,
-  &conn_info,
-  
MAC_STATUS_DISCONNECTED,
-  NULL,
-  conn_attr->arg);
+ &conn_info, MAC_STATUS_DISCONNECTED,
+ NULL, conn_attr->arg);
hif_drv->hif_state = HOST_IF_IDLE;
kfree(conn_info.req_ies);
conn_info.req_ies = NULL;
-- 
2.7.4



[PATCH 06/30] staging: wilc1000: fix line over 80 chars issue in host_int_handle_disconnect()

2018-05-07 Thread Ajay Singh
Fix line over 80 char issue in host_int_handle_disconnect() by using
temp variable to hold the 'wilc_connect_result' function pointer.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index a341ff1..0d84af9 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1401,6 +1401,7 @@ static inline void host_int_handle_disconnect(struct 
wilc_vif *vif)
 {
struct disconnect_info disconn_info;
struct host_if_drv *hif_drv = vif->hif_drv;
+   wilc_connect_result conn_result = hif_drv->usr_conn_req.conn_result;
 
memset(&disconn_info, 0, sizeof(struct disconnect_info));
 
@@ -1413,13 +1414,12 @@ static inline void host_int_handle_disconnect(struct 
wilc_vif *vif)
disconn_info.ie = NULL;
disconn_info.ie_len = 0;
 
-   if (hif_drv->usr_conn_req.conn_result) {
+   if (conn_result) {
wilc_optaining_ip = false;
wilc_set_power_mgmt(vif, 0, 0);
 
-   
hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF,
- NULL, 0, &disconn_info,
- hif_drv->usr_conn_req.arg);
+   conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF, NULL, 0,
+   &disconn_info, hif_drv->usr_conn_req.arg);
} else {
netdev_err(vif->ndev, "Connect result NULL\n");
}
-- 
2.7.4



Re: [linux-firmware] Version in WHENCE file

2018-05-07 Thread Sedat Dilek
On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho  wrote:
> On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote:
>> Hi Luca,
>>
>> I hope I catched the correct MLs (not sure if linux-firmware has a
>> ML,
>> I did not found any in the MAINTAINERS file).
>>
>> I have seen that in the WHENCE file there is "Version" with and
>> without ":", mostly iwlwifi ucodes.
>>
>> As an example:
>>
>>  File: iwlwifi-8265-36.ucode
>> -Version 36.e91976c0.0
>> +Version: 36.e91976c0.0
>>
>> I don't know the workflow: Do you want to fix it in your tree or
>> directly in linux-firmware.git upstream?
>> My attached patch is against upstream.
>
> Thanks, Sedat!
>
> I'm going to send a new pull-request this week, so I can include your
> patch in my tree and as part of the pull-request.
>
> --
> Cheers,
> Luca.

OK, Thanks.
Attached Patch v2 is against your tree [1].
It differs from v1 against upstream.

- Sedat -

[1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/
From 6e3a597632ab38619383d27a23b7369121da6d1b Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Mon, 7 May 2018 09:44:26 +0200
Subject: [PATCH] WHENCE: Fix typo Version v2

---
 WHENCE | 56 
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/WHENCE b/WHENCE
index fe63439b8cad..3678bc41a0f0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -866,10 +866,10 @@ File: iwlwifi-7260-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7260-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7260-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-3160-7.ucode
 Version: 22.1.7.0
@@ -890,10 +890,10 @@ File: iwlwifi-3160-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-3160-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-3160-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-7265-8.ucode
 Version: 22.24.8.0
@@ -911,10 +911,10 @@ File: iwlwifi-7265-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7265-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7265-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-7265D-10.ucode
 Version: 23.15.10.0
@@ -926,73 +926,73 @@ File: iwlwifi-7265D-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7265D-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7265D-17.ucode
-Version 17.352738.0
+Version: 17.352738.0
 
 File: iwlwifi-7265D-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-7265D-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-7265D-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-7265D-29.ucode
-Version 29.3e3b4de5.0
+Version: 29.3e3b4de5.0
 
 File: iwlwifi-3168-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-3168-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-3168-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-3168-29.ucode
-Version 29.3e3b4de5.0
+Version: 29.3e3b4de5.0
 
 File: iwlwifi-8000C-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-8000C-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-8000C-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-8000C-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-8000C-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-8000C-31.ucode
-Version 31.560484.0
+Version: 31.560484.0
 
 File: iwlwifi-8000C-34.ucode
-Version 34.610288.0
+Version: 34.610288.0
 
 File: iwlwifi-8000C-36.ucode
-Version 36.7596afd4.0
+Version: 36.7596afd4.0
 
 File: iwlwifi-8265-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-8265-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-8265-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-8265-31.ucode
-Version 31.560484.0
+Version: 31.560484.0
 
 File: iwlwifi-8265-34.ucode
-Version 34.610288.0
+Version: 34.610288.0
 
 File: iwlwifi-8265-36.ucode
 Version: 36.7596afd4.0
-- 
2.17.0