linux-toradex.git/drivers/net/wireless/mwifiex, branch v3.9.4

mwifiex: fix setting of multicast filter

2013-05-19T18:38:28+00:00

commit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream.

A small bug in this code was causing the ALLMULTI filter to be set
when in fact we were just wanting to program a selective multicast list
to the hardware.

Fix that bug and remove a redundant if condition in the code that
follows.

This fixes wakeup behaviour when multicast WOL is enabled. Previously,
all multicast packets would wake up the system. Now, only those that the
host intended to receive trigger wakeups.

Signed-off-by: Daniel Drake 
Acked-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: fix memory leak issue when driver unload

2013-05-19T18:38:27+00:00

commit f16fdc9d2dc1e5b270e9a08377587e831e0d36ac upstream.

After unregister_netdevice() call the request is queued and
reg_state is changed to NETREG_UNREGISTERING.
As we check for NETREG_UNREGISTERED state, free_netdev() never
gets executed causing memory leak.

Initialize "dev->destructor" to free_netdev() to free device
data after unregistration.

Reported-by: Daniel Drake 
Tested-by: Daniel Drake 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: clear is_suspended flag when interrupt is received early

2013-05-19T18:38:27+00:00

commit 48795424acff7215d5eac0b52793a2c1eb3a6283 upstream.

When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN
mwifiex is often flooded with "not allowed while suspended" messages
and the interface is unusable.

[  202.171609] int: sdio_ireg = 0x1
[  202.180700] info: mwifiex_process_hs_config: auto cancelling host
               sleep since there is interrupt from the firmware
[  202.201880] event: wakeup device...
[  202.211452] event: hs_deactivated
[  202.514638] info: --- Rx: Data packet ---
[  202.514753] data: 4294957544 BSS(0-0): Data <= kernel
[  202.514825] PREP_CMD: device in suspended state
[  202.514839] data: dequeuing the packet ec7248c0 ec4869c0
[  202.514886] mwifiex_write_data_sync: not allowed while suspended
[  202.514886] host_to_card, write iomem (1) failed: -1
[  202.514917] mwifiex_write_data_sync: not allowed while suspended
[  202.514936] host_to_card, write iomem (2) failed: -1
[  202.514949] mwifiex_write_data_sync: not allowed while suspended
[  202.514965] host_to_card, write iomem (3) failed: -1
[  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF

This can be readily reproduced when putting the XO-4 in a loop where
it goes to sleep due to inactivity, but then wakes up due to an
incoming ping. The error is hit within an hour or two.

This issue happens when an interrupt comes in early while host sleep
is still activated. Driver handles this case by auto cancelling host
sleep. However is_suspended flag is still set which prevents any cmd
or data from being sent to firmware. Fix it by clearing is_suspended
flag in this path.

Reported-by: Daniel Drake 
Tested-by: Daniel Drake 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: Call pci_release_region after calling pci_disable_device

2013-05-08T03:33:04+00:00

commit 5b0d9b218b74042ff72bf4bfda6eeb2e4bf98397 upstream.

"drivers should call pci_release_region() AFTER
calling pci_disable_device()"

Please refer section 3.2 Request MMIO/IOP resources
in Documentation/PCI/pci.txt

Signed-off-by: Avinash Patil 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Yogesh Ashok Powar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: Use pci_release_region() instead of a pci_release_regions()

2013-05-08T03:33:04+00:00

commit c380aafb77b7435d010698fe3ca6d3e1cd745fde upstream.

PCI regions are associated with the device using
pci_request_region() call. Hence use pci_release_region()
instead of pci_release_regions().

Signed-off-by: Yogesh Ashok Powar 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Avinash Patil 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: complete last internal scan

2013-04-03T18:31:56+00:00

We are waiting on first scan command of internal scan request
before association, so we should complete on last internal scan
command response.

Cc:  # 3.8
Tested-by: Daniel Drake 
Tested-by: Marco Cesarano 
Signed-off-by: Bing Zhao 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: John W. Linville

mwifiex: limit channel number not to overflow memory

2013-04-01T20:02:25+00:00

Limit the channel number in scan request, or the driver scan
config structure memory will be overflowed.

Cc:  # 3.5+
Signed-off-by: Stone Piao 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

mwifiex: reset skb->data after processing PCIe sleep confirm cmd respose

2013-03-25T18:54:45+00:00

This patch is a bug fix for an issue wherein power save was not
working for PCIe. This happens because for processing power save
sleep confirm command we pull skb so that skb->data points ahead
of interface header. We use same skb to get other cmda responses
as well. So if we don't push skb after processing cmd response,
it results into reduction in skb->len and finally skb->len reaches
zero. This causes failure in processing sleep command response.
Fix this by pushing skb by INTF_HEADER_LEN at the end of command
response processing.

Signed-off-by: Avinash Patil 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

mwifiex: cancel cmd timer and free curr_cmd in shutdown process

2013-03-18T19:20:38+00:00

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.

Cc:  # 3.8
Tested-by: Marco Cesarano 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

mwifiex: skip pending commands after function shutdown

2013-03-18T19:20:38+00:00

During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is
sent to firmware. Firmware expcets only FUNC_INIT once WLAN
function is shut down.

Any command pending in the command queue should be ignored and
freed.

Cc:  # 3.8
Tested-by: Daniel Drake 
Tested-by: Marco Cesarano 
Signed-off-by: Bing Zhao 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: John W. Linville