* Re: [v2] rsi: sdio suspend and resume support
From: Souptick Joarder @ 2017-09-21 13:38 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Kalle Valo, linux-wireless, Amitkumar Karwar,
Prameela Rani Garnepudi, Karun Eagalapati
In-Reply-To: <1505998288-2041-1-git-send-email-amitkarwar@gmail.com>
On Thu, Sep 21, 2017 at 6:21 PM, Amitkumar Karwar <amitkarwar@gmail.com> wrote:
> From: Karun Eagalapati <karun256@gmail.com>
>
> SDIO suspend and resume handlers are implemented and verified
> that device works after suspend/resume cycle.
>
> Signed-off-by: Karun Eagalapati <karun256@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
> ---
> v2: Replaced never ending while loop with 20msecs loop(Kalle Valo)
> ---
> drivers/net/wireless/rsi/rsi_91x_sdio.c | 128 +++++++++++++++++++++++++++++++-
> drivers/net/wireless/rsi/rsi_sdio.h | 2 +
> 2 files changed, 126 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> index 8d3a483..b3f8006 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> @@ -1059,16 +1059,136 @@ static void rsi_disconnect(struct sdio_func *pfunction)
> }
>
> #ifdef CONFIG_PM
> +static int rsi_set_sdio_pm_caps(struct rsi_hw *adapter)
> +{
> + struct rsi_91x_sdiodev *dev =
> + (struct rsi_91x_sdiodev *)adapter->rsi_dev;
> + struct sdio_func *func = dev->pfunction;
> + int ret;
> +
> + ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
> + if (ret)
> + rsi_dbg(ERR_ZONE, "Set sdio keep pwr flag failed: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int rsi_sdio_disable_interrupts(struct sdio_func *pfunc)
> +{
> + struct rsi_hw *adapter = sdio_get_drvdata(pfunc);
> + u8 isr_status = 0, data = 0;
> + int ret;
> + unsigned long t1;
> +
> + rsi_dbg(INFO_ZONE, "Waiting for interrupts to be cleared..");
> + t1 = jiffies;
> + do {
> + rsi_sdio_read_register(adapter, RSI_FN1_INT_REGISTER,
> + &isr_status);
> + rsi_dbg(INFO_ZONE, ".");
> + } while ((isr_status) && (jiffies_to_msecs(jiffies - t1) < 20));
> + rsi_dbg(INFO_ZONE, "Interrupts cleared\n");
> +
> + sdio_claim_host(pfunc);
> + ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to read int enable register\n",
> + __func__);
> + goto done;
> + }
> +
> + data &= RSI_INT_ENABLE_MASK;
> + ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to write to int enable register\n",
> + __func__);
> + goto done;
> + }
> + ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to read int enable register\n",
> + __func__);
> + goto done;
> + }
> + rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
> +
> +done:
> + sdio_release_host(pfunc);
> + return ret;
> +}
> +
> +static int rsi_sdio_enable_interrupts(struct sdio_func *pfunc)
> +{
> + u8 data;
> + int ret;
> +
> + sdio_claim_host(pfunc);
> + ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to read int enable register\n", __func__);
> + goto done;
> + }
> +
> + data |= ~RSI_INT_ENABLE_MASK & 0xff;
> +
> + ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to write to int enable register\n",
> + __func__);
> + goto done;
> + }
> +
> + ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
> + if (ret < 0) {
> + rsi_dbg(ERR_ZONE,
> + "%s: Failed to read int enable register\n", __func__);
> + goto done;
> + }
> + rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
> +
> +done:
> + sdio_release_host(pfunc);
> + return ret;
> +}
> +
> static int rsi_suspend(struct device *dev)
> {
> - /* Not yet implemented */
> - return -ENOSYS;
> + int ret;
> + struct sdio_func *pfunction = dev_to_sdio_func(dev);
> + struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
> + struct rsi_common *common;
> +
> + if (!adapter) {
> + rsi_dbg(ERR_ZONE, "Device is not ready\n");
> + return -ENODEV;
> + }
> + common = adapter->priv;
> + rsi_sdio_disable_interrupts(pfunction);
> +
> + ret = rsi_set_sdio_pm_caps(adapter);
> + if (ret)
> + rsi_dbg(INFO_ZONE,
> + "Setting power management caps failed\n");
> + common->fsm_state = FSM_CARD_NOT_READY;
> +
> + return 0;
I think it should be return ret if rsi_set_sdio_pm_caps() fails.
> }
>
> static int rsi_resume(struct device *dev)
> {
> - /* Not yet implemented */
> - return -ENOSYS;
> + struct sdio_func *pfunction = dev_to_sdio_func(dev);
> + struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
> + struct rsi_common *common = adapter->priv;
> +
> + common->fsm_state = FSM_MAC_INIT_DONE;
> + rsi_sdio_enable_interrupts(pfunction);
> +
> + return 0;
> }
>
> static const struct dev_pm_ops rsi_pm_ops = {
> diff --git a/drivers/net/wireless/rsi/rsi_sdio.h b/drivers/net/wireless/rsi/rsi_sdio.h
> index 95e4bed..49c549b 100644
> --- a/drivers/net/wireless/rsi/rsi_sdio.h
> +++ b/drivers/net/wireless/rsi/rsi_sdio.h
> @@ -48,6 +48,8 @@ enum sdio_interrupt_type {
>
> #define RSI_DEVICE_BUFFER_STATUS_REGISTER 0xf3
> #define RSI_FN1_INT_REGISTER 0xf9
> +#define RSI_INT_ENABLE_REGISTER 0x04
> +#define RSI_INT_ENABLE_MASK 0xfc
> #define RSI_SD_REQUEST_MASTER 0x10000
>
> /* FOR SD CARD ONLY */
> --
> 2.7.4
>
^ permalink raw reply
* [v2] rsi: sdio suspend and resume support
From: Amitkumar Karwar @ 2017-09-21 12:51 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
From: Karun Eagalapati <karun256@gmail.com>
SDIO suspend and resume handlers are implemented and verified
that device works after suspend/resume cycle.
Signed-off-by: Karun Eagalapati <karun256@gmail.com>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
---
v2: Replaced never ending while loop with 20msecs loop(Kalle Valo)
---
drivers/net/wireless/rsi/rsi_91x_sdio.c | 128 +++++++++++++++++++++++++++++++-
drivers/net/wireless/rsi/rsi_sdio.h | 2 +
2 files changed, 126 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index 8d3a483..b3f8006 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -1059,16 +1059,136 @@ static void rsi_disconnect(struct sdio_func *pfunction)
}
#ifdef CONFIG_PM
+static int rsi_set_sdio_pm_caps(struct rsi_hw *adapter)
+{
+ struct rsi_91x_sdiodev *dev =
+ (struct rsi_91x_sdiodev *)adapter->rsi_dev;
+ struct sdio_func *func = dev->pfunction;
+ int ret;
+
+ ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
+ if (ret)
+ rsi_dbg(ERR_ZONE, "Set sdio keep pwr flag failed: %d\n", ret);
+
+ return ret;
+}
+
+static int rsi_sdio_disable_interrupts(struct sdio_func *pfunc)
+{
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunc);
+ u8 isr_status = 0, data = 0;
+ int ret;
+ unsigned long t1;
+
+ rsi_dbg(INFO_ZONE, "Waiting for interrupts to be cleared..");
+ t1 = jiffies;
+ do {
+ rsi_sdio_read_register(adapter, RSI_FN1_INT_REGISTER,
+ &isr_status);
+ rsi_dbg(INFO_ZONE, ".");
+ } while ((isr_status) && (jiffies_to_msecs(jiffies - t1) < 20));
+ rsi_dbg(INFO_ZONE, "Interrupts cleared\n");
+
+ sdio_claim_host(pfunc);
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n",
+ __func__);
+ goto done;
+ }
+
+ data &= RSI_INT_ENABLE_MASK;
+ ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to write to int enable register\n",
+ __func__);
+ goto done;
+ }
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n",
+ __func__);
+ goto done;
+ }
+ rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
+
+done:
+ sdio_release_host(pfunc);
+ return ret;
+}
+
+static int rsi_sdio_enable_interrupts(struct sdio_func *pfunc)
+{
+ u8 data;
+ int ret;
+
+ sdio_claim_host(pfunc);
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n", __func__);
+ goto done;
+ }
+
+ data |= ~RSI_INT_ENABLE_MASK & 0xff;
+
+ ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to write to int enable register\n",
+ __func__);
+ goto done;
+ }
+
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n", __func__);
+ goto done;
+ }
+ rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
+
+done:
+ sdio_release_host(pfunc);
+ return ret;
+}
+
static int rsi_suspend(struct device *dev)
{
- /* Not yet implemented */
- return -ENOSYS;
+ int ret;
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common;
+
+ if (!adapter) {
+ rsi_dbg(ERR_ZONE, "Device is not ready\n");
+ return -ENODEV;
+ }
+ common = adapter->priv;
+ rsi_sdio_disable_interrupts(pfunction);
+
+ ret = rsi_set_sdio_pm_caps(adapter);
+ if (ret)
+ rsi_dbg(INFO_ZONE,
+ "Setting power management caps failed\n");
+ common->fsm_state = FSM_CARD_NOT_READY;
+
+ return 0;
}
static int rsi_resume(struct device *dev)
{
- /* Not yet implemented */
- return -ENOSYS;
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common = adapter->priv;
+
+ common->fsm_state = FSM_MAC_INIT_DONE;
+ rsi_sdio_enable_interrupts(pfunction);
+
+ return 0;
}
static const struct dev_pm_ops rsi_pm_ops = {
diff --git a/drivers/net/wireless/rsi/rsi_sdio.h b/drivers/net/wireless/rsi/rsi_sdio.h
index 95e4bed..49c549b 100644
--- a/drivers/net/wireless/rsi/rsi_sdio.h
+++ b/drivers/net/wireless/rsi/rsi_sdio.h
@@ -48,6 +48,8 @@ enum sdio_interrupt_type {
#define RSI_DEVICE_BUFFER_STATUS_REGISTER 0xf3
#define RSI_FN1_INT_REGISTER 0xf9
+#define RSI_INT_ENABLE_REGISTER 0x04
+#define RSI_INT_ENABLE_MASK 0xfc
#define RSI_SD_REQUEST_MASTER 0x10000
/* FOR SD CARD ONLY */
--
2.7.4
^ permalink raw reply related
* [v2] rsi: add version information
From: Amitkumar Karwar @ 2017-09-21 12:50 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Pavani Muthyala
From: Pavani Muthyala <pavani.muthyala@redpinesignals.com>
We will dump information about firmware version, firmware file
name and operating mode during initialization.
Signed-off-by: Pavani Muthyala <pavani.muthyala@redpinesignals.com>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
---
v2: Removed driver version information.(Kalle Valo)
---
drivers/net/wireless/rsi/rsi_91x_debugfs.c | 19 ++++++-------------
drivers/net/wireless/rsi/rsi_91x_hal.c | 13 +++++++++++++
drivers/net/wireless/rsi/rsi_91x_main.c | 25 +++++++++++++++++++++++++
drivers/net/wireless/rsi/rsi_hal.h | 3 +++
drivers/net/wireless/rsi/rsi_main.h | 14 ++++++++++----
5 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_debugfs.c b/drivers/net/wireless/rsi/rsi_91x_debugfs.c
index e98eb55..8c6ca8e 100644
--- a/drivers/net/wireless/rsi/rsi_91x_debugfs.c
+++ b/drivers/net/wireless/rsi/rsi_91x_debugfs.c
@@ -83,19 +83,12 @@ static int rsi_version_read(struct seq_file *seq, void *data)
{
struct rsi_common *common = seq->private;
- common->driver_ver.major = 0;
- common->driver_ver.minor = 1;
- common->driver_ver.release_num = 0;
- common->driver_ver.patch_num = 0;
- seq_printf(seq, "Driver : %x.%d.%d.%d\nLMAC : %d.%d.%d.%d\n",
- common->driver_ver.major,
- common->driver_ver.minor,
- common->driver_ver.release_num,
- common->driver_ver.patch_num,
- common->fw_ver.major,
- common->fw_ver.minor,
- common->fw_ver.release_num,
- common->fw_ver.patch_num);
+ seq_printf(seq, "LMAC : %d.%d.%d.%d\n",
+ common->lmac_ver.major,
+ common->lmac_ver.minor,
+ common->lmac_ver.release_num,
+ common->lmac_ver.patch_num);
+
return 0;
}
diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c
index 7e8e5d4..71b02ad 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -769,6 +769,7 @@ static int auto_fw_upgrade(struct rsi_hw *adapter, u8 *flash_content,
static int rsi_load_firmware(struct rsi_hw *adapter)
{
+ struct rsi_common *common = adapter->priv;
struct rsi_host_intf_ops *hif_ops = adapter->host_intf_ops;
const struct firmware *fw_entry = NULL;
u32 regout_val = 0, content_size;
@@ -844,6 +845,18 @@ static int rsi_load_firmware(struct rsi_hw *adapter)
content_size = fw_entry->size;
rsi_dbg(INFO_ZONE, "FW Length = %d bytes\n", content_size);
+ /* Get the firmware version */
+ common->lmac_ver.ver.info.fw_ver[0] =
+ flash_content[LMAC_VER_OFFSET] & 0xFF;
+ common->lmac_ver.ver.info.fw_ver[1] =
+ flash_content[LMAC_VER_OFFSET + 1] & 0xFF;
+ common->lmac_ver.major = flash_content[LMAC_VER_OFFSET + 2] & 0xFF;
+ common->lmac_ver.release_num =
+ flash_content[LMAC_VER_OFFSET + 3] & 0xFF;
+ common->lmac_ver.minor = flash_content[LMAC_VER_OFFSET + 4] & 0xFF;
+ common->lmac_ver.patch_num = 0;
+ rsi_print_version(common);
+
status = bl_write_header(adapter, flash_content, content_size);
if (status) {
rsi_dbg(ERR_ZONE,
diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c
index b57bfdc..71b8cfb 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -20,6 +20,7 @@
#include <linux/firmware.h>
#include "rsi_mgmt.h"
#include "rsi_common.h"
+#include "rsi_hal.h"
u32 rsi_zone_enabled = /* INFO_ZONE |
INIT_ZONE |
@@ -56,6 +57,30 @@ void rsi_dbg(u32 zone, const char *fmt, ...)
}
EXPORT_SYMBOL_GPL(rsi_dbg);
+static char *opmode_str(int oper_mode)
+{
+ switch (oper_mode) {
+ case RSI_DEV_OPMODE_WIFI_ALONE:
+ return "Wi-Fi alone";
+ }
+
+ return "Unknown";
+}
+
+void rsi_print_version(struct rsi_common *common)
+{
+ rsi_dbg(ERR_ZONE, "================================================\n");
+ rsi_dbg(ERR_ZONE, "================ RSI Version Info ==============\n");
+ rsi_dbg(ERR_ZONE, "================================================\n");
+ rsi_dbg(ERR_ZONE, "FW Version\t: %d.%d.%d\n",
+ common->lmac_ver.major, common->lmac_ver.minor,
+ common->lmac_ver.release_num);
+ rsi_dbg(ERR_ZONE, "Operating mode\t: %d [%s]",
+ common->oper_mode, opmode_str(common->oper_mode));
+ rsi_dbg(ERR_ZONE, "Firmware file\t: %s", common->priv->fw_file_name);
+ rsi_dbg(ERR_ZONE, "================================================\n");
+}
+
/**
* rsi_prepare_skb() - This function prepares the skb.
* @common: Pointer to the driver private structure.
diff --git a/drivers/net/wireless/rsi/rsi_hal.h b/drivers/net/wireless/rsi/rsi_hal.h
index ad0d653..a09d36b 100644
--- a/drivers/net/wireless/rsi/rsi_hal.h
+++ b/drivers/net/wireless/rsi/rsi_hal.h
@@ -101,6 +101,9 @@
#define BBP_INFO_40MHZ 0x6
+#define FW_FLASH_OFFSET 0x820
+#define LMAC_VER_OFFSET (FW_FLASH_OFFSET + 0x200)
+
struct bl_header {
__le32 flags;
__le32 image_no;
diff --git a/drivers/net/wireless/rsi/rsi_main.h b/drivers/net/wireless/rsi/rsi_main.h
index 34089ab..a118b7a 100644
--- a/drivers/net/wireless/rsi/rsi_main.h
+++ b/drivers/net/wireless/rsi/rsi_main.h
@@ -113,8 +113,13 @@ extern __printf(2, 3) void rsi_dbg(u32 zone, const char *fmt, ...);
struct version_info {
u16 major;
u16 minor;
- u16 release_num;
- u16 patch_num;
+ u8 release_num;
+ u8 patch_num;
+ union {
+ struct {
+ u8 fw_ver[8];
+ } info;
+ } ver;
} __packed;
struct skb_info {
@@ -199,8 +204,7 @@ struct rsi_common {
struct vif_priv vif_info[RSI_MAX_VIFS];
bool mgmt_q_block;
- struct version_info driver_ver;
- struct version_info fw_ver;
+ struct version_info lmac_ver;
struct rsi_thread tx_thread;
struct sk_buff_head tx_queue[NUM_EDCA_QUEUES + 2];
@@ -334,6 +338,8 @@ struct rsi_hw {
int (*determine_event_timeout)(struct rsi_hw *adapter);
};
+void rsi_print_version(struct rsi_common *common);
+
struct rsi_host_intf_ops {
int (*read_pkt)(struct rsi_hw *adapter, u8 *pkt, u32 len);
int (*write_pkt)(struct rsi_hw *adapter, u8 *pkt, u32 len);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] wireless: broadcom: brcm80211: use setup_timer() helper
From: Allen Pais @ 2017-09-21 12:43 UTC (permalink / raw)
To: linux-kernel; +Cc: arend.vanspriel, kvalo, linux-wireless, Allen Pais
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 613caca..5adce0e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4144,10 +4144,8 @@ struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev)
init_waitqueue_head(&bus->dcmd_resp_wait);
/* Set up the watchdog timer */
- init_timer(&bus->timer);
- bus->timer.data = (unsigned long)bus;
- bus->timer.function = brcmf_sdio_watchdog;
-
+ setup_timer(&bus->timer, brcmf_sdio_watchdog,
+ (unsigned long)bus);
/* Initialize watchdog thread */
init_completion(&bus->watchdog_wait);
bus->watchdog_tsk = kthread_run(brcmf_sdio_watchdog_thread,
--
2.7.4
^ permalink raw reply related
* Re: [v2,1/2] qtnfmac: lock access to h/w in tx path
From: Sergey Matyukevich @ 2017-09-21 11:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Igor Mitsyanko, Avinash Patil
In-Reply-To: <878th870u7.fsf@codeaurora.org>
> > - these two fixes will show up in wireless-drivers-next at some point
> > in the future after you move wireless-drivers-next forward, rebasing
> > it on top of one of the upcoming "-rc"
>
> I would not use the term "rebase" here, as that means rewriting the
> history which should be avoided on public trees. What I usually do is to
> "merge" (git pull) or "fast forward" (git pull --ff-only).
>
> You are correct that eventually commits from wireless-drivers trickle
> down to wireless-drivers-next, I guess usually it takes something like
> 2-4 weeks. Most of them time they trickle down when Dave merges net to
> net-next and I fast forward wireless-drivers-next to latest net-next
> (after Dave has pulled from me). But occasionally I also merge
> wireless-drivers to wireless-drivers-next myself, for example I did that
> last cycle as there were major conflicts on iwlwifi and we wanted to fix
> those early on. The earlier the conflicts are resolved the smoother it
> is for everyone.
Understood.
> So if you have needs for getting the commits from wireless-drivers to
> wireless-drivers-next please let me know and let's see what's the best
> way forward.
Ok, good to know. But not this time, of course. We are keeping a bunch
of upcoming features and fixes in our internal tree on top of
wireless-drivers-next. So two more small patches for two more weeks
don't make any difference.
> Did this help?
Sure, thanks a lot for explanation!
Regards,
Sergey
^ permalink raw reply
* Re: [v2,1/2] qtnfmac: lock access to h/w in tx path
From: Kalle Valo @ 2017-09-21 11:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Igor Mitsyanko, Avinash Patil
In-Reply-To: <20170921080147.tvcztifyfwy2lp7g@bars>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:
> Hello Kalle,
>
>> > Fix tx path regression. Lock should be held when queuing packets
>> > to h/w fifos in order to properly handle configurations with
>> > multiple enabled interfaces.
>> >
>> > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
>>
>> 2 patches applied to wireless-drivers.git, thanks.
>>
>> 20da2ec06bfa qtnfmac: lock access to h/w in tx path
>> a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes
>
> Could you please clarify a couple of points regarding wireless-drivers-next
> and wireless-drivers trees. I checked development process article at
> wireless.wiki.kernel.org, but it looks a bit outdated.
You mean this page:
https://wireless.wiki.kernel.org/en/developers/process
Yeah, that is outdated :)
> So am I correct assuming the following: - these two fixes were applied
> to wireless-drivers because I asked to to queue them to 4.14
Correct.
> - these two fixes will show up in wireless-drivers-next at some point
> in the future after you move wireless-drivers-next forward, rebasing
> it on top of one of the upcoming "-rc"
I would not use the term "rebase" here, as that means rewriting the
history which should be avoided on public trees. What I usually do is to
"merge" (git pull) or "fast forward" (git pull --ff-only).
You are correct that eventually commits from wireless-drivers trickle
down to wireless-drivers-next, I guess usually it takes something like
2-4 weeks. Most of them time they trickle down when Dave merges net to
net-next and I fast forward wireless-drivers-next to latest net-next
(after Dave has pulled from me). But occasionally I also merge
wireless-drivers to wireless-drivers-next myself, for example I did that
last cycle as there were major conflicts on iwlwifi and we wanted to fix
those early on. The earlier the conflicts are resolved the smoother it
is for everyone.
So if you have needs for getting the commits from wireless-drivers to
wireless-drivers-next please let me know and let's see what's the best
way forward.
Did this help?
--
Kalle Valo
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-21 8:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <20170920232228.GC9210@us.netrek.org>
On Thu, Sep 21, 2017 at 09:22:28AM +1000, James Cameron wrote:
> On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> > On 09/20/2017 04:36 AM, James Cameron wrote:
> > >When the problem occurs, register 0x350 bit 25 is set, for which a
> > >comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
> > >hang.
> > >
> > >So perhaps driver should call _rtl8821ae_check_pcie_dma_hang
> > >and _rtl8821ae_reset_pcie_interface_dma.
> > >
> > >Any ideas where to do this?
> >
> > Thanks for the extended debugging.
> >
> > I was able to repeat your findings. With the 8-bit read of
> > REG_DBI_RDATA, I got poor connection stability. Reverting that part
> > made it stable again. For that reason, I pushed the partial
> > reversion of commit 40b368af4b75 ("rtlwifi: Fix alignment issues").
>
> That's great you were able to reproduce, thanks!
> [...]
> I'm still pondering a few more theories;
>
> - change write_readback, it is true now, and the while()/udelay in
> _rtl8821ae_dbi_read seems a waste, it never executes,
My test kernel "-qb" was write_readback = false in sw.c, with 8-bit
read of REG_DBI_RDATA, and has been stable for four hours. I'll focus
on some more testing of this one. It is a surprise.
http://dev.laptop.org/~quozl/z/1dutXk.txt (dmesg)
Observe how REG_DBI_FLAG+0 is briefly seen as 1, which doesn't happen
with write_readback = true.
> - clearing REG_DBI_CTRL write enable bits at the end of
> _rtl8821ae_dbi_write,
My test kernel "-qc" had reset of REG_DBI_ADDR as last step in both
_rtl8821ae_dbi_read and _rtl8821ae_dbi_write, and was very unstable,
not able to connect.
http://dev.laptop.org/~quozl/y/1dutbX.txt (git diff v4.13)
http://dev.laptop.org/~quozl/z/1dutuM.txt (dmesg)
My test kernel "-qd" had reset of REG_DBI_ADDR as last step in only
_rtl8821ae_dbi_write, and had poor connection stability.
http://dev.laptop.org/~quozl/y/1dutr3.txt (git diff v4.13)
http://dev.laptop.org/~quozl/z/1duuDc.txt (dmesg connection lost)
Based on the above two kernels, clearing REG_DBI_ADDR after a read is
a bad idea, and suggests there is some underlying asynchronicity about
the DBI access. Almost as if some other condition should signal
completion rather than zero in REG_DBI_FLAG+0.
> - switching to 32-bit access as used by rtl8192de.
My test kernel "-qe" changed RED_DBI_RDATA read to 32-bit, then used a
union hack to pull out the desired byte, and had poor connection
stability.
http://dev.laptop.org/~quozl/y/1duvIC.txt (git diff v4.13)
http://dev.laptop.org/~quozl/z/1duwI1.txt (dmesg connection lost)
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [v2,1/2] qtnfmac: lock access to h/w in tx path
From: Sergey Matyukevich @ 2017-09-21 8:01 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Igor Mitsyanko, Avinash Patil
In-Reply-To: <20170920123553.7121D6070F@smtp.codeaurora.org>
Hello Kalle,
> > Fix tx path regression. Lock should be held when queuing packets
> > to h/w fifos in order to properly handle configurations with
> > multiple enabled interfaces.
> >
> > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
>
> 2 patches applied to wireless-drivers.git, thanks.
>
> 20da2ec06bfa qtnfmac: lock access to h/w in tx path
> a715b3a0efe7 qtnfmac: cancel scans on wireless interface changes
Could you please clarify a couple of points regarding wireless-drivers-next
and wireless-drivers trees. I checked development process article at
wireless.wiki.kernel.org, but it looks a bit outdated. So am I correct
assuming the following:
- these two fixes were applied to wireless-drivers because I asked to
to queue them to 4.14
- these two fixes will show up in wireless-drivers-next at some point
in the future after you move wireless-drivers-next forward, rebasing
it on top of one of the upcoming "-rc"
Regards,
Sergey
^ permalink raw reply
* Re: AP6335 with mainline kernel
From: Arend van Spriel @ 2017-09-21 7:26 UTC (permalink / raw)
To: Vanessa Ayumi Maegima, linux-wireless
Cc: embed3d, joerg.krause, Vanessa Maegima
In-Reply-To: <CABACg+yVE+fuzT-qwjNnACqq24KQbNJOae22=v+J+0Q=8kuKRQ@mail.gmail.com>
On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
> Hi,
>
> I am trying to enable Wifi on imx7d-pico using mainline kernel. imx7d-pico
> has an AP6335 chip.
>
> I am facing some issues related to the nvram file. I am using the firmware
> provided by Buildroot (brcmfmac4339-sdio.bin). I get the following error:
>
> [ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
> clkctl 0x50
>
> I have tried to use the firmware and nvram provided by TechNexion but I get
> the same error.
>
> Is there anyone that could enable Wifi on AP6335 using kernel mainline?
> What nvram file was used?
>
> I am able to use Wifi on the board if I use the firmware, nvram file and kernel
> provided by TechNexion. They use a 4.1 kernel from NXP with the bcmdhd
> driver.
>
> So I know that the hardware is functional.
>
> Any suggestions as how to get it working with a 4.13 and brcmfmac driver is
> appreciated.
So the nvram file is specific to the wifi chipset on your platform so
best to stick with the provided one. The "HT Avail timeout" most often
is an indication that the firmware crashed. So getting more debug output
would help us understand how it ended up like that. Can you build the
brcmfmac with CONFIG_BRCMDBG and load the driver using:
$ insmod brcmfmac.ko debug=0x1416
Regards,
Arend
> Thanks!
>
> Regards,
> Vanessa
>
^ permalink raw reply
* [PATCH v2 13/31] timer: Remove meaningless .data/.function assignments
From: Kees Cook @ 2017-09-20 23:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Krzysztof Halasa, Aditya Shankar, Ganesh Krishna,
Greg Kroah-Hartman, Jens Axboe, netdev, linux-wireless, devel,
linux-kernel
In-Reply-To: <1505950075-50223-1-git-send-email-keescook@chromium.org>
Several timer users needlessly reset their .function/.data fields during
their timer callback, but nothing else changes them. Some users do not
use their .data field at all. Each instance is removed here.
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Aditya Shankar <aditya.shankar@microchip.com>
Cc: Ganesh Krishna <ganesh.krishna@microchip.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jens Axboe <axboe@fb.com>
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> # for staging
Acked-by: Krzysztof Halasa <khc@pm.waw.pl> # for wan/hdlc*
Acked-by: Jens Axboe <axboe@kernel.dk> # for amiflop
---
drivers/block/amiflop.c | 3 +--
drivers/net/wan/hdlc_cisco.c | 2 --
drivers/net/wan/hdlc_fr.c | 2 --
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +---
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index c4b1cba27178..6680d75bc857 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -323,7 +323,7 @@ static void fd_deselect (int drive)
}
-static void motor_on_callback(unsigned long nr)
+static void motor_on_callback(unsigned long ignored)
{
if (!(ciaa.pra & DSKRDY) || --on_attempts == 0) {
complete_all(&motor_on_completion);
@@ -344,7 +344,6 @@ static int fd_motor_on(int nr)
fd_select(nr);
reinit_completion(&motor_on_completion);
- motor_on_timer.data = nr;
mod_timer(&motor_on_timer, jiffies + HZ/2);
on_attempts = 10;
diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index c696d42f4502..6c98d85f2773 100644
--- a/drivers/net/wan/hdlc_cisco.c
+++ b/drivers/net/wan/hdlc_cisco.c
@@ -276,8 +276,6 @@ static void cisco_timer(unsigned long arg)
spin_unlock(&st->lock);
st->timer.expires = jiffies + st->settings.interval * HZ;
- st->timer.function = cisco_timer;
- st->timer.data = arg;
add_timer(&st->timer);
}
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index de42faca076a..7da2424c28a4 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -644,8 +644,6 @@ static void fr_timer(unsigned long arg)
state(hdlc)->settings.t391 * HZ;
}
- state(hdlc)->timer.function = fr_timer;
- state(hdlc)->timer.data = arg;
add_timer(&state(hdlc)->timer);
}
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index ac5aaafa461c..60f088babf27 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -266,7 +266,7 @@ static void update_scan_time(void)
last_scanned_shadow[i].time_scan = jiffies;
}
-static void remove_network_from_shadow(unsigned long arg)
+static void remove_network_from_shadow(unsigned long unused)
{
unsigned long now = jiffies;
int i, j;
@@ -287,7 +287,6 @@ static void remove_network_from_shadow(unsigned long arg)
}
if (last_scanned_cnt != 0) {
- hAgingTimer.data = arg;
mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME));
}
}
@@ -304,7 +303,6 @@ static int is_network_in_shadow(struct network_info *pstrNetworkInfo,
int i;
if (last_scanned_cnt == 0) {
- hAgingTimer.data = (unsigned long)user_void;
mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME));
state = -1;
} else {
--
2.7.4
^ permalink raw reply related
* Re: rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-20 23:22 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <476b183f-5cc5-9a34-1a85-332dd5244b66@lwfinger.net>
On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> On 09/20/2017 04:36 AM, James Cameron wrote:
> >When the problem occurs, register 0x350 bit 25 is set, for which a
> >comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
> >hang.
> >
> >So perhaps driver should call _rtl8821ae_check_pcie_dma_hang
> >and _rtl8821ae_reset_pcie_interface_dma.
> >
> >Any ideas where to do this?
>
> Thanks for the extended debugging.
>
> I was able to repeat your findings. With the 8-bit read of
> REG_DBI_RDATA, I got poor connection stability. Reverting that part
> made it stable again. For that reason, I pushed the partial
> reversion of commit 40b368af4b75 ("rtlwifi: Fix alignment issues").
That's great you were able to reproduce, thanks!
> Where did you detect that bit 25 of register 0x350 was set?
In _rtl8821ae_check_pcie_dma_hang on link up.
REG_DBI_FLAG (0x350 bits 16-31) is observed as;
- 0x0000 on entry to function after warm boot,
- 0x0400 on exit from function; debug bit 23 is set by the function,
- 0x0400 on entry to function on link up when the problem has not
happened,
- 0x0600 on entry to function on link up when the problem has
happened.
But I don't know if 0x0600 is useful to detect earlier, or if it is
only a symptom of link down while device active. Either way, if it
truly does signal an RX hang or firmware RX queue full, it's useful.
My "-q9" and "-qa" test kernels dump REG_DBI_CTRL and REG_DBI_FLAG.
"-q9" is with 8-bit read of REG_DBI_RDATA.
"-qa" is with 16-bit read of REG_DBI_DATA.
My "-qa" test kernel;
http://dev.laptop.org/~quozl/y/1dunwN.txt (git diff v4.13)
http://dev.laptop.org/~quozl/z/1dubX7.txt (dmesg)
REG_DBI_CTRL+3 used by _rtl8821ae_check_pcie_dma_hang is effectively
REG_DBI_FLAG+1 (0x353).
REG_DBI_CTRL is REG_DBI_ADDR; a duplicate register definition.
I'm still pondering a few more theories;
- change write_readback, it is true now, and the while()/udelay in
_rtl8821ae_dbi_read seems a waste, it never executes,
- clearing REG_DBI_CTRL write enable bits at the end of
_rtl8821ae_dbi_write,
- switching to 32-bit access as used by rtl8192de.
And a giggle from reviewing the code,
_rtl8821ae_wowlan_initialize_adapter says "Patch Pcie Rx DMA hang
after S3/S4 several times. The root cause has not be found."
... I've learned that root causes that aren't found tend to cause
further problems later. ;-)
Given this, my gut feel is firmware or silicon problem; RX DMA ceases,
the driver does not detect it, the connection is lost.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: Larry Finger @ 2017-09-20 21:48 UTC (permalink / raw)
To: James Cameron; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <20170920093633.GO9946@us.netrek.org>
On 09/20/2017 04:36 AM, James Cameron wrote:
> When the problem occurs, register 0x350 bit 25 is set, for which a
> comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
> hang.
>
> So perhaps driver should call _rtl8821ae_check_pcie_dma_hang
> and _rtl8821ae_reset_pcie_interface_dma.
>
> Any ideas where to do this?
Thanks for the extended debugging.
I was able to repeat your findings. With the 8-bit read of REG_DBI_RDATA, I got
poor connection stability. Reverting that part made it stable again. For that
reason, I pushed the partial reversion of commit 40b368af4b75 ("rtlwifi: Fix
alignment issues").
Where did you detect that bit 25 of register 0x350 was set?
Larry
^ permalink raw reply
* [PATCH] rtlwifi: rtl8821ae: Fix connection lost problem
From: Larry Finger @ 2017-09-20 21:15 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Stable, Ping-Ke Shih
In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read
of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi
this change results in reduced stability for the wireless connection.
This regression was located using bisection.
Fixes: 40b368af4b75 ("rtlwifi: Fix alignment issues")
Reported-and-tested-by: James Cameron <quozl@laptop.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.11+
Cc: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 3571ce4bd276..ac2ce86de506 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1122,7 +1122,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
- ret = rtl_read_byte(rtlpriv, read_addr);
+ ret = rtl_read_word(rtlpriv, read_addr);
}
return ret;
}
--
2.12.3
^ permalink raw reply related
* Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Johannes Berg @ 2017-09-20 19:55 UTC (permalink / raw)
To: Christian Lamparter, Andrey Konovalov
Cc: Kalle Valo, linux-wireless, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, syzkaller, Stephen Boyd, Tejun Heo, Yong Zhang
In-Reply-To: <2277141.bYDD1vAb9W@debian64>
On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
> It seems this is caused as a result of:
> -> lock_map_acquire(&work->lockdep_map);
> lock_map_release(&work->lockdep_map);
>
> in flush_work() [0]
Agree.
> This was added by:
>
> commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
> Author: Stephen Boyd <sboyd@codeaurora.org>
> Date: Fri Apr 20 17:28:50 2012 -0700
>
> workqueue: Catch more locking problems with flush_work()
Yes, but that doesn't matter.
> Looking at the Stephen's patch, it's clear that it was made
> with "static DECLARE_WORK(work, my_work)" in mind. However
> p54's led_work is "per-device", hence it is stored in the
> devices context p54_common, which is dynamically allocated.
> So, maybe revert Stephen's patch?
I disagree - as the lockdep warning says:
> > INFO: trying to register non-static key.
> > the code is fine but needs lockdep annotation.
> > turning off the locking correctness validator.
What it needs is to actually correctly go through initializing the work
at least once.
Without more information, I can't really say what's going on, but I
assume that something is failing and p54_unregister_leds() is getting
invoked without p54_init_leds() having been invoked, so essentially
it's trying to flush a work that was never initialized?
INIT_DELAYED_WORK() does, after all, initialize the lockdep map
properly via __INIT_WORK().
johannes
^ permalink raw reply
* AP6335 with mainline kernel
From: Vanessa Ayumi Maegima @ 2017-09-20 19:33 UTC (permalink / raw)
To: linux-wireless; +Cc: arend.vanspriel, embed3d, joerg.krause, Vanessa Maegima
Hi,
I am trying to enable Wifi on imx7d-pico using mainline kernel. imx7d-pico
has an AP6335 chip.
I am facing some issues related to the nvram file. I am using the firmware
provided by Buildroot (brcmfmac4339-sdio.bin). I get the following error:
[ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
clkctl 0x50
I have tried to use the firmware and nvram provided by TechNexion but I get
the same error.
Is there anyone that could enable Wifi on AP6335 using kernel mainline?
What nvram file was used?
I am able to use Wifi on the board if I use the firmware, nvram file and kernel
provided by TechNexion. They use a 4.1 kernel from NXP with the bcmdhd
driver.
So I know that the hardware is functional.
Any suggestions as how to get it working with a 4.13 and brcmfmac driver is
appreciated.
Thanks!
Regards,
Vanessa
^ permalink raw reply
* Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Christian Lamparter @ 2017-09-20 19:27 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Kalle Valo, linux-wireless, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, syzkaller, Stephen Boyd, Tejun Heo, Yong Zhang
In-Reply-To: <CAAeHK+xPoNn7i5xOzEqHX6tfDpmpb1rd0hcAxZpTHKi6B8xzsw@mail.gmail.com>
On Wednesday, September 20, 2017 8:37:08 PM CEST Andrey Konovalov wrote:
> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.
>
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
> 4.14.0-rc1-42251-gebb2c2437d80-dirty #205
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x292/0x395 lib/dump_stack.c:52
> register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
> __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
> lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
> flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
> __cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
> cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
> p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
> p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
> p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
> usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
> __device_release_driver drivers/base/dd.c:861
> device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
> device_release_driver+0x1e/0x30 drivers/base/dd.c:918
> bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
> device_del+0x5c4/0xab0 drivers/base/core.c:1985
> usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
> usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
> hub_port_connect drivers/usb/core/hub.c:4754
> hub_port_connect_change drivers/usb/core/hub.c:5009
> port_event drivers/usb/core/hub.c:5115
> hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
> process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
> process_scheduled_works kernel/workqueue.c:2179
> worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
> kthread+0x3a1/0x470 kernel/kthread.c:231
> ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
It seems this is caused as a result of:
-> lock_map_acquire(&work->lockdep_map);
lock_map_release(&work->lockdep_map);
in flush_work() [0]
This was added by:
commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri Apr 20 17:28:50 2012 -0700
workqueue: Catch more locking problems with flush_work()
Looking at the Stephen's patch, it's clear that it was made
with "static DECLARE_WORK(work, my_work)" in mind. However
p54's led_work is "per-device", hence it is stored in the
devices context p54_common, which is dynamically allocated.
So, maybe revert Stephen's patch?
[0] <http://elixir.free-electrons.com/linux/latest/source/kernel/workqueue.c#L2853>
^ permalink raw reply
* usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Andrey Konovalov @ 2017-09-20 18:37 UTC (permalink / raw)
To: Christian Lamparter, Kalle Valo, linux-wireless, netdev, LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
__lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
__cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
__device_release_driver drivers/base/dd.c:861
device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
device_release_driver+0x1e/0x30 drivers/base/dd.c:918
bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
device_del+0x5c4/0xab0 drivers/base/core.c:1985
usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
hub_port_connect drivers/usb/core/hub.c:4754
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
process_scheduled_works kernel/workqueue.c:2179
worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
^ permalink raw reply
* Re: mac80211: avoid allocating TXQs that won't be used
From: Johannes Berg @ 2017-09-20 17:51 UTC (permalink / raw)
To: Colin Ian King
Cc: David S. Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <3592b0b1-0455-ca9a-9ca7-702d7cf421ff@canonical.com>
On Wed, 2017-09-20 at 17:08 +0100, Colin Ian King wrote:
> Johannes,
>
> Static analysis with CoverityScan on linux-next today detected a null
> pointer dereference issue on commit:
>
> From 0fc4b3403d215ecd3c05505ec1f0028a227ed319 Mon Sep 17 00:00:00
> 2001
> From: Johannes Berg <johannes.berg@intel.com>
> Date: Thu, 22 Jun 2017 12:20:29 +0200
> Subject: [PATCH] mac80211: avoid allocating TXQs that won't be used
>
> Issue: sdata is null when the sdata is dereferenced by:
>
> sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
> sdata->vif.type != NL80211_IFTYPE_MONITOR)
>
> note that sdata is assigned a non-null much later with the statement
> sdata = netdev_priv(ndev).
Yeah, umm, that should be checking just 'type'. Thanks, will fix.
johannes
^ permalink raw reply
* re: mac80211: avoid allocating TXQs that won't be used
From: Colin Ian King @ 2017-09-20 16:08 UTC (permalink / raw)
To: Johannes Berg
Cc: David S. Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
Johannes,
Static analysis with CoverityScan on linux-next today detected a null
pointer dereference issue on commit:
>From 0fc4b3403d215ecd3c05505ec1f0028a227ed319 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg@intel.com>
Date: Thu, 22 Jun 2017 12:20:29 +0200
Subject: [PATCH] mac80211: avoid allocating TXQs that won't be used
Issue: sdata is null when the sdata is dereferenced by:
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_MONITOR)
note that sdata is assigned a non-null much later with the statement
sdata = netdev_priv(ndev).
Detected by CoverityScan CID#1456974 ("Explicit null dereferenced")
Colin
^ permalink raw reply
* Re: [V2, 1/9] qtnfmac: qlink: convert channel width from bitfiled to simple enum
From: Sergey Matyukevich @ 2017-09-20 15:33 UTC (permalink / raw)
To: Kalle Valo; +Cc: Igor Mitsyanko, linux-wireless, avinashp, johannes
In-Reply-To: <871sn1zh0y.fsf@purkki.adurom.net>
Hello Kalle,
> BTW, I got a mail undelivered message. Not sure why smtp.codeaurora.org
> could not find the host but reporting it here just in case:
>
> <avinashp@quantenna.com>: unable to look up host
> quantenna-com.mail.protection.outlook.com: Name or service not known
>
> <igor.mitsyanko.os@quantenna.com>: unable to look up host
> quantenna-com.mail.protection.outlook.com: Name or service not known
>
> <sergey.matyukevich.os@quantenna.com>: unable to look up host
> quantenna-com.mail.protection.outlook.com: Name or service not known
Thanks for letting us know. I see those emails im my box, but probably
because of mailing list subscription. I will check with colleagues
if they see your replies as well.
Regards,
Sergey
^ permalink raw reply
* Re: [2/2] mwifiex: use get_random_mask_addr() helper
From: Kalle Valo @ 2017-09-20 12:49 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1505720537-13362-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> Avoid calculating random MAC address in driver. Instead make
> use of 'get_random_mask_addr()' function.
>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
e9a3846afaa4 mwifiex: use get_random_mask_addr() helper
--
https://patchwork.kernel.org/patch/9955631/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: avoid storing random_mac in private
From: Kalle Valo @ 2017-09-20 12:48 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1505717702-10342-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> Application will keep track of whether MAC address randomization
> is enabled or not during scan. But at present driver is storing
> 'random_mac' in mwifiex_private which implies even after scan is
> done driver has some reference to the earlier 'scan request'. To
> avoid this, make use of 'mac_addr' variable in 'scan_request' to
> store 'random_mac'. This structure will be freed by cfg80211 once
> scan is done.
>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
e251a882c0ba mwifiex: avoid storing random_mac in private
--
https://patchwork.kernel.org/patch/9955573/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: make const arrays static to shink object code size
From: Kalle Valo @ 2017-09-20 12:47 UTC (permalink / raw)
To: Colin Ian King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170916153424.28285-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate const arrays on the stack, instead make them static
> Makes the object code smaller by nearly 300 bytes:
>
> Before:
> text data bss dec hex filename
> 69260 16149 576 85985 14fe1 cfg80211.o
>
> After:
> text data bss dec hex filename
> 68385 16725 576 85686 14eb6 cfg80211.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
d157bcfaf854 mwifiex: make const arrays static to shink object code size
--
https://patchwork.kernel.org/patch/9954375/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: remove unnecessary call to memset
From: Kalle Valo @ 2017-09-20 12:47 UTC (permalink / raw)
To: Himanshu Jha
Cc: amitkarwar, nishants, gbhat, huxm, linux-wireless, netdev,
Himanshu Jha
In-Reply-To: <1505133964-376-1-git-send-email-himanshujha199640@gmail.com>
Himanshu Jha <himanshujha199640@gmail.com> wrote:
> call to memset to assign 0 value immediately after allocating
> memory with kzalloc is unnecesaary as kzalloc allocates the memory
> filled with 0 value.
>
> Semantic patch used to resolve this issue:
>
> @@
> expression e,e2; constant c;
> statement S;
> @@
>
> e = kzalloc(e2, c);
> if(e == NULL) S
> - memset(e, 0, e2);
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
85dafc129196 mwifiex: remove unnecessary call to memset
--
https://patchwork.kernel.org/patch/9947331/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: check for mfg_mode in add_virtual_intf
From: Kalle Valo @ 2017-09-20 12:46 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1504816363-31015-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> If driver is loaded with 'mfg_mode' enabled, then the sending
> commands are not allowed. So, skip sending commands, to firmware
> in mwifiex_add_virtual_intf if 'mfg_mode' is enabled.
>
> Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added interface")
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
26177d7f3969 mwifiex: check for mfg_mode in add_virtual_intf
--
https://patchwork.kernel.org/patch/9942827/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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