> > + 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 =
+ 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 =
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/d
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
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/wirel
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
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 del
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
>
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
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
>
> 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(-)
>
-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
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
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
>
>
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
[
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
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
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
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
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
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 @@
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 @@
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
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
):
>
> @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 +-
>
;
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
;
> 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/
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
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);
> > +
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
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
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);
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
> ---
>
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
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
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
> 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
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
> 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]
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
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
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.
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
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?
t 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 --
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
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
...@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
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
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
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 c
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
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
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
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 processin
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
> > happ
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
>
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
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
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
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
[]
(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
] (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
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
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
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
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) {
> > > -
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;
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
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
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: Avina
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
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
> &
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
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
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
or (... ; <+... 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/d
/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
>
> 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 1
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
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
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
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
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.
> > 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
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 ++--
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
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
ost(). 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
>
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
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
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
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
> ---
> driv
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
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
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
96 matches
Mail list logo
