- 11 Jan, 2013 9 commits
-
-
Piotr Haber authored
On hardware reintialization reference count of already existing timers would be increased again. This leads to problems on module unloading. Cc: stable@vger.kernel.org Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Piotr Haber <phaber@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Right now the rx flush is not doing anything useful on AR9003+, as it only works if the buffers in the rx FIFO have not been purged yet, as is done by ath_stoprecv. To fix this, always call ath_flushrecv from within ath_stoprecv before the FIFO is emptied, but still after the hw receive path has been stopped. This ensures that frames received (and ACKed by the hardware) shortly before a reset will be seen by the software, which should improve A-MPDU session stability. Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
Ensure that the rx tasklet is no longer running when entering the reset path. Also remove the distinction between flush and no-flush frame processing. If a frame has been received and ACKed by the hardware, the stack needs to see it, so that the BA receive window does not go out of sync. Cc: stable@vger.kernel.org Signed-off-by:
-
Felix Fietkau authored
During teardown, mac80211 will not return a new beacon. This is normal and handled properly in the driver, so there's no need to spam the user with a kernel warning here. Cc: stable@vger.kernel.org Signed-off-by:
-
Felix Fietkau authored
When the next beacon is sent, the ath_buf from the previous run is reused. If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet the skb is freed, leading to a double-free on the next beacon tx attempt, resulting in a system crash. Cc: stable@vger.kernel.org Signed-off-by:
-
Felix Fietkau authored
On AR9300 the rx FIFO needs to be empty during reset to ensure that no further DMA activity is generated, otherwise it might lead to memory corruption issues. Cc: stable@vger.kernel.org Signed-off-by:
-
Sujith Manoharan authored
SKBs that are allocated in the HTC layer do not have callbacks registered and hence ended up not being freed, Fix this by freeing them properly in the TX completion routine. Cc: <stable@vger.kernel.org> Reported-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Tested-by:
-
Amitkumar Karwar authored
BAND_G is implicit when BAND_GN is present. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
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. Cc: "3.7.y" <stable@vger.kernel.org> Signed-off-by:
-
- 10 Jan, 2013 3 commits
-
-
Gustavo Padovan authored
Checking only for sco_conn seems to not be enough and lead to NULL dereferences in the code, check for hcon instead. <1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at 0000000 8 <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0 <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000 <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c <0>[11340.226674] Stack: <4>[11340.226682] c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00 00000000 e0fdff5c <4>[11340.226718] c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852 d7813800 62262f10 <4>[11340.226752] e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac c175425c 00000041 <0>[11340.226793] Call Trace: <4>[11340.226813] [<c184db87>] ? sco_sock_clear_timer+0x27/0x60 <4>[11340.226831] [<c1251028>] ? local_bh_enable+0x68/0xd0 <4>[11340.226846] [<c1754aef>] ? lock_sock_nested+0x4f/0x60 <4>[11340.226862] [<c184f587>] sco_sock_shutdown+0x67/0xb0 <4>[11340.226879] [<c1751852>] ? sockfd_lookup_light+0x22/0x80 <4>[11340.226897] [<c1753c00>] sys_shutdown+0x30/0x60 <4>[11340.226912] [<c175425c>] sys_socketcall+0x1dc/0x2a0 <4>[11340.226929] [<c149ba78>] ? trace_hardirqs_on_thunk+0xc/0x10 <4>[11340.226944] [<c18860f1>] syscall_call+0x7/0xb <4>[11340.226960] [<c1880000>] ? restore_cur+0x5e/0xd7 <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74 2f b8 0a 00 00 Reported-by:
Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Jaganath Kanakkassery authored
If remote device sends l2cap info request before read_remote_ext_feature completes then mgmt_connected will be sent in hci_acldata_packet() and remote name request wont be sent and eventually authentication wont happen Hcidump log of the issue < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid) Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 12 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 > HCI Event: Max Slots Change (0x1b) plen 3 handle 12 slots 5 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 12 page 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 > ACL data: handle 12 flags 0x02 dlen 10 L2CAP(s): Info req: type 2 < ACL data: handle 12 flags 0x00 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00b8 Enhanced Retransmission mode Streaming mode FCS Option Fixed Channels > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 12 page 1 max 1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > ACL data: handle 12 flags 0x02 dlen 10 L2CAP(s): Info req: type 3 < ACL data: handle 12 flags 0x00 dlen 20 L2CAP(s): Info rsp: type 3 result 0 Fixed channel list 0x00000002 L2CAP Signalling Channel > HCI Event: Number of Completed Packets (0x13) plen 5 handle 12 packets 2 This patch moves sending mgmt_connected from hci_acldata_packet() to l2cap_connect_req() since this code is to handle the scenario remote device sends l2cap connect req too fast Signed-off-by:Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by:
-
Sergio Cambra authored
Output of /sys/kernel/debug/usb/devices T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3008 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Sergio Cambra <sergio@programatica.es> Signed-off-by:
-
- 09 Jan, 2013 6 commits
-
-
Anderson Lizardo authored
The length parameter should be sizeof(req->name) - 1 because there is no guarantee that string provided by userspace will contain the trailing '\0'. Can be easily reproduced by manually setting req->name to 128 non-zero bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on input subsystem: $ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af ("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys" field in struct hid_device due to overflow.) Cc: stable@vger.kernel.org Signed-off-by:Anderson Lizardo <anderson.lizardo@openbossa.org> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
AceLan Kao authored
Add support for the AR9462 chip T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e056 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
-
AceLan Kao authored
Add support for the AR9462 chip T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e04e Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
-
Daniel Schaal authored
T: Bus=02 Lev=02 Prnt=02 Port=06 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3006 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Daniel Schaal <farbing@web.de> Signed-off-by:
-
AceLan Kao authored
Add support for the AR9462 chip T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3393 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
-
Szymon Janc authored
After sending reset command wait for its command complete event before sending next command. Some chips sends CC event for command received before reset if reset was send before chip replied with CC. This is also required by specification that host shall not send additional HCI commands before receiving CC for reset. < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850 Write Extended Inquiry Response (0x03|0x0052) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864 Reset (0x03|0x0003) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062 > HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835 Signed-off-by:Szymon Janc <szymon.janc@tieto.com> Cc: stable@vger.kernel.org Acked-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
- 07 Jan, 2013 4 commits
-
-
Larry Finger authored
Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space would time out. The original fix for b43 (commit 6b6fa586) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43 is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. This driver reads several firmware files - the remainder can be read synchronously. On some test systems, the async read fails; however, a following synch read works, thus the async failure falls through to the sync try. Reported-and-Tested by: Felix Janda <felix.janda@posteo.de> Signed-off-by:
-
Chen Gang authored
The fields must be null-terminated, or simple_strtoul will cause issue. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Nickolai Zeldovich authored
Do not dereference p->station_id after kfree(cmd) because p points into the cmd data structure. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by:
-
Julian Wollrath authored
Signed-off-by:
Julian Wollrath <jwollrath@web.de> Acked-by:
-
- 04 Jan, 2013 6 commits
-
-
Vladimir Kondratiev authored
This adds support for the 60 GHz 802.11ad Wilocity card through a new driver, wil6210. Wilocity implemented the firmware, QCA maintains the device driver. Currently supported: - STA: with security - AP: limited to 1 connected STA, security disabled - Monitor: due to a hardware/firmware limitation either control or non-control frames are monitored Using a STA and AP with this drive, one can assemble a fully functional BSS. Throughput of 1.2Gbps is achieved with iperf. The wil6210 cards have on-board flash memory for the firmware, the cards comes pre-flashed and no firmware download is required. For more details see: http://wireless.kernel.org/en/users/Drivers/wil6210Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
-
Amitkumar Karwar authored
commit 683b6d3b... "cfg80211: pass a channel definition struct" accidentally changed "==" to "!=". Signed-off-by:
-
Bing Zhao authored
wait_event_interruptible function returns -ERESTARTSYS if it's interrupted by a signal. Driver should check the return value and handle this case properly. In mwifiex_wait_queue_complete() routine, as we are now checking wait_event_interruptible return value, the condition check is not required. Also, we have removed mwifiex_cancel_pending_ioctl() call to avoid a chance of sending second command to FW by other path as soon as we clear current command node. FW can not handle two commands simultaneously. Cc: "3.6+" <stable@vger.kernel.org> Signed-off-by:
-
-
-
Vladimir Kondratiev authored
Ath9k consists of 2 different sub-modules: ATH9K and ATH9K_HTC. Both uses common Atheros code from ath.ko and need ATH_COMMON. However, while ATH9K selects ATH_COMMON, ATH9K_HTC does not. As result, if ATH9K_HTC is the only Atheros card selected, compilation fails with unresolved symbols. This patch moves ATH_COMMON selection to the common part for both ATH9K and ATH9K_HTC Signed-off-by:
-
- 03 Jan, 2013 10 commits
-
-
Emmanuel Grumbach authored
There's a bug in the currently released firmware version, the sequence control in the Tx response isn't updated in all cases. Take it from the packet as a workaround. Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
By accident, commit eb647644 ("iwlwifi: protect use_ict with irq_lock") changed the return value of the iwl_pcie_isr() function in case it handles an interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED. Put back the correct return value. Cc: stable@vger.kernel.org Reviewed-by:
-
Chaitanya authored
The maximum MTU shouldn't take the headers into account, the maximum MSDU size is exactly the maximum MTU. Signed-off-by:
T Krishna Chaitanya <chaitanyatk@posedge.com> Signed-off-by:
-
Johannes Berg authored
When AP's SSID is hidden the BSS can appear several times in cfg80211's BSS list: once with a zero-length SSID that comes from the beacon, and once for each SSID from probe reponses. Since the mac80211 stores its data in ieee80211_bss which is embedded into cfg80211_bss, mac80211's data will be duplicated too. This becomes a problem when a driver needs the dtim_period since this data exists only in the beacon's instance in cfg80211 bss table which isn't the instance that is used when associating. Remove the DTIM period from the BSS table and track it explicitly to avoid this problem. Cc: stable@vger.kernel.org Tested-by:
Efi Tubul <efi.tubul@intel.com> Signed-off-by:
-
Johannes Berg authored
This is a very old bug, but there's nothing that prevents the timer from running while the module is being removed when we only do del_timer() instead of del_timer_sync(). The timer should normally not be running at this point, but it's not clearly impossible (or we could just remove this.) Cc: stable@vger.kernel.org Tested-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Johannes Berg authored
Unfortunately, commit b22cfcfc, intended to speed up roaming by avoiding the synchronize_rcu() broke AP/mesh modes as it moved some code into that work item that will still call into the driver at a time where it's no longer expected to handle this: after the AP or mesh has been stopped. To fix this problem remove the per-station work struct, maintain a station cleanup list instead and flush this list when stations are flushed. To keep this patch smaller for stable, do this when the stations are flushed (sta_info_flush()). This unfortunately brings back the original roaming delay; I'll fix that again in a separate patch. Also, Ben reported that the original commit could sometimes (with many interfaces) cause long delays when an interface is set down, due to blocking on flush_workqueue(). Since we now maintain the cleanup list, this particular change of the original patch can be reverted. Cc: stable@vger.kernel.org [3.7] Reported-by:
-
Thomas Pedersen authored
The array of rmc_entrys is redundant since only the list_head is used. Make this an array of list_heads instead and save ~6k per vif at runtime :D Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Johannes Berg authored
Make AP_VLAN type interfaces track the AP master channel context so they have one assigned for the various lookups. Don't give them their own refcount etc. since they're just slaves to the AP master. Signed-off-by: -
Felix Fietkau authored
Signed-off-by:
-
Stanislaw Gruszka authored
Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this can trigger Microcode errors on iwlwifi and iwlegacy drivers. Also rename ieee80211_request_internal_scan() function since it is only used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss(). This patch should address: https://bugzilla.redhat.com/show_bug.cgi?id=883414 https://bugzilla.kernel.org/show_bug.cgi?id=49411Reported-by:
Jesse Kahtava <jesse_kahtava@f-m.fm> Reported-by:
Mikko Rapeli <mikko.rapeli@iki.fi> Cc: stable@vger.kernel.org Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
- 02 Jan, 2013 2 commits
-
-
Hante Meuleman authored
RSN IEs got incorrectly parsed and therefore ap mode using WPA2 security was not working. Cc: stable@vger.kernel.org Reviewed-by:
-
Arend van Spriel authored
Patches from Canonical involved the introduction of new source files debug.[ch]. That coincided with other patches from Broadcom introducing the same files. Cc: Seth Forshee <seth.forshee@canonical.com> Reviewed-by:
-
