RE: [patch V2] wireless: mwifiex: Use the proper interfaces
> > + u32 queue_delay = ktime_to_ms(net_timedelta(skb->tstamp)); > > FWIW, I think the same as patch 12 applies here. net_timedelta() doesn't > really seem to be a good way to calculate time deltas. Shall we change net_timedelta to ktime_sub() using ktime_get()? + u32 queue_delay = ktime_to_ms(ktime_sub(ktime_get(), skb->tstamp)); Thanks, Bing > > And yes - I've seen situations where this matters, e.g. when running > ntpdate after system startup. > > johannes >
RE: [patch V2] wireless: mwifiex: Use the proper interfaces
+ u32 queue_delay = ktime_to_ms(net_timedelta(skb-tstamp)); FWIW, I think the same as patch 12 applies here. net_timedelta() doesn't really seem to be a good way to calculate time deltas. Shall we change net_timedelta to ktime_sub() using ktime_get()? + u32 queue_delay = ktime_to_ms(ktime_sub(ktime_get(), skb-tstamp)); Thanks, Bing And yes - I've seen situations where this matters, e.g. when running ntpdate after system startup. johannes
RE: [patch 11/13] wireless: mwifiex: Use the proper interfaces
Hi Thomas, Thanks for your patch. > Why is converting time formats so desired if there are proper > interfaces for this? > > Signed-off-by: Thomas Gleixner > Cc: Bing Zhao > Cc: "John W. Linville" > Cc: linux-wirel...@vger.kernel.org [...] > Index: linux/drivers/net/wireless/mwifiex/main.c > === > --- linux.orig/drivers/net/wireless/mwifiex/main.c > +++ linux/drivers/net/wireless/mwifiex/main.c > @@ -611,7 +611,6 @@ mwifiex_hard_start_xmit(struct sk_buff * > struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev); > struct sk_buff *new_skb; > struct mwifiex_txinfo *tx_info; > - struct timeval tv; > > dev_dbg(priv->adapter->dev, "data: %lu BSS(%d-%d): Data <= kernel\n", > jiffies, priv->bss_type, priv->bss_num); > @@ -658,8 +657,7 @@ mwifiex_hard_start_xmit(struct sk_buff * >* firmware for aggregate delay calculation for stats and >* MSDU lifetime expiry. >*/ > - do_gettimeofday(); > - skb->tstamp = timeval_to_ktime(tv); > + __net_timestamp(skb); > > mwifiex_queue_tx_pkt(priv, skb); > > Index: linux/drivers/net/wireless/mwifiex/tdls.c > === > --- linux.orig/drivers/net/wireless/mwifiex/tdls.c > +++ linux/drivers/net/wireless/mwifiex/tdls.c > @@ -552,8 +552,7 @@ int mwifiex_send_tdls_data_frame(struct > tx_info->bss_num = priv->bss_num; > tx_info->bss_type = priv->bss_type; > > - do_gettimeofday(); > - skb->tstamp = timeval_to_ktime(tv); > + __net_timestamp(skb); I guess we need to remove "struct timeval tv" local variable too. > mwifiex_queue_tx_pkt(priv, skb); > > return 0; > @@ -710,8 +709,7 @@ int mwifiex_send_tdls_action_frame(struc > pkt_len = skb->len - MWIFIEX_MGMT_FRAME_HEADER_SIZE - sizeof(pkt_len); > memcpy(skb->data + MWIFIEX_MGMT_FRAME_HEADER_SIZE, _len, > sizeof(pkt_len)); > - do_gettimeofday(); > - skb->tstamp = timeval_to_ktime(tv); > + __net_timestamp(skb); And here too. Could you please remove these two "struct timeval tv" and send v2 with my ACK? Acked-by: Bing Zhao Thanks, Bing > mwifiex_queue_tx_pkt(priv, skb); > > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch 11/13] wireless: mwifiex: Use the proper interfaces
Hi Thomas, Thanks for your patch. Why is converting time formats so desired if there are proper interfaces for this? Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Bing Zhao bz...@marvell.com Cc: John W. Linville linvi...@tuxdriver.com Cc: linux-wirel...@vger.kernel.org [...] Index: linux/drivers/net/wireless/mwifiex/main.c === --- linux.orig/drivers/net/wireless/mwifiex/main.c +++ linux/drivers/net/wireless/mwifiex/main.c @@ -611,7 +611,6 @@ mwifiex_hard_start_xmit(struct sk_buff * struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev); struct sk_buff *new_skb; struct mwifiex_txinfo *tx_info; - struct timeval tv; dev_dbg(priv-adapter-dev, data: %lu BSS(%d-%d): Data = kernel\n, jiffies, priv-bss_type, priv-bss_num); @@ -658,8 +657,7 @@ mwifiex_hard_start_xmit(struct sk_buff * * firmware for aggregate delay calculation for stats and * MSDU lifetime expiry. */ - do_gettimeofday(tv); - skb-tstamp = timeval_to_ktime(tv); + __net_timestamp(skb); mwifiex_queue_tx_pkt(priv, skb); Index: linux/drivers/net/wireless/mwifiex/tdls.c === --- linux.orig/drivers/net/wireless/mwifiex/tdls.c +++ linux/drivers/net/wireless/mwifiex/tdls.c @@ -552,8 +552,7 @@ int mwifiex_send_tdls_data_frame(struct tx_info-bss_num = priv-bss_num; tx_info-bss_type = priv-bss_type; - do_gettimeofday(tv); - skb-tstamp = timeval_to_ktime(tv); + __net_timestamp(skb); I guess we need to remove struct timeval tv local variable too. mwifiex_queue_tx_pkt(priv, skb); return 0; @@ -710,8 +709,7 @@ int mwifiex_send_tdls_action_frame(struc pkt_len = skb-len - MWIFIEX_MGMT_FRAME_HEADER_SIZE - sizeof(pkt_len); memcpy(skb-data + MWIFIEX_MGMT_FRAME_HEADER_SIZE, pkt_len, sizeof(pkt_len)); - do_gettimeofday(tv); - skb-tstamp = timeval_to_ktime(tv); + __net_timestamp(skb); And here too. Could you please remove these two struct timeval tv and send v2 with my ACK? Acked-by: Bing Zhao bz...@marvell.com Thanks, Bing mwifiex_queue_tx_pkt(priv, skb); return 0; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mwifiex: use time_after()
Hi Manuel,
Thanks for the patch.
> To be future-proof and for better readability the time comparisons are
> modified to use time_after() instead of plain, error-prone math.
>
> Signed-off-by: Manuel Schölling
Acked-by: Bing Zhao
Regards,
Bing
> ---
> drivers/net/wireless/mwifiex/main.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mwifiex/main.h
> b/drivers/net/wireless/mwifiex/main.h
> index d53e1e8..3191066 100644
> --- a/drivers/net/wireless/mwifiex/main.h
> +++ b/drivers/net/wireless/mwifiex/main.h
> @@ -1101,7 +1101,7 @@ mwifiex_11h_get_csa_closed_channel(struct
> mwifiex_private *priv)
> return 0;
>
> /* Clear csa channel, if DFS channel move time has passed */
> - if (jiffies > priv->csa_expire_time) {
> + if (time_after(jiffies, priv->csa_expire_time)) {
> priv->csa_chan = 0;
> priv->csa_expire_time = 0;
> }
> --
> 1.7.10.4
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] mwifiex: use time_after()
Hi Manuel,
Thanks for the patch.
To be future-proof and for better readability the time comparisons are
modified to use time_after() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling manuel.schoell...@gmx.de
Acked-by: Bing Zhao bz...@marvell.com
Regards,
Bing
---
drivers/net/wireless/mwifiex/main.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/main.h
b/drivers/net/wireless/mwifiex/main.h
index d53e1e8..3191066 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -1101,7 +1101,7 @@ mwifiex_11h_get_csa_closed_channel(struct
mwifiex_private *priv)
return 0;
/* Clear csa channel, if DFS channel move time has passed */
- if (jiffies priv-csa_expire_time) {
+ if (time_after(jiffies, priv-csa_expire_time)) {
priv-csa_chan = 0;
priv-csa_expire_time = 0;
}
--
1.7.10.4
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH][linux-next] wireless: fixed bad dev_info integer type warning
Hi Jan, Thanks for the patch. > The pointer difference (ptrdiff_t) should be formatted by %tx, not %lx. > > Signed-off-by: Jan Moskyto Matejka Acked-by: Bing Zhao Regards, Bing > --- > drivers/net/wireless/mwifiex/pcie.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/mwifiex/pcie.c > b/drivers/net/wireless/mwifiex/pcie.c > index 9c1f427..e04141a 100644 > --- a/drivers/net/wireless/mwifiex/pcie.c > +++ b/drivers/net/wireless/mwifiex/pcie.c > @@ -2321,7 +2321,7 @@ static void mwifiex_pcie_fw_dump_work(struct > work_struct *work) > if (stat != RDWR_STATUS_DONE) > continue; > > - dev_info(adapter->dev, "%s done: size=0x%lx\n", > + dev_info(adapter->dev, "%s done: size=0x%tx\n", >entry->mem_name, dbg_ptr - entry->mem_ptr); > memset(filename, 0, sizeof(filename)); > memcpy(filename, name_prefix, strlen(name_prefix)); > -- > 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the wireless-next tree
Hi Stephen,
> Hi John,
>
> After merging the wireless-next tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/wireless/mwifiex/pcie.c: In function 'mwifiex_pcie_fw_dump_work':
> drivers/net/wireless/mwifiex/pcie.c:2290:3: error: implicit declaration of
> function 'vmalloc' [-
> Werror=implicit-function-declaration]
>entry->mem_ptr = vmalloc(memory_size + 1);
>^
> drivers/net/wireless/mwifiex/pcie.c:2290:18: warning: assignment makes
> pointer from integer without a
> cast [enabled by default]
>entry->mem_ptr = vmalloc(memory_size + 1);
> ^
> drivers/net/wireless/mwifiex/pcie.c:2361:4: error: implicit declaration of
> function 'vfree' [-
> Werror=implicit-function-declaration]
> vfree(entry->mem_ptr);
> ^
>
> Caused by commit e050c76fcf49 ("mwifiex: add firmware dump feature for
> PCIe").
>
> I have applied this patch for today:
Sorry for the trouble and thanks a lot for the fix.
Regards,
Bing
>
> From: Stephen Rothwell
> Date: Wed, 23 Apr 2014 13:44:59 +1000
> Subject: [PATCH] mwifiex: using vmallog requires including vmalloc.h
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/wireless/mwifiex/pcie.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c
> b/drivers/net/wireless/mwifiex/pcie.c
> index 51989b31137a..9c1f42754bbe 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -17,6 +17,7 @@
> * this warranty disclaimer.
> */
>
> +#include
> #include
>
> #include "decl.h"
> --
> 1.9.2
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the wireless-next tree
Hi Stephen, Hi John, After merging the wireless-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/wireless/mwifiex/pcie.c: In function 'mwifiex_pcie_fw_dump_work': drivers/net/wireless/mwifiex/pcie.c:2290:3: error: implicit declaration of function 'vmalloc' [- Werror=implicit-function-declaration] entry-mem_ptr = vmalloc(memory_size + 1); ^ drivers/net/wireless/mwifiex/pcie.c:2290:18: warning: assignment makes pointer from integer without a cast [enabled by default] entry-mem_ptr = vmalloc(memory_size + 1); ^ drivers/net/wireless/mwifiex/pcie.c:2361:4: error: implicit declaration of function 'vfree' [- Werror=implicit-function-declaration] vfree(entry-mem_ptr); ^ Caused by commit e050c76fcf49 (mwifiex: add firmware dump feature for PCIe). I have applied this patch for today: Sorry for the trouble and thanks a lot for the fix. Regards, Bing From: Stephen Rothwell s...@canb.auug.org.au Date: Wed, 23 Apr 2014 13:44:59 +1000 Subject: [PATCH] mwifiex: using vmallog requires including vmalloc.h Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/net/wireless/mwifiex/pcie.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c index 51989b31137a..9c1f42754bbe 100644 --- a/drivers/net/wireless/mwifiex/pcie.c +++ b/drivers/net/wireless/mwifiex/pcie.c @@ -17,6 +17,7 @@ * this warranty disclaimer. */ +#include linux/vmalloc.h #include linux/firmware.h #include decl.h -- 1.9.2 -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH][linux-next] wireless: fixed bad dev_info integer type warning
Hi Jan, Thanks for the patch. The pointer difference (ptrdiff_t) should be formatted by %tx, not %lx. Signed-off-by: Jan Moskyto Matejka m...@suse.cz Acked-by: Bing Zhao bz...@marvell.com Regards, Bing --- drivers/net/wireless/mwifiex/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c index 9c1f427..e04141a 100644 --- a/drivers/net/wireless/mwifiex/pcie.c +++ b/drivers/net/wireless/mwifiex/pcie.c @@ -2321,7 +2321,7 @@ static void mwifiex_pcie_fw_dump_work(struct work_struct *work) if (stat != RDWR_STATUS_DONE) continue; - dev_info(adapter-dev, %s done: size=0x%lx\n, + dev_info(adapter-dev, %s done: size=0x%tx\n, entry-mem_name, dbg_ptr - entry-mem_ptr); memset(filename, 0, sizeof(filename)); memcpy(filename, name_prefix, strlen(name_prefix)); -- 1.8.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 6/7] mwifiex: Remove casts of pointer to same type
Hi Joe,
Thanks for the patch.
> Casting a pointer to a pointer of the same type is pointless,
> so remove these unnecessary casts.
>
> Done via coccinelle script:
>
> $ cat typecast_2.cocci
> @@
> type T;
> T *foo;
> @@
>
> - (T *)foo
> + foo
>
> Signed-off-by: Joe Perches
Acked-by: Bing Zhao
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/pcie.c | 6 +++---
> drivers/net/wireless/mwifiex/scan.c | 2 +-
> drivers/net/wireless/mwifiex/tdls.c | 6 +++---
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c
> b/drivers/net/wireless/mwifiex/pcie.c
> index 9f1683b..c0c598d 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1009,7 +1009,7 @@ static int mwifiex_pcie_send_data_complete(struct
> mwifiex_adapter *adapter)
> card->tx_buf_list[wrdoneidx] = NULL;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->txbd_ring[wrdoneidx];
> + desc2 = card->txbd_ring[wrdoneidx];
> memset(desc2, 0, sizeof(*desc2));
> } else {
> desc = card->txbd_ring[wrdoneidx];
> @@ -1094,7 +1094,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter,
> struct sk_buff *skb,
> card->tx_buf_list[wrindx] = skb;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->txbd_ring[wrindx];
> + desc2 = card->txbd_ring[wrindx];
> desc2->paddr = buf_pa;
> desc2->len = (u16)skb->len;
> desc2->frag_len = (u16)skb->len;
> @@ -1254,7 +1254,7 @@ static int mwifiex_pcie_process_recv_data(struct
> mwifiex_adapter *adapter)
> card->rx_buf_list[rd_index] = skb_tmp;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->rxbd_ring[rd_index];
> + desc2 = card->rxbd_ring[rd_index];
> desc2->paddr = buf_pa;
> desc2->len = skb_tmp->len;
> desc2->frag_len = skb_tmp->len;
> diff --git a/drivers/net/wireless/mwifiex/scan.c
> b/drivers/net/wireless/mwifiex/scan.c
> index f139244..825aeec 100644
> --- a/drivers/net/wireless/mwifiex/scan.c
> +++ b/drivers/net/wireless/mwifiex/scan.c
> @@ -1653,7 +1653,7 @@ mwifiex_parse_single_response_buf(struct
> mwifiex_private *priv, u8 **bss_info,
> curr_bcn_bytes -= ETH_ALEN;
>
> if (!ext_scan) {
> - rssi = (s32) *(u8 *)current_ptr;
> + rssi = (s32) *current_ptr;
> rssi = (-rssi) * 100; /* Convert dBm to mBm */
> current_ptr += sizeof(u8);
> curr_bcn_bytes -= sizeof(u8);
> diff --git a/drivers/net/wireless/mwifiex/tdls.c
> b/drivers/net/wireless/mwifiex/tdls.c
> index 8cec6e4..97662a1 100644
> --- a/drivers/net/wireless/mwifiex/tdls.c
> +++ b/drivers/net/wireless/mwifiex/tdls.c
> @@ -730,13 +730,13 @@ void mwifiex_process_tdls_action_frame(struct
> mwifiex_private *priv,
>
> if (len < (sizeof(struct ethhdr) + 3))
> return;
> - if (*(u8 *)(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
> + if (*(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
> return;
> - if (*(u8 *)(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
> + if (*(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
> return;
>
> peer = buf + ETH_ALEN;
> - action = *(u8 *)(buf + sizeof(struct ethhdr) + 2);
> + action = *(buf + sizeof(struct ethhdr) + 2);
>
> /* just handle TDLS setup request/response/confirm */
> if (action > WLAN_TDLS_SETUP_CONFIRM)
> --
> 1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 6/7] mwifiex: Remove casts of pointer to same type
Hi Joe,
Thanks for the patch.
Casting a pointer to a pointer of the same type is pointless,
so remove these unnecessary casts.
Done via coccinelle script:
$ cat typecast_2.cocci
@@
type T;
T *foo;
@@
- (T *)foo
+ foo
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Bing Zhao bz...@marvell.com
Thanks,
Bing
---
drivers/net/wireless/mwifiex/pcie.c | 6 +++---
drivers/net/wireless/mwifiex/scan.c | 2 +-
drivers/net/wireless/mwifiex/tdls.c | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/pcie.c
b/drivers/net/wireless/mwifiex/pcie.c
index 9f1683b..c0c598d 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -1009,7 +1009,7 @@ static int mwifiex_pcie_send_data_complete(struct
mwifiex_adapter *adapter)
card-tx_buf_list[wrdoneidx] = NULL;
if (reg-pfu_enabled) {
- desc2 = (void *)card-txbd_ring[wrdoneidx];
+ desc2 = card-txbd_ring[wrdoneidx];
memset(desc2, 0, sizeof(*desc2));
} else {
desc = card-txbd_ring[wrdoneidx];
@@ -1094,7 +1094,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter,
struct sk_buff *skb,
card-tx_buf_list[wrindx] = skb;
if (reg-pfu_enabled) {
- desc2 = (void *)card-txbd_ring[wrindx];
+ desc2 = card-txbd_ring[wrindx];
desc2-paddr = buf_pa;
desc2-len = (u16)skb-len;
desc2-frag_len = (u16)skb-len;
@@ -1254,7 +1254,7 @@ static int mwifiex_pcie_process_recv_data(struct
mwifiex_adapter *adapter)
card-rx_buf_list[rd_index] = skb_tmp;
if (reg-pfu_enabled) {
- desc2 = (void *)card-rxbd_ring[rd_index];
+ desc2 = card-rxbd_ring[rd_index];
desc2-paddr = buf_pa;
desc2-len = skb_tmp-len;
desc2-frag_len = skb_tmp-len;
diff --git a/drivers/net/wireless/mwifiex/scan.c
b/drivers/net/wireless/mwifiex/scan.c
index f139244..825aeec 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -1653,7 +1653,7 @@ mwifiex_parse_single_response_buf(struct
mwifiex_private *priv, u8 **bss_info,
curr_bcn_bytes -= ETH_ALEN;
if (!ext_scan) {
- rssi = (s32) *(u8 *)current_ptr;
+ rssi = (s32) *current_ptr;
rssi = (-rssi) * 100; /* Convert dBm to mBm */
current_ptr += sizeof(u8);
curr_bcn_bytes -= sizeof(u8);
diff --git a/drivers/net/wireless/mwifiex/tdls.c
b/drivers/net/wireless/mwifiex/tdls.c
index 8cec6e4..97662a1 100644
--- a/drivers/net/wireless/mwifiex/tdls.c
+++ b/drivers/net/wireless/mwifiex/tdls.c
@@ -730,13 +730,13 @@ void mwifiex_process_tdls_action_frame(struct
mwifiex_private *priv,
if (len (sizeof(struct ethhdr) + 3))
return;
- if (*(u8 *)(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
+ if (*(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
return;
- if (*(u8 *)(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
+ if (*(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
return;
peer = buf + ETH_ALEN;
- action = *(u8 *)(buf + sizeof(struct ethhdr) + 2);
+ action = *(buf + sizeof(struct ethhdr) + 2);
/* just handle TDLS setup request/response/confirm */
if (action WLAN_TDLS_SETUP_CONFIRM)
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.14] mwifiex: rename usb driver name registerring to usb core
Both libertas USB driver and mwifiex_usb driver are registerring
with name 'usb8xxx'. The following conflict happens while trying
to load both drivers.
[6.211307] Error: Driver 'usb8xxx' is already registered...
[6.217261] mwifiex_usb: Driver register failed!
Fix it by renaming mwifiex_usb driver's name.
Reported-by: Fengguang Wu
Signed-off-by: Bing Zhao
---
drivers/net/wireless/mwifiex/usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index e8ebbd4..cb6b70a 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -22,8 +22,6 @@
#define USB_VERSION"1.0"
-static const char usbdriver_name[] = "usb8xxx";
-
static struct mwifiex_if_ops usb_ops;
static struct semaphore add_remove_card_sem;
static struct usb_card_rec *usb_card;
@@ -567,7 +565,7 @@ static void mwifiex_usb_disconnect(struct usb_interface
*intf)
}
static struct usb_driver mwifiex_usb_driver = {
- .name = usbdriver_name,
+ .name = "mwifiex_usb",
.probe = mwifiex_usb_probe,
.disconnect = mwifiex_usb_disconnect,
.id_table = mwifiex_usb_table,
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [mwifiex/USB8897] Error: Driver 'usb8xxx' is already registered, aborting...
Hi Fengguang, > Greetings, > > I got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 68458dede7e0055198318dcb0318df3b4f419507 > CommitDate: Mon Jan 13 14:46:59 2014 -0500 > > mwifiex: add USB8897 support > > [6.211307] Error: Driver 'usb8xxx' is already registered, aborting... > [6.211307] Error: Driver 'usb8xxx' is already registered, aborting... > [6.217261] mwifiex_usb: Driver register failed! > [6.217261] mwifiex_usb: Driver register failed! Thanks for reporting this bug. I will send the patch to fix it shortly. Regards, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [mwifiex/USB8897] Error: Driver 'usb8xxx' is already registered, aborting...
Hi Fengguang, Greetings, I got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 68458dede7e0055198318dcb0318df3b4f419507 CommitDate: Mon Jan 13 14:46:59 2014 -0500 mwifiex: add USB8897 support [6.211307] Error: Driver 'usb8xxx' is already registered, aborting... [6.211307] Error: Driver 'usb8xxx' is already registered, aborting... [6.217261] mwifiex_usb: Driver register failed! [6.217261] mwifiex_usb: Driver register failed! Thanks for reporting this bug. I will send the patch to fix it shortly. Regards, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.14] mwifiex: rename usb driver name registerring to usb core
Both libertas USB driver and mwifiex_usb driver are registerring
with name 'usb8xxx'. The following conflict happens while trying
to load both drivers.
[6.211307] Error: Driver 'usb8xxx' is already registered...
[6.217261] mwifiex_usb: Driver register failed!
Fix it by renaming mwifiex_usb driver's name.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Bing Zhao bz...@marvell.com
---
drivers/net/wireless/mwifiex/usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index e8ebbd4..cb6b70a 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -22,8 +22,6 @@
#define USB_VERSION1.0
-static const char usbdriver_name[] = usb8xxx;
-
static struct mwifiex_if_ops usb_ops;
static struct semaphore add_remove_card_sem;
static struct usb_card_rec *usb_card;
@@ -567,7 +565,7 @@ static void mwifiex_usb_disconnect(struct usb_interface
*intf)
}
static struct usb_driver mwifiex_usb_driver = {
- .name = usbdriver_name,
+ .name = mwifiex_usb,
.probe = mwifiex_usb_probe,
.disconnect = mwifiex_usb_disconnect,
.id_table = mwifiex_usb_table,
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3.6 17/19] mwifiex: slight optimization of addr compare
Hi Ding,
> - if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
> -ibss_coal_resp->bssid, ETH_ALEN)) {
> + if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address,
> ibss_coal_resp->bssid))
Still wrong... ;)
Have you actually run the checkpatch.pl script?
By the way, your subject prefix "PATCH v3.6" is confusing. It ought to be
"PATCH v6", I guess.
Thanks,
Bing
RE: [PATCH v3.5 17/19] mwifiex: slight optimization of addr compare
Hi Ding,
> Use possibly more efficient ether_addr_equal
> instead of memcmp.
> @@ -782,8 +782,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct
> mwifiex_private *priv,
> }
>
> /* If BSSID is diff, modify current BSS parameters */
> - if (memcmp(priv->curr_bss_params.bss_descriptor.mac_address,
> -ibss_coal_resp->bssid, ETH_ALEN)) {
> + if (!ether_addr_equal(priv->curr_bss_params.bss_descriptor.mac_address,
> ibss_coal_resp->bssid))
Could you break the line?
If you run "checkpatch.pl" you will spot this warning.
> if (!IS_11N_ENABLED(priv) ||
> - memcmp(priv->curr_addr, rx_pkt_hdr->eth803_hdr.h_dest, ETH_ALEN)) {
> + !ether_addr_equal_unaligned(priv->curr_addr,
> rx_pkt_hdr->eth803_hdr.h_dest)) {
Also over 80 characters here.
Thanks,
Bing
RE: [PATCH v3.5 17/19] mwifiex: slight optimization of addr compare
Hi Ding,
Use possibly more efficient ether_addr_equal
instead of memcmp.
@@ -782,8 +782,7 @@ static int mwifiex_ret_ibss_coalescing_status(struct
mwifiex_private *priv,
}
/* If BSSID is diff, modify current BSS parameters */
- if (memcmp(priv-curr_bss_params.bss_descriptor.mac_address,
-ibss_coal_resp-bssid, ETH_ALEN)) {
+ if (!ether_addr_equal(priv-curr_bss_params.bss_descriptor.mac_address,
ibss_coal_resp-bssid))
Could you break the line?
If you run checkpatch.pl you will spot this warning.
if (!IS_11N_ENABLED(priv) ||
- memcmp(priv-curr_addr, rx_pkt_hdr-eth803_hdr.h_dest, ETH_ALEN)) {
+ !ether_addr_equal_unaligned(priv-curr_addr,
rx_pkt_hdr-eth803_hdr.h_dest)) {
Also over 80 characters here.
Thanks,
Bing
RE: [PATCH v3.6 17/19] mwifiex: slight optimization of addr compare
Hi Ding,
- if (memcmp(priv-curr_bss_params.bss_descriptor.mac_address,
-ibss_coal_resp-bssid, ETH_ALEN)) {
+ if (!ether_addr_equal(priv-curr_bss_params.bss_descriptor.mac_address,
ibss_coal_resp-bssid))
Still wrong... ;)
Have you actually run the checkpatch.pl script?
By the way, your subject prefix PATCH v3.6 is confusing. It ought to be
PATCH v6, I guess.
Thanks,
Bing
RE: [PATCH 15/21] mwifiex: slight optimization of addr compare
Hi Ding,
> diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c
> b/drivers/net/wireless/mwifiex/11n_rxreorder.c
> index ada809f..a180298 100644
> --- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
> +++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
> @@ -164,7 +164,7 @@ mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private
> *priv, int tid, u8 *ta)
>
> spin_lock_irqsave(>rx_reorder_tbl_lock, flags);
> list_for_each_entry(tbl, >rx_reorder_tbl_ptr, list) {
> - if (!memcmp(tbl->ta, ta, ETH_ALEN) && tbl->tid == tid) {
> + if (ether_addr_equal_unaligned(tbl->ta, ta) && tbl->tid == tid)
> {
checkpatch.pl found several warnings in this patch.
WARNING: line over 80 characters
Could you please fix these warnings by splitting the function arguments into
multiple lines?
Thanks,
Bing
RE: [PATCH 15/21] mwifiex: slight optimization of addr compare
Hi Ding,
diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c
b/drivers/net/wireless/mwifiex/11n_rxreorder.c
index ada809f..a180298 100644
--- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
@@ -164,7 +164,7 @@ mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private
*priv, int tid, u8 *ta)
spin_lock_irqsave(priv-rx_reorder_tbl_lock, flags);
list_for_each_entry(tbl, priv-rx_reorder_tbl_ptr, list) {
- if (!memcmp(tbl-ta, ta, ETH_ALEN) tbl-tid == tid) {
+ if (ether_addr_equal_unaligned(tbl-ta, ta) tbl-tid == tid)
{
checkpatch.pl found several warnings in this patch.
WARNING: line over 80 characters
Could you please fix these warnings by splitting the function arguments into
multiple lines?
Thanks,
Bing
RE: [PATCH 09/11] mwifiex: Remove extern from function prototypes
Hi Joe, Thanks for your patch. > There are a mix of function prototypes with and without extern > in the kernel sources. Standardize on not using extern for > function prototypes. > > Function prototypes don't need to be written with extern. > extern is assumed by the compiler. Its use is as unnecessary as > using auto to declare automatic/local variables in a block. > > Signed-off-by: Joe Perches Acked-by: Bing Zhao Thanks, Bing > --- > drivers/net/wireless/mwifiex/wmm.h | 24 ++-- > 1 file changed, 10 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 09/11] mwifiex: Remove extern from function prototypes
Hi Joe, Thanks for your patch. There are a mix of function prototypes with and without extern in the kernel sources. Standardize on not using extern for function prototypes. Function prototypes don't need to be written with extern. extern is assumed by the compiler. Its use is as unnecessary as using auto to declare automatic/local variables in a block. Signed-off-by: Joe Perches j...@perches.com Acked-by: Bing Zhao bz...@marvell.com Thanks, Bing --- drivers/net/wireless/mwifiex/wmm.h | 24 ++-- 1 file changed, 10 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 11/19] wireless: Change variable type to bool
Hi Peter, Thanks for your patch. > The variables cancel_scan_cmd, enable_data, hs_activate and valid are > only assigned the values true and false. Change its type to bool. > > The simplified semantic patch that find this problem is as > follows (http://coccinelle.lip6.fr/): > > @exists@ > type T; > identifier b; > @@ > - T > + bool > b = ...; > ... when any > b = \(true\|false\) > > Signed-off-by: Peter Senna Tschudin Acked-by: Bing Zhao Thanks, Bing > --- > drivers/net/wireless/mwifiex/cmdevt.c | 2 +- > drivers/net/wireless/mwifiex/join.c| 2 +- > drivers/net/wireless/mwifiex/sta_cmd.c | 2 +- > drivers/net/wireless/mwifiex/wmm.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 11/19] wireless: Change variable type to bool
Hi Peter, Thanks for your patch. The variables cancel_scan_cmd, enable_data, hs_activate and valid are only assigned the values true and false. Change its type to bool. The simplified semantic patch that find this problem is as follows (http://coccinelle.lip6.fr/): @exists@ type T; identifier b; @@ - T + bool b = ...; ... when any b = \(true\|false\) Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com Acked-by: Bing Zhao bz...@marvell.com Thanks, Bing --- drivers/net/wireless/mwifiex/cmdevt.c | 2 +- drivers/net/wireless/mwifiex/join.c| 2 +- drivers/net/wireless/mwifiex/sta_cmd.c | 2 +- drivers/net/wireless/mwifiex/wmm.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm_ops
> Convert the mwifiex/pci driver to use dev_pm_ops for power management and > remove Legacy PM handling. This change re-uses existing suspend and resume > interfaces for dev_pm_ops, and changes CONFIG_PM ifdefs to CONFIG_PM_SLEEP > as the driver does not support run-time PM. > > Signed-off-by: Shuah Khan Acked-by: Bing Zhao Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm_ops
Convert the mwifiex/pci driver to use dev_pm_ops for power management and remove Legacy PM handling. This change re-uses existing suspend and resume interfaces for dev_pm_ops, and changes CONFIG_PM ifdefs to CONFIG_PM_SLEEP as the driver does not support run-time PM. Signed-off-by: Shuah Khan shuah...@samsung.com Acked-by: Bing Zhao bz...@marvell.com Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm ops
Hi Hauke,
Thanks for your comments.
> > @@ -213,7 +227,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
> > if (user_rmmod) {
> > #ifdef CONFIG_PM
> > if (adapter->is_suspended)
> > - mwifiex_pcie_resume(pdev);
> > + __mwifiex_pcie_resume(pdev);
>
> You could use mwifiex_pcie_resume(>dev) here and then the extra
> function __mwifiex_pcie_resume() is not needed any more.
That makes more sense.
Thanks,
Bing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm ops
Hi Shuah, Thanks for the patch. > Convert the mwifiex/pci driver to use dev_pm_ops for power management and > remove Legacy PM handling. This change re-uses existing suspend and resume > interfaces for dev_pm_ops. > > Signed-off-by: Shuah Khan Acked-by: Bing Zhao Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm ops
Hi Shuah, Thanks for the patch. Convert the mwifiex/pci driver to use dev_pm_ops for power management and remove Legacy PM handling. This change re-uses existing suspend and resume interfaces for dev_pm_ops. Signed-off-by: Shuah Khan shuah...@samsung.com Acked-by: Bing Zhao bz...@marvell.com Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: Convert mwifiex/pcie to dev_pm_ops from legacy pm ops
Hi Hauke,
Thanks for your comments.
@@ -213,7 +227,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (user_rmmod) {
#ifdef CONFIG_PM
if (adapter-is_suspended)
- mwifiex_pcie_resume(pdev);
+ __mwifiex_pcie_resume(pdev);
You could use mwifiex_pcie_resume(pdev-dev) here and then the extra
function __mwifiex_pcie_resume() is not needed any more.
That makes more sense.
Thanks,
Bing
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
Hi Harvey,
> From: Huawei Yang
>
> In function 'mwifiex_write_data_complete' it need tx info to find the
> mwifiex_private to updates statistics and wake up tx queues.
> Or we may trigger tx queues timeout when transmitting lots of mgmt frames.
>
> Signed-off-by: Huawei Yang
> ---
> drivers/net/wireless/mwifiex/cfg80211.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
> b/drivers/net/wireless/mwifiex/cfg80211.c
> index e42b266..b4e2538 100644
> --- a/drivers/net/wireless/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/mwifiex/cfg80211.c
> @@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> struct sk_buff *skb;
> u16 pkt_len;
> const struct ieee80211_mgmt *mgmt;
> + struct mwifiex_txinfo *tx_info;
> struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev-
> >netdev);
>
> if (!buf || !len) {
> @@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> wiphy_err(wiphy, "allocate skb failed for management
> frame\n");
> return -ENOMEM;
> }
> +
Here checkpatch.pl script reports whitespace damaged error.
I can fix it in my local tree and resend v3 to John after the 3.11 merge window.
Thanks,
Bing
> + tx_info = MWIFIEX_SKB_TXCB(skb);
> + tx_info->bss_num = priv->bss_num;
> + tx_info->bss_type = priv->bss_type;
>
> mwifiex_form_mgmt_frame(skb, buf, len);
> mwifiex_queue_tx_pkt(priv, skb);
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] mwifiex: add tx info to skb when forming mgmt frame
Hi Harvey, Thanks for your patch. > From: Huawei Yang > > In function 'mwifiex_write_data_complete' it need tx info to find the > mwifiex_private to updates > statistics and wake up tx queues. Or we may trigger tx queues timeout when > transmitting lots of mgmt > frames burstly. Please shorten the commit log to less than 68 characters per line. > > Signed-off-by: Huawei Yang > --- > drivers/net/wireless/mwifiex/cfg80211.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/wireless/mwifiex/cfg80211.c > b/drivers/net/wireless/mwifiex/cfg80211.c > index e42b266..e8655f9 100644 > --- a/drivers/net/wireless/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/mwifiex/cfg80211.c > @@ -166,6 +166,10 @@ mwifiex_form_mgmt_frame(struct sk_buff *skb, const u8 > *buf, size_t len) > memcpy(skb_put(skb, len - sizeof(struct ieee80211_hdr_3addr)), > buf + sizeof(struct ieee80211_hdr_3addr), > len - sizeof(struct ieee80211_hdr_3addr)); > + > + tx_info = MWIFIEX_SKB_TXCB(skb); > + tx_info->bss_num = priv->bss_num; > + tx_info->bss_type = priv->bss_type; This code doesn't compile because both tx_info and priv are undefined in this function. Perhaps you meant to add it in mwifiex_cfg80211_mgmt_tx() instead? @@ -216,6 +216,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wirele return -ENOMEM; } + tx_info = MWIFIEX_SKB_TXCB(skb); + tx_info->bss_num = priv->bss_num; + tx_info->bss_type = priv->bss_type; + mwifiex_form_mgmt_frame(skb, buf, len); mwifiex_queue_tx_pkt(priv, skb); > > skb->priority = LOW_PRIO_TID; > do_gettimeofday(); Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] mwifiex: add tx info to skb when forming mgmt frame
Hi Harvey, Thanks for your patch. From: Huawei Yang harvey.huawei.y...@gmail.com In function 'mwifiex_write_data_complete' it need tx info to find the mwifiex_private to updates statistics and wake up tx queues. Or we may trigger tx queues timeout when transmitting lots of mgmt frames burstly. Please shorten the commit log to less than 68 characters per line. Signed-off-by: Huawei Yang harvey.huawei.y...@gmail.com --- drivers/net/wireless/mwifiex/cfg80211.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c index e42b266..e8655f9 100644 --- a/drivers/net/wireless/mwifiex/cfg80211.c +++ b/drivers/net/wireless/mwifiex/cfg80211.c @@ -166,6 +166,10 @@ mwifiex_form_mgmt_frame(struct sk_buff *skb, const u8 *buf, size_t len) memcpy(skb_put(skb, len - sizeof(struct ieee80211_hdr_3addr)), buf + sizeof(struct ieee80211_hdr_3addr), len - sizeof(struct ieee80211_hdr_3addr)); + + tx_info = MWIFIEX_SKB_TXCB(skb); + tx_info-bss_num = priv-bss_num; + tx_info-bss_type = priv-bss_type; This code doesn't compile because both tx_info and priv are undefined in this function. Perhaps you meant to add it in mwifiex_cfg80211_mgmt_tx() instead? @@ -216,6 +216,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wirele return -ENOMEM; } + tx_info = MWIFIEX_SKB_TXCB(skb); + tx_info-bss_num = priv-bss_num; + tx_info-bss_type = priv-bss_type; + mwifiex_form_mgmt_frame(skb, buf, len); mwifiex_queue_tx_pkt(priv, skb); skb-priority = LOW_PRIO_TID; do_gettimeofday(tv); Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
Hi Harvey,
From: Huawei Yang harvey.huawei.y...@gmail.com
In function 'mwifiex_write_data_complete' it need tx info to find the
mwifiex_private to updates statistics and wake up tx queues.
Or we may trigger tx queues timeout when transmitting lots of mgmt frames.
Signed-off-by: Huawei Yang harvey.huawei.y...@gmail.com
---
drivers/net/wireless/mwifiex/cfg80211.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
b/drivers/net/wireless/mwifiex/cfg80211.c
index e42b266..b4e2538 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
struct wireless_dev *wdev,
struct sk_buff *skb;
u16 pkt_len;
const struct ieee80211_mgmt *mgmt;
+ struct mwifiex_txinfo *tx_info;
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev-
netdev);
if (!buf || !len) {
@@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
struct wireless_dev *wdev,
wiphy_err(wiphy, allocate skb failed for management
frame\n);
return -ENOMEM;
}
+
Here checkpatch.pl script reports whitespace damaged error.
I can fix it in my local tree and resend v3 to John after the 3.11 merge window.
Thanks,
Bing
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info-bss_num = priv-bss_num;
+ tx_info-bss_type = priv-bss_type;
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
> I didn't get the same result..In my case, it's working fine. > But as Bing's result, i will check more and share the result. I want to add that my kernel is from "cros/release-R26-3701.B" branch with this HEAD: 4e13a9c CHERRY-PICK: UPSTREAM: loop: prevent bdev freeing while device in use Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
I didn't get the same result..In my case, it's working fine. But as Bing's result, i will check more and share the result. I want to add that my kernel is from cros/release-R26-3701.B branch with this HEAD: 4e13a9c CHERRY-PICK: UPSTREAM: loop: prevent bdev freeing while device in use Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
> I think the proposal on the table is to take Seungwon's patches > instead of mine. Assuming they solve your problems, I'm OK with that. > I think he was requesting testing the first of his two patches alone > and then both of his two patches together. Test #1: Swungwon's patch #1 alone [1] Test #2: Swungwon's patch #2 alone [1] Test #3: Swungwon's patch #1 and #2 [1] Test #4: Doug's original patch [2] Test #1 and #3: it doesn't work; system reboots due to kernel hung_task Test #2 and #4: it works; instead of hung_task driver gets CRC error (which is expected) Thanks, Bing [1] https://lkml.org/lkml/2013/4/8/316 [2] https://lkml.org/lkml/2013/3/15/583 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
I think the proposal on the table is to take Seungwon's patches instead of mine. Assuming they solve your problems, I'm OK with that. I think he was requesting testing the first of his two patches alone and then both of his two patches together. Test #1: Swungwon's patch #1 alone [1] Test #2: Swungwon's patch #2 alone [1] Test #3: Swungwon's patch #1 and #2 [1] Test #4: Doug's original patch [2] Test #1 and #3: it doesn't work; system reboots due to kernel hung_task Test #2 and #4: it works; instead of hung_task driver gets CRC error (which is expected) Thanks, Bing [1] https://lkml.org/lkml/2013/4/8/316 [2] https://lkml.org/lkml/2013/3/15/583 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Doug, > > I tested Doug's patch on my failing unit. > > > > Without this patch, mmc got hung_task and rebooted eventually. > > With this patch applied, mmc returns CRC error instead of hung_task, and > > the error is handled > gracefully. > > Have you tried one or both or Seungwon's fixes without mine? I only tested your original patch. That was several months ago I think. I still have that unit. Let me know if you want me to try Seungwon's patches. Thanks, Bing > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Seungwon, > > I don't have the failing unit myself, so we'll have to get Bing to try > > the patches. You are suggesting that we try applying both of your > > patches, right? > Did you test the patch? > I wonder that both are good for your side. I tested Doug's patch on my failing unit. Without this patch, mmc got hung_task and rebooted eventually. With this patch applied, mmc returns CRC error instead of hung_task, and the error is handled gracefully. Thanks, Bing > > Thanks, > Seungwon Jeon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Seungwon, I don't have the failing unit myself, so we'll have to get Bing to try the patches. You are suggesting that we try applying both of your patches, right? Did you test the patch? I wonder that both are good for your side. I tested Doug's patch on my failing unit. Without this patch, mmc got hung_task and rebooted eventually. With this patch applied, mmc returns CRC error instead of hung_task, and the error is handled gracefully. Thanks, Bing Thanks, Seungwon Jeon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Doug, I tested Doug's patch on my failing unit. Without this patch, mmc got hung_task and rebooted eventually. With this patch applied, mmc returns CRC error instead of hung_task, and the error is handled gracefully. Have you tried one or both or Seungwon's fixes without mine? I only tested your original patch. That was several months ago I think. I still have that unit. Let me know if you want me to try Seungwon's patches. Thanks, Bing -Doug -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 1/1] mwifiex: Remove stop_net_dev_queue operation when uap handling packets forwarding.
Hi Huawei,
Thanks for the patch.
> Under uap mode mwifiex may stop all net tx queues on forwarding packets. This
> may stop some tx queues
> and they never have chance to be waked up... There is also no need to check
> tx_pending and stop
> queues here. Because local host has such kind of check when transmitting
> packets and it's not proper
> to have forwarding affect local transmitting.
>
> Signed-off-by: Huawei Yang
Reviewed-by: Avinash Patil
Acked-by: Bing Zhao
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/uap_txrx.c |4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/uap_txrx.c
> b/drivers/net/wireless/mwifiex/uap_txrx.c
> index a018e42..11df2b2 100644
> --- a/drivers/net/wireless/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/mwifiex/uap_txrx.c
> @@ -95,10 +95,6 @@ static void mwifiex_uap_queue_bridged_pkt(struct
> mwifiex_private *priv,
> atomic_inc(>tx_pending);
> atomic_inc(>pending_bridged_pkts);
>
> - if ((atomic_read(>tx_pending) >= MAX_TX_PENDING)) {
> - mwifiex_set_trans_start(priv->netdev);
> - mwifiex_stop_net_dev_queue(priv->netdev, priv->adapter);
> - }
> return;
> }
>
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 1/1] mwifiex: Remove stop_net_dev_queue operation when uap handling packets forwarding.
Hi Huawei,
Thanks for the patch.
Under uap mode mwifiex may stop all net tx queues on forwarding packets. This
may stop some tx queues
and they never have chance to be waked up... There is also no need to check
tx_pending and stop
queues here. Because local host has such kind of check when transmitting
packets and it's not proper
to have forwarding affect local transmitting.
Signed-off-by: Huawei Yang harvey.huawei.y...@gmail.com
Reviewed-by: Avinash Patil pat...@marvell.com
Acked-by: Bing Zhao bz...@marvell.com
Thanks,
Bing
---
drivers/net/wireless/mwifiex/uap_txrx.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/uap_txrx.c
b/drivers/net/wireless/mwifiex/uap_txrx.c
index a018e42..11df2b2 100644
--- a/drivers/net/wireless/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/mwifiex/uap_txrx.c
@@ -95,10 +95,6 @@ static void mwifiex_uap_queue_bridged_pkt(struct
mwifiex_private *priv,
atomic_inc(adapter-tx_pending);
atomic_inc(adapter-pending_bridged_pkts);
- if ((atomic_read(adapter-tx_pending) = MAX_TX_PENDING)) {
- mwifiex_set_trans_start(priv-netdev);
- mwifiex_stop_net_dev_queue(priv-netdev, priv-adapter);
- }
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] net/wireless/mwifiex/pcie: Convert to dev_pm_ops from legacy pm ops
Hi Shuah,
> Convert the driver to use dev_pm_ops for power management and remove Legacy PM
> handling. This change re-uses existing suspend and resume interfaces for
> dev_pm_ops.
>
> Signed-off-by: Shuah Khan
> Cc: Shuah Khan
> Suggested-by: rafael.j.wyso...@intel.com
Acked-by: Bing Zhao
Thanks,
Bing
> ---
>
> Rafael,
>
> This is the first driver patch to convert drivers to use dev_pm_ops for
> power management. Please review for the approach and make suggestions for
> improvement.
>
> thanks,
> -- Shuah
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [RFC PATCH] net/wireless/mwifiex/pcie: Convert to dev_pm_ops from legacy pm ops
Hi Shuah,
Convert the driver to use dev_pm_ops for power management and remove Legacy PM
handling. This change re-uses existing suspend and resume interfaces for
dev_pm_ops.
Signed-off-by: Shuah Khan shuah...@samsung.com
Cc: Shuah Khan shuahk...@gmail.com
Suggested-by: rafael.j.wyso...@intel.com
Acked-by: Bing Zhao bz...@marvell.com
Thanks,
Bing
---
Rafael,
This is the first driver patch to convert drivers to use dev_pm_ops for
power management. Please review for the approach and make suggestions for
improvement.
thanks,
-- Shuah
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Marcel, > Hi Bing, > > > Add a "wireless/nl80211_iftype" entry in the net device sysfs > > file structure to indicate the mode of the wireless device so > > it can be discovered easily from userspace. > > I do question a little bit the usefulness for this one. > It would only work on netdev and on wdev devices. It's true. That's why the new sysfs entry is added in the 'wireless' placeholder. /sys/class/net/ethX/wireless/ For non-wireless dev, this won't apply. Thanks, Bing > Using nl80211 to discover this information seems a lot better approach. > > Regards > > Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Marcel, Hi Bing, Add a wireless/nl80211_iftype entry in the net device sysfs file structure to indicate the mode of the wireless device so it can be discovered easily from userspace. I do question a little bit the usefulness for this one. It would only work on netdev and on wdev devices. It's true. That's why the new sysfs entry is added in the 'wireless' placeholder. /sys/class/net/ethX/wireless/ For non-wireless dev, this won't apply. Thanks, Bing Using nl80211 to discover this information seems a lot better approach. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net-sysfs: Add entry for nl80211 interface type
Add a "wireless/nl80211_iftype" entry in the net device sysfs
file structure to indicate the mode of the wireless device so
it can be discovered easily from userspace.
Signed-off-by: Paul Stewart
Signed-off-by: Bing Zhao
---
net/core/net-sysfs.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 7427ab5..454bd7f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -448,7 +449,24 @@ static struct attribute_group netstat_group = {
};
#if IS_ENABLED(CONFIG_WIRELESS_EXT) || IS_ENABLED(CONFIG_CFG80211)
+static ssize_t show_nl80211_iftype(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct net_device *netdev = to_net_dev(dev);
+ ssize_t ret = 0;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+ if (netdev->ieee80211_ptr)
+ ret = sprintf(buf, "%d\n", netdev->ieee80211_ptr->iftype);
+ rtnl_unlock();
+
+ return ret;
+}
+static DEVICE_ATTR(nl80211_iftype, S_IRUGO, show_nl80211_iftype, NULL);
+
static struct attribute *wireless_attrs[] = {
+ _attr_nl80211_iftype.attr,
NULL
};
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net-sysfs: Add entry for nl80211 interface type
Add a wireless/nl80211_iftype entry in the net device sysfs
file structure to indicate the mode of the wireless device so
it can be discovered easily from userspace.
Signed-off-by: Paul Stewart ps...@chromium.org
Signed-off-by: Bing Zhao bz...@marvell.com
---
net/core/net-sysfs.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 7427ab5..454bd7f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -17,6 +17,7 @@
#include linux/nsproxy.h
#include net/sock.h
#include net/net_namespace.h
+#include net/cfg80211.h
#include linux/rtnetlink.h
#include linux/vmalloc.h
#include linux/export.h
@@ -448,7 +449,24 @@ static struct attribute_group netstat_group = {
};
#if IS_ENABLED(CONFIG_WIRELESS_EXT) || IS_ENABLED(CONFIG_CFG80211)
+static ssize_t show_nl80211_iftype(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct net_device *netdev = to_net_dev(dev);
+ ssize_t ret = 0;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+ if (netdev-ieee80211_ptr)
+ ret = sprintf(buf, %d\n, netdev-ieee80211_ptr-iftype);
+ rtnl_unlock();
+
+ return ret;
+}
+static DEVICE_ATTR(nl80211_iftype, S_IRUGO, show_nl80211_iftype, NULL);
+
static struct attribute *wireless_attrs[] = {
+ dev_attr_nl80211_iftype.attr,
NULL
};
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [ 099/171 ] mwifiex: fix race when queuing commands
Hi Steven, > 3.6.11.2 stable review patch. > If anyone has any objections, please let me know. > > -- > > From: Amitkumar Karwar > > [ Upstream commit 00d7ea11ff0783e24fe70778f3141270b561aaa1 ] > > Running the following script repeatedly on XO-4 with SD8787 > produces command timeout and system lockup. The patch 099/171 and 100/171 (mwifiex: skip pending commands after function shutdown) are intended for 3.8 to solve a race issue found on XO-4 platform. For 3.7 and lower kernel versions, these patches are not verified. I'd suggest do not merge them to 3.6.11.x to avoid potential side effects. Later, if we get a user report of the same problem on 3.6, we can verify these patches on his/her platform and add these patches back. Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 099/171 ] mwifiex: fix race when queuing commands
Hi Steven, 3.6.11.2 stable review patch. If anyone has any objections, please let me know. -- From: Amitkumar Karwar akar...@marvell.com [ Upstream commit 00d7ea11ff0783e24fe70778f3141270b561aaa1 ] Running the following script repeatedly on XO-4 with SD8787 produces command timeout and system lockup. The patch 099/171 and 100/171 (mwifiex: skip pending commands after function shutdown) are intended for 3.8 to solve a race issue found on XO-4 platform. For 3.7 and lower kernel versions, these patches are not verified. I'd suggest do not merge them to 3.6.11.x to avoid potential side effects. Later, if we get a user report of the same problem on 3.6, we can verify these patches on his/her platform and add these patches back. Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 054/102] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Luis, > 3.5.7.10 -stable review patch. If anyone has any objections, please let me > know. > > -- > > From: Bing Zhao > > commit 084c7189acb3f969c855536166042e27f5dd703f upstream. > > curr_cmd points to the command that is in processing or waiting > for its command response from firmware. If the function shutdown > happens to occur at this time we should cancel the cmd timer and > put the command back to free queue. > > Tested-by: Marco Cesarano > Signed-off-by: Bing Zhao > Signed-off-by: John W. Linville > Signed-off-by: Luis Henriques This patch is intended for kernel 3.8+. Please drop it from linux-3.5.7.10 stable. Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 14/56] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Ben, Greg,
> > From: Bing Zhao
> >
> > commit 084c7189acb3f969c855536166042e27f5dd703f upstream.
> >
> > curr_cmd points to the command that is in processing or waiting
> > for its command response from firmware. If the function shutdown
> > happens to occur at this time we should cancel the cmd timer and
> > put the command back to free queue.
> >
> > Tested-by: Marco Cesarano
> > Signed-off-by: Bing Zhao
> > Signed-off-by: John W. Linville
> > Signed-off-by: Greg Kroah-Hartman
>
> This also had:
>
> Cc: # 3.8
>
> so I wonder whether this is good/bad/indifferent for 3.0.y.
Please drop this patch from stable kernel < 3.8.
Thanks,
Bing
>
> Ben.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [ 25/68] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Greg, > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Bing Zhao > > commit 084c7189acb3f969c855536166042e27f5dd703f upstream. > > curr_cmd points to the command that is in processing or waiting > for its command response from firmware. If the function shutdown > happens to occur at this time we should cancel the cmd timer and > put the command back to free queue. > > Tested-by: Marco Cesarano > Signed-off-by: Bing Zhao > Signed-off-by: John W. Linville > Signed-off-by: Greg Kroah-Hartman > This patch is intended for kernel 3.8+. Please drop it from linux-3.4.y queue. Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 25/68] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Greg, 3.4-stable review patch. If anyone has any objections, please let me know. -- From: Bing Zhao bz...@marvell.com commit 084c7189acb3f969c855536166042e27f5dd703f upstream. curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Tested-by: Marco Cesarano ma...@marvell.com Signed-off-by: Bing Zhao bz...@marvell.com Signed-off-by: John W. Linville linvi...@tuxdriver.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org This patch is intended for kernel 3.8+. Please drop it from linux-3.4.y queue. Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 14/56] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Ben, Greg,
From: Bing Zhao bz...@marvell.com
commit 084c7189acb3f969c855536166042e27f5dd703f upstream.
curr_cmd points to the command that is in processing or waiting
for its command response from firmware. If the function shutdown
happens to occur at this time we should cancel the cmd timer and
put the command back to free queue.
Tested-by: Marco Cesarano ma...@marvell.com
Signed-off-by: Bing Zhao bz...@marvell.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
This also had:
Cc: sta...@vger.kernel.org # 3.8
so I wonder whether this is good/bad/indifferent for 3.0.y.
Please drop this patch from stable kernel 3.8.
Thanks,
Bing
Ben.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 054/102] mwifiex: cancel cmd timer and free curr_cmd in shutdown process
Hi Luis, 3.5.7.10 -stable review patch. If anyone has any objections, please let me know. -- From: Bing Zhao bz...@marvell.com commit 084c7189acb3f969c855536166042e27f5dd703f upstream. curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Tested-by: Marco Cesarano ma...@marvell.com Signed-off-by: Bing Zhao bz...@marvell.com Signed-off-by: John W. Linville linvi...@tuxdriver.com Signed-off-by: Luis Henriques luis.henriq...@canonical.com This patch is intended for kernel 3.8+. Please drop it from linux-3.5.7.10 stable. Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Daniel, > > Do you have any concern for OLPC platforms with above change? If it doesn't > > seem to break OLPC I > will send a patch to the list. > > Looks fine to me. Thanks for investigating. Thanks. I've just sent the patch. Regards, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9] libertas: fix crash for SD8688
For SD8688, FUNC_INIT command is queued before fw_ready flag is
set. This causes the following crash as lbs_thread blocks any
command if fw_ready is not set.
[ 209.338953] [] (__schedule+0x610/0x764) from []
(__lbs_cmd+0xb8/0x130 [libertas])
[ 209.348340] [] (__lbs_cmd+0xb8/0x130 [libertas]) from []
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [] (if_sdio_power_on+0x18c/0x20c
[libertas_sdio])
[ 209.373052] [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from
[] (if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
[] (sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
[] (driver_probe_device+0x12c/0x348)
[ 209.407214] [] (driver_probe_device+0x12c/0x348) from []
(__driver_attach+0x78/0x9c)
[ 209.416798] [] (__driver_attach+0x78/0x9c) from []
(bus_for_each_dev+0x50/0x88)
[ 209.425946] [] (bus_for_each_dev+0x50/0x88) from []
(bus_add_driver+0x108/0x268)
[ 209.435180] [] (bus_add_driver+0x108/0x268) from []
(driver_register+0xa4/0x134)
[ 209.26] [] (driver_register+0xa4/0x134) from []
(if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
from [] (do_one_initcall+0x98/0x174)
[ 209.466236] [] (do_one_initcall+0x98/0x174) from []
(load_module+0x1c5c/0x1f80)
[ 209.475390] [] (load_module+0x1c5c/0x1f80) from []
(sys_init_module+0x104/0x128)
[ 209.484632] [] (sys_init_module+0x104/0x128) from []
(ret_fast_syscall+0x0/0x38)
Fix it by setting fw_ready flag prior to queuing FUNC_INIT command.
Cc: # 3.5+
Reported-by: Lubomir Rintel
Tested-by: Lubomir Rintel
Signed-off-by: Bing Zhao
---
drivers/net/wireless/libertas/if_sdio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 739309e..4557833 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,11 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
sdio_release_host(func);
+ /* Set fw_ready before queuing any commands so that
+* lbs_thread won't block from sending them to firmware.
+*/
+ priv->fw_ready = 1;
+
/*
* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
*/
@@ -839,7 +844,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
}
- priv->fw_ready = 1;
wake_up(>pwron_waitq);
if (!card->started) {
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9] libertas: fix crash for SD8688
For SD8688, FUNC_INIT command is queued before fw_ready flag is
set. This causes the following crash as lbs_thread blocks any
command if fw_ready is not set.
[ 209.338953] [c0502248] (__schedule+0x610/0x764) from [bf20ae24]
(__lbs_cmd+0xb8/0x130 [libertas])
[ 209.348340] [bf20ae24] (__lbs_cmd+0xb8/0x130 [libertas]) from [bf222474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [bf222474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf2226c4] (if_sdio_power_on+0x18c/0x20c
[libertas_sdio])
[ 209.373052] [bf2226c4] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from
[bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
[bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
[c02e729c] (driver_probe_device+0x12c/0x348)
[ 209.407214] [c02e729c] (driver_probe_device+0x12c/0x348) from [c02e7530]
(__driver_attach+0x78/0x9c)
[ 209.416798] [c02e7530] (__driver_attach+0x78/0x9c) from [c02e5658]
(bus_for_each_dev+0x50/0x88)
[ 209.425946] [c02e5658] (bus_for_each_dev+0x50/0x88) from [c02e6810]
(bus_add_driver+0x108/0x268)
[ 209.435180] [c02e6810] (bus_add_driver+0x108/0x268) from [c02e782c]
(driver_register+0xa4/0x134)
[ 209.26] [c02e782c] (driver_register+0xa4/0x134) from [bf22601c]
(if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [bf22601c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
from [c00085b8] (do_one_initcall+0x98/0x174)
[ 209.466236] [c00085b8] (do_one_initcall+0x98/0x174) from [c0076504]
(load_module+0x1c5c/0x1f80)
[ 209.475390] [c0076504] (load_module+0x1c5c/0x1f80) from [c007692c]
(sys_init_module+0x104/0x128)
[ 209.484632] [c007692c] (sys_init_module+0x104/0x128) from [c0008c40]
(ret_fast_syscall+0x0/0x38)
Fix it by setting fw_ready flag prior to queuing FUNC_INIT command.
Cc: sta...@vger.kernel.org # 3.5+
Reported-by: Lubomir Rintel lkund...@v3.sk
Tested-by: Lubomir Rintel lkund...@v3.sk
Signed-off-by: Bing Zhao bz...@marvell.com
---
drivers/net/wireless/libertas/if_sdio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 739309e..4557833 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,11 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
sdio_release_host(func);
+ /* Set fw_ready before queuing any commands so that
+* lbs_thread won't block from sending them to firmware.
+*/
+ priv-fw_ready = 1;
+
/*
* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
*/
@@ -839,7 +844,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
netdev_alert(priv-dev, CMD_FUNC_INIT cmd failed\n);
}
- priv-fw_ready = 1;
wake_up(card-pwron_waitq);
if (!card-started) {
--
1.7.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Daniel, Do you have any concern for OLPC platforms with above change? If it doesn't seem to break OLPC I will send a patch to the list. Looks fine to me. Thanks for investigating. Thanks. I've just sent the patch. Regards, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Daniel,
> > There seems to be a race condition in lbs_thread().
> >
> > At line 582:
> > 582 if (!priv->fw_ready)
> > 583 continue;
> >
> > The fw_ready is 0, so you never get the chance to execute the FUNC_INIT
> > command.
> >
> > 617 /* Execute the next command */
> > 618 if (!priv->dnld_sent && !priv->cur_cmd)
> > 619 lbs_execute_next_command(priv);
> >
> >
> > Could you try the following change?
> >
> > diff --git a/drivers/net/wireless/libertas/if_sdio.c
> > b/drivers/net/wireless/libe
> > index 739309e..8f5d977 100644
> > --- a/drivers/net/wireless/libertas/if_sdio.c
> > +++ b/drivers/net/wireless/libertas/if_sdio.c
> > @@ -825,6 +825,8 @@ static void if_sdio_finish_power_on(struct if_sdio_card
> > *car
> >
> > sdio_release_host(func);
> >
> > + priv->fw_ready = 1;
> > +
> > /*
> > * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
> > */
> > @@ -839,7 +841,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
> > *car
> > netdev_alert(priv->dev, "CMD_FUNC_INIT cmd
> > failed\n");
> > }
> >
> > - priv->fw_ready = 1;
> > wake_up(>pwron_waitq);
> >
> > if (!card->started) {
>
> Thank you.
> Everything seem to work fine for me with the patch applied.
Do you have any concern for OLPC platforms with above change? If it doesn't
seem to break OLPC I will send a patch to the list.
Thanks,
Bing
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Daniel,
There seems to be a race condition in lbs_thread().
At line 582:
582 if (!priv-fw_ready)
583 continue;
The fw_ready is 0, so you never get the chance to execute the FUNC_INIT
command.
617 /* Execute the next command */
618 if (!priv-dnld_sent !priv-cur_cmd)
619 lbs_execute_next_command(priv);
Could you try the following change?
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libe
index 739309e..8f5d977 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,8 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*car
sdio_release_host(func);
+ priv-fw_ready = 1;
+
/*
* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
*/
@@ -839,7 +841,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*car
netdev_alert(priv-dev, CMD_FUNC_INIT cmd
failed\n);
}
- priv-fw_ready = 1;
wake_up(card-pwron_waitq);
if (!card-started) {
Thank you.
Everything seem to work fine for me with the patch applied.
Do you have any concern for OLPC platforms with above change? If it doesn't
seem to break OLPC I will send a patch to the list.
Thanks,
Bing
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Lubomir,
> > > @@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct
> > > if_sdio_card *card)
> > >
> > > sdio_release_host(func);
> > >
> > > - /*
> > > - * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
> > > - */
> > > - if (card->model == MODEL_8688) {
> > > - struct cmd_header cmd;
> > > -
> > > - memset(, 0, sizeof(cmd));
> > > -
> > > - lbs_deb_sdio("send function INIT command\n");
> > > - if (__lbs_cmd(priv, CMD_FUNC_INIT, , sizeof(cmd),
> > > - lbs_cmd_copyback, (unsigned long) ))
> > > - netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
> > > - }
> > > -
> >
> > Removing FUNC_INIT could break things in some scenarios.
> > Could you please test the following case?
> >
> > 1. insmod liberates -> download firmware, send FUNC_INIT, ...
> > 2. rmmod libertas -> send FUNC_SHUTDOWN command to firmware; BT is still
> > working.
> > 3. insmod libertas -> skip firmware downloading, send FUNC_INIT, ...
> >
> > If FUNC_INIT is removed, I don't expect step 3 to work.
>
> In case btmrvl_sdio is loaded, the driver always locks up in FUNC_INIT
> upon probe time, thus I'm not able to proceed to further steps.
>
> [ 209.338953] [] (__schedule+0x610/0x764) from []
> (__lbs_cmd+0xb8/0x130
> [libertas])
> [ 209.348340] [] (__lbs_cmd+0xb8/0x130 [libertas]) from
> []
> (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
> [ 209.360136] [] (if_sdio_finish_power_on+0xec/0x1b0
> [libertas_sdio]) from []
> (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
> [ 209.373052] [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
> from []
> (if_sdio_probe+0x200/0x31c [libertas_sdio])
> [ 209.385316] [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
> []
> (sdio_bus_probe+0x94/0xfc [mmc_core])
> [ 209.396748] [] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
> []
> (driver_probe_device+0x12c/0x348)
> [ 209.407214] [] (driver_probe_device+0x12c/0x348) from
> []
> (__driver_attach+0x78/0x9c)
> [ 209.416798] [] (__driver_attach+0x78/0x9c) from []
> (bus_for_each_dev+0x50/0x88)
> [ 209.425946] [] (bus_for_each_dev+0x50/0x88) from []
> (bus_add_driver+0x108/0x268)
> [ 209.435180] [] (bus_add_driver+0x108/0x268) from []
> (driver_register+0xa4/0x134)
> [ 209.26] [] (driver_register+0xa4/0x134) from []
> (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
> [ 209.455339] [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
> from []
> (do_one_initcall+0x98/0x174)
> [ 209.466236] [] (do_one_initcall+0x98/0x174) from []
> (load_module+0x1c5c/0x1f80)
> [ 209.475390] [] (load_module+0x1c5c/0x1f80) from []
> (sys_init_module+0x104/0x128)
> [ 209.484632] [] (sys_init_module+0x104/0x128) from []
> (ret_fast_syscall+0x0/0x38)
>
> In case btmrvl_sdio is _not_ loaded, insmod returns, but driver locks up
> waiting for FUNC_INIT to finish:
>
> [ 300.538859] [] (__schedule+0x610/0x764) from []
> (__lbs_cmd+0xb8/0x130
> [libertas])
> [ 300.548600] [] (__lbs_cmd+0xb8/0x130 [libertas]) from
> []
> (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
> [ 300.560398] [] (if_sdio_finish_power_on+0xec/0x1b0
> [libertas_sdio]) from []
> (if_sdio_do_prog_firmware+0x414/0x454 [libertas_sdio])
> [ 300.574052] [] (if_sdio_do_prog_firmware+0x414/0x454
> [libertas_sdio]) from []
> (lbs_fw_loaded+0x24/0x58 [libertas])
> [ 300.586907] [] (lbs_fw_loaded+0x24/0x58 [libertas]) from
> []
> (request_firmware_work_func+0xb0/0xf4)
> [ 300.597746] [] (request_firmware_work_func+0xb0/0xf4) from
> []
> (process_one_work+0x348/0x6a8)
> [ 300.608288] [] (process_one_work+0x348/0x6a8) from []
> (worker_thread+0x268/0x390)
> [ 300.617630] [] (worker_thread+0x268/0x390) from []
> (kthread+0xc0/0xd4)
> [ 300.625947] [] (kthread+0xc0/0xd4) from []
> (ret_from_fork+0x14/0x20)
> [ 300.634135] 2 locks held by kworker/0:1/19:
> [ 300.638383] #0: (events){.+.+.+}, at: []
> process_one_work+0x208/0x6a8
> [ 300.646512] #1: ((_work->work)){+.+.+.}, at: []
> process_one_work+0x208/0x6a8
There seems to be a race condition in lbs_thread().
At line 582:
582 if (!priv->fw_ready)
583 continue;
The fw_ready is 0, so you never get the chance to execute the FUNC_INIT command.
617 /* Execute the next command */
618 if (!priv->dnld_sent && !priv->cur_cmd)
619 lbs_execute_next_command(priv);
Could you try the following change?
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libe
index 739309e..8f5d977 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,8 @@ static void if_sdio_finish_power_on(struct if_sdio_card *car
sdio_release_host(func);
+ priv->fw_ready = 1;
+
/*
* FUNC_INIT is required for SD8688 WLAN/BT multiple functions
*/
@@ -839,7 +841,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card *car
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Lubomir,
@@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct
if_sdio_card *card)
sdio_release_host(func);
- /*
- * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
- */
- if (card-model == MODEL_8688) {
- struct cmd_header cmd;
-
- memset(cmd, 0, sizeof(cmd));
-
- lbs_deb_sdio(send function INIT command\n);
- if (__lbs_cmd(priv, CMD_FUNC_INIT, cmd, sizeof(cmd),
- lbs_cmd_copyback, (unsigned long) cmd))
- netdev_alert(priv-dev, CMD_FUNC_INIT cmd failed\n);
- }
-
Removing FUNC_INIT could break things in some scenarios.
Could you please test the following case?
1. insmod liberates - download firmware, send FUNC_INIT, ...
2. rmmod libertas - send FUNC_SHUTDOWN command to firmware; BT is still
working.
3. insmod libertas - skip firmware downloading, send FUNC_INIT, ...
If FUNC_INIT is removed, I don't expect step 3 to work.
In case btmrvl_sdio is loaded, the driver always locks up in FUNC_INIT
upon probe time, thus I'm not able to proceed to further steps.
[ 209.338953] [c0502248] (__schedule+0x610/0x764) from [bf20ae24]
(__lbs_cmd+0xb8/0x130
[libertas])
[ 209.348340] [bf20ae24] (__lbs_cmd+0xb8/0x130 [libertas]) from
[bf222474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [bf222474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf2226c4]
(if_sdio_power_on+0x18c/0x20c [libertas_sdio])
[ 209.373052] [bf2226c4] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
from [bf222944]
(if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [bf222944] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from
[bf01d820]
(sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [bf01d820] (sdio_bus_probe+0x94/0xfc [mmc_core]) from
[c02e729c]
(driver_probe_device+0x12c/0x348)
[ 209.407214] [c02e729c] (driver_probe_device+0x12c/0x348) from
[c02e7530]
(__driver_attach+0x78/0x9c)
[ 209.416798] [c02e7530] (__driver_attach+0x78/0x9c) from [c02e5658]
(bus_for_each_dev+0x50/0x88)
[ 209.425946] [c02e5658] (bus_for_each_dev+0x50/0x88) from [c02e6810]
(bus_add_driver+0x108/0x268)
[ 209.435180] [c02e6810] (bus_add_driver+0x108/0x268) from [c02e782c]
(driver_register+0xa4/0x134)
[ 209.26] [c02e782c] (driver_register+0xa4/0x134) from [bf22601c]
(if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [bf22601c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
from [c00085b8]
(do_one_initcall+0x98/0x174)
[ 209.466236] [c00085b8] (do_one_initcall+0x98/0x174) from [c0076504]
(load_module+0x1c5c/0x1f80)
[ 209.475390] [c0076504] (load_module+0x1c5c/0x1f80) from [c007692c]
(sys_init_module+0x104/0x128)
[ 209.484632] [c007692c] (sys_init_module+0x104/0x128) from [c0008c40]
(ret_fast_syscall+0x0/0x38)
In case btmrvl_sdio is _not_ loaded, insmod returns, but driver locks up
waiting for FUNC_INIT to finish:
[ 300.538859] [c0502248] (__schedule+0x610/0x764) from [bf1fae24]
(__lbs_cmd+0xb8/0x130
[libertas])
[ 300.548600] [bf1fae24] (__lbs_cmd+0xb8/0x130 [libertas]) from
[bf212474]
(if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 300.560398] [bf212474] (if_sdio_finish_power_on+0xec/0x1b0
[libertas_sdio]) from [bf213230]
(if_sdio_do_prog_firmware+0x414/0x454 [libertas_sdio])
[ 300.574052] [bf213230] (if_sdio_do_prog_firmware+0x414/0x454
[libertas_sdio]) from [bf1fffbc]
(lbs_fw_loaded+0x24/0x58 [libertas])
[ 300.586907] [bf1fffbc] (lbs_fw_loaded+0x24/0x58 [libertas]) from
[c02f02c0]
(request_firmware_work_func+0xb0/0xf4)
[ 300.597746] [c02f02c0] (request_firmware_work_func+0xb0/0xf4) from
[c003ae0c]
(process_one_work+0x348/0x6a8)
[ 300.608288] [c003ae0c] (process_one_work+0x348/0x6a8) from [c003b408]
(worker_thread+0x268/0x390)
[ 300.617630] [c003b408] (worker_thread+0x268/0x390) from [c00414b0]
(kthread+0xc0/0xd4)
[ 300.625947] [c00414b0] (kthread+0xc0/0xd4) from [c0008ce8]
(ret_from_fork+0x14/0x20)
[ 300.634135] 2 locks held by kworker/0:1/19:
[ 300.638383] #0: (events){.+.+.+}, at: [c003accc]
process_one_work+0x208/0x6a8
[ 300.646512] #1: ((fw_work-work)){+.+.+.}, at: [c003accc]
process_one_work+0x208/0x6a8
There seems to be a race condition in lbs_thread().
At line 582:
582 if (!priv-fw_ready)
583 continue;
The fw_ready is 0, so you never get the chance to execute the FUNC_INIT command.
617 /* Execute the next command */
618 if (!priv-dnld_sent !priv-cur_cmd)
619 lbs_execute_next_command(priv);
Could you try the following change?
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libe
index 739309e..8f5d977 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,6 +825,8 @@ static void if_sdio_finish_power_on(struct if_sdio_card
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben,
> > Right, I've managed to pick up 3 changes to mwifiex that it looks like I
> > shouldn't have included. Firstly:
> >
> > 9c969d8ccb1e mwifiex: check wait_event_interruptible return value
> >
> > This had "3.6+" to the left of , whereas I
> > expect version qualifiers to be on the right. So my import script just
> > put this in the queue without asking me to interpret the version
> > qualifier. (I don't automate *that* because people use too wide a
> > variety of syntaxes.)
>
> Sorry. From now on I will put version qualifiers on the right side of
>
I forgot to mention that the upstream patch "9c969d8ccb1e mwifiex: check
wait_event_interruptible return value" is also needed for 3.2-stable, and your
backport patch [016/128] is correct.
The reason I put "3.6+" instead of "3.2+" for stable is that the upstream patch
cannot apply cleanly against kernel versions older than 3.6. It must be back
ported.
Thanks,
Bing
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben,
Right, I've managed to pick up 3 changes to mwifiex that it looks like I
shouldn't have included. Firstly:
9c969d8ccb1e mwifiex: check wait_event_interruptible return value
This had 3.6+ to the left of sta...@vger.kernel.org, whereas I
expect version qualifiers to be on the right. So my import script just
put this in the queue without asking me to interpret the version
qualifier. (I don't automate *that* because people use too wide a
variety of syntaxes.)
Sorry. From now on I will put version qualifiers on the right side of
stable@vger...
I forgot to mention that the upstream patch 9c969d8ccb1e mwifiex: check
wait_event_interruptible return value is also needed for 3.2-stable, and your
backport patch [016/128] is correct.
The reason I put 3.6+ instead of 3.2+ for stable is that the upstream patch
cannot apply cleanly against kernel versions older than 3.6. It must be back
ported.
Thanks,
Bing
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben, > On Mon, 2013-02-04 at 11:43 -0800, Bing Zhao wrote: > > Hi Ben, > > > > > 3.2-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Avinash Patil > > > > > > commit bbea3bc432dc5c08d09ca5c80afdd82515470688 upstream. > > > > This patch is not for stable kernel. > [...] > > Right, I've managed to pick up 3 changes to mwifiex that it looks like I > shouldn't have included. Firstly: > > 9c969d8ccb1e mwifiex: check wait_event_interruptible return value > > This had "3.6+" to the left of , whereas I > expect version qualifiers to be on the right. So my import script just > put this in the queue without asking me to interpret the version > qualifier. (I don't automate *that* because people use too wide a > variety of syntaxes.) Sorry. From now on I will put version qualifiers on the right side of > > When trying to apply that, I found that it seemed to depend on these > two: > > bbea3bc432dc mwifiex: wakeup and stop multiple tx queues in net_device I'd rather classify this patch as an enhancement because the code change is relatively large. To play it safe, let's drop this patch from -stable. > b7097eb75fa1 mwifiex: handle association failure case correctly This is a bug fix indeed. > > which also looked like they were important fixes. Presumably I should > drop all of those? Please drop bbea3bc432dc only. I can resend a backport of "b7097eb75fa1 mwifiex: handle association failure case correctly" for 3.2-stable. Thanks, Bing
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben, > 3.2-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Avinash Patil > > commit bbea3bc432dc5c08d09ca5c80afdd82515470688 upstream. This patch is not for stable kernel. Thanks, Bing > > replace single queue function calls with equivalent multiple queue > functions. Wakeup queue and stop queue calls are guarded by spin lock. > > Signed-off-by: Avinash Patil > Signed-off-by: Kiran Divekar > Signed-off-by: Bing Zhao > Signed-off-by: John W. Linville > Signed-off-by: Ben Hutchings > --- > drivers/net/wireless/mwifiex/init.c | 40 > ++ > drivers/net/wireless/mwifiex/main.c | 11 > drivers/net/wireless/mwifiex/main.h |9 +++ > drivers/net/wireless/mwifiex/sta_event.c |6 ++--- > drivers/net/wireless/mwifiex/sta_ioctl.c |4 +-- > drivers/net/wireless/mwifiex/txrx.c |5 ++-- > 6 files changed, 63 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 26/89] mwifiex: update config_bands during infra association
Hi Ben, > > From: Amitkumar Karwar > > > > commit d7b9c5204e9c6810a20d509ee47bc70419096e59 upstream. > > > > Currently "adapter->config_bands" is updated during infra > > association only if channel is provided by user in "iw connect" > > command. config_bands is used while preparing association > > request to calculate supported rates by intersecting our rates > > with the rates advertised by AP. > > > > There is corner case in which we include zero rates in > > supported rates TLV based on previous IBSS network history, > > which leads to association failure. > > > > This patch fixes the problem by correctly updating config_bands. > > > > Signed-off-by: Amitkumar Karwar > > Signed-off-by: Bing Zhao > > Signed-off-by: John W. Linville > > Signed-off-by: Greg Kroah-Hartman > [...] > > Is this fix needed for earlier kernel versions (3.0, 3.2, 3.4)? If so, > could you provide backports? This patch is not needed for earlier kernel 3.0, 3.2, and 3.4. Thanks, Bing
RE: [ 26/89] mwifiex: update config_bands during infra association
Hi Ben, From: Amitkumar Karwar akar...@marvell.com commit d7b9c5204e9c6810a20d509ee47bc70419096e59 upstream. Currently adapter-config_bands is updated during infra association only if channel is provided by user in iw connect command. config_bands is used while preparing association request to calculate supported rates by intersecting our rates with the rates advertised by AP. There is corner case in which we include zero rates in supported rates TLV based on previous IBSS network history, which leads to association failure. This patch fixes the problem by correctly updating config_bands. Signed-off-by: Amitkumar Karwar akar...@marvell.com Signed-off-by: Bing Zhao bz...@marvell.com Signed-off-by: John W. Linville linvi...@tuxdriver.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org [...] Is this fix needed for earlier kernel versions (3.0, 3.2, 3.4)? If so, could you provide backports? This patch is not needed for earlier kernel 3.0, 3.2, and 3.4. Thanks, Bing
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben, 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Avinash Patil pat...@marvell.com commit bbea3bc432dc5c08d09ca5c80afdd82515470688 upstream. This patch is not for stable kernel. Thanks, Bing replace single queue function calls with equivalent multiple queue functions. Wakeup queue and stop queue calls are guarded by spin lock. Signed-off-by: Avinash Patil pat...@marvell.com Signed-off-by: Kiran Divekar dki...@marvell.com Signed-off-by: Bing Zhao bz...@marvell.com Signed-off-by: John W. Linville linvi...@tuxdriver.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/net/wireless/mwifiex/init.c | 40 ++ drivers/net/wireless/mwifiex/main.c | 11 drivers/net/wireless/mwifiex/main.h |9 +++ drivers/net/wireless/mwifiex/sta_event.c |6 ++--- drivers/net/wireless/mwifiex/sta_ioctl.c |4 +-- drivers/net/wireless/mwifiex/txrx.c |5 ++-- 6 files changed, 63 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device
Hi Ben, On Mon, 2013-02-04 at 11:43 -0800, Bing Zhao wrote: Hi Ben, 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Avinash Patil pat...@marvell.com commit bbea3bc432dc5c08d09ca5c80afdd82515470688 upstream. This patch is not for stable kernel. [...] Right, I've managed to pick up 3 changes to mwifiex that it looks like I shouldn't have included. Firstly: 9c969d8ccb1e mwifiex: check wait_event_interruptible return value This had 3.6+ to the left of sta...@vger.kernel.org, whereas I expect version qualifiers to be on the right. So my import script just put this in the queue without asking me to interpret the version qualifier. (I don't automate *that* because people use too wide a variety of syntaxes.) Sorry. From now on I will put version qualifiers on the right side of stable@vger... When trying to apply that, I found that it seemed to depend on these two: bbea3bc432dc mwifiex: wakeup and stop multiple tx queues in net_device I'd rather classify this patch as an enhancement because the code change is relatively large. To play it safe, let's drop this patch from -stable. b7097eb75fa1 mwifiex: handle association failure case correctly This is a bug fix indeed. which also looked like they were important fixes. Presumably I should drop all of those? Please drop bbea3bc432dc only. I can resend a backport of b7097eb75fa1 mwifiex: handle association failure case correctly for 3.2-stable. Thanks, Bing
RE: [PATCH] mwifiex: avoid out of bounds access in mwifiex_get_common_rates.
Hi Cyril,
Thanks for your patch.
> Check that the array indexes are in-bounds before accessing the rate2 and tmp
> arrays.
>
> Found with the following semantic patch:
>
>
> @@
> identifier t;
> identifier idx;
> expression E;
> statement S;
> @@
> * for (... ; <+... t[idx] ...+> && idx < E ; ...)
> S
>
>
> Signed-off-by: Cyril Roelandt
Acked-by: Bing Zhao
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/join.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/join.c
> b/drivers/net/wireless/mwifiex/join.c
> index 893d809..f0a634d 100644
> --- a/drivers/net/wireless/mwifiex/join.c
> +++ b/drivers/net/wireless/mwifiex/join.c
> @@ -157,8 +157,8 @@ static int mwifiex_get_common_rates(struct
> mwifiex_private *priv, u8 *rate1,
>
> memset(rate1, 0, rate1_size);
>
> - for (i = 0; rate2[i] && i < rate2_size; i++) {
> - for (j = 0; tmp[j] && j < rate1_size; j++) {
> + for (i = 0; i < rate2_size && rate2[i]; i++) {
> + for (j = 0; j < rate1_size && tmp[j]; j++) {
> /* Check common rate, excluding the bit for
> basic rate */
> if ((rate2[i] & 0x7F) == (tmp[j] & 0x7F)) {
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mwifiex: avoid out of bounds access in mwifiex_get_common_rates.
Hi Cyril,
Thanks for your patch.
Check that the array indexes are in-bounds before accessing the rate2 and tmp
arrays.
Found with the following semantic patch:
smpl
@@
identifier t;
identifier idx;
expression E;
statement S;
@@
* for (... ; +... t[idx] ...+ idx E ; ...)
S
/smpl
Signed-off-by: Cyril Roelandt tipec...@gmail.com
Acked-by: Bing Zhao bz...@marvell.com
Thanks,
Bing
---
drivers/net/wireless/mwifiex/join.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/join.c
b/drivers/net/wireless/mwifiex/join.c
index 893d809..f0a634d 100644
--- a/drivers/net/wireless/mwifiex/join.c
+++ b/drivers/net/wireless/mwifiex/join.c
@@ -157,8 +157,8 @@ static int mwifiex_get_common_rates(struct
mwifiex_private *priv, u8 *rate1,
memset(rate1, 0, rate1_size);
- for (i = 0; rate2[i] i rate2_size; i++) {
- for (j = 0; tmp[j] j rate1_size; j++) {
+ for (i = 0; i rate2_size rate2[i]; i++) {
+ for (j = 0; j rate1_size tmp[j]; j++) {
/* Check common rate, excluding the bit for
basic rate */
if ((rate2[i] 0x7F) == (tmp[j] 0x7F)) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mwifiex: don't return zero on failure paths in mwifiex_pcie_init()
Hi Alexey,
Thanks for the patch.
> If pci_iomap() fails in mwifiex_pcie_init(), it breaks off initialization,
> deallocates all resources, but returns zero.
> The patch adds -EIO as return value in this case.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Acked-by: Bing Zhao
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/pcie.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c
> b/drivers/net/wireless/mwifiex/pcie.c
> index 13fbc4e..9d9349c 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1739,6 +1739,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter
> *adapter)
> card->pci_mmap = pci_iomap(pdev, 0, 0);
> if (!card->pci_mmap) {
> dev_err(adapter->dev, "iomap(0) error\n");
> + ret = -EIO;
> goto err_iomap0;
> }
> ret = pci_request_region(pdev, 2, DRV_NAME);
> @@ -1749,6 +1750,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter
> *adapter)
> card->pci_mmap1 = pci_iomap(pdev, 2, 0);
> if (!card->pci_mmap1) {
> dev_err(adapter->dev, "iomap(2) error\n");
> + ret = -EIO;
> goto err_iomap2;
> }
>
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mwifiex: don't return zero on failure paths in mwifiex_pcie_init()
Hi Alexey,
Thanks for the patch.
If pci_iomap() fails in mwifiex_pcie_init(), it breaks off initialization,
deallocates all resources, but returns zero.
The patch adds -EIO as return value in this case.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
Acked-by: Bing Zhao bz...@marvell.com
Thanks,
Bing
---
drivers/net/wireless/mwifiex/pcie.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/pcie.c
b/drivers/net/wireless/mwifiex/pcie.c
index 13fbc4e..9d9349c 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -1739,6 +1739,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter
*adapter)
card-pci_mmap = pci_iomap(pdev, 0, 0);
if (!card-pci_mmap) {
dev_err(adapter-dev, iomap(0) error\n);
+ ret = -EIO;
goto err_iomap0;
}
ret = pci_request_region(pdev, 2, DRV_NAME);
@@ -1749,6 +1750,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter
*adapter)
card-pci_mmap1 = pci_iomap(pdev, 2, 0);
if (!card-pci_mmap1) {
dev_err(adapter-dev, iomap(2) error\n);
+ ret = -EIO;
goto err_iomap2;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Lubomir,
> It actually times out on a 8688 present in GuruPlug with sd8688.bin
> (md5=7233401e9687f8c880da547beed4324e) firmware (that's present in
> linux-firmware tree), but the adapter works fine.
>
> For that firmware times out with libertas_uap [1] as well, though it succeeds
> with sd8688_ap.bin (md5=52cd8f8296b9a7e1d3835d57416256b2) that was originally
> shipped with GuruPlug. That firmware is not in linux-firmware tree and btmrvl
> driver might win the race programming the 8688 with sd8688.bin anyway.
>
> [1] https://github.com/lkundrak/linux/tree/libertas_uap
> ---
> drivers/net/wireless/libertas/if_sdio.c | 14 --
> 1 files changed, 0 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_sdio.c
> b/drivers/net/wireless/libertas/if_sdio.c
> index 2ecab49..3c4c555 100644
> --- a/drivers/net/wireless/libertas/if_sdio.c
> +++ b/drivers/net/wireless/libertas/if_sdio.c
> @@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
> *card)
>
> sdio_release_host(func);
>
> - /*
> - * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
> - */
> - if (card->model == MODEL_8688) {
> - struct cmd_header cmd;
> -
> - memset(, 0, sizeof(cmd));
> -
> - lbs_deb_sdio("send function INIT command\n");
> - if (__lbs_cmd(priv, CMD_FUNC_INIT, , sizeof(cmd),
> - lbs_cmd_copyback, (unsigned long) ))
> - netdev_alert(priv->dev, "CMD_FUNC_INIT cmd failed\n");
> - }
> -
Removing FUNC_INIT could break things in some scenarios.
Could you please test the following case?
1. insmod liberates -> download firmware, send FUNC_INIT, ...
2. rmmod libertas -> send FUNC_SHUTDOWN command to firmware; BT is still
working.
3. insmod libertas -> skip firmware downloading, send FUNC_INIT, ...
If FUNC_INIT is removed, I don't expect step 3 to work.
Thanks,
Bing
> priv->fw_ready = 1;
> wake_up(>pwron_waitq);
>
> --
> 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] libertas sdio: remove CMD_FUNC_INIT call
Hi Lubomir,
It actually times out on a 8688 present in GuruPlug with sd8688.bin
(md5=7233401e9687f8c880da547beed4324e) firmware (that's present in
linux-firmware tree), but the adapter works fine.
For that firmware times out with libertas_uap [1] as well, though it succeeds
with sd8688_ap.bin (md5=52cd8f8296b9a7e1d3835d57416256b2) that was originally
shipped with GuruPlug. That firmware is not in linux-firmware tree and btmrvl
driver might win the race programming the 8688 with sd8688.bin anyway.
[1] https://github.com/lkundrak/linux/tree/libertas_uap
---
drivers/net/wireless/libertas/if_sdio.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c
b/drivers/net/wireless/libertas/if_sdio.c
index 2ecab49..3c4c555 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -825,20 +825,6 @@ static void if_sdio_finish_power_on(struct if_sdio_card
*card)
sdio_release_host(func);
- /*
- * FUNC_INIT is required for SD8688 WLAN/BT multiple functions
- */
- if (card-model == MODEL_8688) {
- struct cmd_header cmd;
-
- memset(cmd, 0, sizeof(cmd));
-
- lbs_deb_sdio(send function INIT command\n);
- if (__lbs_cmd(priv, CMD_FUNC_INIT, cmd, sizeof(cmd),
- lbs_cmd_copyback, (unsigned long) cmd))
- netdev_alert(priv-dev, CMD_FUNC_INIT cmd failed\n);
- }
-
Removing FUNC_INIT could break things in some scenarios.
Could you please test the following case?
1. insmod liberates - download firmware, send FUNC_INIT, ...
2. rmmod libertas - send FUNC_SHUTDOWN command to firmware; BT is still
working.
3. insmod libertas - skip firmware downloading, send FUNC_INIT, ...
If FUNC_INIT is removed, I don't expect step 3 to work.
Thanks,
Bing
priv-fw_ready = 1;
wake_up(card-pwron_waitq);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: sd8688 firmware location
Hi Dan, > > btmrvl_sdio and libertas_sdio both use firmware files sd8688.bin and > > sd8688_helper.bin. In linux-firmware, they're present in libertas/ tree and > > (since 3d32a58b) libertas_sdio perfers loading it from there, while it is > > able > > to fallback to load it from linux-firmware root. btmrvl_sdio, on the other > > hand > > only looks in the root and ends up not being successful. > > > > Obviously, there are two solutions to the problem -- either teach > > btmrvl_sdio > > to look into libertas/, or move the files in linux-firmware tree. I don't > > really have a strong preference, though it probably makes less sense to > > keep in > > in libertas/, since the bluetooth hardware is not really marketed as > > "Libertas." > > > > I'm following up with patches to linux and linux-firmware and I'd be very > > thankful if you could pick one (not both of them). > > So the BT part and the wifi part have different SDIO IDs; are they > actually connected separately to the SDIO bus? Or is the chip only in > one mode at one time or something like that? Is there a problem with > having both libertas and btmrvl loaded at the same time since they're > essentially the same chip? SD8688 is a combo chip with different device IDs for WLAN (function 1) and BT (function 2). WLAN + BT together are connected to the bus with a single SDIO interface. Both libertas and btmrvl drivers can be loaded at the same time, and WLAN & BT functions work concurrently. Of course the SDIO bus is shared between WLAN and BT. The firmware image can be downloaded from host to device by either libertas or btmrvl driver whoever becomes the winner from firmware downloading perspective. Regards, Bing > > I don't really mind moving stuff to mrvl/ out of libertas/ for these > devices, but I do want some backwards compat code in libertas for that. > Unless, of course, Marcel was talking about symlinks in the > linux-firmware git tree, which would be fine with me. The important > point is that simply updating your linux-firmware package or install or > whatever *should not* result in a failed firmware load. > > Dan
RE: sd8688 firmware location
Hi Dan, btmrvl_sdio and libertas_sdio both use firmware files sd8688.bin and sd8688_helper.bin. In linux-firmware, they're present in libertas/ tree and (since 3d32a58b) libertas_sdio perfers loading it from there, while it is able to fallback to load it from linux-firmware root. btmrvl_sdio, on the other hand only looks in the root and ends up not being successful. Obviously, there are two solutions to the problem -- either teach btmrvl_sdio to look into libertas/, or move the files in linux-firmware tree. I don't really have a strong preference, though it probably makes less sense to keep in in libertas/, since the bluetooth hardware is not really marketed as Libertas. I'm following up with patches to linux and linux-firmware and I'd be very thankful if you could pick one (not both of them). So the BT part and the wifi part have different SDIO IDs; are they actually connected separately to the SDIO bus? Or is the chip only in one mode at one time or something like that? Is there a problem with having both libertas and btmrvl loaded at the same time since they're essentially the same chip? SD8688 is a combo chip with different device IDs for WLAN (function 1) and BT (function 2). WLAN + BT together are connected to the bus with a single SDIO interface. Both libertas and btmrvl drivers can be loaded at the same time, and WLAN BT functions work concurrently. Of course the SDIO bus is shared between WLAN and BT. The firmware image can be downloaded from host to device by either libertas or btmrvl driver whoever becomes the winner from firmware downloading perspective. Regards, Bing I don't really mind moving stuff to mrvl/ out of libertas/ for these devices, but I do want some backwards compat code in libertas for that. Unless, of course, Marcel was talking about symlinks in the linux-firmware git tree, which would be fine with me. The important point is that simply updating your linux-firmware package or install or whatever *should not* result in a failed firmware load. Dan
RE: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
> > linux-firmware ships the sd8688* firmware images that are shared with > > libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both > > places > > and so should we. > > > > Signed-off-by: Lubomir Rintel > > --- > > drivers/bluetooth/btmrvl_sdio.c | 24 ++-- > > drivers/bluetooth/btmrvl_sdio.h |6 -- > > 2 files changed, 26 insertions(+), 4 deletions(-) > > NAK from me on this one. I do not want the driver to check two > locations. That is what userspace can work around. > > If we want to unify the location between the WiFi driver and the > Bluetooth driver, I am fine with that, but seriously, just pick one over > the other. I do not care which one. The unified location is mrvl/ directory. We can probably move SD8688 firmware & helper binaries to mrvl/ and have both drivers grab the images there? Regards, Bing
RE: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
linux-firmware ships the sd8688* firmware images that are shared with libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places and so should we. Signed-off-by: Lubomir Rintel lkund...@v3.sk --- drivers/bluetooth/btmrvl_sdio.c | 24 ++-- drivers/bluetooth/btmrvl_sdio.h |6 -- 2 files changed, 26 insertions(+), 4 deletions(-) NAK from me on this one. I do not want the driver to check two locations. That is what userspace can work around. If we want to unify the location between the WiFi driver and the Bluetooth driver, I am fine with that, but seriously, just pick one over the other. I do not care which one. The unified location is mrvl/ directory. We can probably move SD8688 firmware helper binaries to mrvl/ and have both drivers grab the images there? Regards, Bing
RE: [PATCH -v2 18/26] drivers/net: rename random32() to prandom_u32()
Hi Akinobu, > Use more preferable function name which implies using a pseudo-random > number generator. > > Signed-off-by: Akinobu Mita > Acked-by: Thomas Sailer > Cc: "David S. Miller" > Cc: Michael Chan > Cc: Thomas Sailer > Cc: Jean-Paul Roubelat > Cc: Bing Zhao > Cc: net...@vger.kernel.org > Cc: linux-h...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org Acked-by: Bing Zhao [mwifiex] Thanks, Bing > --- > > No change from v1 > > drivers/net/ethernet/broadcom/cnic.c| 4 ++-- > drivers/net/hamradio/baycom_epp.c | 2 +- > drivers/net/hamradio/hdlcdrv.c | 2 +- > drivers/net/hamradio/yam.c | 2 +- > drivers/net/wireless/mwifiex/cfg80211.c | 4 ++-- > 5 files changed, 7 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -v2 18/26] drivers/net: rename random32() to prandom_u32()
Hi Akinobu, Use more preferable function name which implies using a pseudo-random number generator. Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Acked-by: Thomas Sailer t.sai...@alumni.ethz.ch Cc: David S. Miller da...@davemloft.net Cc: Michael Chan mc...@broadcom.com Cc: Thomas Sailer t.sai...@alumni.ethz.ch Cc: Jean-Paul Roubelat j...@f6fbb.org Cc: Bing Zhao bz...@marvell.com Cc: net...@vger.kernel.org Cc: linux-h...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Acked-by: Bing Zhao bz...@marvell.com [mwifiex] Thanks, Bing --- No change from v1 drivers/net/ethernet/broadcom/cnic.c| 4 ++-- drivers/net/hamradio/baycom_epp.c | 2 +- drivers/net/hamradio/hdlcdrv.c | 2 +- drivers/net/hamradio/yam.c | 2 +- drivers/net/wireless/mwifiex/cfg80211.c | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 07/25] mwifiex: don't use [delayed_]work_pending()
Hi Tejun,
Thanks for the patch.
> Drop work_pending() test from mwifiex_sdio_card_reset(). As
> work_pending() becomes %false before sdio_card_reset_worker() starts
> executing, it doesn't really protect anything. reset_host may change
> between mmc_remove_host() and mmc_add_host(). Make
> sdio_card_reset_worker() cache the target mmc_host so that it isn't
> affected by mwifiex_sdio_card_reset() racing with it.
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: Bing Zhao
> Cc: linux-wirel...@vger.kernel.org
Acked-by: Bing Zhao
> ---
> Please let me know how this patch should be routed. I can take it
> through the workqueue tree if necessary.
If you are taking other patches in this series through your tree, please take
this one too.
Thanks,
Bing
>
> Thanks.
>
> drivers/net/wireless/mwifiex/sdio.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/sdio.c
> b/drivers/net/wireless/mwifiex/sdio.c
> index 5a1c1d0..f2874c3 100644
> --- a/drivers/net/wireless/mwifiex/sdio.c
> +++ b/drivers/net/wireless/mwifiex/sdio.c
> @@ -1752,6 +1752,8 @@ mwifiex_update_mp_end_port(struct mwifiex_adapter
> *adapter, u16 port)
> static struct mmc_host *reset_host;
> static void sdio_card_reset_worker(struct work_struct *work)
> {
> + struct mmc_host *target = reset_host;
> +
> /* The actual reset operation must be run outside of driver thread.
>* This is because mmc_remove_host() will cause the device to be
>* instantly destroyed, and the driver then needs to end its thread,
> @@ -1761,10 +1763,10 @@ static void sdio_card_reset_worker(struct work_struct
> *work)
>*/
>
> pr_err("Resetting card...\n");
> - mmc_remove_host(reset_host);
> + mmc_remove_host(target);
> /* 20ms delay is based on experiment with sdhci controller */
> mdelay(20);
> - mmc_add_host(reset_host);
> + mmc_add_host(target);
> }
> static DECLARE_WORK(card_reset_work, sdio_card_reset_worker);
>
> @@ -1773,9 +1775,6 @@ static void mwifiex_sdio_card_reset(struct
> mwifiex_adapter *adapter)
> {
> struct sdio_mmc_card *card = adapter->card;
>
> - if (work_pending(_reset_work))
> - return;
> -
> reset_host = card->func->card->host;
> schedule_work(_reset_work);
> }
> --
> 1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 07/25] mwifiex: don't use [delayed_]work_pending()
Hi Tejun,
Thanks for the patch.
Drop work_pending() test from mwifiex_sdio_card_reset(). As
work_pending() becomes %false before sdio_card_reset_worker() starts
executing, it doesn't really protect anything. reset_host may change
between mmc_remove_host() and mmc_add_host(). Make
sdio_card_reset_worker() cache the target mmc_host so that it isn't
affected by mwifiex_sdio_card_reset() racing with it.
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Bing Zhao bz...@marvell.com
Cc: linux-wirel...@vger.kernel.org
Acked-by: Bing Zhao bz...@marvell.com
---
Please let me know how this patch should be routed. I can take it
through the workqueue tree if necessary.
If you are taking other patches in this series through your tree, please take
this one too.
Thanks,
Bing
Thanks.
drivers/net/wireless/mwifiex/sdio.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sdio.c
b/drivers/net/wireless/mwifiex/sdio.c
index 5a1c1d0..f2874c3 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1752,6 +1752,8 @@ mwifiex_update_mp_end_port(struct mwifiex_adapter
*adapter, u16 port)
static struct mmc_host *reset_host;
static void sdio_card_reset_worker(struct work_struct *work)
{
+ struct mmc_host *target = reset_host;
+
/* The actual reset operation must be run outside of driver thread.
* This is because mmc_remove_host() will cause the device to be
* instantly destroyed, and the driver then needs to end its thread,
@@ -1761,10 +1763,10 @@ static void sdio_card_reset_worker(struct work_struct
*work)
*/
pr_err(Resetting card...\n);
- mmc_remove_host(reset_host);
+ mmc_remove_host(target);
/* 20ms delay is based on experiment with sdhci controller */
mdelay(20);
- mmc_add_host(reset_host);
+ mmc_add_host(target);
}
static DECLARE_WORK(card_reset_work, sdio_card_reset_worker);
@@ -1773,9 +1775,6 @@ static void mwifiex_sdio_card_reset(struct
mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter-card;
- if (work_pending(card_reset_work))
- return;
-
reset_host = card-func-card-host;
schedule_work(card_reset_work);
}
--
1.8.0.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: mwifiex: remove unreachable paths
Hi Sasha,
Thanks for the patch.
> We know 'firmware' is non-NULL from the beginning of mwifiex_prog_fw_w_helper,
> remove all !firmware paths from the rest of the function.
After removing all !firmware paths the function 'mwifiex_get_fw_data' becomes
an orphan.
Could you please remove that function as well and resend a v2 patch?
Thanks,
Bing
>
> Signed-off-by: Sasha Levin
> ---
> drivers/net/wireless/mwifiex/usb.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/usb.c
> b/drivers/net/wireless/mwifiex/usb.c
> index 63ac9f2..8bd7098 100644
> --- a/drivers/net/wireless/mwifiex/usb.c
> +++ b/drivers/net/wireless/mwifiex/usb.c
> @@ -836,23 +836,14 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
> dlen = 0;
> } else {
> /* copy the header of the fw_data to get the length */
> - if (firmware)
> - memcpy(>fw_hdr, [tlen],
> -sizeof(struct fw_header));
> - else
> - mwifiex_get_fw_data(adapter, tlen,
> - sizeof(struct fw_header),
> - (u8 *)>fw_hdr);
> + memcpy(>fw_hdr, [tlen],
> +sizeof(struct fw_header));
>
> dlen = le32_to_cpu(fwdata->fw_hdr.data_len);
> dnld_cmd = le32_to_cpu(fwdata->fw_hdr.dnld_cmd);
> tlen += sizeof(struct fw_header);
>
> - if (firmware)
> - memcpy(fwdata->data, [tlen], dlen);
> - else
> - mwifiex_get_fw_data(adapter, tlen, dlen,
> - (u8 *)fwdata->data);
> + memcpy(fwdata->data, [tlen], dlen);
>
> fwdata->seq_num = cpu_to_le32(fw_seqnum);
> tlen += dlen;
> --
> 1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] wireless: mwifiex: remove unreachable paths
Hi Sasha,
Thanks for the patch.
We know 'firmware' is non-NULL from the beginning of mwifiex_prog_fw_w_helper,
remove all !firmware paths from the rest of the function.
After removing all !firmware paths the function 'mwifiex_get_fw_data' becomes
an orphan.
Could you please remove that function as well and resend a v2 patch?
Thanks,
Bing
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
drivers/net/wireless/mwifiex/usb.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index 63ac9f2..8bd7098 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -836,23 +836,14 @@ static int mwifiex_prog_fw_w_helper(struct
mwifiex_adapter *adapter,
dlen = 0;
} else {
/* copy the header of the fw_data to get the length */
- if (firmware)
- memcpy(fwdata-fw_hdr, firmware[tlen],
-sizeof(struct fw_header));
- else
- mwifiex_get_fw_data(adapter, tlen,
- sizeof(struct fw_header),
- (u8 *)fwdata-fw_hdr);
+ memcpy(fwdata-fw_hdr, firmware[tlen],
+sizeof(struct fw_header));
dlen = le32_to_cpu(fwdata-fw_hdr.data_len);
dnld_cmd = le32_to_cpu(fwdata-fw_hdr.dnld_cmd);
tlen += sizeof(struct fw_header);
- if (firmware)
- memcpy(fwdata-data, firmware[tlen], dlen);
- else
- mwifiex_get_fw_data(adapter, tlen, dlen,
- (u8 *)fwdata-data);
+ memcpy(fwdata-data, firmware[tlen], dlen);
fwdata-seq_num = cpu_to_le32(fw_seqnum);
tlen += dlen;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [trivial] wireless: mwifiex: Fix typo in wireless/mwifiex driver
Hi Masanari,
Thanks for your patch.
> Subject: [PATCH] [trivial] wireless: mwifiex: Fix typo in wireless/mwifiex
> driver
>
> Correct spelling typo in wireless/mwifiex driver.
>
> Signed-off-by: Masanari Iida
Acked-by: Bing Zhao
Regards,
Bing
> ---
> drivers/net/wireless/mwifiex/sta_ioctl.c | 2 +-
> drivers/net/wireless/mwifiex/usb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c
> b/drivers/net/wireless/mwifiex/sta_ioctl.c
> index 552d72e..21035e6 100644
> --- a/drivers/net/wireless/mwifiex/sta_ioctl.c
> +++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
> @@ -463,7 +463,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
> }
>
> if (adapter->hs_activated) {
> - dev_dbg(adapter->dev, "cmd: HS Already actived\n");
> + dev_dbg(adapter->dev, "cmd: HS Already activated\n");
> return true;
> }
>
> diff --git a/drivers/net/wireless/mwifiex/usb.c
> b/drivers/net/wireless/mwifiex/usb.c
> index 22a5916..5eb3b33 100644
> --- a/drivers/net/wireless/mwifiex/usb.c
> +++ b/drivers/net/wireless/mwifiex/usb.c
> @@ -351,7 +351,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
> card->udev = udev;
> card->intf = intf;
>
> - pr_debug("info: bcdUSB=%#x Device Class=%#x SubClass=%#x Protocl=%#x\n",
> + pr_debug("info: bcdUSB=%#x Device Class=%#x SubClass=%#x
> Protocol=%#x\n",
>udev->descriptor.bcdUSB, udev->descriptor.bDeviceClass,
>udev->descriptor.bDeviceSubClass,
>udev->descriptor.bDeviceProtocol);
> --
> 1.8.0.1.347.gf94c325
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [trivial] wireless: mwifiex: Fix typo in wireless/mwifiex driver
Hi Masanari,
Thanks for your patch.
Subject: [PATCH] [trivial] wireless: mwifiex: Fix typo in wireless/mwifiex
driver
Correct spelling typo in wireless/mwifiex driver.
Signed-off-by: Masanari Iida standby2...@gmail.com
Acked-by: Bing Zhao bz...@marvell.com
Regards,
Bing
---
drivers/net/wireless/mwifiex/sta_ioctl.c | 2 +-
drivers/net/wireless/mwifiex/usb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c
b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 552d72e..21035e6 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -463,7 +463,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
}
if (adapter-hs_activated) {
- dev_dbg(adapter-dev, cmd: HS Already actived\n);
+ dev_dbg(adapter-dev, cmd: HS Already activated\n);
return true;
}
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index 22a5916..5eb3b33 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -351,7 +351,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
card-udev = udev;
card-intf = intf;
- pr_debug(info: bcdUSB=%#x Device Class=%#x SubClass=%#x Protocl=%#x\n,
+ pr_debug(info: bcdUSB=%#x Device Class=%#x SubClass=%#x
Protocol=%#x\n,
udev-descriptor.bcdUSB, udev-descriptor.bDeviceClass,
udev-descriptor.bDeviceSubClass,
udev-descriptor.bDeviceProtocol);
--
1.8.0.1.347.gf94c325
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 04/21] wireless: Convert is__ether_addr uses to eth_addr_
Hi Joe, > Subject: [PATCH net-next 04/21] wireless: Convert is__ether_addr uses to > eth_addr_ > > Convert the old ether_addr tests to eth_addr_. > Adds api consistency. > > Signed-off-by: Joe Perches Acked-by: Bing Zhao [mwifiex] Thanks, Bing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 04/21] wireless: Convert is_foo_ether_addr uses to eth_addr_foo
Hi Joe, Subject: [PATCH net-next 04/21] wireless: Convert is_foo_ether_addr uses to eth_addr_foo Convert the old ether_addr tests to eth_addr_foo. Adds api consistency. Signed-off-by: Joe Perches j...@perches.com Acked-by: Bing Zhao bz...@marvell.com [mwifiex] Thanks, Bing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
