Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Rob Herring]

On Wed, Jun 29, 2016 at 04:04:31PM +0200, Hans de Goede wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.

What about putting its contents directly into DT? It's just text 
key/value pairs so it would match up well.

Also, I have to wonder how all the non-SDIO based cards don't need this 
file.
  
> Signed-off-by: Hans de Goede 
> ---
>  .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt  | 2 ++
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c   | 2 ++
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 
> ++
>  include/linux/platform_data/brcmfmac.h  | 2 ++
>  4 files changed, 12 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 5dbf169..2ba13a6 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -11,6 +11,7 @@ Required properties:
>  Optional properties:
>   - brcm,drive-strength : drive strength used for SDIO pins on device in mA
>   (default = 6).
> + - brcm,nvram_file_name : name of the nvram file to load

The need for firmware file names has come up several times though 
nothing merged to yet. There has been at least some level of agreement 
to use "firmware-name" here. 

>   - interrupt-parent : the phandle for the interrupt controller to which the
>   device interrupts are connected.
>   - interrupts : specifies attributes for the out-of-band interrupt 
> (host-wake).
> @@ -34,6 +35,7 @@ mmc3: mmc@01c12000 {
>   brcmf: bcrmf@1 {
>   reg = <1>;
>   compatible = "brcm,bcm4329-fmac";
> + brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
>   interrupt-parent = <>;
>   interrupts = <10 8>; /* PH10 / EINT10 */
>   interrupt-names = "host-wake";
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] cfg80211: Add mesh peer AID setting API

[Masashi Honma]

Previously, mesh power management functionality works only with kernel
MPM. Because user space MPM did not report mesh peer AID to kernel,
the kernel could not identify the bit in TIM element. So this patch
adds mesh peer AID setting API.

Signed-off-by: Masashi Honma 
---
 include/net/cfg80211.h   | 2 ++
 include/uapi/linux/nl80211.h | 5 +
 net/mac80211/cfg.c   | 1 +
 net/wireless/nl80211.c   | 7 +++
 4 files changed, 15 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7bbb00d..23e34ca 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -774,6 +774,7 @@ enum station_parameters_apply_mask {
  * (bitmask of BIT(NL80211_STA_FLAG_...))
  * @listen_interval: listen interval or -1 for no change
  * @aid: AID or zero for no change
+ * @peer_aid: mesh peer AID or zero for no change
  * @plink_action: plink action to take
  * @plink_state: set the peer link state for a station
  * @ht_capa: HT capabilities of station
@@ -805,6 +806,7 @@ struct station_parameters {
u32 sta_modify_mask;
int listen_interval;
u16 aid;
+   u16 peer_aid;
u8 supported_rates_len;
u8 plink_action;
u8 plink_state;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 53c8278..f8c454e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1829,6 +1829,9 @@ enum nl80211_commands {
  * %NL80211_ATTR_EXT_CAPA_MASK, to specify the extended capabilities per
  * interface type.
  *
+ * @NL80211_ATTR_MESH_PEER_AID: Association ID for the mesh peer (u16). This is
+ * used to pull the stored data for mesh peer in power save state.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2213,6 +2216,8 @@ enum nl80211_attrs {
 
NL80211_ATTR_IFTYPE_EXT_CAPA,
 
+   NL80211_ATTR_MESH_PEER_AID,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0c12e40..47e99ab8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -997,6 +997,7 @@ static void sta_apply_mesh_params(struct ieee80211_local 
*local,
if (sta->mesh->plink_state != NL80211_PLINK_ESTAB)
changed = mesh_plink_inc_estab_count(sdata);
sta->mesh->plink_state = params->plink_state;
+   sta->mesh->aid = params->peer_aid;
 
ieee80211_mps_sta_status_update(sta);
changed |= ieee80211_mps_set_sta_local_pm(sta,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 244d552..8337349 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4410,6 +4410,13 @@ static int nl80211_set_station(struct sk_buff *skb, 
struct genl_info *info)
nla_get_u8(info->attrs[NL80211_ATTR_STA_PLINK_STATE]);
if (params.plink_state >= NUM_NL80211_PLINK_STATES)
return -EINVAL;
+   if (info->attrs[NL80211_ATTR_MESH_PEER_AID]) {
+   if (nla_get_u16(info->attrs[NL80211_ATTR_MESH_PEER_AID])
+   > IEEE80211_MAX_AID)
+   return -EINVAL;
+   params.peer_aid = nla_get_u16(
+   info->attrs[NL80211_ATTR_MESH_PEER_AID]);
+   }
params.sta_modify_mask |= STATION_PARAM_APPLY_PLINK_STATE;
}
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[lilei]

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: mask PCIe interrupts before removal

[Brian Norris]

The PCIe driver didn't mask the host interrupts before trying to tear
down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
since the MSI handler gets confused and locks up the system.

Also tested on 8897, which does not support MSI-X (and wasn't
experiencing this same bug). No regressions seen there.

Signed-off-by: Brian Norris 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 0c7937eb6b77..af98371dc2af 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -440,6 +440,11 @@ static int mwifiex_pcie_disable_host_int(struct 
mwifiex_adapter *adapter)
return 0;
 }
 
+static void mwifiex_pcie_disable_host_int_noerr(struct mwifiex_adapter 
*adapter)
+{
+   WARN_ON(mwifiex_pcie_disable_host_int(adapter));
+}
+
 /*
  * This function enables the host interrupt.
  *
@@ -2945,6 +2950,7 @@ static struct mwifiex_if_ops pcie_ops = {
.register_dev = mwifiex_register_dev,
.unregister_dev =   mwifiex_unregister_dev,
.enable_int =   mwifiex_pcie_enable_host_int,
+   .disable_int =  mwifiex_pcie_disable_host_int_noerr,
.process_int_status =   mwifiex_process_int_status,
.host_to_card = mwifiex_pcie_host_to_card,
.wakeup =   mwifiex_pm_wakeup_card,
-- 
2.8.0.rc3.226.g39d4020

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

building brcmfmac driver for iMX6 Ultralite platform

[Michael Eskowitz]

I am trying to bring up the brcmfmac driver on an iMX6 Ultralite board.  I
have both a 43341 and 43362 Wi-Fi SDIO module up and running on this
platform already using the standard bcmdhd.  I am told by some Broadcom
folks that the brcmfmac driver should support concurrent connections which
is something the bcmdhd does not do and that is my primary motivation for
getting the fmac driver up and running.

The brcmfmac driver is included in NXP's kernel git and I have successfully
built it and have it on the Ultralite platform running kernel 3.14.38.  When
I attempt to insert the module using the command

insmod  brcmfmac.ko
firmware_path=ISM4334X_Wifi_FW_6.10.190.49_P.bin
nvram_path=ISM4334X_NVRAM_C1.txt

I receive the following errors:

brcmfmac: Unknown symbol brcmu_pktq_mlen (err 0)
brcmfmac: Unknown symbol brcmu_pkt_buf_free_skb (err 0)
brcmfmac: Unknown symbol brcmu_pktq_init (err 0)
brcmfmac: Unknown symbol brcmu_pktq_penq_head (err 0)
brcmfmac: Unknown symbol brcmu_pktq_pdeq (err 0)
brcmfmac: Unknown symbol brcmu_pktq_peek_tail (err 0)
brcmfmac: Unknown symbol brcmu_pktq_flush (err 0)
brcmfmac: Unknown symbol brcmu_pktq_pdeq_match (err 0)
brcmfmac: Unknown symbol brcmu_pktq_mdeq (err 0)
brcmfmac: Unknown symbol brcmu_pktq_penq (err 0)
brcmfmac: Unknown symbol brcmu_pktq_pdeq_tail (err 0)
brcmfmac: Unknown symbol brcmu_pkt_buf_get_skb (err 0)
brcmfmac: Unknown symbol brcmu_d11_attach (err 0)
insmod: ERROR: could not insert module brcmfmac.ko: Unknown symbol
in module

I'm not sure that the firmware_path and nvram_path should be specified in
this manner, but I doubt that is what is causing these errors.  

The module compiled and built just fine so I am assuming that there are some
dependencies that aren't being met.  Is there another module that I need to
load before attempting to load the fmac driver?

Thanks,
-Mike




--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

On Thu, Jun 30, 2016 at 11:09:31AM +, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan  writes:
> 
> > Hi Kalle,
> >
> > On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote:
> >> Kalle Valo  writes:
> >> 
> >> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
> >> >> ath10k_hw_params_list[] = {
> >> >> .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >> >> .board_size = QCA4019_BOARD_DATA_SZ,
> >> >> .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> >> +   .extd_peer_stats = true,
> >> >> },
> >> >> },
> >> >>  };
> >> >
> >> > This is not a hardware feature so hw_params is not really the right
> >> > place to handle this. In the pending branch I tried to solve this a bit
> >> > differently:
> >> >
> >> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >> >
> >> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> >> > detect if extended stats are used. Would that work? Please note that I
> >> > have only compile tested the patch.
> >
> > [shafi] thanks for taking time to do this, the change looks fine to me !
> > since 'ath10k_sta_update_rx_duration' is called right after 
> > 'ath10k_wmi_pull_fw_stats'
> > this should properly update the rx_duration based on the current data
> 
> Could you also run some tests to make sure? I don't trust my own code :)
>
[shafi] sure no problem, will do that, thanks for fixing this properly

regards,
shafi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arend Van Spriel]

On 30-6-2016 13:31, Arnd Bergmann wrote:
> On Thursday, June 30, 2016 12:25:15 PM CEST Hans de Goede wrote:
>>> So then how about making use of a more specific compatible string?
>>>
>>> e.g.
>>>
>>> brcmf {
>>> compatible = "foo,ap6210", "brcm,bcm4329-fmac";
>>> ...
>>> };
>>>
>>> and if the compatible has more than one element you request
>>> FW_NAME_.txt as the nvram file. Or try each comptible (and
>>> lastly no suffix) until you get a match. (AFAICT, this is what the
>>> "model" property was originally intended for anyway, but almost nobody
>>> did it right, and everyone put a user readable string into "model" for
>>> boards instead of the ePAPR defined compatible string).
>>
>> Hmm, interesting idea. Not sure how easy / hard it will be to implement
>> this, but from a dt binding point of view it seems elegant.
>>
>> Kalle, Arend, what do you think of this ?

At first glance I like the suggestion, but this would mean updating the
bindings document for each new wifi module that we want to add. Not a
big problem, but it makes that I have a slight preference to using a
property for it, eg. brcm,module = "ap6210";

> I think that's reasonable. Also, we have precedent for using things like
> the boardid as part of the compatible string, which would help do what
> Kalle suggested earlier with "nvram--.txt",
> as we get that for free by trying out all the compatible strings.

The suggestion from Kalle was to use the field in the nvram file, but
things are a bit more complicated. The fields are only used if it is not
stored on the device in OTP or SROM. The 43362 does not have a SROM, but
it still has a small OTP storage if I am not mistaken. The brcmfmac
exposes a revinfo file in debugfs containing boardtype and boardrev, but
that is after starting the firmware. Still worth to check if those
values match the values in the ap6210 nvram file.

Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mwifiex: add hostcmd wext ioctl support

[kbuild test robot]

Hi,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.7-rc5 next-20160630]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/mwifiex-add-hostcmd-wext-ioctl-support/20160630-231444
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: arm-exynos_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/net/wireless/marvell/mwifiex/main.c: In function 'mwifiex_do_ioctl':
   drivers/net/wireless/marvell/mwifiex/main.c:1220:20: error: 'struct 
mwifiex_adapter' has no member named 'mfg_mode'
 if (!priv->adapter->mfg_mode)
   ^
   drivers/net/wireless/marvell/mwifiex/main.c: At top level:
   drivers/net/wireless/marvell/mwifiex/main.c:1260:2: error: unknown field 
'num_private_args' specified in initializer
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
   In file included from drivers/net/wireless/marvell/mwifiex/main.h:23:0,
from drivers/net/wireless/marvell/mwifiex/main.c:20:
   include/linux/kernel.h:54:25: warning: initialization makes pointer from 
integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
   drivers/net/wireless/marvell/mwifiex/main.c:1260:22: note: in expansion of 
macro 'ARRAY_SIZE'
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
   include/linux/kernel.h:54:25: note: (near initialization for 
'mwifiex_iwpriv_handler_def.standard')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
   drivers/net/wireless/marvell/mwifiex/main.c:1260:22: note: in expansion of 
macro 'ARRAY_SIZE'
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
   drivers/net/wireless/marvell/mwifiex/main.c:1261:2: error: unknown field 
'private_args' specified in initializer
 .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
 ^
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: warning: initialization 
makes integer from pointer without a cast [-Wint-conversion]
 .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
 ^
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: note: (near 
initialization for 'mwifiex_iwpriv_handler_def.num_standard')
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: error: initializer 
element is not computable at load time
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: note: (near 
initialization for 'mwifiex_iwpriv_handler_def.num_standard')
   drivers/net/wireless/marvell/mwifiex/main.c: In function 
'mwifiex_init_priv_params':
>> drivers/net/wireless/marvell/mwifiex/main.c:1289:5: error: 'struct 
>> net_device' has no member named 'wireless_handlers'
 dev->wireless_handlers = _iwpriv_handler_def;
^

vim +1289 drivers/net/wireless/marvell/mwifiex/main.c

  1255  "hostcmd"
  1256  },
  1257  };
  1258  
  1259  static struct iw_handler_def mwifiex_iwpriv_handler_def = {
  1260  .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
> 1261  .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
  1262  };
  1263  
  1264  /*
  1265   * This function initializes the private structure parameters.
  1266   *
  1267   * The following wait queues are initialized -
  1268   *  - IOCTL wait queue
  1269   *  - Command wait queue
  1270   *  - Statistics wait queue
  1271   *
  1272   * ...and the following default parameters are set -
  1273   *  - Current key index : Set to 0
  1274   *  - Rate index: Set to auto
  1275   *  - Media connected   : Set to disconnected
  1276   *  - Adhoc link sensed : Set to false
  1277   *  - Nick name : Set to null
  1278   *  - Number of Tx timeout  : Set to 0
  1279   *  - Device address: Set to current address
  1280   *  - Rx histogram statistc : Set to 0
  1281   *
  1282   * In addition, the CFG80211 work queue is also created.
  1283   */
  1284  void mwifiex_init_priv_params(struct mwifiex_private *priv,
  1285struct net_device *dev)
  1286  {
  1287  dev->netdev_ops = _netdev_ops;
  1288  dev->destructor = free_netdev;
> 1289  dev->wireless_handlers = _iwpriv_handler_def;
  1290  /* Initialize private stru

Re: [PATCH 1/2] mwifiex: add hostcmd wext ioctl support

[kbuild test robot]

Hi,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.7-rc5 next-20160630]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/mwifiex-add-hostcmd-wext-ioctl-support/20160630-231444
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/net/wireless/marvell/mwifiex/main.c: In function 'mwifiex_do_ioctl':
   drivers/net/wireless/marvell/mwifiex/main.c:1220:20: error: 'struct 
mwifiex_adapter' has no member named 'mfg_mode'
 if (!priv->adapter->mfg_mode)
   ^
   drivers/net/wireless/marvell/mwifiex/main.c: At top level:
>> drivers/net/wireless/marvell/mwifiex/main.c:1260:2: error: unknown field 
>> 'num_private_args' specified in initializer
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
   In file included from drivers/net/wireless/marvell/mwifiex/main.h:23:0,
from drivers/net/wireless/marvell/mwifiex/main.c:20:
>> include/linux/kernel.h:54:25: warning: initialization makes pointer from 
>> integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
>> drivers/net/wireless/marvell/mwifiex/main.c:1260:22: note: in expansion of 
>> macro 'ARRAY_SIZE'
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
   include/linux/kernel.h:54:25: note: (near initialization for 
'mwifiex_iwpriv_handler_def.standard')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
>> drivers/net/wireless/marvell/mwifiex/main.c:1260:22: note: in expansion of 
>> macro 'ARRAY_SIZE'
 .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
 ^
>> drivers/net/wireless/marvell/mwifiex/main.c:1261:2: error: unknown field 
>> 'private_args' specified in initializer
 .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
 ^
>> drivers/net/wireless/marvell/mwifiex/main.c:1261:18: warning: initialization 
>> makes integer from pointer without a cast [-Wint-conversion]
 .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
 ^
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: note: (near 
initialization for 'mwifiex_iwpriv_handler_def.num_standard')
>> drivers/net/wireless/marvell/mwifiex/main.c:1261:18: error: initializer 
>> element is not computable at load time
   drivers/net/wireless/marvell/mwifiex/main.c:1261:18: note: (near 
initialization for 'mwifiex_iwpriv_handler_def.num_standard')

vim +/num_private_args +1260 drivers/net/wireless/marvell/mwifiex/main.c

  1214  static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, 
int cmd)
  1215  {
  1216  struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
  1217  struct iwreq *wrq = (struct iwreq *)req;
  1218  int ret;
  1219  
> 1220  if (!priv->adapter->mfg_mode)
  1221  return -EINVAL;
  1222  
  1223  dev_dbg(priv->adapter->dev, "ioctl cmd = 0x%x\n", cmd);
  1224  
  1225  switch (cmd) {
  1226  case MWIFIEX_HOSTCMD_IOCTL:
  1227  ret = mwifiex_process_host_command(priv, wrq);
  1228  break;
  1229  default:
  1230  ret = -EINVAL;
  1231  break;
  1232  }
  1233  
  1234  return ret;
  1235  }
  1236  
  1237  /* Network device handlers */
  1238  static const struct net_device_ops mwifiex_netdev_ops = {
  1239  .ndo_open = mwifiex_open,
  1240  .ndo_stop = mwifiex_close,
  1241  .ndo_start_xmit = mwifiex_hard_start_xmit,
  1242  .ndo_set_mac_address = mwifiex_set_mac_address,
  1243  .ndo_do_ioctl = mwifiex_do_ioctl,
  1244  .ndo_validate_addr = eth_validate_addr,
  1245  .ndo_tx_timeout = mwifiex_tx_timeout,
  1246  .ndo_get_stats = mwifiex_get_stats,
  1247  .ndo_set_rx_mode = mwifiex_set_multicast_list,
  1248  .ndo_select_queue = mwifiex_netdev_select_wmm_queue,
  1249  };
  1250  
  1251  static const struct iw_priv_args mwifiex_iwpriv_args[] = {
  1252  {   MWIFIEX_HOSTCMD_IOCTL,
  1253  IW_PRIV_TYPE_BYTE | 2047,
  1254 

[PATCH] wcn36xx: Implement print_reg indication

[Bjorn Andersson]

Some firmware versions sends a "print register indication", handle this
by printing out the content.

Cc: Nicolas Dechesne 
Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/hal.h | 16 
 drivers/net/wireless/ath/wcn36xx/smd.c | 30 ++
 2 files changed, 46 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h 
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 4f87ef1e1eb8..b765c647319d 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -350,6 +350,8 @@ enum wcn36xx_hal_host_msg_type {
 
WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
 
+   WCN36XX_HAL_PRINT_REG_INFO_IND = 259,
+
WCN36XX_HAL_MSG_MAX = WCN36XX_HAL_MSG_TYPE_MAX_ENUM_SIZE
 };
 
@@ -4703,4 +4705,18 @@ struct stats_class_b_ind {
u32 rx_time_total;
 };
 
+/* WCN36XX_HAL_PRINT_REG_INFO_IND */
+struct wcn36xx_hal_print_reg_info_ind {
+   struct wcn36xx_hal_msg_header header;
+
+   u32 count;
+   u32 scenario;
+   u32 reason;
+
+   struct {
+   u32 addr;
+   u32 value;
+   } regs[];
+} __packed;
+
 #endif /* _HAL_H_ */
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 87a62eb6228c..28d6ca0ca819 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2109,6 +2109,30 @@ static int wcn36xx_smd_delete_sta_context_ind(struct 
wcn36xx *wcn,
return -ENOENT;
 }
 
+static int wcn36xx_smd_print_reg_info_ind(struct wcn36xx *wcn,
+ void *buf,
+ size_t len)
+{
+   struct wcn36xx_hal_print_reg_info_ind *rsp = buf;
+   int i;
+
+   if (len < sizeof(*rsp)) {
+   wcn36xx_warn("Corrupted print reg info indication\n");
+   return -EIO;
+   }
+
+   wcn36xx_dbg(WCN36XX_DBG_HAL,
+   "reginfo indication, scenario: 0x%x reason: 0x%x\n",
+   rsp->scenario, rsp->reason);
+
+   for (i = 0; i < rsp->count; i++) {
+   wcn36xx_dbg(WCN36XX_DBG_HAL, "\t0x%x: 0x%x\n",
+   rsp->regs[i].addr, rsp->regs[i].value);
+   }
+
+   return 0;
+}
+
 int wcn36xx_smd_update_cfg(struct wcn36xx *wcn, u32 cfg_id, u32 value)
 {
struct wcn36xx_hal_update_cfg_req_msg msg_body, *body;
@@ -2238,6 +2262,7 @@ int wcn36xx_smd_rsp_process(struct qcom_smd_channel 
*channel,
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
+   case WCN36XX_HAL_PRINT_REG_INFO_IND:
msg_ind = kmalloc(sizeof(*msg_ind) + len, GFP_ATOMIC);
if (!msg_ind) {
/*
@@ -2300,6 +2325,11 @@ static void wcn36xx_ind_smd_work(struct work_struct 
*work)
   hal_ind_msg->msg,
   hal_ind_msg->msg_len);
break;
+   case WCN36XX_HAL_PRINT_REG_INFO_IND:
+   wcn36xx_smd_print_reg_info_ind(wcn,
+  hal_ind_msg->msg,
+  hal_ind_msg->msg_len);
+   break;
default:
wcn36xx_err("SMD_EVENT (%d) not supported\n",
  msg_header->msg_type);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] wlcore: Add support for get_expected_throughput opcode

[kbuild test robot]

Hi,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.7-rc5 next-20160630]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Maxim-Altshul/wlcore-Add-support-for-get_expected_throughput-opcode/20160630-234034
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All error/warnings (new ones prefixed by >>):

   drivers/net/wireless/ti/wlcore/main.c: In function 
'wlcore_op_get_expected_throughput':
>> drivers/net/wireless/ti/wlcore/main.c:5678:28: error: 'struct 
>> wl1271_station' has no member named 'wl'
 struct wl1271 *wl = wl_sta->wl;
   ^
>> drivers/net/wireless/ti/wlcore/main.c:5682:26: error: 'struct wl1271_link' 
>> has no member named 'fw_rate_mbps'
  return (wl->links[hlid].fw_rate_mbps * 1000);
 ^
>> drivers/net/wireless/ti/wlcore/main.c:5683:1: warning: control reaches end 
>> of non-void function [-Wreturn-type]
}
^

vim +5678 drivers/net/wireless/ti/wlcore/main.c

  5672  mutex_unlock(>mutex);
  5673  }
  5674  
  5675  static u32 wlcore_op_get_expected_throughput(struct ieee80211_sta *sta)
  5676  {
  5677  struct wl1271_station *wl_sta = (struct wl1271_station 
*)sta->drv_priv;
> 5678  struct wl1271 *wl = wl_sta->wl;
  5679  u8 hlid = wl_sta->hlid;
  5680  
  5681  /* return in units of Kbps */
> 5682  return (wl->links[hlid].fw_rate_mbps * 1000);
> 5683  }
  5684  
  5685  static bool wl1271_tx_frames_pending(struct ieee80211_hw *hw)
  5686  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] mwifiex: Change default firmware for PCIe8997 chipset

[Amitkumar Karwar]

PCIe-USB8997 variant is being used in the product. Let's change default
firmware from PCIe-UART to PCIe-USB. So by default PCIe-USB firmware would
be downloaded if version register doesn't give any information.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 12 ++--
 drivers/net/wireless/marvell/mwifiex/pcie.h |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index e15c483..2352031 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2841,20 +2841,20 @@ static void mwifiex_pcie_get_fw_name(struct 
mwifiex_adapter *adapter)
version &= 0x7;
switch (revision_id) {
case PCIE8997_V2:
-   if (version == CHIP_VER_PCIEUSB)
+   if (version == CHIP_VER_PCIEUART)
strcpy(adapter->fw_name,
-  PCIEUSB8997_FW_NAME_V2);
+  PCIEUART8997_FW_NAME_V2);
else
strcpy(adapter->fw_name,
-  PCIEUART8997_FW_NAME_V2);
+  PCIEUSB8997_FW_NAME_V2);
break;
case PCIE8997_Z:
-   if (version == CHIP_VER_PCIEUSB)
+   if (version == CHIP_VER_PCIEUART)
strcpy(adapter->fw_name,
-  PCIEUSB8997_FW_NAME_Z);
+  PCIEUART8997_FW_NAME_Z);
else
strcpy(adapter->fw_name,
-  PCIEUART8997_FW_NAME_Z);
+  PCIEUSB8997_FW_NAME_Z);
break;
default:
strcpy(adapter->fw_name, PCIE8997_DEFAULT_FW_NAME);
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 9c00c7e..f05061c 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -32,7 +32,7 @@
 #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
 #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
 #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
-#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieuart8997_combo_v2.bin"
+#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
 #define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
 #define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
 #define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
@@ -48,7 +48,7 @@
 #define PCIE8897_B00x1200
 #define PCIE8997_Z 0x0
 #define PCIE8997_V20x471
-#define CHIP_VER_PCIEUSB   0x2
+#define CHIP_VER_PCIEUART  0x3
 
 /* Constants for Buffer Descriptor (BD) rings */
 #define MWIFIEX_MAX_TXRX_BD0x20
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] nl80211: Allow GET_INTERFACE dumps to be filtered

[Denis Kenzior]

This patch allows GET_INTERFACE dumps to be filtered based on
NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV.  The documentation for
GET_INTERFACE mentions that this is possible:
"Request an interface's configuration; either a dump request on
a %NL80211_ATTR_WIPHY or ..."

However, this behavior has not been implemented until now.
---
 net/wireless/nl80211.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 244d552..24cb4d9 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2515,15 +2515,47 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 
portid, u32 seq, int flag
return -EMSGSIZE;
 }
 
+static int nl80211_dump_interface_parse(struct sk_buff *skb,
+   struct netlink_callback *cb,
+   int *filter_wiphy)
+{
+   struct nlattr **tb = nl80211_fam.attrbuf;
+   int ret = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
+ tb, nl80211_fam.maxattr, nl80211_policy);
+   /* ignore parse errors for backward compatibility */
+   if (ret)
+   return 0;
+
+   if (tb[NL80211_ATTR_WIPHY])
+   *filter_wiphy = nla_get_u32(tb[NL80211_ATTR_WIPHY]);
+   if (tb[NL80211_ATTR_WDEV])
+   *filter_wiphy = nla_get_u64(tb[NL80211_ATTR_WDEV]) >> 32;
+
+   return 0;
+}
+
 static int nl80211_dump_interface(struct sk_buff *skb, struct netlink_callback 
*cb)
 {
int wp_idx = 0;
int if_idx = 0;
int wp_start = cb->args[0];
int if_start = cb->args[1];
+   int filter_wiphy = cb->args[2];
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
 
+   if (!wp_start && !if_start && !filter_wiphy) {
+   int ret;
+
+   filter_wiphy = -1;
+
+   ret = nl80211_dump_interface_parse(skb, cb, _wiphy);
+   if (ret)
+   return ret;
+
+   cb->args[2] = filter_wiphy;
+   }
+
rtnl_lock();
list_for_each_entry(rdev, _rdev_list, list) {
if (!net_eq(wiphy_net(>wiphy), sock_net(skb->sk)))
@@ -2532,6 +2564,10 @@ static int nl80211_dump_interface(struct sk_buff *skb, 
struct netlink_callback *
wp_idx++;
continue;
}
+
+   if (filter_wiphy != -1 && filter_wiphy != rdev->wiphy_idx)
+   continue;
+
if_idx = 0;
 
list_for_each_entry(wdev, >wiphy.wdev_list, list) {
-- 
2.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] wlcore: Add support for get_expected_throughput opcode

[Maxim Altshul]

Adding this opcode, allows the TI wireless driver,
to report throughput directly from FW to mac80211.

This is used mainly for mesh metric calculation.

Signed-off-by: Maxim Altshul 
---
Removed ret and NULL test.

 drivers/net/wireless/ti/wlcore/main.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 39dec7d..237dae8c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5851,6 +5851,16 @@ out:
mutex_unlock(>mutex);
 }
 
+static u32 wlcore_op_get_expected_throughput(struct ieee80211_sta *sta)
+{
+   struct wl1271_station *wl_sta = (struct wl1271_station *)sta->drv_priv;
+   struct wl1271 *wl = wl_sta->wl;
+   u8 hlid = wl_sta->hlid;
+
+   /* return in units of Kbps */
+   return (wl->links[hlid].fw_rate_mbps * 1000);
+}
+
 static bool wl1271_tx_frames_pending(struct ieee80211_hw *hw)
 {
struct wl1271 *wl = hw->priv;
@@ -6051,6 +6061,7 @@ static const struct ieee80211_ops wl1271_ops = {
.switch_vif_chanctx = wlcore_op_switch_vif_chanctx,
.sta_rc_update = wlcore_op_sta_rc_update,
.sta_statistics = wlcore_op_sta_statistics,
+   .get_expected_throughput = wlcore_op_get_expected_throughput,
CFG80211_TESTMODE_CMD(wl1271_tm_cmd)
 };
 
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] mwifiex: manufacturing mode

[Amitkumar Karwar]

This patch series adds support for loading the driver in manufacturing
mode. It's needed to perform certain factory tests.

Amitkumar Karwar (1):
  mwifiex: add manufacturing mode support

Xinming Hu (1):
  mwifiex: add hostcmd wext ioctl support

 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 67 
 drivers/net/wireless/marvell/mwifiex/init.c   | 22 +---
 drivers/net/wireless/marvell/mwifiex/main.c   | 73 +--
 drivers/net/wireless/marvell/mwifiex/main.h   | 13 -
 drivers/net/wireless/marvell/mwifiex/pcie.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/sdio.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/usb.c|  2 +-
 7 files changed, 166 insertions(+), 15 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mac80211: mesh: Add support for HW RC implementation

[Maxim Altshul]

Mesh HWMP module will be able to rely on the HW
RC algorithm if it exists, for path metric calculations.

This allows the metric calculation mechanism to calculate
a correct metric, based on PER and last TX rate both via
HW RC algorithm if it exists or via parameters collected
by the SW.

Signed-off-by: Maxim Altshul 
---
Changed the function to return u32, I agree that this
is much clearer.
As for the rate, two things:
1. I had to divide the returned value by 100, since
drv_get_expected_throughput returns values in units of Kbps.
On the contrary, the function cfg80211_calculate_bitrate
returns in units of 100Kbps, so a correction is needed.
2. Why return the value into rate?
As I understand, rate here is actually bitrate,
and so, we have two possible outcomes:
- A SW/HW RC algo does exist, and an estimated throughput is
returned. err is set to 0 (as it is already included in the RC algo)
and the airtime is calculated using the estimated throughput.
- A SW/HW RC algo does not exist, and thus the regular calculation
takes place, in which an estimated throughput is calculated
using the bitrate and the err parameter.
>From this calculation the airtime is calculated.

 net/mac80211/mesh_hwmp.c | 25 +
 net/mac80211/sta_info.c  | 23 +++
 net/mac80211/sta_info.h  |  2 ++
 3 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index c6be0b4..ad67f46 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -322,19 +322,28 @@ static u32 airtime_link_metric_get(struct ieee80211_local 
*local,
int device_constant = 1 << ARITH_SHIFT;
int test_frame_len = TEST_FRAME_LEN << ARITH_SHIFT;
int s_unit = 1 << ARITH_SHIFT;
-   int rate, err;
+   int rate = 0, err = 0;
u32 tx_time, estimated_retx;
u64 result;
 
-   if (sta->mesh->fail_avg >= 100)
-   return MAX_METRIC;
+   /* Try to get rate based on HW/SW RC algorithm.
+* Rate is returned in units of Kbps, correct this
+* to comply with airtime calculation units
+*/
+   rate = sta_get_expected_throughput(sta) / 100;
+
+   /* if we did not get a rate */
+   if (!rate) {
+   if (sta->mesh->fail_avg >= 100)
+   return MAX_METRIC;
 
-   sta_set_rate_info_tx(sta, >tx_stats.last_rate, );
-   rate = cfg80211_calculate_bitrate();
-   if (WARN_ON(!rate))
-   return MAX_METRIC;
+   sta_set_rate_info_tx(sta, >tx_stats.last_rate, );
+   rate = cfg80211_calculate_bitrate();
+   if (WARN_ON(!rate))
+   return MAX_METRIC;
 
-   err = (sta->mesh->fail_avg << ARITH_SHIFT) / 100;
+   err = (sta->mesh->fail_avg << ARITH_SHIFT) / 100;
+   }
 
/* bitrate is in units of 100 Kbps, while we need rate in units of
 * 1Mbps. This will be corrected on tx_time computation.
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 63ea6cb..fa2c507 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2069,14 +2069,29 @@ void sta_set_sinfo(struct sta_info *sta, struct 
station_info *sinfo)
if (test_sta_flag(sta, WLAN_STA_TDLS_PEER))
sinfo->sta_flags.set |= BIT(NL80211_STA_FLAG_TDLS_PEER);
 
+   thr = sta_get_expected_throughput(sta);
+
+   if (thr != 0) {
+   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
+   sinfo->expected_throughput = thr;
+   }
+}
+
+u32 sta_get_expected_throughput(struct sta_info *sta)
+{
+   struct ieee80211_sub_if_data *sdata = sta->sdata;
+   struct ieee80211_local *local = sdata->local;
+   struct rate_control_ref *ref = NULL;
+   u32 thr = 0;
+
+   if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
+   ref = local->rate_ctrl;
+
/* check if the driver has a SW RC implementation */
if (ref && ref->ops->get_expected_throughput)
thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
else
thr = drv_get_expected_throughput(local, >sta);
 
-   if (thr != 0) {
-   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
-   sinfo->expected_throughput = thr;
-   }
+   return thr;
 }
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 2cafb21..5c9c8be 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -661,6 +661,8 @@ void sta_set_rate_info_tx(struct sta_info *sta,
  struct rate_info *rinfo);
 void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo);
 
+u32 sta_get_expected_throughput(struct sta_info *sta);
+
 void ieee80211_sta_expire(struct ieee80211_sub_if_data *sdata,
  unsigned long exp_time);
 u8 sta_info_tx_streams(struct sta_info *sta);
-- 
2.9.0

--
To unsubscribe from 

ath9k: EEPROM format / byte swapping

[Martin Blumenstingl]

Hello,

I have a question regarding the ath9k EEPROM format.
Most EEPROM versions have two magic bytes at the beginning, indicating
the endianness of the data in this EEPROM.

Let's take the AR9287 EEPROM as an example:
during ath9k initialization
ath9k/eeprom_9287.c:ath9k_hw_ar9287_check_eeprom is called, which
calls ath9k/eeprom.c:ath9k_hw_nvram_swap_data to:
a) check if a swap is required
b) perform swab16 on the EEPROM data

If a swap was required then ath9k_hw_ar9287_check_eeprom will apply
more swapping (this time selectively, based on the property it will us
swab16 or swab16).
However, it's not doing this with all data but only some!
One example (where the data is not swapped in _check_eeprom) is the
macAddr array in modal_eep_ar9287_header. It is not swapped in
ath9k_hw_ar9287_check_eeprom but read (with the values as they are) in
ath9k/eeprom_9287.c:ath9k_hw_ar9287_get_eeprom
(the same also applies for other values, such as openLoopPwrCntl, etc.)

Is there any documentation how this EEPROM data should look like,
where swapping is required, etc.?
I am trying to figure out if the current implementation of all
eeprom_ops.check_eeprom implementations is correct (or not).


Regards,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wlcore: Add support for get_expected_throughput opcode

[Johannes Berg]

On Thu, 2016-06-30 at 17:49 +0300, Maxim Altshul wrote:
> Adding this opcode, allows the TI wireless driver,
> to report throughput directly from FW to mac80211.
> 
> This is used mainly for mesh metric calculation.
> 
> Signed-off-by: Maxim Altshul 
> ---
> Changed the units of returned value.
> drv_get_expected_throughput returns units of Kbps 
> by definition, and thus we must comply as well.
> Mbps * 1000 = Kbps.
> 
>  drivers/net/wireless/ti/wlcore/main.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/net/wireless/ti/wlcore/main.c
> b/drivers/net/wireless/ti/wlcore/main.c
> index 39dec7d..cb1103b 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -5851,6 +5851,20 @@ out:
>   mutex_unlock(>mutex);
>  }
>  
> +static u32 wlcore_op_get_expected_throughput(struct ieee80211_sta
> *sta)
> +{
> + struct wl1271_station *wl_sta = (struct wl1271_station
> *)sta->drv_priv;
> + struct wl1271 *wl = wl_sta->wl;
> + u8 hlid = wl_sta->hlid;
> + u32 ret = 0;
> +
> + /* return in units of Kbps */
> + if (wl)
> + ret = (wl->links[hlid].fw_rate_mbps * 1000);
> +
I don't see how wl can ever be NULL?

Also, you can certainly remove the 'ret' variable.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] mwifiex: add hostcmd wext ioctl support

[Amitkumar Karwar]

From: Xinming Hu 

This patch adds ndo_ioctl support to mwifiex netdev handlers.
This will be used to download hostcmds to firmware from userspace.
This is needed for manufacturing mode support in mwifiex. ndo_ioctl
is allowed only when mfg mode is enabled via module load parameters.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++
 drivers/net/wireless/marvell/mwifiex/main.c   | 38 +
 drivers/net/wireless/marvell/mwifiex/main.h   |  9 +++-
 3 files changed, 105 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..fcfe556 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -818,6 +818,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+   adapter->hostcmd_resp_data.len = size;
+   memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1200,6 +1202,63 @@ mwifiex_process_hs_config(struct mwifiex_adapter 
*adapter)
   false);
 }
 EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+   * to be download to FW.
+  */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+struct iwreq *wrq)
+{
+   struct mwifiex_ds_misc_cmd *hostcmd_buf;
+   struct host_cmd_ds_command *cmd;
+   struct mwifiex_adapter *adapter = priv->adapter;
+   int ret;
+
+   hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+   if (!hostcmd_buf)
+   return -ENOMEM;
+
+   cmd = (void *)hostcmd_buf->cmd;
+
+   if (copy_from_user(cmd, wrq->u.data.pointer,
+  sizeof(cmd->command) + sizeof(cmd->size))) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   hostcmd_buf->len = le16_to_cpu(cmd->size);
+   if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+   ret = -EINVAL;
+   goto done;
+   }
+
+   if (copy_from_user(cmd, wrq->u.data.pointer, hostcmd_buf->len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+   dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+   ret = -EFBIG;
+   goto done;
+   }
+
+   if (copy_to_user(wrq->u.data.pointer, adapter->hostcmd_resp_data.cmd,
+adapter->hostcmd_resp_data.len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+   wrq->u.data.length = adapter->hostcmd_resp_data.len;
+
+   ret = 0;
+done:
+   kfree(hostcmd_buf);
+   return ret;
+}
 
 /*
  * This function handles the command response of a sleep confirm command.
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 0e280f8..8b06d1d 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1211,17 +1211,54 @@ mwifiex_netdev_select_wmm_queue(struct net_device *dev, 
struct sk_buff *skb,
return mwifiex_1d_to_wmm_queue[skb->priority];
 }
 
+static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
+{
+   struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+   struct iwreq *wrq = (struct iwreq *)req;
+   int ret;
+
+   if (!priv->adapter->mfg_mode)
+   return -EINVAL;
+
+   dev_dbg(priv->adapter->dev, "ioctl cmd = 0x%x\n", cmd);
+
+   switch (cmd) {
+   case MWIFIEX_HOSTCMD_IOCTL:
+   ret = mwifiex_process_host_command(priv, wrq);
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+
+   return ret;
+}
+
 /* Network device handlers */
 static const struct net_device_ops mwifiex_netdev_ops = {
.ndo_open = mwifiex_open,
.ndo_stop = mwifiex_close,
.ndo_start_xmit = mwifiex_hard_start_xmit,
.ndo_set_mac_address = mwifiex_set_mac_address,
+   .ndo_do_ioctl = mwifiex_do_ioctl,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = mwifiex_tx_timeout,
.ndo_get_stats = mwifiex_get_stats,
.ndo_set_rx_mode = mwifiex_set_multicast_list,
.ndo_select_queue = mwifiex_netdev_select_wmm_queue,
+   };
+
+static const 

[PATCH 2/2] mwifiex: add manufacturing mode support

[Amitkumar Karwar]

By default normal mode is chosen when driver is loaded. This patch adds
a provision to choose manufacturing mode via module parameters.

Command to load driver in manufacturing mode
insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.

Tested-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c |  8 ++
 drivers/net/wireless/marvell/mwifiex/init.c   | 22 +++--
 drivers/net/wireless/marvell/mwifiex/main.c   | 35 ---
 drivers/net/wireless/marvell/mwifiex/main.h   |  4 +++
 drivers/net/wireless/marvell/mwifiex/pcie.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/sdio.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/usb.c|  2 +-
 7 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index fcfe556..d961305 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -581,6 +581,14 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
return -1;
}
}
+   /* We don't expect commands in manufacturing mode. They are cooked
+* in application and ready to download buffer is passed to the driver
+   */
+   if (adapter->mfg_mode && cmd_no) {
+   dev_dbg(adapter->dev, "Ignoring commands in manufacturing 
mode\n");
+   return -1;
+   }
+
 
/* Get a new command node */
cmd_node = mwifiex_get_cmd_node(adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 1489c90..82839d9 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -298,6 +298,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter 
*adapter)
memset(>arp_filter, 0, sizeof(adapter->arp_filter));
adapter->arp_filter_size = 0;
adapter->max_mgmt_ie_index = MAX_MGMT_IE_INDEX;
+   adapter->mfg_mode = mfg_mode;
adapter->key_api_major_ver = 0;
adapter->key_api_minor_ver = 0;
eth_broadcast_addr(adapter->perm_addr);
@@ -553,15 +554,22 @@ int mwifiex_init_fw(struct mwifiex_adapter *adapter)
return -1;
}
}
+   if (adapter->mfg_mode) {
+   adapter->hw_status = MWIFIEX_HW_STATUS_READY;
+   ret = -EINPROGRESS;
+   } else {
+   for (i = 0; i < adapter->priv_num; i++) {
+   if (adapter->priv[i]) {
+   ret = mwifiex_sta_init_cmd(adapter->priv[i],
+  first_sta, true);
+   if (ret == -1)
+   return -1;
+
+   first_sta = false;
+   }
+
 
-   for (i = 0; i < adapter->priv_num; i++) {
-   if (adapter->priv[i]) {
-   ret = mwifiex_sta_init_cmd(adapter->priv[i], first_sta,
-  true);
-   if (ret == -1)
-   return -1;
 
-   first_sta = false;
}
}
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 8b06d1d..e3e1fe9 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -36,6 +36,14 @@ static unsigned short driver_mode;
 module_param(driver_mode, ushort, 0);
 MODULE_PARM_DESC(driver_mode,
 "station=0x1(default), ap-sta=0x3, station-p2p=0x5, 
ap-sta-p2p=0x7");
+bool mfg_mode;
+module_param(mfg_mode, bool, 0);
+MODULE_PARM_DESC(mfg_mode, "0:disable 1:enable (bool)");
+
+char *mfg_firmware = "";
+module_param(mfg_firmware, charp, 0);
+MODULE_PARM_DESC(mfg_firmware, "firmware path");
+
 
 /*
  * This function registers the device and performs all the necessary
@@ -559,10 +567,12 @@ static void mwifiex_fw_dpc(const struct firmware 
*firmware, void *context)
goto done;
}
/* Wait for mwifiex_init to complete */
-   wait_event_interruptible(adapter->init_wait_q,
-adapter->init_wait_q_woken);
-   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
-   goto err_init_fw;
+   if (!adapter->mfg_mode) {
+   wait_event_interruptible(adapter->init_wait_q,
+adapter->init_wait_q_woken);
+   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
+   goto err_init_fw;
+   }
 
priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
if (mwifiex_register_cfg80211(adapter)) {
@@ -666,6 +676,23 @@ static int mwifiex_init_hw_fw(struct 

Re: [PATCHV2 1/3] ath10k: move firmware_swap_code_seg_info to ath10k_fw_file

[Valo, Kalle]

 writes:

> From: Tamizh chelvam 
>
> Preparation to make use of firmware_swap_code_seg_info for
> UTF binary.
>
> Signed-off-by: Tamizh chelvam 

This patchset crashes my x86 laptop once I start hostapd. Unfortunately
I can't provide any logs as I don't have netconsole set up yet, but this
is the board I'm using:

[   58.481559] ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[   58.633122] ath10k_pci :02:00.0: qca988x hw2.0 target 0x4100016c chip_id 
0x043202ff sub :
[   58.633126] ath10k_pci :02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 
0 testmode 1
[   58.633318] ath10k_pci :02:00.0: firmware ver 10.2.4.70.52 api 5 
features no-p2p,raw-mode,mfp crc32 67c4d25c
[   58.690098] ath10k_pci :02:00.0: board_file api 1 bmi_id N/A crc32 
bebc7c08
[   59.950554] ath10k_pci :02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp 
max-sta 128 raw 0 hwcrypto 1

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Add mesh peer AID setting API

[Masashi Honma]

On 2016年06月30日 20:11, Bob Copeland wrote:

Let's call it peer_aid or mesh_peer_aid or something like that, per my
email on hostapd list.  Also you probably saw kbuild robot pointed out
missing documentation for the field.

Yes. I will modify this also.


We need a check against IEEE80211_MAX_AID somewhere.

Sure. I will add a check.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHV2 3/3] ath10k: add testmode support for 10.4 firmware

[Valo, Kalle]

 writes:

> From: Tamizh chelvam 
>
> This patch adds testmode support for QCA99X0 chipsets which uses
> 10.4 firmware and added code swap support for UTF binary.
>
> Signed-off-by: Tamizh chelvam 

There were few checkpatch warnings, I fixed them in the pending branch:

$ ath10k-check 
drivers/net/wireless/ath/ath10k/testmode.c:247: Alignment should match open 
parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:250: Alignment should match open 
parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:298: Alignment should match open 
parenthesis
drivers/net/wireless/ath/ath10k/testmode.c:325: Alignment should match open 
parenthesis

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Arnd Bergmann]

On Thursday, June 30, 2016 12:25:15 PM CEST Hans de Goede wrote:
> > So then how about making use of a more specific compatible string?
> >
> > e.g.
> >
> > brcmf {
> > compatible = "foo,ap6210", "brcm,bcm4329-fmac";
> > ...
> > };
> >
> > and if the compatible has more than one element you request
> > FW_NAME_.txt as the nvram file. Or try each comptible (and
> > lastly no suffix) until you get a match. (AFAICT, this is what the
> > "model" property was originally intended for anyway, but almost nobody
> > did it right, and everyone put a user readable string into "model" for
> > boards instead of the ePAPR defined compatible string).
> 
> Hmm, interesting idea. Not sure how easy / hard it will be to implement
> this, but from a dt binding point of view it seems elegant.
> 
> Kalle, Arend, what do you think of this ?

I think that's reasonable. Also, we have precedent for using things like
the boardid as part of the compatible string, which would help do what
Kalle suggested earlier with "nvram--.txt",
as we get that for free by trying out all the compatible strings.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ath10k: remove unused

[Valo, Kalle]

Sergei Shtylyov  writes:

> On 6/21/2016 2:45 PM, Chaehyun Lim wrote:
>
>>  is not used anymore, so just remove it.
>
>s/it/#include/?

Fixed that in the pending branch.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k: Fix programming of minCCA power threshold

[Kalle Valo]

Sven Eckelmann  wrote:
> The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not
> a pointer to the channel but a boolean value describing whether the channel
> is 2.4GHz or not. This broke (according to the origin commit) the ETSI
> regulatory compliance on 5GHz channels.
> 
> Fixes: 3533bf6b15a0 ("ath9k: Fix regulatory compliance")
> Signed-off-by: Sven Eckelmann 
> Cc: Simon Wunderlich 
> Cc: Sujith Manoharan 

Thanks, 1 patch applied to ath-next branch of ath.git:

aaab50fcea78 ath9k: Fix programming of minCCA power threshold

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9183173/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k: return false when reading wrong eeprom offset

[Kalle Valo]

Eduardo Abinader  wrote:
> Just setting the proper return for reading beyond the eeprom data.
> 
> Signed-off-by: Eduardo Abinader 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to ath-next branch of ath.git:

0f27ac40fb64 ath9k: return false when reading wrong eeprom offset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9181371/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Add mesh peer AID setting API

[Bob Copeland]

On Thu, Jun 30, 2016 at 06:00:58PM +0900, Masashi Honma wrote:
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 7bbb00d..2fa5896 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -805,6 +805,7 @@ struct station_parameters {
>   u32 sta_modify_mask;
>   int listen_interval;
>   u16 aid;
> + u16 mesh_aid;

Let's call it peer_aid or mesh_peer_aid or something like that, per my
email on hostapd list.  Also you probably saw kbuild robot pointed out
missing documentation for the field.

> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index c503e96..f41fb61 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -4410,6 +4410,9 @@ static int nl80211_set_station(struct sk_buff *skb, 
> struct genl_info *info)
>   nla_get_u8(info->attrs[NL80211_ATTR_STA_PLINK_STATE]);
>   if (params.plink_state >= NUM_NL80211_PLINK_STATES)
>   return -EINVAL;
> + if (info->attrs[NL80211_ATTR_MESH_PEER_AID])
> + params.mesh_aid = nla_get_u16(
> + info->attrs[NL80211_ATTR_MESH_PEER_AID]);

We need a check against IEEE80211_MAX_AID somewhere.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Valo, Kalle]

Mohammed Shafi Shajakhan  writes:

> Hi Kalle,
>
> On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote:
>> Kalle Valo  writes:
>> 
>> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
>> >> ath10k_hw_params_list[] = {
>> >>   .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>> >>   .board_size = QCA4019_BOARD_DATA_SZ,
>> >>   .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
>> >> + .extd_peer_stats = true,
>> >>   },
>> >>   },
>> >>  };
>> >
>> > This is not a hardware feature so hw_params is not really the right
>> > place to handle this. In the pending branch I tried to solve this a bit
>> > differently:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
>> >
>> > I added a bool "extended" to struct ath10k_fw_stats which is used to
>> > detect if extended stats are used. Would that work? Please note that I
>> > have only compile tested the patch.
>
> [shafi] thanks for taking time to do this, the change looks fine to me !
> since 'ath10k_sta_update_rx_duration' is called right after 
> 'ath10k_wmi_pull_fw_stats'
> this should properly update the rx_duration based on the current data

Could you also run some tests to make sure? I don't trust my own code :)

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] ath10k: Fix some typo in spectral code commments

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Found this obvious typo while going through the spectral
> code design in ath10k
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

3fa35bacc16a ath10k: fix some typo in spectral code commments

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9181333/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: Disable TX_STBC for tx chainmask of 1

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1'
> TX_STBC is required only for devices with tx_chainmask > 1. This fixes
> a ping failure for QCA9887 (1x1) in HT/VHT mode
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

34663241d81f ath10k: disable TX_STBC for tx chainmask of 1

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180781/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Mohammed Shafi Shajakhan]

Hi Kalle,

On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote:
> Kalle Valo  writes:
> 
> >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
> >> ath10k_hw_params_list[] = {
> >>.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
> >>.board_size = QCA4019_BOARD_DATA_SZ,
> >>.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> >> +  .extd_peer_stats = true,
> >>},
> >>},
> >>  };
> >
> > This is not a hardware feature so hw_params is not really the right
> > place to handle this. In the pending branch I tried to solve this a bit
> > differently:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
> >
> > I added a bool "extended" to struct ath10k_fw_stats which is used to
> > detect if extended stats are used. Would that work? Please note that I
> > have only compile tested the patch.

[shafi] thanks for taking time to do this, the change looks fine to me !
since 'ath10k_sta_update_rx_duration' is called right after 
'ath10k_wmi_pull_fw_stats'
this should properly update the rx_duration based on the current data

> 
> Here's a diff of what I did:
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 58932c09efc5..b734345ab598 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -180,7 +180,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -203,7 +202,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA9984_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -261,7 +259,6 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA4019_BOARD_DATA_SZ,
>   .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> - .extd_peer_stats = true,
>   },
>   },
>  };
> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> b/drivers/net/wireless/ath/ath10k/core.h
> index 73a0b1ae1559..3707d8a707a2 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -263,6 +263,7 @@ struct ath10k_fw_stats_pdev {
>  };
>  
>  struct ath10k_fw_stats {
> + bool extended;
>   struct list_head pdevs;
>   struct list_head vdevs;
>   struct list_head peers;
> @@ -754,7 +755,6 @@ struct ath10k {
>   const char *board;
>   size_t board_size;
>   size_t board_ext_size;
> - bool extd_peer_stats;
>   } fw;
>   } hw_params;
>  
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 001c0a144614..355e1ae665f9 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -327,6 +327,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
>  {
>   spin_lock_bh(>data_lock);
>   ar->debug.fw_stats_done = false;
> + ar->debug.fw_stats.extended = false;
>   ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
>   ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
>   ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
> diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c 
> b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> index af3d49af9eab..0da8a57e0ba7 100644
> --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> @@ -19,14 +19,14 @@
>  #include "debug.h"
>  
>  static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
> -  struct list_head *head)
> +  struct ath10k_fw_stats 
> *stats)
>  {
> - struct ieee80211_sta *sta;
>   struct ath10k_fw_extd_stats_peer *peer;
> + struct ieee80211_sta *sta;
>   struct ath10k_sta *arsta;
>  
>   rcu_read_lock();
> - list_for_each_entry(peer, head, list) {
> + list_for_each_entry(peer, >peers_extd, list) {
>   sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
>  NULL);
>   if (!sta)
> @@ -38,13 +38,14 @@ static void 
> 

Re: ath10k: Enable beacon loss detection support for 10.4

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Enable beacon loss detection support for 10.4 by handling
> roam event. With this change QCA99X0 station is able to
> detect beacon loss when the AP is powered off
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

343bf960f03c ath10k: enable beacon loss detection support for 10.4

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9180777/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] ath10k: Fix crash during card removal

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Usually when the firmware crashes we check for the value
> 'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
> disabling the irq and dumping firmware 'crash dump'. Now
> when the PCI card is unplugged from the device the PCI controller
> seems to generate a spurious interrupt after some time which
> was as treated a firmware crash and resulting in the below race
> condition (and eventually crashing the system)
> 
>   ath10k_core_unregister -> ath10k_core_free_board_files
> 
>   .. device unplug spurious interrupt .
> 
>   ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump  ...etc
> 
> Clearly even after the firmware board files related data structure
> is freed up we are getting a spurious interrupt from PCI with 0xfff
> in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
> and doing a crash dump, printing f/w board related info resulting in the
> below crash. Fix this by detecting this spurious interrupt in ath10k PCI
> irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
> helping us conclude the most appropriate fix.
> 
> Call trace:
> 
>  EIP is at ath10k_debug_print_board_info+0x39/0xb0
> [ath10k_core]
> EAX:  EBX: d4de15a0 ECX:  EDX: 0064
> ESI: f615ddd0 EDI: f853 EBP: f615de3c ESP: f615ddbc
>  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> CR0: 80050033 CR2: 0004 CR3: 01c0a000 CR4: 06f0
> Stack:
>  f615ddd0 0064 f8b4ecdd   00412f4e
>  
>      
>  
>       
>  
> Call Trace:
>   [] ath10k_print_driver_info+0x17/0x30
> [ath10k_core]
> [] ath10k_pci_fw_crashed_dump+0x7a/0xe0
> [ath10k_pci]
> [] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
> [] tasklet_action+0x9e/0xb0
> 
> Cc: Michal Kazior 
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

fb7caababc02 ath10k: fix crash during card removal

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9167045/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: fix potential null dereference bugs

[Kalle Valo]

Bob Copeland  wrote:
> Smatch warns about a number of cases in ath10k where a pointer is
> null-checked after it has already been dereferenced, in code involving
> ath10k private virtual interface pointers.
> 
> Fix these by making the dereference happen later.
> 
> Addresses the following smatch warnings:
> 
> drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: 
> variable dereferenced before check 'txq' (see line 3649)
> drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: 
> variable dereferenced before check 'txq' (see line 3659)
> drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() 
> warn: variable dereferenced before check 'txq->sta' (see line 52)
> drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() 
> warn: variable dereferenced before check 'cb->vif' (see line 736)
> drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: 
> variable dereferenced before check 'txq' (see line 84)
> drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: 
> variable dereferenced before check 'cb->vif' (see line 1825)
> 
> Signed-off-by: Bob Copeland 

Thanks, 1 patch applied to ath-next branch of ath.git:

a66cd733a729 ath10k: fix potential null dereference bugs

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9169669/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> The below warning message seems to hit occasionally with the following
> combination (IPQ4019 + ACS scan) where we receive packets as a self peer
> when hostapd does ACS when we bring up AP mode . ath10k has the below
> fall back mechanism to fetch current operating channel in rx (it will
> check for the next channel tracking variable if the current one is NULL)
> 
>   [scan channel] --> [rx channel] --> [peer channel] -->
>   [vdev channel] -->  [any vdev channel] --> [target oper channel]
> 
> 'scan channel' and 'target operating channel' are directly fetched from
> firmware events. All the others should be updated by mac80211.
> 
> During ACS scan we wouldn't have a valid channel context
> assigned from mac80211 ('ar->rx_channel'), and also relying on
> ('ar->scan_channel') is not helpful (it becomes NULL when it goes to
> BSS channel and also when the scan event is completed). In short we
> cannot always rely on these two channel tracking variables.
> 
> 'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
> the current operating even while we are doing ACS scan and etc. Hence
> remove this un-necessary warning message and continue with
> target_operating channel. At the worst case scenario when the target
> operating channel is invalid (NULL) we already have an ath10k warning
> message to notify we really don't have a proper channel configured in
> rx to update the rx status("no channel configured; ignoring frame(s)!")
> 
> WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
> [] (warn_slowpath_null) from []
> (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
> [] (ath10k_htt_rx_h_channel [ath10k_core]) from
> [] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
> [] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
> [] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
> [] (ath10k_htt_txrx_compl_task [ath10k_core])
> 
> Fixes:3b0499e9ce42 ("ath10k: reduce warning messages during rx without proper 
> channel context")
> Signed-off-by: Mohammed Shafi Shajakhan 

Thanks, 1 patch applied to ath-next branch of ath.git:

569fba2cbb6d ath10k: remove unneccessary WARN_ON_ONCE in rx during ACS

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9167049/

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Valo, Kalle]

Kalle Valo  writes:

>> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
>> ath10k_hw_params_list[] = {
>>  .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>>  .board_size = QCA4019_BOARD_DATA_SZ,
>>  .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
>> +.extd_peer_stats = true,
>>  },
>>  },
>>  };
>
> This is not a hardware feature so hw_params is not really the right
> place to handle this. In the pending branch I tried to solve this a bit
> differently:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96
>
> I added a bool "extended" to struct ath10k_fw_stats which is used to
> detect if extended stats are used. Would that work? Please note that I
> have only compile tested the patch.

Here's a diff of what I did:

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 58932c09efc5..b734345ab598 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -180,7 +180,6 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
-   .extd_peer_stats = true,
},
},
{
@@ -203,7 +202,6 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
-   .extd_peer_stats = true,
},
},
{
@@ -261,7 +259,6 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
-   .extd_peer_stats = true,
},
},
 };
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 73a0b1ae1559..3707d8a707a2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -263,6 +263,7 @@ struct ath10k_fw_stats_pdev {
 };
 
 struct ath10k_fw_stats {
+   bool extended;
struct list_head pdevs;
struct list_head vdevs;
struct list_head peers;
@@ -754,7 +755,6 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
-   bool extd_peer_stats;
} fw;
} hw_params;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 001c0a144614..355e1ae665f9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -327,6 +327,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
 {
spin_lock_bh(>data_lock);
ar->debug.fw_stats_done = false;
+   ar->debug.fw_stats.extended = false;
ath10k_fw_stats_pdevs_free(>debug.fw_stats.pdevs);
ath10k_fw_stats_vdevs_free(>debug.fw_stats.vdevs);
ath10k_fw_stats_peers_free(>debug.fw_stats.peers);
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c 
b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index af3d49af9eab..0da8a57e0ba7 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -19,14 +19,14 @@
 #include "debug.h"
 
 static void ath10k_sta_update_extd_stats_rx_duration(struct ath10k *ar,
-struct list_head *head)
+struct ath10k_fw_stats 
*stats)
 {
-   struct ieee80211_sta *sta;
struct ath10k_fw_extd_stats_peer *peer;
+   struct ieee80211_sta *sta;
struct ath10k_sta *arsta;
 
rcu_read_lock();
-   list_for_each_entry(peer, head, list) {
+   list_for_each_entry(peer, >peers_extd, list) {
sta = ieee80211_find_sta_by_ifaddr(ar->hw, peer->peer_macaddr,
   NULL);
if (!sta)
@@ -38,13 +38,14 @@ static void ath10k_sta_update_extd_stats_rx_duration(struct 
ath10k *ar,
 }
 
 static void ath10k_sta_update_stats_rx_duration(struct ath10k *ar,
-   struct list_head *head)
-{  struct ieee80211_sta *sta;
+   struct ath10k_fw_stats *stats)
+{
struct ath10k_fw_stats_peer *peer;
+   struct ieee80211_sta *sta;
struct ath10k_sta *arsta;
 

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

[Valo, Kalle]

Mohammed Shafi Shajakhan  writes:

> From: Mohammed Shafi Shajakhan 
>
> 10.4 'extended peer stats' will be not be appended with normal peer stats
> data and they shall be coming in separate chunks. Fix this by maintaining
> a separate linked list 'extender peer stats' for 10.4 and update
> rx_duration for per station statistics. Also parse through beacon filter
> (if enabled), to make sure we parse the extended peer stats properly.
> This issue was exposed when more than one client is connected and
> extended peer stats for 10.4 is enabled
>
> The order for the stats is as below
> S - standard peer stats, E- extended peer stats, B - beacon filter stats
>
> {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
>
> Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 
> 10.4")
> Signed-off-by: Mohammed Shafi Shajakhan 
> ---
> [v1: addressed line wrap around comment from Kalle]
> [v2: fixed ; in dummy inline function definition - thanks Sven Eckelmann]
> [v3: removed wmi-op-version suggested by Kalle, introduced fw specifi hw 
> param for extd_stats]

I was sure I replied to this, but I can't find my reply anywhere. So I
guess I didn't, sorry about that.

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> + .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -203,6 +204,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA9984_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA99X0_BOARD_DATA_SZ,
>   .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
> + .extd_peer_stats = true,
>   },
>   },
>   {
> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params 
> ath10k_hw_params_list[] = {
>   .board = QCA4019_HW_1_0_BOARD_DATA_FILE,
>   .board_size = QCA4019_BOARD_DATA_SZ,
>   .board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
> + .extd_peer_stats = true,
>   },
>   },
>  };

This is not a hardware feature so hw_params is not really the right
place to handle this. In the pending branch I tried to solve this a bit
differently:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=ecf4daadc7677518ec7185dbddab959ac6e2db96

I added a bool "extended" to struct ath10k_fw_stats which is used to
detect if extended stats are used. Would that work? Please note that I
have only compile tested the patch.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Jonas Gorski]

Hi,

On 30 June 2016 at 12:04, Hans de Goede  wrote:
> Hi,
>
>
> On 30-06-16 11:58, Kalle Valo wrote:
>>
>> Hans de Goede  writes:
>>
>>> Hi,
>>>
>>> On 30-06-16 11:02, Kalle Valo wrote:

 Priit Laes  writes:

>> What is the size of this nvram file? As it's board specific, I wonder
>> if we can simply include it inside of the DT verbatim. I remember
>> doing that (in the pre-dtb days, on real open firmware) for the
>> "spidernet"
>> ethernet driver.
>
>
> It contains a bit too much info:
>
> This is what CubieTruck requires:
>
>
> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt


 In the nvram file I see lots of identifiers:

 manfid=0x2d0
 prodid=0x492
 vendid=0x14e4
 devid=0x4343
 boardtype=0x0598
 boardrev=0x1307
 boardnum=777

 Are any of these (or a combination of them) unique for each board type?
 What if one of these is provided through DT and then the driver could
 choose the nvram file based on the board id? Just another idea...
>>>
>>>
>>> That would require updating a table in the driver every time a new
>>> board comes out, I do not believe that that is a good solution.
>>
>>
>> You don't necessarily need to have a table in the driver if you embed
>> the id to the filename, for example something like this:
>>
>> nvram-0598-1307.txt
>> nvram--.txt
>
>
> Downside of this is, that as Arend already said, the nvram files are not
> readily available.
>
> Typically the boards we are talking about are shipped with android,
> and the mainline kernel bringup is done by a user, not the manufacturer.
>
> So the nvram file needs to be extracted from e.g. an android image,
> having ap6210 in the filename allows the user to see that his module
> (which is clearly labelled ap6210 is already supported, where as the
> boardtype/boardrev magic numbers are a big unknown.
>
> So I believe that using a human readable string is better here.

So then how about making use of a more specific compatible string?

e.g.

brcmf {
compatible = "foo,ap6210", "brcm,bcm4329-fmac";
...
};

and if the compatible has more than one element you request
FW_NAME_.txt as the nvram file. Or try each comptible (and
lastly no suffix) until you get a match. (AFAICT, this is what the
"model" property was originally intended for anyway, but almost nobody
did it right, and everyone put a user readable string into "model" for
boards instead of the ePAPR defined compatible string).


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 30-06-16 12:18, Jonas Gorski wrote:

Hi,

On 30 June 2016 at 12:04, Hans de Goede  wrote:

Hi,


On 30-06-16 11:58, Kalle Valo wrote:


Hans de Goede  writes:


Hi,

On 30-06-16 11:02, Kalle Valo wrote:


Priit Laes  writes:


What is the size of this nvram file? As it's board specific, I wonder
if we can simply include it inside of the DT verbatim. I remember
doing that (in the pre-dtb days, on real open firmware) for the
"spidernet"
ethernet driver.



It contains a bit too much info:

This is what CubieTruck requires:


http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt



In the nvram file I see lots of identifiers:

manfid=0x2d0
prodid=0x492
vendid=0x14e4
devid=0x4343
boardtype=0x0598
boardrev=0x1307
boardnum=777

Are any of these (or a combination of them) unique for each board type?
What if one of these is provided through DT and then the driver could
choose the nvram file based on the board id? Just another idea...



That would require updating a table in the driver every time a new
board comes out, I do not believe that that is a good solution.



You don't necessarily need to have a table in the driver if you embed
the id to the filename, for example something like this:

nvram-0598-1307.txt
nvram--.txt



Downside of this is, that as Arend already said, the nvram files are not
readily available.

Typically the boards we are talking about are shipped with android,
and the mainline kernel bringup is done by a user, not the manufacturer.

So the nvram file needs to be extracted from e.g. an android image,
having ap6210 in the filename allows the user to see that his module
(which is clearly labelled ap6210 is already supported, where as the
boardtype/boardrev magic numbers are a big unknown.

So I believe that using a human readable string is better here.


So then how about making use of a more specific compatible string?

e.g.

brcmf {
compatible = "foo,ap6210", "brcm,bcm4329-fmac";
...
};

and if the compatible has more than one element you request
FW_NAME_.txt as the nvram file. Or try each comptible (and
lastly no suffix) until you get a match. (AFAICT, this is what the
"model" property was originally intended for anyway, but almost nobody
did it right, and everyone put a user readable string into "model" for
boards instead of the ePAPR defined compatible string).


Hmm, interesting idea. Not sure how easy / hard it will be to implement
this, but from a dt binding point of view it seems elegant.

Kalle, Arend, what do you think of this ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Valo, Kalle]

Ben Greear  writes:

> Is there a better way than posting to the ath10k mailing list?  There are 
> quite
> a few more of my patches that are stuck in pending or ignored state.  If you
> could review some of them and add them to your testing trees then it might 
> help
> them go upstream.

Yes, as you seem to test with your custom ath10k and custom firmware
review and testing feedback from others is more than welcome. That way I
can have more confidence that the patch really works with the mainline
version.

The problem with your patches is that you dump more responsibility on
me. I have no idea if they work with the mainline kernel, or if they
break something, so I need to personally test the patch and that takes
time. Basically I have a rule if that I need to use more than two
minutes on a patch it goes to the Deferred queue and I'll go through
that less often than the normal patch queue.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix fq lockdep warnings

[Johannes Berg]

On Wed, 2016-06-29 at 14:00 +0200, Michal Kazior wrote:
> Some lockdep assertions were not fulfilled and
> resulted in a kernel warning/call trace if driver
> used intermediate software queues (e.g. ath10k).
> 
> Existing code sequences should've guranteed safety
> but it's always good to be extra careful.
> 
Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: use common cleanup for user/!user_mpm

[Johannes Berg]

On Sat, 2016-06-25 at 19:14 -0400, Bob Copeland wrote:
> We've accumulated a couple of different fixes now to
> mesh_sta_cleanup()
> due to the different paths that user_mpm and !user_mpm cases take --
> one
> fix to flush nexthop paths and one to fix the counting.
> 
> The only caller of mesh_plink_deactivate() is mesh_sta_cleanup(), so
> we
> can push the user_mpm checks down into there in order to share more
> code.
> 
> In doing so, we can remove an extra call to
> mesh_path_flush_by_nexthop()
> and the (unnecessary) call to mesh_accept_plinks_update().  This will
> also ensure the powersaving state code gets called in the user_mpm
> case.
> 
> The only cleanup tasks we need to avoid when MPM is in user-space
> are sending the peering frames and stopping the plink timer, so wrap
> those in the appropriate check.
> 
> Signed-off-by: Bob Copeland 
> ---
> 
> This applies on top of Jouni's patch,
> "mac80211: Fix mesh estab_plinks counting in STA removal case", so
> this can go for -next.
> 
Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Kalle Valo]

Hans de Goede  writes:

> Hi,
>
> On 30-06-16 11:02, Kalle Valo wrote:
>> Priit Laes  writes:
>>
 What is the size of this nvram file? As it's board specific, I wonder
 if we can simply include it inside of the DT verbatim. I remember
 doing that (in the pre-dtb days, on real open firmware) for the
 "spidernet"
 ethernet driver.
>>>
>>> It contains a bit too much info:
>>>
>>> This is what CubieTruck requires:
>>>
>>> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt
>>
>> In the nvram file I see lots of identifiers:
>>
>> manfid=0x2d0
>> prodid=0x492
>> vendid=0x14e4
>> devid=0x4343
>> boardtype=0x0598
>> boardrev=0x1307
>> boardnum=777
>>
>> Are any of these (or a combination of them) unique for each board type?
>> What if one of these is provided through DT and then the driver could
>> choose the nvram file based on the board id? Just another idea...
>
> That would require updating a table in the driver every time a new
> board comes out, I do not believe that that is a good solution.

You don't necessarily need to have a table in the driver if you embed
the id to the filename, for example something like this:

nvram-0598-1307.txt
nvram--.txt

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 30-06-16 11:58, Kalle Valo wrote:

Hans de Goede  writes:


Hi,

On 30-06-16 11:02, Kalle Valo wrote:

Priit Laes  writes:


What is the size of this nvram file? As it's board specific, I wonder
if we can simply include it inside of the DT verbatim. I remember
doing that (in the pre-dtb days, on real open firmware) for the
"spidernet"
ethernet driver.


It contains a bit too much info:

This is what CubieTruck requires:

http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt


In the nvram file I see lots of identifiers:

manfid=0x2d0
prodid=0x492
vendid=0x14e4
devid=0x4343
boardtype=0x0598
boardrev=0x1307
boardnum=777

Are any of these (or a combination of them) unique for each board type?
What if one of these is provided through DT and then the driver could
choose the nvram file based on the board id? Just another idea...


That would require updating a table in the driver every time a new
board comes out, I do not believe that that is a good solution.


You don't necessarily need to have a table in the driver if you embed
the id to the filename, for example something like this:

nvram-0598-1307.txt
nvram--.txt


Downside of this is, that as Arend already said, the nvram files are not
readily available.

Typically the boards we are talking about are shipped with android,
and the mainline kernel bringup is done by a user, not the manufacturer.

So the nvram file needs to be extracted from e.g. an android image,
having ap6210 in the filename allows the user to see that his module
(which is clearly labelled ap6210 is already supported, where as the
boardtype/boardrev magic numbers are a big unknown.

So I believe that using a human readable string is better here.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Add mesh peer AID setting API

[kbuild test robot]

Hi,

[auto build test WARNING on mac80211-next/master]
[also build test WARNING on next-20160629]
[cannot apply to v4.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Masashi-Honma/cfg80211-Add-mesh-peer-AID-setting-API/20160630-171005
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'
>> include/net/cfg80211.h:827: warning: No description found for parameter 
>> 'mesh_aid'

vim +/mesh_aid +827 include/net/cfg80211.h

9c3990aa Javier Cardona   2011-05-03  811   u8 plink_state;
2c1aabf3 Johannes Berg2013-02-14  812   const struct ieee80211_ht_cap 
*ht_capa;
2c1aabf3 Johannes Berg2013-02-14  813   const struct ieee80211_vht_cap 
*vht_capa;
c75786c9 Eliad Peller 2011-08-23  814   u8 uapsd_queues;
c75786c9 Eliad Peller 2011-08-23  815   u8 max_sp;
3b1c5a53 Marco Porsch 2013-01-07  816   enum nl80211_mesh_power_mode 
local_pm;
9d62a986 Jouni Malinen2013-02-14  817   u16 capability;
2c1aabf3 Johannes Berg2013-02-14  818   const u8 *ext_capab;
9d62a986 Jouni Malinen2013-02-14  819   u8 ext_capab_len;
c01fc9ad Sunil Dutt   2013-10-09  820   const u8 *supported_channels;
c01fc9ad Sunil Dutt   2013-10-09  821   u8 supported_channels_len;
c01fc9ad Sunil Dutt   2013-10-09  822   const u8 
*supported_oper_classes;
c01fc9ad Sunil Dutt   2013-10-09  823   u8 supported_oper_classes_len;
60f4a7b1 Marek Kwaczynski 2013-12-03  824   u8 opmode_notif;
60f4a7b1 Marek Kwaczynski 2013-12-03  825   bool opmode_notif_used;
17b94247 Ayala Beker  2016-03-17  826   int support_p2p_ps;
5727ef1b Johannes Berg2007-12-19 @827  };
5727ef1b Johannes Berg2007-12-19  828  
fd5b74dc Johannes Berg2007-12-19  829  /**
89c771e5 Jouni Malinen2014-10-10  830   * struct station_del_parameters - 
station deletion parameters
89c771e5 Jouni Malinen2014-10-10  831   *
89c771e5 Jouni Malinen2014-10-10  832   * Used to delete a station entry 
(or all stations).
89c771e5 Jouni Malinen2014-10-10  833   *
89c771e5 Jouni Malinen2014-10-10  834   * @mac: MAC address of the station 
to remove or NULL to remove all stations
98856866 Jouni Malinen2014-10-20  835   * @subtype: Management frame 
subtype to use for indicating removal

:: The code at line 827 was first introduced by commit
:: 5727ef1b2e797a1922f5bc239b6afb2b4cfb80bc cfg80211/nl80211: station 
handling

:: TO: Johannes Berg <johan...@sipsolutions.net>
:: CC: David S. Miller <da...@davemloft.net>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 29-06-16 20:51, 'Arend Van Spriel' via linux-sunxi wrote:

On 29-6-2016 20:01, Hans de Goede wrote:

Hi,

On 29-06-16 19:00, Kalle Valo wrote:

Hans de Goede  writes:


Hi,

On 29-06-16 16:42, Jonas Gorski wrote:

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.


Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


It only defines the base-filename, not the entire path, how / where
this file is searched for / loaded-from is then left up to the os


It's still a bad idea. The filename, including the path, should be
created in the driver. Can't you provide chipname (or similar) via
device tree and then the driver can choose what image to use?


No, the driver already does that, but this is not ...


Can you tell more about the naming the firmware image, how does it work
exactly?


About firmware, this is about the nvram file which is board specific,
rather then chip specific.


The nvram filename is determined pretty much the same as the firmware
filename, but indeed the nvram data is board specific. This is main
reason why we do not submit nvram files to linux-firmware, because we
simply do not have those files.


Typical wifi devices will have some sort of non volatile storage
on board to not only store the ethernet(mac) address, but also
to contain e.g. info about the antenna gain so that the firmware
and/or the driver can take the antenna gain into account and ensure
that they never exceed the maximum allowed broadcast strength.

However on some embedded devices there is no non-volatile storage
for the wifi (for cost reasons) and instead this configuration info
(which is board / pcb specific) is loaded in the form of a
file which contains the contents which would normally be in the
non-volatile storage.

Since we are dealing with a per-board config-file here, which is
loaded from the os filesystem we really need to specify a basename
here as the list of possible boards is endless, so we cannot
have a lookup table in the driver.


As Jonas mentioned the general principle of device tree is to be
agnostic with regards to OS and/or driver as you undoubtedly know. His
proposal seems like a usable solution for your problem while complying
to the device tree principle. So instead of overriding the default
brcmfmac should modify it when dt specifies the "module" property, ie:

no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt
"module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt


Yes that seems like a good solution, I will send a v2 implementing this.


By the way, the example in the bindings file does not seem to specify a
basename, but path+basename+fileext.


fileext is always part of a file basename, but you're right that it
does include a relative path because of the way the existing firmware
files are organized under /lib/firmware under Linux and yes I'll admit
that that is a bit os specific :)

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 30-06-16 11:02, Kalle Valo wrote:

Priit Laes  writes:


What is the size of this nvram file? As it's board specific, I wonder
if we can simply include it inside of the DT verbatim. I remember
doing that (in the pre-dtb days, on real open firmware) for the
"spidernet"
ethernet driver.


It contains a bit too much info:

This is what CubieTruck requires:

http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt


In the nvram file I see lots of identifiers:

manfid=0x2d0
prodid=0x492
vendid=0x14e4
devid=0x4343
boardtype=0x0598
boardrev=0x1307
boardnum=777

Are any of these (or a combination of them) unique for each board type?
What if one of these is provided through DT and then the driver could
choose the nvram file based on the board id? Just another idea...


That would require updating a table in the driver every time a new
board comes out, I do not believe that that is a good solution.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Hans de Goede]

Hi,

On 30-06-16 10:46, Kalle Valo wrote:

Arend Van Spriel  writes:


Since we are dealing with a per-board config-file here, which is
loaded from the os filesystem we really need to specify a basename
here as the list of possible boards is endless, so we cannot
have a lookup table in the driver.


As Jonas mentioned the general principle of device tree is to be
agnostic with regards to OS and/or driver as you undoubtedly know. His
proposal seems like a usable solution for your problem while complying
to the device tree principle. So instead of overriding the default
brcmfmac should modify it when dt specifies the "module" property, ie:

no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt
"module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt


Just out of curiosity, what does "ap6210" exactly mean? I get that 43362
is the chip id, but not ap6210. Is it just an arbitrary name?


It is more or less an arbitrary name, typically these sdio wifi chips
are used as a pre-assembled module (a tiny pcb) with some things like
the necessary crystal / resonator and various capacitors and resistors
on there. The brcm based sdio wifi modules typically come with a metal
shield cap which has a module type stamped on it, e.g. ap6210,
ap6476, toc9002.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Prasun Maiti]

On Thu, Jun 30, 2016 at 1:05 PM, Amitkumar Karwar  wrote:
> Hi Prasun,
>
>> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
>> Sent: Friday, June 24, 2016 12:27 PM
>> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
>> Cc: Linux Wireless; Linux Next; Linux Kernel
>> Subject: Re: [PATCH] mwifiex: Fixed endianness for event TLV type
>> TLV_BTCOEX_WL_SCANTIME
>>
>> On Thu, Jun 16, 2016 at 9:49 AM, Prasun Maiti 
>> wrote:
>> > The two members min_scan_time and max_scan_time of structure
>> > "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
>> > are assigned directtly from firmware without endian conversion
>> handling.
>> > So, wrong datas will get saved in big-endian systems.
>> >
>> > This patch converts the values into cpu's byte order before assigning
>> > them into the local members.
>> >
>> > Signed-off-by: Prasun Maiti 
>> > ---
>> >  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c
>> > b/drivers/net/wireless/marvell/mwifiex/sta_event.c
>> > index 0104108..7dff452 100644
>> > --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
>> > +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
>> > @@ -474,8 +474,8 @@ void
>> mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
>> > scantlv =
>> > (struct mwifiex_ie_types_btcoex_scan_time
>> *)tlv;
>> > adapter->coex_scan = scantlv->coex_scan;
>> > -   adapter->coex_min_scan_time = scantlv-
>> >min_scan_time;
>> > -   adapter->coex_max_scan_time = scantlv-
>> >max_scan_time;
>> > +   adapter->coex_min_scan_time =
>> le16_to_cpu(scantlv->min_scan_time);
>> > +   adapter->coex_max_scan_time =
>> > + le16_to_cpu(scantlv->max_scan_time);
>> > break;
>> >
>> > default:
>> > --
>> > 1.9.1
>> >
>
> Along with this change, you need to define these elements as __le16 in 
> scan_tlv structure. Ensure that sparse compilation is passed with your final 
> patch.
>

Hi Amitkumar,

Thanks for your suggestion.
I have added this in scan_tlv structure to fix the sparse compilation
warnings. Updated patch v2 is sent.
Please verify this.

-- 
Thanks,
Prasun
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Kalle Valo]

Priit Laes  writes:

>> What is the size of this nvram file? As it's board specific, I wonder
>> if we can simply include it inside of the DT verbatim. I remember
>> doing that (in the pre-dtb days, on real open firmware) for the
>> "spidernet"
>> ethernet driver.
>
> It contains a bit too much info:
>
> This is what CubieTruck requires:
>
> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt

In the nvram file I see lots of identifiers:

manfid=0x2d0
prodid=0x492
vendid=0x14e4
devid=0x4343
boardtype=0x0598
boardrev=0x1307
boardnum=777

Are any of these (or a combination of them) unique for each board type?
What if one of these is provided through DT and then the driver could
choose the nvram file based on the board id? Just another idea...

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Kalle Valo]

Arend Van Spriel  writes:

>>> Typical wifi devices will have some sort of non volatile storage
>>> on board to not only store the ethernet(mac) address, but also
>>> to contain e.g. info about the antenna gain so that the firmware
>>> and/or the driver can take the antenna gain into account and ensure
>>> that they never exceed the maximum allowed broadcast strength.
>>>
>>> However on some embedded devices there is no non-volatile storage
>>> for the wifi (for cost reasons) and instead this configuration info
>>> (which is board / pcb specific) is loaded in the form of a
>>> file which contains the contents which would normally be in the
>>> non-volatile storage.
>>>
>>> Since we are dealing with a per-board config-file here, which is
>>> loaded from the os filesystem we really need to specify a basename
>>> here as the list of possible boards is endless, so we cannot
>>> have a lookup table in the driver.
>
> As a note: For BT Marcel was playing with the idea of having a lookup
> table on the file system which would be loaded by the driver.

In ath10k we have a similar problem but in our case we can use the
subsystem id to detect what board file to use, so it's not exactly same
as yours. In our board-2.bin we have identifiers like this from which
ath10k selects the correct board file:

bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=334e
bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3360
bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3361

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cfg80211: Add mesh peer AID setting API

[Masashi Honma]

Previously, mesh peer AID is not reported to kernel when local mesh
STA is created without iw command. The mesh peer AID is needed by
mesh peer power management functionality to identify a AID in a TIM
element.

This patch creates mesh peer AID setting API.

Signed-off-by: Masashi Honma 
---
 include/net/cfg80211.h   | 1 +
 include/uapi/linux/nl80211.h | 5 +
 net/mac80211/cfg.c   | 1 +
 net/wireless/nl80211.c   | 3 +++
 4 files changed, 10 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7bbb00d..2fa5896 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -805,6 +805,7 @@ struct station_parameters {
u32 sta_modify_mask;
int listen_interval;
u16 aid;
+   u16 mesh_aid;
u8 supported_rates_len;
u8 plink_action;
u8 plink_state;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 53c8278..f8c454e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1829,6 +1829,9 @@ enum nl80211_commands {
  * %NL80211_ATTR_EXT_CAPA_MASK, to specify the extended capabilities per
  * interface type.
  *
+ * @NL80211_ATTR_MESH_PEER_AID: Association ID for the mesh peer (u16). This is
+ * used to pull the stored data for mesh peer in power save state.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2213,6 +2216,8 @@ enum nl80211_attrs {
 
NL80211_ATTR_IFTYPE_EXT_CAPA,
 
+   NL80211_ATTR_MESH_PEER_AID,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0c12e40..08802f7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -997,6 +997,7 @@ static void sta_apply_mesh_params(struct ieee80211_local 
*local,
if (sta->mesh->plink_state != NL80211_PLINK_ESTAB)
changed = mesh_plink_inc_estab_count(sdata);
sta->mesh->plink_state = params->plink_state;
+   sta->mesh->aid = params->mesh_aid;
 
ieee80211_mps_sta_status_update(sta);
changed |= ieee80211_mps_set_sta_local_pm(sta,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c503e96..f41fb61 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4410,6 +4410,9 @@ static int nl80211_set_station(struct sk_buff *skb, 
struct genl_info *info)
nla_get_u8(info->attrs[NL80211_ATTR_STA_PLINK_STATE]);
if (params.plink_state >= NUM_NL80211_PLINK_STATES)
return -EINVAL;
+   if (info->attrs[NL80211_ATTR_MESH_PEER_AID])
+   params.mesh_aid = nla_get_u16(
+   info->attrs[NL80211_ATTR_MESH_PEER_AID]);
params.sta_modify_mask |= STATION_PARAM_APPLY_PLINK_STATE;
}
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> -Original Message-
> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Thursday, June 30, 2016 2:01 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v2] mwifiex: Fix endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> The two members min_scan_time and max_scan_time of structure
> "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> are assigned directtly from firmware without endian conversion handling.
> So, wrong datas will get saved in big-endian systems.
> 
> This patch converts the values into cpu's byte order before assigning
> them into the local members.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v2:
>   - Fixed the following sparse compilation warnings:
>   * sta_event.c:477:55: warning: cast to restricted __le16
>   * sta_event.c:478:55: warning: cast to restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/fw.h| 4 ++--
>  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index 8e4145a..03d3edf 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -1958,8 +1958,8 @@ struct mwifiex_ie_types_btcoex_scan_time {
>   struct mwifiex_ie_types_header header;
>   u8 coex_scan;
>   u8 reserved;
> - u16 min_scan_time;
> - u16 max_scan_time;
> + __le16 min_scan_time;
> + __le16 max_scan_time;
>  } __packed;
> 
>  struct mwifiex_ie_types_btcoex_aggr_win_size { diff --git
> a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> index 0104108..7dff452 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> @@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct
> mwifiex_private *priv,
>   scantlv =
>   (struct mwifiex_ie_types_btcoex_scan_time *)tlv;
>   adapter->coex_scan = scantlv->coex_scan;
> - adapter->coex_min_scan_time = scantlv->min_scan_time;
> - adapter->coex_max_scan_time = scantlv->max_scan_time;
> + adapter->coex_min_scan_time = le16_to_cpu(scantlv-
> >min_scan_time);
> + adapter->coex_max_scan_time = le16_to_cpu(scantlv-
> >max_scan_time);
>   break;
> 
>   default:
> --
> 1.9.1

Updated change looks fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

[Kalle Valo]

Arend Van Spriel  writes:

>> Since we are dealing with a per-board config-file here, which is
>> loaded from the os filesystem we really need to specify a basename
>> here as the list of possible boards is endless, so we cannot
>> have a lookup table in the driver.
>
> As Jonas mentioned the general principle of device tree is to be
> agnostic with regards to OS and/or driver as you undoubtedly know. His
> proposal seems like a usable solution for your problem while complying
> to the device tree principle. So instead of overriding the default
> brcmfmac should modify it when dt specifies the "module" property, ie:
>
> no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt
> "module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt

Just out of curiosity, what does "ap6210" exactly mean? I get that 43362
is the chip id, but not ap6210. Is it just an arbitrary name?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Prasun Maiti]

On Thu, Jun 30, 2016 at 2:07 PM, Amitkumar Karwar  wrote:
> Hi Prasun,
> Updated change looks fine to me.
>
> Acked-by: Amitkumar Karwar 
>
> Regards,
> Amitkumar

Hi AmitKumar,

Thanks for your verification.

-- 
Thanks,
Prasun
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Prasun Maiti]

The two members min_scan_time and max_scan_time of structure
"mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
are assigned directtly from firmware without endian conversion handling.
So, wrong datas will get saved in big-endian systems.

This patch converts the values into cpu's byte order before assigning them
into the local members.

Signed-off-by: Prasun Maiti 
---
Changes in v2:
- Fixed the following sparse compilation warnings:
* sta_event.c:477:55: warning: cast to restricted __le16
* sta_event.c:478:55: warning: cast to restricted __le16

 drivers/net/wireless/marvell/mwifiex/fw.h| 4 ++--
 drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index 8e4145a..03d3edf 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -1958,8 +1958,8 @@ struct mwifiex_ie_types_btcoex_scan_time {
struct mwifiex_ie_types_header header;
u8 coex_scan;
u8 reserved;
-   u16 min_scan_time;
-   u16 max_scan_time;
+   __le16 min_scan_time;
+   __le16 max_scan_time;
 } __packed;

 struct mwifiex_ie_types_btcoex_aggr_win_size {
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c 
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 0104108..7dff452 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct 
mwifiex_private *priv,
scantlv =
(struct mwifiex_ie_types_btcoex_scan_time *)tlv;
adapter->coex_scan = scantlv->coex_scan;
-   adapter->coex_min_scan_time = scantlv->min_scan_time;
-   adapter->coex_max_scan_time = scantlv->max_scan_time;
+   adapter->coex_min_scan_time = 
le16_to_cpu(scantlv->min_scan_time);
+   adapter->coex_max_scan_time = 
le16_to_cpu(scantlv->max_scan_time);
break;

default:
--
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 24, 2016 12:27 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Linux Wireless; Linux Next; Linux Kernel
> Subject: Re: [PATCH] mwifiex: Fixed endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> On Thu, Jun 16, 2016 at 9:49 AM, Prasun Maiti 
> wrote:
> > The two members min_scan_time and max_scan_time of structure
> > "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> > are assigned directtly from firmware without endian conversion
> handling.
> > So, wrong datas will get saved in big-endian systems.
> >
> > This patch converts the values into cpu's byte order before assigning
> > them into the local members.
> >
> > Signed-off-by: Prasun Maiti 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > index 0104108..7dff452 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > @@ -474,8 +474,8 @@ void
> mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
> > scantlv =
> > (struct mwifiex_ie_types_btcoex_scan_time
> *)tlv;
> > adapter->coex_scan = scantlv->coex_scan;
> > -   adapter->coex_min_scan_time = scantlv-
> >min_scan_time;
> > -   adapter->coex_max_scan_time = scantlv-
> >max_scan_time;
> > +   adapter->coex_min_scan_time =
> le16_to_cpu(scantlv->min_scan_time);
> > +   adapter->coex_max_scan_time =
> > + le16_to_cpu(scantlv->max_scan_time);
> > break;
> >
> > default:
> > --
> > 1.9.1
> >

Along with this change, you need to define these elements as __le16 in scan_tlv 
structure. Ensure that sparse compilation is passed with your final patch.

Regards,
Amitkumar