- 13 Aug, 2010 24 commits
-
-
John W. Linville authored
commit 8f1d2d2b upstream. ieee80211_beacon_get can return NULL... Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Johannes Berg authored
commit e95b7435 upstream. The TX tracing code copies with the wrong length, which will typically copy too little data. Fix this by using the correct length variable. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Peter Huewe authored
commit fa260c00 upstream. Fix a build failure "error: void value not ignored as it ought to be" by removing an assignment of a void return value. The functionality of the code is not changed. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Acked-by:
Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 966cca02 upstream. Since 2.6.31, swap_map[]'s refcounting was changed to show that a used swap entry is just for swap-cache, can be reused. Then, while scanning free entry in swap_map[], a swap entry may be able to be reclaimed and reused. It was caused by commit c9e44410 ("mm: reuse unused swap entry if necessary"). But this caused deta corruption at resume. The scenario is - Assume a clean-swap cache, but mapped. - at hibernation_snapshot[], clean-swap-cache is saved as clean-swap-cache and swap_map[] is marked as SWAP_HAS_CACHE. - then, save_image() is called. And reuse SWAP_HAS_CACHE entry to save image, and break the contents. After resume: - the memory reclaim runs and finds clean-not-referenced-swap-cache and discards it because it's marked as clean. But here, the contents on disk and swap-cache is inconsistent. Hance memory is corrupted. This patch avoids the bug by not reclaiming swap-entry during hibernation. This is a quick fix for backporting. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Reported-by:
Ondreg Zary <linux@rainbow-software.org> Tested-by:
Andrea Gelmini <andrea.gelmini@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Jiri Slaby authored
commit bf9c1fca upstream. Sorry, one more fix, this one depends on the other, so this is rather 2/2. -- tty->driver_data is used all over the code, but never set. This results in oopses like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffff814a0040>] mutex_lock+0x10/0x40 ... Pid: 2157, comm: modem-manager Not tainted 2.6.34.1-0.1-desktop #1 2768DR7/2768DR7 RIP: 0010:[<ffffffff814a0040>] [<ffffffff814a0040>] mutex_lock+0x10/0x40 RSP: 0018:ffff88007b16fa50 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000130 RCX: 0000000000000003 RDX: 0000000000000003 RSI: 0000000000000286 RDI: 0000000000000130 RBP: 0000000000001000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000130 R13: 0000000000000001 R14: 0000000000000000 R15: ffff88007b16feb4 ... Call Trace: [<ffffffffa077690d>] ntty_write_room+0x4d/0x90 [nozomi] ... Set tty->driver_data to the computed port in .install to not recompute it in every place where needed. Switch .open to use driver_data too. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Jiri Slaby authored
commit ee78bb95 upstream. Currently ntty_install omits to increment tty count and we get the following warnings: Warning: dev (noz2) tty->count(0) != #fd's(1) in tty_open So to fix that, add one tty->count++ there. Signed-off-by:
-
Takashi Iwai authored
commit e096c8e6 upstream. An Intel board needs a white-list entry to enable PC-beep. Otherwise the driver misdetects (due to bogus BIOS info) and ignores the PC-beep on 2.6.35. Reported-and-tested-by:
Leandro Lucarella <luca@llucax.com.ar> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Suresh Siddha authored
commit 68f202e4 upstream. Use the stop machine context rather than IPI's to rendezvous all the cpus for MTRR initialization that happens during cpu bringup or for MTRR modifications during runtime. This avoids deadlock scenario (reported by Prarit) like: cpu A holds a read_lock (tasklist_lock for example) with irqs enabled cpu B waits for the same lock with irqs disabled using write_lock_irq cpu C doing set_mtrr() (during AP bringup for example), which will try to rendezvous all the cpus using IPI's This will result in C and A come to the rendezvous point and waiting for B. B is stuck forever waiting for the lock and thus not reaching the rendezvous point. Using stop cpu (run in the process context of per cpu based keventd) to do this rendezvous, avoids this deadlock scenario. Also make sure all the cpu's are in the rendezvous handler before we proceed with the local_irq_save() on each cpu. This lock step disabling irqs on all the cpus will avoid other deadlock scenarios (for example involving with the blocking smp_call_function's etc). [ This problem is very old. Marking -stable only for 2.6.35 as the stop_one_cpu_nowait() API is present only in 2.6.35. Any older kernel interested in this fix need to do some more work in backporting this patch. ] Reported-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1280515602.2682.10.camel@sbsiddha-MOBL3.sc.intel.com> Acked-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
David Woodhouse authored
commit 1f6ea6e5 upstream. We were seeing faults in the solos-pci receive tasklet when packets arrived for a VCC which was currently being closed: [18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14 [18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1 [18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684] [18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci] [18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci] [18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48 [18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57 [18845.274437] [<c1025720>] tasklet_action+0x42/0x69 [18845.303247] [<c102643f>] __do_softirq+0x8e/0x129 [18845.331540] [<c10264ff>] do_softirq+0x25/0x2a [18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a [18845.389677] [<c102666d>] local_bh_enable+0xb/0xe [18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic] [18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox] This patch uses an RCU-inspired approach to fix it. In the RX tasklet's find_vcc() function we first refuse to use a VCC which already has the ATM_VF_READY bit cleared. And in the VCC close function, we synchronise with the tasklet to ensure that it can't still be using the VCC before we continue and allow the VCC to be destroyed. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Tested-by:
Nathan Williams <nathan@traverse.com.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tejun Heo authored
commit 549e1561 upstream. MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 3d2a5318 upstream. There is no reason to run NVidia-specific quirks related to HT MSI mappings with MSI disabled via pci=nomsi, so make __nv_msi_ht_cap_quirk() return immediately in that case. This allows at least one machine to boot 100% of the time with pci=nomsi (it still doesn't boot reliably without that). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16443 . Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Lytochkin Boris authored
commit e847003f upstream. Signed-off-by:
Lytochkin Boris <lytboris@gmail.com> Tested-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
Haiyang Zhang authored
commit 54d2379c upstream. LBDAF is not available nor necessary on 64BIT kernel. This patch fixed the dependency for hv_blkvsc module on 64BIT kernel. Thanks vrataj2 [vrataj2@comcast.net] for reporting this problem. Reported-by:
vrataj2 <vrataj2@comcast.net> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
Peter Huewe authored
commit 060132ae upstream. This patch prevents the code from calling parport_release and parport_unregister_device twice with the same arguments - and thus fixes an oops. Rationale: After the first call the parport is already released and the handle isn't valid anymore and calling parport_release and parport_unregister_device twice isn't a good idea. Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Randy Dunlap authored
commit e928c077 upstream. line6 uses snd_pcm*() functions, so it should select SND_PCM. ERROR: "snd_pcm_period_elapsed" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_set_ops" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_free_pages" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_ioctl" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_malloc_pages" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_hw_constraint_ratdens" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_format_physical_width" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_preallocate_pages_for_all" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_new" [drivers/staging/line6/line6usb.ko] undefined! Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Markus Grabner <grabner@icg.tugraz.at> Signed-off-by:
-
Larry Finger authored
commit 5d92fe33 upstream. Device missing from current tables. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
Rod Huffaker <rod.huffaker@gmail.com> Signed-off-by:
-
H. Peter Anvin authored
commit 113fc5a6 upstream. xchg() and cmpxchg() modify their memory operands, not merely read them. For some versions of gcc the "memory" clobber has apparently dealt with the situation, but not for all. Originally-by:
H. Peter Anvin <hpa@zytor.com> Cc: Glauber Costa <glommer@redhat.com> Cc: Avi Kivity <avi@redhat.com> Cc: Peter Palfrader <peter@palfrader.org> Cc: Greg KH <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Zachary Amsden <zamsden@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> LKML-Reference: <4C4F7277.8050306@zytor.com> Signed-off-by:
-
Dominik Brodowski authored
commit 127c03cd upstream. NR_IRQS may be as low as 16, causing a (harmless?) buffer overflow in pcmcia_setup_isa_irq(): static u8 pcmcia_used_irq[NR_IRQS]; ... if ((try < 32) && pcmcia_used_irq[irq]) continue; This is read-only, so if this address would be non-zero, it would just mean we would not attempt an IRQ >= NR_IRQS -- which would fail anyway! And as request_irq() fails for an irq >= NR_IRQS, the setting code path: pcmcia_used_irq[irq]++; is never reached as well. Reported-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Bjorn Helgaas authored
commit 2491762c upstream. This DMI quirk turns on "pci=use_crs" for the ALiveSATA2-GLAN because amd_bus.c doesn't handle this system correctly. The system has a single HyperTransport I/O chain, but has two PCI host bridges to buses 00 and 80. amd_bus.c learns the MMIO range associated with buses 00-ff and that this range is routed to the HT chain hosted at node 0, link 0: bus: [00, ff] on node 0 link 0 bus: 00 index 1 [mem 0x80000000-0xfcffffffff] This includes the address space for both bus 00 and bus 80, and amd_bus.c assumes it's all routed to bus 00. We find device 80:01.0, which BIOS left in the middle of that space, but we don't find a bridge from bus 00 to bus 80, so we conclude that 80:01.0 is unreachable from bus 00, and we move it from the original, working, address to something outside the bus 00 aperture, which does not work: pci 0000:80:01.0: reg 10: [mem 0xfebfc000-0xfebfffff 64bit] pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] The BIOS told us everything we need to know to handle this correctly, so we're better off if we just pay attention, which lets us leave the 80:01.0 device at the original, working, address: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xff37ffff] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) pci_root PNP0A08:00: host bridge window [mem 0xfebfc000-0xfebfffff] This was a regression between 2.6.33 and 2.6.34. In 2.6.33, amd_bus.c was used only when we found multiple HT chains. 3e3da00c, which enabled amd_bus.c even on systems with a single HT chain, caused this failure. This quirk was written by Graham. If we ever enable "pci=use_crs" for machines from 2006 or earlir, this quirk should be removed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16007Reported-by:
Graham Ramsey <ramsey.graham@ntlworld.com> Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Marcin Slusarz authored
commit 8b8f79b9 upstream. After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule the same pages for release. Obviously it will explode on second free. Fix it by marking kmmio_fault_pages which are scheduled for release and not adding them second time. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by:
Marcin Kocielnicki <koriakin@0x04.net> Tested-by:
Shinpei KATO <shinpei@il.is.s.u-tokyo.ac.jp> Acked-by:
Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Marcin Kocielnicki <koriakin@0x04.net> Cc: nouveau@lists.freedesktop.org LKML-Reference: <20100613215654.GA3829@joi.lan> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Sam Ravnborg authored
commit e32e78c5 upstream. Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by:
Thomas Backlund <tmb@mandriva.org> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Scott Wood authored
commit 69e77a8b upstream. Commit 6b95ed34 changed from a struct initializer to perf_sample_data_init(), but the setting of the .period member was left out. Signed-off-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Tejun Heo authored
commit 213373cf upstream. SIDPR window registers are shared across ports and as each access is done in two steps, accesses to different ports under EH may race. This primarily is caused by incorrect host locking in EH context and should be fixed by defining locking requirements for each EH operation which can be used during EH and enforcing them but for now work around the problem by adding a dedicated SIDPR lock and grabbing it for each SIDPR access. Signed-off-by:
Mark Knecht <markknecht@gmail.com> Reported-by:
Paul Check <paul@thechecks.ca> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Alok Kataria authored
commit 9f242dc1 upstream. When running on VMware's platform, we have seen situations where the AP's try to calibrate the lpj values and fail to get good calibration runs becasue of timing issues. As a result delays don't work correctly on all cpus. The solutions is to set preset_lpj value based on the current tsc frequency value. This is similar to what KVM does as well. Signed-off-by:
Alok N Kataria <akataria@vmware.com> LKML-Reference: <1280790637.14933.29.camel@ank32.eng.vmware.com> Signed-off-by:
-
- 10 Aug, 2010 16 commits
-
-
Greg Kroah-Hartman authored
-
Chris Wilson authored
commit a1efd14a upstream. Apparently i830 and i845 cannot handle any stride that is not a multiple of 256, unlike their brethren which do support 64 byte aligned strides. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Chris Wilson authored
commit cda4b7d3 upstream. The docs warn that to position the cursor such that no part of it is visible on the pipe is an undefined operation. Avoid such circumstances upon changing the mode, or at any other time, by unsetting the cursor if it moves out of bounds. "For normal high resolution display modes, the cursor must have at least a single pixel positioned over the active screen.” (p143, p148 of the hardware registers docs). Fixes: Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS enabled https://bugs.freedesktop.org/show_bug.cgi?id=24748 v2: Only update the cursor registers if they change. v3: Fix the unsigned comparision of x,y against width,height. v4: Always set CUR.BASE or else the cursor may become corrupt. Signed-off-by:
Christian Eggers <ceggers@gmx.de> Cc: Christopher James Halse Rogers <chalserogers@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit e06b14ee upstream. Logic was: if (mode0 && mode1) else if (mode0) else Should be: if (mode0 && mode1) else if (mode0) else if (mode1) Otherwise we may end up calculating the priority regs with unitialized values. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16492Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 812d0469 upstream. Use of HDP_*_COHERENCY_FLUSH_CNTL can cause a hang in certain situations. Add workaround. Signed-off-by:
-
Michel Dänzer authored
commit e376573f upstream. This fixes a problem where on low VRAM cards we'd run out of space for validation. [airlied: Tested on my M7, Thinkpad T42, compiz works with no problems.] Signed-off-by:
Michel Dänzer <daenzer@vmware.com> Signed-off-by:
-
Alex Deucher authored
commit 1297c05a upstream. New evergreen and r7xx ids. Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 8a22b999 upstream. xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a process actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
James Bottomley authored
commit a91c1be2 upstream. we also need to clean up and free the cdev. Reported-by:
Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
David Howells authored
commit 694f690d upstream. Commit 8f92054e ("CRED: Fix __task_cred()'s lockdep check and banner comment") fixed the lockdep checks on __task_cred(). This has shown up a place in the signalling code where a lock should be held - namely that check_kill_permission() requires its callers to hold the RCU lock. Fix group_send_sig_info() to get the RCU read lock around its call to check_kill_permission(). Without this patch, the following warning can occur: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/signal.c:660 invoked rcu_dereference_check() without protection! ... Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
John W. Linville authored
commit c9370197 upstream. While mesh_rx_plink_frame holds sta->lock... mesh_rx_plink_frame -> mesh_plink_inc_estab_count -> ieee80211_bss_info_change_notify ...but ieee80211_bss_info_change_notify is allowed to sleep. A driver taking advantage of that allowance can cause a scheduling while atomic bug. Similar paths exist for mesh_plink_dec_estab_count, so work around those as well. http://bugzilla.kernel.org/show_bug.cgi?id=16099 Also, correct a minor kerneldoc comment error (mismatched function names). Signed-off-by:
-
Johannes Berg authored
commit ccb6c136 upstream. When kernel-internal users use cfg80211_get_bss() to get a reference to a BSS struct, they may end up getting one that would have been removed from the list if there had been any userspace access to the list. This leads to inconsistencies and problems. Fix it by making cfg80211_get_bss() ignore BSSes that cfg80211_bss_expire() would remove. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180Reported-by:
Jiajia Zheng <jiajia.zheng@intel.com> Tested-by:
-
Johannes Berg authored
commit 643f82e3 upstream. Ever since mac80211/drivers are no longer fully in charge of keeping track of the auth status, trying to make them do so will fail. Instead of warning and reporting the deauthentication to userspace, cfg80211 must simply ignore it so that spurious deauthentications, e.g. before starting authentication, aren't seen by userspace as actual deauthentications. Reported-by:
Paul Stewart <pstew@google.com> Signed-off-by:
-
Larry Finger authored
commit 9d1ac34e upstream. In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread (http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a netbook owned by John Linville (http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports of ssb failing to detect an SPROM at the normal location. After studying the MMIO trace dump for the Broadcom wl driver, it was determined that the affected boxes had a relocated SPROM. This patch fixes all systems that have reported this problem. Signed-off-by:
-
Stanislaw Gruszka authored
commit d28232b4 upstream. Fix possible double priv->mutex lock introduced by commit a69b03e9 "iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" . We can not call cancel_delayed_work_sync(&priv->scan_check) with priv->mutex locked because workqueue function iwl_bg_scan_check() take that lock internally. We do not need to synchronize when canceling priv->scan_check work. We can avoid races (sending double abort command or send no command at all) using STATUS_SCAN_ABORT bit. Moreover current iwl_bg_scan_check() code seems to be broken, as we should not send abort commands when currently aborting. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Felix Fietkau authored
commit 601e0cb1 upstream. On AR9285, the antenna switch configuration register uses more than just 16 bits. Because of an arbitrary mask applied to the EEPROM value that stores this configuration, diversity was broken in some cases, leading to a significant degradation in signal strength. Fix this by changing the callback to return a 32 bit value and remove the arbitrary mask. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
