* [PATCH v2 0/3] Mesh mpm fixes and enhancements
From: Yaniv Machani @ 2016-07-13 11:44 UTC (permalink / raw)
To: linux-kernel; +Cc: johannes, netdev, linux-wireless, Yaniv Machani
This patch set is addressing some issues found in the current 802.11s implementation, specifically when using hostap mpm.
It's aligning the beacon format and handling some corner cases.
V2 - Updated patches following review comments.
- Remove unneccary patches (already upsteamed)
Maital Hahn (1):
mac80211: mesh: flush stations before beacons are stopped
Yaniv Machani (2):
mac80211: mesh: improve path resolving time
mac80211: mesh: fixed HT ies in beacon template
net/mac80211/mesh.c | 43 ++++++++++++++++++++++++++++++++++++++-----
net/mac80211/mesh_hwmp.c | 42 +++++++++++++++++++++++++-----------------
net/mac80211/util.c | 3 ---
3 files changed, 63 insertions(+), 25 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH v2 2/2] mwifiex: add hostcmd wext ioctl support
From: Amitkumar Karwar @ 2016-07-13 11:19 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1468408746-28376-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
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 <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
Changes in v2:
1) Sequence of these two patches are changed to resolve compilation
error seen if only 1/2 is applied.
2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
kbuild test robot.
---
drivers/net/wireless/marvell/mwifiex/Kconfig | 3 ++
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++++++++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.c | 38 +++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.h | 9 +++-
4 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/Kconfig b/drivers/net/wireless/marvell/mwifiex/Kconfig
index 279167d..5b1d52a 100644
--- a/drivers/net/wireless/marvell/mwifiex/Kconfig
+++ b/drivers/net/wireless/marvell/mwifiex/Kconfig
@@ -13,6 +13,7 @@ config MWIFIEX_SDIO
depends on MWIFIEX && MMC
select FW_LOADER
select WANT_DEV_COREDUMP
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8786/8787/8797/8887/8897/8997 chipsets with SDIO interface.
@@ -25,6 +26,7 @@ config MWIFIEX_PCIE
depends on MWIFIEX && PCI
select FW_LOADER
select WANT_DEV_COREDUMP
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8766/8897/8997 chipsets with PCIe interface.
@@ -36,6 +38,7 @@ config MWIFIEX_USB
tristate "Marvell WiFi-Ex Driver for USB8766/8797/8997"
depends on MWIFIEX && USB
select FW_LOADER
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8797/8997 chipset with USB interface.
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8d57493..d961305 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -826,6 +826,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);
@@ -1208,6 +1210,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 b54edf4..e3e1fe9 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1238,17 +1238,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 struct iw_priv_args mwifiex_iwpriv_args[] = {
+ { MWIFIEX_HOSTCMD_IOCTL,
+ IW_PRIV_TYPE_BYTE | 2047,
+ IW_PRIV_TYPE_BYTE | 2047,
+ "hostcmd"
+ },
+};
+
+static struct iw_handler_def mwifiex_iwpriv_handler_def = {
+ .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
+ .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
};
/*
@@ -1276,6 +1313,7 @@ void mwifiex_init_priv_params(struct mwifiex_private *priv,
{
dev->netdev_ops = &mwifiex_netdev_ops;
dev->destructor = free_netdev;
+ dev->wireless_handlers = &mwifiex_iwpriv_handler_def;
/* Initialize private structure */
priv->current_key_index = 0;
priv->media_connected = false;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index ee71e4a..5713fe5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -48,6 +48,8 @@
#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <linux/of_irq.h>
+#include <linux/wireless.h>
+#include <net/iw_handler.h>
#include "decl.h"
#include "ioctl.h"
@@ -160,6 +162,9 @@ enum {
/* Threshold for tx_timeout_cnt before we trigger a card reset */
#define TX_TIMEOUT_THRESHOLD 6
+/* IOCTL number used for hostcmd process*/
+#define MWIFIEX_HOSTCMD_IOCTL (SIOCIWFIRSTPRIV + 17)
+
#define MWIFIEX_DRV_INFO_SIZE_MAX 0x40000
/* Address alignment */
@@ -895,6 +900,7 @@ struct mwifiex_adapter {
u8 event_received;
u8 data_received;
u16 seq_num;
+ struct mwifiex_ds_misc_cmd hostcmd_resp_data;
struct cmd_ctrl_node *cmd_pool;
struct cmd_ctrl_node *curr_cmd;
/* spin lock for command */
@@ -1557,7 +1563,8 @@ bool mwifiex_is_bss_in_11ac_mode(struct mwifiex_private *priv);
u8 mwifiex_get_center_freq_index(struct mwifiex_private *priv, u8 band,
u32 pri_chan, u8 chan_bw);
int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter);
-
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+ struct iwreq *wrq);
int mwifiex_tdls_check_tx(struct mwifiex_private *priv, struct sk_buff *skb);
void mwifiex_flush_auto_tdls_list(struct mwifiex_private *priv);
void mwifiex_auto_tdls_update_peer_status(struct mwifiex_private *priv,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Arend Van Spriel @ 2016-07-13 11:20 UTC (permalink / raw)
To: Per Förlin; +Cc: linux-wireless, arend
In-Reply-To: <CAC0pXTKPm=Q2__OuYEp0p4RC_Jum_+tuS3-7R-hBcoa8Ka8==Q@mail.gmail.com>
On 12-7-2016 12:23, Per Förlin wrote:
> 2016-07-12 11:48 GMT+02:00 Arend Van Spriel <arend.vanspriel@broadcom.com>:
>>
>>
>> On 12-7-2016 10:35, Per Förlin wrote:
>>> 2016-07-06 11:53 GMT+02:00 Per Förlin <per.forlin@gmail.com>:
>>>> I have now verified this patch on backports 4.4.
>>>>
>>>> 2016-04-12 23:55 GMT+02:00 <per.forlin@gmail.com>:
>>>>> From: Per Forlin <per.forlin@gmail.com>
>>>>>
>>>>> This patch resolves an issue where pend_8021x_cnt was not decreased
>>>>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>>>>> because the counter indicated pending packets.
>>>>>
>>>>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>>>>> (warn_slowpath_common)
>>>>> (warn_slowpath_null)
>>>>> (brcmf_netdev_wait_pend8021x [brcmfmac])
>>>>> (send_key_to_dongle [brcmfmac])
>>>>> (brcmf_cfg80211_del_key [brcmfmac])
>>>>> (nl80211_del_key [cfg80211])
>>>>> (genl_rcv_msg)
>>>>> (netlink_rcv_skb)
>>>>> (genl_rcv)
>>>>> (netlink_unicast)
>>>>> (netlink_sendmsg)
>>>>> (sock_sendmsg)
>>>>> (___sys_sendmsg)
>>>>> (__sys_sendmsg)
>>>>> (SyS_sendmsg)
>>>>>
>>>>> The solution is to pull back the header offset in case
>>>>> of an error in txdata(), which may happen in case of
>>> Clarification:
>>>
>>> txdata=brcmf_proto_bcdc_txdata()
>>> brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
>>>
>>> The header needs to be pulled back in case of error otherwise
>>> the error handling and cleanup up will fail to decrease the counter
>>> of pending packets.
>>
>> Yes, this part of the patch is clear to me.
>>
> Thanks, I wasn't sure.
>
>>>>> packet overload in brcmf_sdio_bus_txdata.
>>>>>
>>>>> Overloading an WLAN interface is not an unlikely scenario.
>>
>> So here is where things start to look suspicious and I have mentioned
>> this before. My thought here was "How the hell can you end up with a
>> 2048 packets on the sdio queue", which I mentioned to you before. There
>> is a high watermark on the queue upon which we do a netif_stop_queue()
>> so network layer does not keep pushing tx packets our way. Looking
>> further into this I found that we introduced a bug with commit
>> 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
>> up doing nothing except increasing as statistics debug counter :-(
>>
> Is there a fix available for the high watermark issue or is it
> something you will look into?
>
> To produce a load on the wlan interface I run
> iperf -c 239.255.1.3 -u -b 10m -f m -i 60 -t 3000
> and this is enough in my case to fill up the 2048 queue.
>
>>>>> In case of packet overload the error print "out of bus->txq"
>>>>> is very verbose. To reduce SPAM degrade it to a debug print.
>>>>>
>>>>> Signed-off-by: Per Forlin <per.forlin@gmail.com>
>>>>> ---
>>>>> Change log:
>>>>> v2 - Add variable to know whether the counter is increased or not
>>>>> v3 - txfinalize should decrease the counter. Adjust skb header offset
>>>>> v4 - Fix build error
>>>>>
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>>>>> 3 files changed, 8 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>> index ed9998b..f342f7c 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>>> struct ethhdr *eh;
>>>>> u16 type;
>>>>>
>>>>> + if (!ifp)
>>>>> + goto free;
>>>>> +
>>
>> This may not be needed.
>>
> This is not strictly needed. I can remove it.
>
>>>>> eh = (struct ethhdr *)(txp->data);
>>>>> type = ntohs(eh->h_proto);
>>>>>
>>>>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>>> if (!success)
>>>>> ifp->stats.tx_errors++;
>>>>>
>>>>> +free:
>>>>> brcmu_pkt_buf_free_skb(txp);
>>>>> }
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>> index f82c9ab..98cb83f 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
>>>>>
>>>>> if (fws->avoid_queueing) {
>>>>> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
>>>>> - if (rc < 0)
>>>>> + if (rc < 0) {
>>>>> + (void)brcmf_proto_hdrpull(drvr, false, skb, &ifp);
>>
>> Could it be that the ifp is NULL pointer after brcmf_proto_hdrpull().
>> Can you check. Better use tmp_ifp variable in this call as you have a
>> valid ifp before this call for sure.
>>
> To be on the safe side I can use NULL as in param like you propose,
> and use the available ifp.
>
>>>>> brcmf_txfinalize(ifp, skb, false);
>>>>> + }
>>>>> return rc;
>>>>> }
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>> index a14d9d9d..485e2ad 100644
>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>> @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt)
>>>>> *(u16 *)(pkt->cb) = 0;
>>>>> if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) {
>>>>> skb_pull(pkt, bus->tx_hdrlen);
>>>>> - brcmf_err("out of bus->txq !!!\n");
>>>>> + brcmf_dbg(INFO, "out of bus->txq !!!\n");
>>
>> Now that I understand the issue I want to keep this as error print as it
>> should be very unlikely.
> I would like to test this patch with the watermark fix to confirm this.
Can you try this?
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
b/drive
index cd221ab..9f9024a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2469,10 +2469,22 @@ void brcmf_fws_bustxfail(struct brcmf_fws_info
*fws, str
void brcmf_fws_bus_blocked(struct brcmf_pub *drvr, bool flow_blocked)
{
struct brcmf_fws_info *fws = drvr->fws;
+ struct brcmf_if *ifp;
+ int i;
- fws->bus_flow_blocked = flow_blocked;
- if (!flow_blocked)
- brcmf_fws_schedule_deq(fws);
- else
- fws->stats.bus_flow_block++;
+ if (fws->avoid_queueing) {
+ for (i = 0; i < BRCMF_MAX_IFS; i++) {
+ ifp = drvr->iflist[i];
+ if (!ifp || !ifp->ndev)
+ continue;
+ brcmf_txflowblock_if(ifp,
BRCMF_NETIF_STOP_REASON_FLOW,
+ flow_blocked);
+ }
+ } else {
+ fws->bus_flow_blocked = flow_blocked;
+ if (!flow_blocked)
+ brcmf_fws_schedule_deq(fws);
+ else
+ fws->stats.bus_flow_block++;
+ }
}
^ permalink raw reply related
* [PATCH v2 1/2] mwifiex: add manufacturing mode support
From: Amitkumar Karwar @ 2016-07-13 11:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, 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 <jeffc@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
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 c29f26d..8d57493 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(&adapter->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 0e280f8..b54edf4 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 mwifiex_adapter *adapter)
{
int ret;
+ if (mfg_mode && !strlen(mfg_firmware)) {
+ pr_err("%s: mfg firmware missing. Ignoring manufacturing mode\n",
+ __func__);
+ mfg_mode = false;
+ }
+
+ /* Override default firmware with manufacturing one if
+ * manufacturing mode is enabled
+ */
+ if (mfg_mode) {
+ if (strlcpy(adapter->fw_name, mfg_firmware,
+ sizeof(adapter->fw_name)) >=
+ sizeof(adapter->fw_name)) {
+ pr_err("%s: fw_name too long!\n", __func__);
+ return -1;
+ }
+ }
ret = request_firmware_nowait(THIS_MODULE, 1, adapter->fw_name,
adapter->dev, GFP_KERNEL, adapter,
mwifiex_fw_dpc);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 9f6bb40..ee71e4a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -58,6 +58,9 @@
#include "sdio.h"
extern const char driver_version[];
+extern bool mfg_mode;
+extern char *mfg_firmware;
+
struct mwifiex_adapter;
struct mwifiex_private;
@@ -989,6 +992,7 @@ struct mwifiex_adapter {
u32 drv_info_size;
bool scan_chan_gap_enabled;
struct sk_buff_head rx_data_q;
+ bool mfg_mode;
struct mwifiex_chan_stats *chan_stats;
u32 num_in_chan_stats;
int survey_idx;
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 22fe993..e54a98a 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -226,7 +226,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
#ifdef CONFIG_PM_SLEEP
if (adapter->is_suspended)
mwifiex_pcie_resume(&pdev->dev);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..6dba409 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -289,7 +289,7 @@ mwifiex_sdio_remove(struct sdio_func *func)
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
if (adapter->is_suspended)
mwifiex_sdio_resume(adapter->dev);
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 0857575..ba616ec 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -611,7 +611,7 @@ static void mwifiex_usb_disconnect(struct usb_interface *intf)
if (!adapter->priv_num)
return;
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
#ifdef CONFIG_PM
if (adapter->is_suspended)
mwifiex_usb_resume(intf);
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template
From: Machani, Yaniv @ 2016-07-13 11:15 UTC (permalink / raw)
To: Johannes Berg, linux-kernel@vger.kernel.org, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Kama, Meirav
In-Reply-To: <1467184655.2461.2.camel@sipsolutions.net>
T24gV2VkLCBKdW4gMjksIDIwMTYgYXQgMTA6MTc6MzUsIEpvaGFubmVzIEJlcmcgd3JvdGU6DQo+
IENjOiBLYW1hLCBNZWlyYXYNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzRdIG1hYzgwMjExOiBt
ZXNoOiBmaXhlZCBIVCBpZXMgaW4gYmVhY29uIA0KPiB0ZW1wbGF0ZQ0KPiANCj4gT24gVHVlLCAy
MDE2LTA2LTI4IGF0IDE0OjEzICswMzAwLCBZYW5pdiBNYWNoYW5pIHdyb3RlOg0KPiA+DQo+ID4g
wqBuZXQvbWFjODAyMTEvbWVzaC5jIHwgMzMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KystDQo+ID4gwqBuZXQvbWFjODAyMTEvdXRpbC5jIHzCoMKgMyAtLS0NCj4gPiDCoG5ldC93aXJl
bGVzcy9tZXNoLmMgfMKgwqAyICstDQo+IA0KPiBUaGF0J3Mgbm90IGEgZ29vZCBwYXRjaCAtIG9u
ZSBjaGFuZ2UgaXMgbWFjODAyMTEgYW5kIHRoZSBvdGhlciBjZmc4MDIxMS4NCj4gDQo+ID4gLQku
aHRfb3Btb2RlID0NCj4gSUVFRTgwMjExX0hUX09QX01PREVfUFJPVEVDVElPTl9OT05IVF9NSVhF
RCwNCj4gPiArCS5odF9vcG1vZGUgPSBJRUVFODAyMTFfSFRfT1BfTU9ERV9QUk9URUNUSU9OX05P
TkUsDQo+ID4NCj4gSG93IGFyZSB5b3UgcGxhbm5pbmcgdG8gY29tcGx5IHdpdGggODAyLjExIG5v
dz8NCg0KR29vZCBwb2ludCwgdGhpcyBjaGFuZ2VkIHNob3VsZCBiZSByZW1vdmVkLg0KVGhlIHJl
YXNvbiBmb3IgdGhpcyBjaGFuZ2Ugd2FzIHRoYXQgd2UndmUgbm90aWNlZCBhIGRpZmZlcmVuY2Ug
YmV0d2VlbiBtZXNoIGJlYWNvbiAoYnVpbHQgYnkgdGhlIG1hYzgwMjExKSBhbmQgbWVzaCBhY3Rp
b25zIChidWlsdCBieSB0aGUgc3VwcGxpY2FudCkgaW4gdGhlIEhUIGluZm9ybWF0aW9uIElFLg0K
SW4gYmVhY29ucyB0aGUgSFQgb3BlcmF0aW9uYWwgbW9kZSBpcyBNaXhlZCBNb2RlICgweDExKSAg
d2hpbGUgaW4gYWN0aW9ucyBpdCBpcyBOb25lICgweDAwKS4gDQpBZnRlciBhIHNlY29uZCBsb29r
LCBpdCBzZWVtcyB0aGF0IGl0J3MgdGhlIFN1cHBsaWNhbnQgdGhhdCBkb2Vzbid0IHNldCB0aGUg
ZGVmYXVsdCB2YWx1ZSBjb3JyZWN0bHkuDQoNCldlJ2xsIHNlbmQgYW4gdXBkYXRlZCBwYXRjaCBm
b3IgaXQuDQpUaGFua3MsDQpZYW5pdg0KDQo+IA0KPiBUaGUgSFQgUHJvdGVjdGlvbiBmaWVsZCBp
biBhIG1lc2ggU1RBIG1heSBiZSBzZXQgdG8gbm8gcHJvdGVjdGlvbiBtb2RlIA0KPiBvbmx5IGlm
IOKAlCBBbGwgU1RBcyBkZXRlY3RlZCBpbiB0aGUgcHJpbWFyeSBvciB0aGUgc2Vjb25kYXJ5IGNo
YW5uZWwgDQo+IGFyZSBIVA0KPiDCoCBTVEFzLCBhbmQNCj4g4oCUIEFsbCBtZXNoIFNUQSBtZW1i
ZXJzIG9mIHRoaXMgTUJTUyB0aGF0IGFyZSBvbmUtaG9wIG5laWdoYm9ycyBvZiB0aGUNCj4gwqAg
dHJhbnNtaXR0aW5nIG1lc2ggU1RBIGFyZSBlaXRoZXI6DQo+IMKgIOKAlCAyMC80MCBNSHogSFQg
bWVzaCBTVEFzIGluIGEgMjAvNDAgTUh6IE1CU1MsIG9yDQo+IMKgIOKAlCAyMCBNSHogSFQgbWVz
aCBTVEFzIGluIGEgMjAgTUh6IE1CU1MuDQo+IA0KPiBqb2hhbm5lcw0KDQoNCg==
^ permalink raw reply
* Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
From: Samuel Ortiz @ 2016-07-13 11:00 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, Gustavo F. Padovan,
Johan Hedberg, Lauro Ramos Venancio, Aloisio Almeida Jr,
Greg Kroah-Hartman, Pavan Savoy, Arnd Bergmann,
open list:BLUETOOTH DRIVERS, linux-media, linux-wireless,
linux-kernel
In-Reply-To: <32897348-2AC5-4AB7-BF58-B1E36FC19CF2@holtmann.org>
Hi Marcel,
On Wed, Jul 13, 2016 at 11:56:02AM +0100, Marcel Holtmann wrote:
> Hi Mauro,
>
> >> On mips and parisc:
> >>
> >> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> >> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit constant conversion [-Woverflow]
> >> hst->reg_status = -EINPROGRESS;
> >>
> >> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> >> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant conversion [-Woverflow]
> >> drv->st_register_cb_status = -EINPROGRESS;
> >>
> >> There are actually two issues:
> >> 1. Whether "char" is signed or unsigned depends on the architecture.
> >> As the completion callback data is used to pass a (negative) error
> >> code, it should always be signed.
> >> 2. EINPROGRESS is 150 on mips, 245 on parisc.
> >> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> >>
> >> Change the callback status from "char" to "int" to fix these.
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Patch looks sane to me, but who will apply it?
> >
> > Anyway:
> >
> > Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> I can take it through bluetooth-next if there is no objection.
>
> Samuel, are you fine with that?
Yes, please go ahead.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
From: Marcel Holtmann @ 2016-07-13 10:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Geert Uytterhoeven, Gustavo F. Padovan, Johan Hedberg,
Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
Greg Kroah-Hartman, Pavan Savoy, Arnd Bergmann,
open list:BLUETOOTH DRIVERS, linux-media, linux-wireless,
linux-kernel
In-Reply-To: <20160713074114.76c35d04@recife.lan>
Hi Mauro,
>> On mips and parisc:
>>
>> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
>> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit constant conversion [-Woverflow]
>> hst->reg_status = -EINPROGRESS;
>>
>> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
>> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant conversion [-Woverflow]
>> drv->st_register_cb_status = -EINPROGRESS;
>>
>> There are actually two issues:
>> 1. Whether "char" is signed or unsigned depends on the architecture.
>> As the completion callback data is used to pass a (negative) error
>> code, it should always be signed.
>> 2. EINPROGRESS is 150 on mips, 245 on parisc.
>> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
>>
>> Change the callback status from "char" to "int" to fix these.
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Patch looks sane to me, but who will apply it?
>
> Anyway:
>
> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
I can take it through bluetooth-next if there is no objection.
Samuel, are you fine with that?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
From: Mauro Carvalho Chehab @ 2016-07-13 10:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
Greg Kroah-Hartman, Pavan Savoy, Arnd Bergmann, linux-bluetooth,
linux-media, linux-wireless, linux-kernel
In-Reply-To: <1465203723-16928-1-git-send-email-geert@linux-m68k.org>
Em Mon, 6 Jun 2016 11:02:03 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> On mips and parisc:
>
> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit constant conversion [-Woverflow]
> hst->reg_status = -EINPROGRESS;
>
> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant conversion [-Woverflow]
> drv->st_register_cb_status = -EINPROGRESS;
>
> There are actually two issues:
> 1. Whether "char" is signed or unsigned depends on the architecture.
> As the completion callback data is used to pass a (negative) error
> code, it should always be signed.
> 2. EINPROGRESS is 150 on mips, 245 on parisc.
> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
>
> Change the callback status from "char" to "int" to fix these.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Patch looks sane to me, but who will apply it?
Anyway:
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> Compile-tested only.
> ---
> drivers/bluetooth/btwilink.c | 4 ++--
> drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
> drivers/misc/ti-st/st_core.c | 2 +-
> drivers/nfc/nfcwilink.c | 4 ++--
> include/linux/ti_wilink_st.h | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 24a652f9252be899..485281b3f1677678 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -51,7 +51,7 @@
> */
> struct ti_st {
> struct hci_dev *hdev;
> - char reg_status;
> + int reg_status;
> long (*st_write) (struct sk_buff *);
> struct completion wait_reg_completion;
> };
> @@ -83,7 +83,7 @@ static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> * status.ti_st_open() function will wait for signal from this
> * API when st_register() function returns ST_PENDING.
> */
> -static void st_reg_completion_cb(void *priv_data, char data)
> +static void st_reg_completion_cb(void *priv_data, int data)
> {
> struct ti_st *lhst = priv_data;
>
> diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c
> index 3f9e6df7d837ac27..642b89c66bcb99eb 100644
> --- a/drivers/media/radio/wl128x/fmdrv_common.c
> +++ b/drivers/media/radio/wl128x/fmdrv_common.c
> @@ -1472,7 +1472,7 @@ static long fm_st_receive(void *arg, struct sk_buff *skb)
> * Called by ST layer to indicate protocol registration completion
> * status.
> */
> -static void fm_st_reg_comp_cb(void *arg, char data)
> +static void fm_st_reg_comp_cb(void *arg, int data)
> {
> struct fmdev *fmdev;
>
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> index dcdbd58672ccc6d2..00051590e00f9647 100644
> --- a/drivers/misc/ti-st/st_core.c
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -141,7 +141,7 @@ static void st_send_frame(unsigned char chnl_id, struct st_data_s *st_gdata)
> * This function is being called with spin lock held, protocol drivers are
> * only expected to complete their waits and do nothing more than that.
> */
> -static void st_reg_complete(struct st_data_s *st_gdata, char err)
> +static void st_reg_complete(struct st_data_s *st_gdata, int err)
> {
> unsigned char i = 0;
> pr_info(" %s ", __func__);
> diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
> index f81e500e765061fd..3fbd18b8e473f696 100644
> --- a/drivers/nfc/nfcwilink.c
> +++ b/drivers/nfc/nfcwilink.c
> @@ -94,7 +94,7 @@ struct nfcwilink {
> struct nci_dev *ndev;
> unsigned long flags;
>
> - char st_register_cb_status;
> + int st_register_cb_status;
> long (*st_write) (struct sk_buff *);
>
> struct completion completed;
> @@ -320,7 +320,7 @@ exit:
> }
>
> /* Called by ST when registration is complete */
> -static void nfcwilink_register_complete(void *priv_data, char data)
> +static void nfcwilink_register_complete(void *priv_data, int data)
> {
> struct nfcwilink *drv = priv_data;
>
> diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
> index 0a0d56834c8eb412..f2293028ab9d65e6 100644
> --- a/include/linux/ti_wilink_st.h
> +++ b/include/linux/ti_wilink_st.h
> @@ -71,7 +71,7 @@ struct st_proto_s {
> enum proto_type type;
> long (*recv) (void *, struct sk_buff *);
> unsigned char (*match_packet) (const unsigned char *data);
> - void (*reg_complete_cb) (void *, char data);
> + void (*reg_complete_cb) (void *, int data);
> long (*write) (struct sk_buff *skb);
> void *priv_data;
>
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-13 10:20 UTC (permalink / raw)
To: Luca Coelho, Kalle Valo
Cc: Grumbach, Emmanuel, linux-kernel@vger.kernel.org, linuxwifi,
Berg, Johannes, Ivgi, Chaya Rachel, netdev@vger.kernel.org,
Sharon, Sara, linux-wireless@vger.kernel.org
In-Reply-To: <1468394693.25088.138.camel@coelho.fi>
On 07/13/2016 03:24 AM, Luca Coelho wrote:
> On Wed, 2016-07-13 at 09:50 +0300, Kalle Valo wrote:
>> Prarit Bhargava <prarit@redhat.com> writes:
>>
>>>> We implement thermal zone because we do support it, but the
>>>> problem is
>>>> that we need the firmware to be loaded for that. So you can argue
>>>> that
>>>> we should register *later* when the firmware is loaded. But this
>>>> is
>>>> really not helping all that much because the firmware can also be
>>>> stopped at any time. So you'd want us to register / unregister
>>>> the
>>>> thermal zone anytime the firmware is loaded / unloaded?
>>>
>>> You might have to do that. I think that if the firmware enables a
>>> feature then
>>> the act of loading the firmware should run the code that enables
>>> the feature.
>>> IMO of course.
>>
>> But I suspect that the iwlwifi firmware is loaded during interface up
>> (and unloaded during interface down) and in that case
>> register/unregister would be happening all the time. That doesn't
>> sound
>> like a good idea. I would rather try to fix the thermal interface to
>> handle the cases when the measurement is not available.
>
> I totally agree with Emmanuel and Kalle. We should not change this.
> It is a design decision to return an error when the interface is down,
> this is very common with other subsystems as well.
Please show me another subsystem or driver that does this. I've looked around
the kernel but cannot find one that updates the firmware and implements new
features on the fly like this. I have come across several drivers that allow
for an update, but they do not implement new features based on the firmware.
Additionally, what happens when someone back revs firmware versions (which
happens far more than you and I would expect)? Does that mean I now go from a
functional system to a non-functional system wrt to userspace?
The userspace
> should be able to handle errors and report something like "unavailable"
> when this kind of error is returned.
>
I myself have made the same arguments wrt to cpufreq code & bad userspace
choices. I just went through this a few months back with what went from a
simple patch and turned out to be a hideous patch in cpufreq. You cannot break
userspace like this.
See commit 51443fbf3d2c ("cpufreq: intel_pstate: Fix intel_pstate powersave
min_perf_pct value"). What should have been a trivial change resulted in a
massive change because of broken userspace.
> I'm not sure EIO is the best we can have, but for me that's exactly
> what it is. The thermal zone *is* there, but cannot be accessed
> because the firmware is not available. I'm okay to change it to EBUSY,
> if that would help userspace, but I think that's a bit misleading. The
> device is not busy, on the contrary, it's not even running at all.
>
I understand that, but by returning -EIO we end up with an error.
> Furthermore, I don't think this is "breaking userspace" in the sense of
> being a regression.
I run (let's say 4.5 kernel). sensors works. I update to 4.7. sensors doesn't
work. How is that not a regression? That's _exactly_ what it should be
reported as.
The userspace API has always been implemented with
> the possibility of returning errors. It's not a good design if a
> single device returning an error causes all the other devices to also
> fail.
>
If that were the case we would never have to worry about "breaking userspace"?
For any kernel change I could just say that the userspace design was bad and be
done with it. Why fix anything then?
I don't see any harm in waiting to register the sysfs files for hwmon until the
firmware has been validated. IIUC, the up/down'ing of the device doesn't happen
that often (during initial boot, and suspend/resume, switching wifi connections,
shutdown?). This would make the iwlwifi community happy (IMO) and sensors would
still work. At the same time I could write a patch for lm-sensors to fix this
issue if it comes up in future versions. [Aside: I'm going to have the
reproducing system available today and will test this out. It looks like just
moving some code around.]
The bottom line is that lm-sensors is currently broken with this change in
iwlwifi. AFAICT, no other thermal device returns an error this way, and IMO
that means the iwlwifi driver is doing something new and unexpected wrt to
userspace.
P.
> --
> Cheers,
> Luca.
>
^ permalink raw reply
* RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped
From: Machani, Yaniv @ 2016-07-13 10:11 UTC (permalink / raw)
To: Johannes Berg, linux-kernel@vger.kernel.org, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Hahn, Maital
In-Reply-To: <1467184459.2461.1.camel@sipsolutions.net>
T24gV2VkLCBKdW4gMjksIDIwMTYgYXQgMTA6MTQ6MTksIEpvaGFubmVzIEJlcmcgd3JvdGU6DQo+
IENjOiBIYWhuLCBNYWl0YWwNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzRdIG1hYzgwMjExOiBt
ZXNoOiBmbHVzaCBzdGF0aW9ucyBiZWZvcmUgYmVhY29ucyANCj4gYXJlIHN0b3BwZWQNCj4gDQo+
IE9uIFR1ZSwgMjAxNi0wNi0yOCBhdCAxNDoxMyArMDMwMCwgWWFuaXYgTWFjaGFuaSB3cm90ZToN
Cj4gPiBGcm9tOiBNYWl0YWwgSGFobiA8bWFpdGFsbUB0aS5jb20+DQo+ID4NCj4gPiBTb21lIGRy
aXZlcnMgKGUuZy4gd2wxOHh4KSBleHBlY3QgdGhhdCB0aGUgbGFzdCBzdGFnZSBpbiB0aGUgDQo+
ID4gZGUtaW5pdGlhbGl6YXRpb24gcHJvY2VzcyB3aWxsIGJlIHN0b3BwaW5nIHRoZSBiZWFjb25z
LCBzaW1pbGFyIHRvIGFwLg0KPiA+IFVwZGF0ZSBpZWVlODAyMTFfc3RvcF9tZXNoKCkgZmxvdyBh
Y2NvcmRpbmdseS4NCj4gPg0KPiBIb3cgd2VsbCBoYXZlIHlvdSB0ZXN0ZWQgdGhhdCB3aXRoIG90
aGVyIGRyaXZlcnM/DQo+IA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UgKEkndmUg
YmVlbiBvdXQpIGFuZCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMsDQpJIGhhdmUgdGVzdGVkIGl0
IHdpdGggUlQzNTcyIGFzIHdlbGwsIGFuZCBkaWRuJ3Qgc2VlIGFueSBpc3N1ZS4NCkknbGwgdXBk
YXRlIHRoZSBjb21tZW50IHRvIHJlZmxlY3QgdGhhdC4NCg0KVGhhbmtzLA0KWWFuaXYNCg0KPiBD
aGFuZ2luZyBiZWhhdmlvdXIgdG8gc29tZXRoaW5nIGEgc2luZ2xlIGRyaXZlciBkZXNpcmVzIGlz
bid0IA0KPiBuZWNlc3NhcmlseSB0aGUgYmVzdCB0aGluZyB0byBkbywgc2luY2UgdGhlcmUgYWx3
YXlzIGFyZSBtdWx0aXBsZSBkcml2ZXJzLg0KPiANCj4gSWYgeW91J3JlIGFibGUgdG8gZGVtb25z
dHJhdGUgdGhhdCBpdCB3b3JrcyB3aXRoIHRoZSBvdGhlciBkcml2ZXJzIEknbSANCj4gd2lsbGlu
ZyB0byB0YWtlIHRoYXQgLSB0aGUgY2hhbmdlIG1ha2VzIHNlbnNlIGFmdGVyIGFsbCwgYW5kIGl0
IHNlZW1zIA0KPiBkcml2ZXJzIG11c3Qgc3VwcG9ydCB0aGlzIG9yZGVyaW5nIHNpbmNlIHBlZXJz
IGFyZSBhbHNvIHJlbW92ZWQgDQo+IGR5bmFtaWNhbGx5Li4uIEJ1dCBzdGlsbC4gRG9uJ3QganVz
dCBtYWtlIGEgY2hhbmdlIGxpa2UgdGhhdCB3aXRob3V0IA0KPiBldmVuIGdpdmluZyBhbnkgaW5k
aWNhdGlvbiB3aHkgeW91IHRoaW5rIGl0J3MgZmluZSBmb3Igb3RoZXIgZHJpdmVycyENCj4gDQo+
IGpvaGFubmVzDQoNCg0K
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-13 10:01 UTC (permalink / raw)
To: Kalle Valo
Cc: Grumbach, Emmanuel, linux-kernel@vger.kernel.org, linuxwifi,
Coelho, Luciano, Berg, Johannes, Ivgi, Chaya Rachel,
netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org
In-Reply-To: <87eg6yav5e.fsf@purkki.adurom.net>
On 07/13/2016 02:50 AM, Kalle Valo wrote:
> Prarit Bhargava <prarit@redhat.com> writes:
>
>>> We implement thermal zone because we do support it, but the problem is
>>> that we need the firmware to be loaded for that. So you can argue that
>>> we should register *later* when the firmware is loaded. But this is
>>> really not helping all that much because the firmware can also be
>>> stopped at any time. So you'd want us to register / unregister the
>>> thermal zone anytime the firmware is loaded / unloaded?
>>
>> You might have to do that. I think that if the firmware enables a feature then
>> the act of loading the firmware should run the code that enables the feature.
>> IMO of course.
>
> But I suspect that the iwlwifi firmware is loaded during interface up
> (and unloaded during interface down) and in that case
> register/unregister would be happening all the time.
You make it sound like the interface is coming and going a 1000 times a second.
Maybe this happens once during runtime & during suspend/resume cycles? What
about the cases when the firmware isn't present (and that's what lead me to this
bug)?
That doesn't sound
> like a good idea. I would rather try to fix the thermal interface to
> handle the cases when the measurement is not available.
>
Userspace is broken because of this change. I've had to make another horrible
change to cpufreq for a similar change so I don't see the argument here to just
blame userspace and ignore the outcome of the patch.
P.
^ permalink raw reply
* RE: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for wl8
From: Machani, Yaniv @ 2016-07-13 9:53 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Kalle Valo
Cc: Hahn, Maital, Eliad Peller, Mishol, Guy, Johannes Berg,
Arik Nemtsov, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20160628104305.4533-1-yanivma@ti.com>
On Tue, Jun 28, 2016 at 13:41:35, Machani, Yaniv wrote:
> Guy; Johannes Berg; Arik Nemtsov; linux-wireless@vger.kernel.org;
> netdev@vger.kernel.org
> Subject: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for
> wl8
>
> From: Maital Hahn <maitalm@ti.com>
>
> 1. Added support for interface and role of mesh type.
> 2. Enabled enable/start of mesh-point role,
> and opening and closing a connection with a mesh peer.
> 3. Added multirole combination of mesh and ap
> under the same limits of dual ap mode.
> 4. Add support for 'sta_rc_update' opcode for mesh IF.
> The 'sta_rc_update' opcode is being used in mesh_plink.c.
> Add support in wlcore to handle this opcode correctly for mesh (as
> opposed to current implementation that handles STA only).
> 5. Bumped the firmware version to support new Mesh functionality
>
> Signed-off-by: Maital Hahn <maitalm@ti.com>
> Signed-off-by: Yaniv Machani <yanivma@ti.com>
> ---
Any comments on this patch ?
Can this be pulled ?
Thanks,
Yaniv
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-13 9:13 UTC (permalink / raw)
To: Felix Fietkau
Cc: make-wifi-fast, linux-wireless, Michal Kazior,
Toke Høiland-Jørgensen
In-Reply-To: <cac14ead-1af5-ff1d-5b35-592933882aae@nbd.name>
On Wed, Jul 13, 2016 at 10:53 AM, Felix Fietkau <nbd@nbd.name> wrote:
>> To me this implies a contending lock issue, too much work in the irq
>> handler or too delayed work in the softirq handler....
>>
>> I thought you were very brave to try and backport this.
> I don't think this has anything to do with contending locks, CPU
> utilization, etc. The code does something to the packets that TCP really
> doesn't like.
With your 70% idle figure, I am inclined to agree... could you get an aircap
of the two different tests? - as well as a regular packetcap taken at
the client or server?
And put somewhere I can get at them?
What version of OSX are you running?
I will setup an ath9k box shortly...
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* [PATCH] mac80211: remove skb header offset mangling in ieee80211_build_hdr
From: Felix Fietkau @ 2016-07-13 9:00 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
Since the code only touches the MAC headers, the offsets to the
network/transport headers remain the same throughout this function.
Remove pointless pieces of code that try to 'preserve' them.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/tx.c | 28 ++--------------------------
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 24ec38a..cc2ca09 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2325,7 +2325,6 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
struct mesh_path __maybe_unused *mppath = NULL, *mpath = NULL;
const u8 *encaps_data;
int encaps_len, skip_header_bytes;
- int nh_pos, h_pos;
bool wme_sta = false, authorized = false;
bool tdls_peer;
bool multicast;
@@ -2634,13 +2633,7 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
encaps_len = 0;
}
- nh_pos = skb_network_header(skb) - skb->data;
- h_pos = skb_transport_header(skb) - skb->data;
-
skb_pull(skb, skip_header_bytes);
- nh_pos -= skip_header_bytes;
- h_pos -= skip_header_bytes;
-
head_need = hdrlen + encaps_len + meshhdrlen - skb_headroom(skb);
head_need += padsize;
@@ -2667,18 +2660,12 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
}
}
- if (encaps_data) {
+ if (encaps_data)
memcpy(skb_push(skb, encaps_len), encaps_data, encaps_len);
- nh_pos += encaps_len;
- h_pos += encaps_len;
- }
#ifdef CONFIG_MAC80211_MESH
- if (meshhdrlen > 0) {
+ if (meshhdrlen > 0)
memcpy(skb_push(skb, meshhdrlen), &mesh_hdr, meshhdrlen);
- nh_pos += meshhdrlen;
- h_pos += meshhdrlen;
- }
#endif
if (padsize)
@@ -2697,15 +2684,7 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
} else
memcpy(skb_push(skb, hdrlen), &hdr, hdrlen);
- nh_pos += hdrlen + padsize;
- h_pos += hdrlen + padsize;
-
- /* Update skb pointers to various headers since this modified frame
- * is going to go through Linux networking code that may potentially
- * need things like pointer to IP header. */
skb_reset_mac_header(skb);
- skb_set_network_header(skb, nh_pos);
- skb_set_transport_header(skb, h_pos);
info = IEEE80211_SKB_CB(skb);
memset(info, 0, sizeof(*info));
@@ -4391,9 +4370,6 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
int ac = ieee802_1d_to_ac[tid & 7];
skb_reset_mac_header(skb);
- skb_reset_network_header(skb);
- skb_reset_transport_header(skb);
-
skb_set_queue_mapping(skb, ac);
skb->priority = tid;
--
2.8.4
^ permalink raw reply related
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-13 8:53 UTC (permalink / raw)
To: Dave Taht
Cc: make-wifi-fast, linux-wireless, Michal Kazior,
Toke Høiland-Jørgensen
In-Reply-To: <CAA93jw7y_dp=AMFB3Nj7TK08PXmdypKBnfAZ_FfnWXOt-+aL2Q@mail.gmail.com>
On 2016-07-13 09:57, Dave Taht wrote:
> On Tue, Jul 12, 2016 at 4:02 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>> On 2016-07-12 14:13, Dave Taht wrote:
>>>> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>>>> Hi,
>>>>>
>>>>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>>>>> regression when running local iperf on an AP (running the txq stuff) to
>>>>> a wireless client.
>>>>
>>>> Your kernel? cpu architecture?
>>> QCA9558, 720 MHz, running Linux 4.4.14
>
> So this is a single core at the near-bottom end of the range. I guess
> we also should find a MIPS 24c derivative that runs at 400Mhz or so.
>
> What HZ? (I no longer know how much higher HZ settings make any
> difference, but I'm usually at NOHZ and 250, rather than 100.)
>
> And all the testing to date was on much higher end multi-cores.
>
>>>> What happens when going through the AP to a server from the wireless client?
>>> Will test that next.
>
> Anddddd?
Single stream: 130 Mbit/s, 70% idle
Two streams: 50-80 Mbit/s (wildly fluctuating), 73% idle.
>>>> Which direction?
>>> AP->STA, iperf running on the AP. Client is a regular MacBook Pro
>>> (Broadcom).
>>
>> There are always 2 wifi chips in play. Like the Sith.
>>
>>>>> Here's some things that I found:
>>>>> - when I use only one TCP stream I get around 90-110 Mbit/s
>>>>
>>>> with how much cpu left over?
>>> ~20%
>>>
>>>>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>>>> with how much cpu left over?
>>> ~30%
>
> To me this implies a contending lock issue, too much work in the irq
> handler or too delayed work in the softirq handler....
>
> I thought you were very brave to try and backport this.
I don't think this has anything to do with contending locks, CPU
utilization, etc. The code does something to the packets that TCP really
doesn't like.
- Felix
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-13 7:57 UTC (permalink / raw)
To: Felix Fietkau
Cc: make-wifi-fast, linux-wireless, Michal Kazior,
Toke Høiland-Jørgensen
In-Reply-To: <CAA93jw4GQknawtp6Lo3ZM8=qW=p2eTnZ_krC7AvnNbKwp8R5SQ@mail.gmail.com>
On Tue, Jul 12, 2016 at 4:02 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau <nbd@nbd.name> wrote:
>> On 2016-07-12 14:13, Dave Taht wrote:
>>> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>>> Hi,
>>>>
>>>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>>>> regression when running local iperf on an AP (running the txq stuff) to
>>>> a wireless client.
>>>
>>> Your kernel? cpu architecture?
>> QCA9558, 720 MHz, running Linux 4.4.14
So this is a single core at the near-bottom end of the range. I guess
we also should find a MIPS 24c derivative that runs at 400Mhz or so.
What HZ? (I no longer know how much higher HZ settings make any
difference, but I'm usually at NOHZ and 250, rather than 100.)
And all the testing to date was on much higher end multi-cores.
>>> What happens when going through the AP to a server from the wireless client?
>> Will test that next.
Anddddd?
>>
>>> Which direction?
>> AP->STA, iperf running on the AP. Client is a regular MacBook Pro
>> (Broadcom).
>
> There are always 2 wifi chips in play. Like the Sith.
>
>>>> Here's some things that I found:
>>>> - when I use only one TCP stream I get around 90-110 Mbit/s
>>>
>>> with how much cpu left over?
>> ~20%
>>
>>>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>>> with how much cpu left over?
>> ~30%
To me this implies a contending lock issue, too much work in the irq
handler or too delayed work in the softirq handler....
I thought you were very brave to try and backport this.
>
> Hmm.
>
> Care to try netperf?
>
>>
>>> context switch difference between the two tests?
>> What's the easiest way to track that?
>
> if you have gnu "time" time -v the_process
>
> or:
>
> perf record -e context-switches -ag
>
> or: process /proc/$PID/status for cntx
>
>>> tcp_limit_output_bytes is?
>> 262144
>
> I keep hoping to be able to reduce this to something saner like 4096
> one day. It got bumped to 64k based on bad wifi performance once, and
> then to it's current size to make the Xen folk happier.
>
> The other param I'd like to see fiddled with is tcp_notsent_lowat.
>
> In both cases reductions will increase your context switches but
> reduce memory pressure and lead to a more reactive tcp.
>
> And in neither case I think this is the real cause of this problem.
>
>
>>> got perf?
>> Need to make a new build for that.
>>
>>>> - fairness between TCP streams looks completely fine
>>>
>>> A codel will get to long term fairness pretty fast. Packet captures
>>> from a fq will show much more regular interleaving of packets,
>>> regardless.
>>>
>>>> - there's no big queue buildup, the code never actually drops any packets
>>>
>>> A "trick" I have been using to observe codel behavior has been to
>>> enable ecn on server and client, then checking in wireshark for ect(3)
>>> marked packets.
>> I verified this with printk. The same issue already appears if I have
>> just the fq patch (with the codel patch reverted).
>
> OK. A four flow test "should" trigger codel....
>
> Running out of cpu (or hitting some other bottleneck), without
> loss/marking "should" result in a tcptrace -G and xplot.org of the
> packet capture showing the window continuing to increase....
>
>
>>>> - if I put a hack in the fq code to force the hash to a constant value
>>>
>>> You could also set "flows" to 1 to keep the hash being generated, but
>>> not actually use it.
>>>
>>>> (effectively disabling fq without disabling codel), the problem
>>>> disappears and even multiple streams get proper performance.
>>>
>>> Meaning you get 90-110Mbits ?
>> Right.
>>
>>> Do you have a "before toke" figure for this platform?
>> It's quite similar.
>>
>>>> Please let me know if you have any ideas.
>>>
>>> I am in berlin, packing hardware...
>> Nice!
>>
>> - Felix
>>
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: pull-request: iwlwifi 2016-07-11
From: Kalle Valo @ 2016-07-13 7:54 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, torvalds, Grumbach, Emmanuel, linuxwifi
In-Reply-To: <1468233921.25088.107.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is a fix for a warning that was spotted by Linus. We already have
> this patch queued in -next, but it should have gone to -fixes. I hope
> it is still possible to send it for 4.7. And it shouldn't be a problem
> to have it in both, right? I guess git merge would take care of that.
Like we discussed privately, even if iwlwifi was printing warnings the
connection was still working for Linus so this is not critical enough
for 4.7 so late in the cycle. So let's drop this and the fix can go to
4.8 as planned.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Arnd Bergmann @ 2016-07-13 7:47 UTC (permalink / raw)
To: Kalle Valo
Cc: Martin Blumenstingl, ath9k-devel, devicetree, linux-wireless,
ath9k-devel, mcgrof, galak, ijc+devicetree, mark.rutland,
pawel.moll, robh+dt, chunkeey, arend.vanspriel, julian.calaby
In-Reply-To: <87a8hmauls.fsf@purkki.adurom.net>
On Wednesday, July 13, 2016 10:02:39 AM CEST Kalle Valo wrote:
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
> > Add documentation how devicetree can be used to configure ath9k based
> > devices.
> >
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > ---
> > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 ++++++++++++++++++++++
> > 1 file changed, 59 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> > new file mode 100644
> > index 0000000..7c62c59
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> > @@ -0,0 +1,59 @@
> > +* Qualcomm Atheros ath9k wireless devices
> > +
> > +This node provides properties for configuring the ath9k wireless device. The
> > +node is expected to be specified as a child node of the PCI controller to
> > +which the wireless chip is connected.
> > +
> > +Required properties:
> > +- compatible: Should be "qca,ath9k"
>
> Isn't this supposed to use the chipset name? ath9k is the driver name
> and something like ar9462 is the chip name. I know in ath10k we used
> "qca,ath10k" but I'm starting to suspect that was a mistake.
>
You are right, but it's actually more complicated than that. For PCI
devices, the format of the compatible strings is defined in
http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf
and it doesn't use the "vendor,device" syntax at all but instead
uses pciVVVV,DDDD where VVVV and DDDD are the hexadecimal (without
leading 0x) vendor and device ID numbers. The document also specifies
seven other formats and in theory you should list them all, but
that really only makes sense for Open Firmware that programatically
creates those strings.
For a hand-written DTS source, I'd just use the shortest one of those.
Linux actually doesn't care at all, as PCI drivers don't use the
compatible string but instead look at the config register values
that were read by the PCI core.
For USB, we do basically the same thing, but have very few examples
of that as Linux only recently started supporting this.
For SDIO devices we should have done the same thing but screwed up
when we made the generic binding and we have no policy, the example
even lists one that makes no sense at all ("brcm,bcm43xx-fmac")
as it is neither a specific device nor something derived from the IDs.
For on-chip devices, we should follow the common policy for on-chip
devices and use the "vendor,chip-funcion" with fallbacks for
compatible devices such as:
compatible = "tplink,tp9343-wifi", "qca,qca9561-wifi", "atheros,ar9001-wifi";
For a chip that is branded by TP-Link and derived from a Qualcomm Atheros
chip it is 100% compatible with, and in turn derived from an older
implementation (just guessing which one was the original ath9k).
Arnd
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Luca Coelho @ 2016-07-13 7:24 UTC (permalink / raw)
To: Kalle Valo, Prarit Bhargava
Cc: Grumbach, Emmanuel, linux-kernel@vger.kernel.org, linuxwifi,
Berg, Johannes, Ivgi, Chaya Rachel, netdev@vger.kernel.org,
Sharon, Sara, linux-wireless@vger.kernel.org
In-Reply-To: <87eg6yav5e.fsf@purkki.adurom.net>
On Wed, 2016-07-13 at 09:50 +0300, Kalle Valo wrote:
> Prarit Bhargava <prarit@redhat.com> writes:
>
> > > We implement thermal zone because we do support it, but the
> > > problem is
> > > that we need the firmware to be loaded for that. So you can argue
> > > that
> > > we should register *later* when the firmware is loaded. But this
> > > is
> > > really not helping all that much because the firmware can also be
> > > stopped at any time. So you'd want us to register / unregister
> > > the
> > > thermal zone anytime the firmware is loaded / unloaded?
> >
> > You might have to do that. I think that if the firmware enables a
> > feature then
> > the act of loading the firmware should run the code that enables
> > the feature.
> > IMO of course.
>
> But I suspect that the iwlwifi firmware is loaded during interface up
> (and unloaded during interface down) and in that case
> register/unregister would be happening all the time. That doesn't
> sound
> like a good idea. I would rather try to fix the thermal interface to
> handle the cases when the measurement is not available.
I totally agree with Emmanuel and Kalle. We should not change this.
It is a design decision to return an error when the interface is down,
this is very common with other subsystems as well. The userspace
should be able to handle errors and report something like "unavailable"
when this kind of error is returned.
I'm not sure EIO is the best we can have, but for me that's exactly
what it is. The thermal zone *is* there, but cannot be accessed
because the firmware is not available. I'm okay to change it to EBUSY,
if that would help userspace, but I think that's a bit misleading. The
device is not busy, on the contrary, it's not even running at all.
Furthermore, I don't think this is "breaking userspace" in the sense of
being a regression. The userspace API has always been implemented with
the possibility of returning errors. It's not a good design if a
single device returning an error causes all the other devices to also
fail.
--
Cheers,
Luca.
^ permalink raw reply
* Re: 4.8 merge window closing
From: Kalle Valo @ 2016-07-13 7:18 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <878txg2ld6.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Linus released 4.7-rc6 last Sunday but didn't give any hints how close
> the real release is, but nevertheless the merge window for 4.8 is
> getting quite close so if there's anything you want to have in
> wireless-drivers-next for 4.8 better send them NOW. Especially as I
> won't have that much time to apply patches the next two weeks.
Due to travelling Linus gave us one more week so the deadline for
wireless-drivers patches is now next Sunday (or so). As I'm taking it
easy this week still I will start actively applying patches only next
week, but better to have the patches reviewed and ready by then.
--
Kalle Valo
^ permalink raw reply
* [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Masashi Honma @ 2016-07-13 7:04 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, j, me, Masashi Honma
The mesh STA sends QoS frame with EOSP (end of service period)
subfiled=1 to end the MPSP(mesh peer service period). Previously, if
the frame was not acked by peer, the mesh STA did not end the MPSP.
This patch ends the MPSP even if the QoS frame was no acked.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/mac80211/status.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index c6d5c72..a2a6826 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -771,6 +771,13 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
clear_sta_flag(sta, WLAN_STA_SP);
acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
+
+ /* mesh Peer Service Period support */
+ if (ieee80211_vif_is_mesh(&sta->sdata->vif) &&
+ ieee80211_is_data_qos(fc))
+ ieee80211_mpsp_trigger_process(
+ ieee80211_get_qos_ctl(hdr), sta, true, acked);
+
if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
/*
* The STA is in power save mode, so assume
@@ -781,13 +788,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
return;
}
- /* mesh Peer Service Period support */
- if (ieee80211_vif_is_mesh(&sta->sdata->vif) &&
- ieee80211_is_data_qos(fc))
- ieee80211_mpsp_trigger_process(
- ieee80211_get_qos_ctl(hdr),
- sta, true, acked);
-
if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL) &&
(ieee80211_is_data(hdr->frame_control)) &&
(rates_idx != -1))
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Kalle Valo @ 2016-07-13 7:02 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
galak, ijc+devicetree, mark.rutland, pawel.moll, robh+dt,
chunkeey, arend.vanspriel, julian.calaby
In-Reply-To: <20160709232834.31654-2-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 0000000..7c62c59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,59 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"
Isn't this supposed to use the chipset name? ath9k is the driver name
and something like ar9462 is the chip name. I know in ath10k we used
"qca,ath10k" but I'm starting to suspect that was a mistake.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Kalle Valo @ 2016-07-13 6:50 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Grumbach, Emmanuel, linux-kernel@vger.kernel.org, linuxwifi,
Coelho, Luciano, Berg, Johannes, Ivgi, Chaya Rachel,
netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org
In-Reply-To: <57840214.8000904@redhat.com>
Prarit Bhargava <prarit@redhat.com> writes:
>> We implement thermal zone because we do support it, but the problem is
>> that we need the firmware to be loaded for that. So you can argue that
>> we should register *later* when the firmware is loaded. But this is
>> really not helping all that much because the firmware can also be
>> stopped at any time. So you'd want us to register / unregister the
>> thermal zone anytime the firmware is loaded / unloaded?
>
> You might have to do that. I think that if the firmware enables a feature then
> the act of loading the firmware should run the code that enables the feature.
> IMO of course.
But I suspect that the iwlwifi firmware is loaded during interface up
(and unloaded during interface down) and in that case
register/unregister would be happening all the time. That doesn't sound
like a good idea. I would rather try to fix the thermal interface to
handle the cases when the measurement is not available.
--
Kalle Valo
^ permalink raw reply
* Re: iwlwifi + wpa2-leap + multiple AP's = call trace
From: Arend Van Spriel @ 2016-07-13 6:21 UTC (permalink / raw)
To: Ismael Farfán, linux-wireless
In-Reply-To: <CANXECd56kVUKF1xjiSjLiDTKAqrv9_TJxgPgxu7F-dBSmXcjLA@mail.gmail.com>
On 13-7-2016 2:29, Ismael Farfán wrote:
> Hello list
>
> I searched this error around and didn't find anything, so here it goes.
>
> Today I tried to connect to an enterprise network, which means,
> literally, tens of AP's sharing the same name... the network requieres
> user/password authentication (wpa2-leap).
>
> I'm using Arch
> $ uname -a
> Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux
>
> Since the thing just didn't connect, I checked dmesg and found this:
>
> Any ideas?
>From the stack trace it seems wpa_supplicant on Arch is using WEXT API.
You could try and change it to use NL80211 API. Personally, I have not
used Arch Linux so no idea where to change that.
The warning is here [1]:
503 IWL_DEBUG_TE(mvm, "Add new TE, duration %d TU\n",
504 le32_to_cpu(te_cmd->duration));
505
506 spin_lock_bh(&mvm->time_event_lock);
507 if (WARN_ON(te_data->id != TE_MAX)) {
508 spin_unlock_bh(&mvm->time_event_lock);
509 return -EIO;
510 }
It seems this function is called with te_data that is already in use,
but that is my uneducated guess so I may be wrong.
Regards,
Arend
[1]
http://lxr.free-electrons.com/source/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c#L507
>
> [ 83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
> by local choice (Reason: 3=DEAUTH_LEAVING)
> [ 83.030073] ------------[ cut here ]------------
> [ 83.030082] WARNING: CPU: 2 PID: 1087 at
> drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
> e_event_send_add+0x1c6/0x200 [iwlmvm]
> [ 83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
> O 4.6.3-1-ARCH #1
> [ 83.030158] Hardware name: Notebook
> P65_P67SA /P65_P67SA
> , BIOS 1.03.01 07/22/2015
> [ 83.030160] 0000000000000286 0000000009e998bc ffff880403a5b940
> ffffffff812e54c2
> [ 83.030162] 0000000000000000 0000000000000000 ffff880403a5b980
> ffffffff8107a6bb
> [ 83.030164] 000001fb81a8a180 ffff88041b443580 ffff88041c329548
> 00000000fffffffb
> [ 83.030167] Call Trace:
> [ 83.030172] [<ffffffff812e54c2>] dump_stack+0x63/0x81
> [ 83.030174] [<ffffffff8107a6bb>] __warn+0xcb/0xf0
> [ 83.030176] [<ffffffff8107a7ed>] warn_slowpath_null+0x1d/0x20
> [ 83.030181] [<ffffffffa0b068d6>]
> iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
> [ 83.030184] [<ffffffff810c4772>] ? up+0x32/0x50
> [ 83.030187] [<ffffffff810d371b>] ? wake_up_klogd+0x3b/0x50
> [ 83.030189] [<ffffffff810d3c19>] ? console_unlock+0x4e9/0x590
> [ 83.030193] [<ffffffffa0b07520>]
> iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
> [ 83.030196] [<ffffffffa0af100e>] ? iwl_mvm_ref_sync+0x2e/0x140 [iwlmvm]
> [ 83.030199] [<ffffffff810d423f>] ? vprintk_default+0x1f/0x30
> [ 83.030202] [<ffffffffa0af154a>]
> iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
> [ 83.030216] [<ffffffffa0c8e198>] ieee80211_mgd_deauth+0x338/0x4d0 [mac80211]
> [ 83.030219] [<ffffffff810b2333>] ? enqueue_entity+0x323/0xd70
> [ 83.030228] [<ffffffffa0c579b8>] ieee80211_deauth+0x18/0x20 [mac80211]
> [ 83.030237] [<ffffffffa05a1b8f>] cfg80211_mlme_deauth+0x9f/0x1a0 [cfg80211]
> [ 83.030242] [<ffffffffa05a62da>] cfg80211_disconnect+0x9a/0x200 [cfg80211]
> [ 83.030248] [<ffffffffa05c4529>]
> cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
> [ 83.030255] [<ffffffffa05c3512>] cfg80211_wext_siwessid+0x22/0x40 [cfg80211]
> [ 83.030258] [<ffffffff815af803>] ioctl_standard_iw_point+0x133/0x350
> [ 83.030264] [<ffffffffa05c34f0>] ?
> cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
> [ 83.030266] [<ffffffff810a4a82>] ? wake_up_q+0x32/0x70
> [ 83.030268] [<ffffffff815b0930>] ? iw_handler_get_private+0x60/0x60
> [ 83.030271] [<ffffffff815afd07>] ioctl_standard_call+0x87/0xd0
> [ 83.030273] [<ffffffff815afc80>] ? call_commit_handler.part.4+0x30/0x30
> [ 83.030275] [<ffffffff815afc10>] wireless_process_ioctl+0x1f0/0x230
> [ 83.030278] [<ffffffff814b52fe>] ? dev_get_by_name_rcu+0x5e/0x80
> [ 83.030280] [<ffffffff815aff58>] wext_handle_ioctl+0x78/0xd0
> [ 83.030283] [<ffffffff814d7777>] dev_ioctl+0x2a7/0x5a0
> [ 83.030285] [<ffffffff8149dc86>] sock_ioctl+0x126/0x290
> [ 83.030287] [<ffffffff81209be3>] do_vfs_ioctl+0xa3/0x5d0
> [ 83.030290] [<ffffffff811f7362>] ? vfs_write+0x142/0x190
> [ 83.030292] [<ffffffff8120a189>] SyS_ioctl+0x79/0x90
> [ 83.030294] [<ffffffff815c71b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> [ 83.030296] ---[ end trace 8247b235a66a1a21 ]---
>
>
>
>
>
^ permalink raw reply
* iwlwifi + wpa2-leap + multiple AP's = call trace
From: Ismael Farfán @ 2016-07-13 0:29 UTC (permalink / raw)
To: linux-wireless
Hello list
I searched this error around and didn't find anything, so here it goes.
Today I tried to connect to an enterprise network, which means,
literally, tens of AP's sharing the same name... the network requieres
user/password authentication (wpa2-leap).
I'm using Arch
$ uname -a
Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux
Since the thing just didn't connect, I checked dmesg and found this:
Any ideas?
[ 83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
by local choice (Reason: 3=DEAUTH_LEAVING)
[ 83.030073] ------------[ cut here ]------------
[ 83.030082] WARNING: CPU: 2 PID: 1087 at
drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
e_event_send_add+0x1c6/0x200 [iwlmvm]
[ 83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
O 4.6.3-1-ARCH #1
[ 83.030158] Hardware name: Notebook
P65_P67SA /P65_P67SA
, BIOS 1.03.01 07/22/2015
[ 83.030160] 0000000000000286 0000000009e998bc ffff880403a5b940
ffffffff812e54c2
[ 83.030162] 0000000000000000 0000000000000000 ffff880403a5b980
ffffffff8107a6bb
[ 83.030164] 000001fb81a8a180 ffff88041b443580 ffff88041c329548
00000000fffffffb
[ 83.030167] Call Trace:
[ 83.030172] [<ffffffff812e54c2>] dump_stack+0x63/0x81
[ 83.030174] [<ffffffff8107a6bb>] __warn+0xcb/0xf0
[ 83.030176] [<ffffffff8107a7ed>] warn_slowpath_null+0x1d/0x20
[ 83.030181] [<ffffffffa0b068d6>]
iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
[ 83.030184] [<ffffffff810c4772>] ? up+0x32/0x50
[ 83.030187] [<ffffffff810d371b>] ? wake_up_klogd+0x3b/0x50
[ 83.030189] [<ffffffff810d3c19>] ? console_unlock+0x4e9/0x590
[ 83.030193] [<ffffffffa0b07520>]
iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
[ 83.030196] [<ffffffffa0af100e>] ? iwl_mvm_ref_sync+0x2e/0x140 [iwlmvm]
[ 83.030199] [<ffffffff810d423f>] ? vprintk_default+0x1f/0x30
[ 83.030202] [<ffffffffa0af154a>]
iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
[ 83.030216] [<ffffffffa0c8e198>] ieee80211_mgd_deauth+0x338/0x4d0 [mac80211]
[ 83.030219] [<ffffffff810b2333>] ? enqueue_entity+0x323/0xd70
[ 83.030228] [<ffffffffa0c579b8>] ieee80211_deauth+0x18/0x20 [mac80211]
[ 83.030237] [<ffffffffa05a1b8f>] cfg80211_mlme_deauth+0x9f/0x1a0 [cfg80211]
[ 83.030242] [<ffffffffa05a62da>] cfg80211_disconnect+0x9a/0x200 [cfg80211]
[ 83.030248] [<ffffffffa05c4529>]
cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
[ 83.030255] [<ffffffffa05c3512>] cfg80211_wext_siwessid+0x22/0x40 [cfg80211]
[ 83.030258] [<ffffffff815af803>] ioctl_standard_iw_point+0x133/0x350
[ 83.030264] [<ffffffffa05c34f0>] ?
cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
[ 83.030266] [<ffffffff810a4a82>] ? wake_up_q+0x32/0x70
[ 83.030268] [<ffffffff815b0930>] ? iw_handler_get_private+0x60/0x60
[ 83.030271] [<ffffffff815afd07>] ioctl_standard_call+0x87/0xd0
[ 83.030273] [<ffffffff815afc80>] ? call_commit_handler.part.4+0x30/0x30
[ 83.030275] [<ffffffff815afc10>] wireless_process_ioctl+0x1f0/0x230
[ 83.030278] [<ffffffff814b52fe>] ? dev_get_by_name_rcu+0x5e/0x80
[ 83.030280] [<ffffffff815aff58>] wext_handle_ioctl+0x78/0xd0
[ 83.030283] [<ffffffff814d7777>] dev_ioctl+0x2a7/0x5a0
[ 83.030285] [<ffffffff8149dc86>] sock_ioctl+0x126/0x290
[ 83.030287] [<ffffffff81209be3>] do_vfs_ioctl+0xa3/0x5d0
[ 83.030290] [<ffffffff811f7362>] ? vfs_write+0x142/0x190
[ 83.030292] [<ffffffff8120a189>] SyS_ioctl+0x79/0x90
[ 83.030294] [<ffffffff815c71b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 83.030296] ---[ end trace 8247b235a66a1a21 ]---
--
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox