- 07 Jun, 2014 40 commits
-
-
Rafael J. Wysocki authored
commit a8d22396 upstream. The ACPI PNP subsystem returns errors from pnpacpi_set_resources() and pnpacpi_disable_resources() if the _SRS or _DIS methods are not present, respectively, but it should not do that, because those methods are optional. For this reason, modify pnpacpi_set_resources() and pnpacpi_disable_resources(), respectively, to ignore missing _SRS or _DIS. This problem has been uncovered by commit 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) and manifested itself by causing serial port suspend to fail on some systems. Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) References: https://bugzilla.kernel.org/show_bug.cgi?id=74371Reported-by:
wxg4net <wxg4net@gmail.com> Reported-and-tested-by: <nonproffessional@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
NeilBrown authored
commit 0f62fb22 upstream. If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because: 1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop. Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit cc13b1d1 upstream. wait_barrier() includes a counter, so we must call it precisely once (unless balanced by allow_barrier()) for each request submitted. Since commit 20d0189b block: Introduce new bio_split() in 3.14-rc1, we don't call it for the extra requests generated when we need to split a bio. When this happens the counter goes negative, any resync/recovery will never start, and "mdadm --stop" will hang. Reported-by:
Chris Murphy <lists@colorremedies.com> Fixes: 20d0189b Cc: Kent Overstreet <kmo@daterainc.com> Signed-off-by:
-
Mike Snitzer authored
commit 131cd131 upstream. Commit 2ee57d58 ("dm cache: add passthrough mode") inadvertently removed the deferred set reference that was taken in cache_map()'s writethrough mode support. Restore taking this reference. This issue was found with code inspection. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Milan Broz authored
commit 3a774521 upstream. Commit 003b5c57 ("block: Convert drivers to immutable biovecs") incorrectly converted biovec iteration in dm-verity to always calculate the hash from a full biovec, but the function only needs to calculate the hash from part of the biovec (up to the calculated "todo" value). Fix this issue by limiting hash input to only the requested data size. This problem was identified using the cryptsetup regression test for veritysetup (verity-compat-test). Signed-off-by:
Milan Broz <gmazyland@gmail.com> Acked-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Viresh Kumar authored
commit 84ea7fe3 upstream. switch_hrtimer_base() calls hrtimer_check_target() which ensures that we do not migrate a timer to a remote cpu if the timer expires before the current programmed expiry time on that remote cpu. But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the new expiry time is set. So the sanity check in hrtimer_check_target() is operating on stale or even uninitialized data. Update expiry time before calling switch_hrtimer_base(). [ tglx: Rewrote changelog once again ] Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: linaro-kernel@lists.linaro.org Cc: linaro-networking@linaro.org Cc: fweisbec@gmail.com Cc: arvind.chauhan@arm.com Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Leon Ma authored
commit 012a45e3 upstream. If a cpu is idle and starts an hrtimer which is not pinned on that same cpu, the nohz code might target the timer to a different cpu. In the case that we switch the cpu base of the timer we already have a sanity check in place, which determines whether the timer is earlier than the current leftmost timer on the target cpu. In that case we enqueue the timer on the current cpu because we cannot reprogram the clock event device on the target. If the timers base is already the target CPU we do not have this sanity check in place so we enqueue the timer as the leftmost timer in the target cpus rb tree, but we cannot reprogram the clock event device on the target cpu. So the timer expires late and subsequently prevents the reprogramming of the target cpu clock event device until the previously programmed event fires or a timer with an earlier expiry time gets enqueued on the target cpu itself. Add the same target check as we have for the switch base case and start the timer on the current cpu if it would become the leftmost timer on the target. [ tglx: Rewrote subject and changelog ] Signed-off-by:
Leon Ma <xindong.ma@intel.com> Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.comSigned-off-by:
-
Stuart Hayes authored
commit 6c6c0d5a upstream. If the last hrtimer interrupt detected a hang it sets hang_detected=1 and programs the clock event device with a delay to let the system make progress. If hang_detected == 1, we prevent reprogramming of the clock event device in hrtimer_reprogram() but not in hrtimer_force_reprogram(). This can lead to the following situation: hrtimer_interrupt() hang_detected = 1; program ce device to Xms from now (hang delay) We have two timers pending: T1 expires 50ms from now T2 expires 5s from now Now T1 gets canceled, which causes hrtimer_force_reprogram() to be invoked, which in turn programs the clock event device to T2 (5 seconds from now). Any hrtimer_start after that will not reprogram the hardware due to hang_detected still being set. So we effectivly block all timers until the T2 event fires and cleans up the hang situation. Add a check for hang_detected to hrtimer_force_reprogram() which prevents the reprogramming of the hang delay in the hardware timer. The subsequent hrtimer_interrupt will resolve all outstanding issues. [ tglx: Rewrote subject and changelog and fixed up the comment in hrtimer_force_reprogram() ] Signed-off-by:
Stuart Hayes <stuart.w.hayes@gmail.com> Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.comSigned-off-by:
-
Grant Likely authored
commit 58b116bc upstream. When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by:
-
Josef Gajdusek authored
commit 3a18e139 upstream. The datasheet for EMC1413/EMC1414, which is fully compatible to EMC1403/1404 and uses the same chip identification, references revision numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers from 0x01 to 0x04 to make sure none are missed. Signed-off-by:
Josef Gajdusek <atx@atx.name> [Guenter Roeck: Updated headline and description] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jean Delvare authored
commit 8759f904 upstream. Commit 454aee17 claims to convert driver emc1403 to use devm_hwmon_device_register_with_groups, however the patch itself makes use of hwmon_device_register_with_groups instead. As the driver remove function was still dropped, the hwmon device is no longer unregistered on driver removal, leading to a resource leak. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 454aee17 hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Josef Gajdusek authored
commit 17c048fc upstream. Attempts to set the hysteresis value to a temperature below the target limit fails with "write error: Numerical result out of range" due to an inverted comparison. Signed-off-by:
-
Guenter Roeck authored
commit c0940e95 upstream. This reverts commit 9fb6c9c7. Tjmax on some Intel CPUs is below 85 degrees C. One known example is L5630 with Tjmax of 71 degrees C. There are other Xeon processors with Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming document states that the temperature target is in bits 23:16 of MSR 0x1a2 (MSR_TEMPERATURE_TARGET), which is 8 bits, not 7. So even if turbostat uses similar checks to validate Tjmax, there is no evidence that the checks are actually required. On the contrary, the checks are known to cause problems and therefore need to be removed. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071. Fixes: 9fb6c9c7 hwmon: (coretemp) Refine TjMax detection Reviewed-by:
-
Rusty Russell authored
commit 79465d2f upstream. We remove the waiting module removal in commit 3f2b9c9c (September 2013), but it turns out that modprobe in kmod (< version 16) was asking for waiting module removal. No one noticed since modprobe would check for 0 usage immediately before trying to remove the module, and the race is unlikely. However, it means that anyone running old (but not ancient) kmod versions is hitting the printk designed to see if anyone was running "rmmod -w". All reports so far have been false positives, so remove the warning. Fixes: 3f2b9c9cReported-by:
Valerio Vanni <valerio.vanni@inwind.it> Cc: Elliott, Robert (Server Storage) <Elliott@hp.com> Acked-by:
Lucas De Marchi <lucas.de.marchi@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Leon Yu authored
commit 754320d6 upstream. iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns, but it doesn't hold when failure happens right after aio_setup_vectored_rw(). Fix that in a such way to avoid hairy goto. Signed-off-by:
Leon Yu <chianglungyu@gmail.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Johannes Berg authored
commit 0229cdaf upstream. If we have no beacon data before association, delay smart FIFO enablement until after we have this data. Not doing so can cause association failures in extremely silent environments (usually only a shielded box/room) as beacon RX is not sent to the host immediately, and then the association time event ends without the host receiving any beacon even though it was on the air - it's just stuck on the FIFO. Fixes: 1f3b0ff8 ("iwlwifi: mvm: Add Smart FIFO support") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Chen Yucong authored
commit b985194c upstream. For handling a free hugepage in memory failure, the race will happen if another thread hwpoisoned this hugepage concurrently. So we need to check PageHWPoison instead of !PageHWPoison. If hwpoison_filter(p) returns true or a race happens, then we need to unlock_page(hpage). Signed-off-by:
Chen Yucong <slaoub@gmail.com> Reviewed-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Tested-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mark Salter authored
commit 4797ec2d upstream. The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [<fffffe0000096034>] dump_backtrace+0x0/0x16c [<fffffe00000961b4>] show_stack+0x14/0x1c [<fffffe000066e648>] dump_stack+0x84/0xb0 [<fffffe0000668678>] panic+0xf4/0x220 [<fffffe000018ec78>] free_reserved_area+0x0/0x110 [<fffffe000018edd8>] free_pages+0x50/0x88 [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40 [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44 [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184 [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c [<fffffe00001edc1c>] __fput+0xb0/0x288 [<fffffe00001ede4c>] ____fput+0xc/0x14 [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c [<fffffe0000095c14>] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by:
Mark Salter <msalter@redhat.com> [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Anthony Iliopoulos authored
commit 9844f546 upstream. The invalidation is required in order to maintain proper semantics under CoW conditions. In scenarios where a process clones several threads, a thread operating on a core whose DTLB entry for a particular hugepage has not been invalidated, will be reading from the hugepage that belongs to the forked child process, even after hugetlb_cow(). The thread will not see the updated page as long as the stale DTLB entry remains cached, the thread attempts to write into the page, the child process exits, or the thread gets migrated to a different processor. Signed-off-by:
Anthony Iliopoulos <anthony.iliopoulos@huawei.com> Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corpSuggested-by:
Shay Goikhman <shay.goikhman@huawei.com> Acked-by:
Dave Hansen <dave.hansen@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Heiko Stuebner authored
commit 282cba6b upstream. The alarm of the hym8563 only supports a minute accuracy, while the uie wants an alarm one second in the future. Therefore things like the select() syscall will fail with a timeout, because the next alarm will happen in a worst case of 60 seconds. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Kirill A. Shutemov authored
commit dd18dbc2 upstream. It's critical for split_huge_page() (and migration) to catch and freeze all PMDs on rmap walk. It gets tricky if there's concurrent fork() or mremap() since usually we copy/move page table entries on dup_mm() or move_page_tables() without rmap lock taken. To get it work we rely on rmap walk order to not miss any entry. We expect to see destination VMA after source one to work correctly. But after switching rmap implementation to interval tree it's not always possible to preserve expected walk order. It works fine for dup_mm() since new VMA has the same vma_start_pgoff() / vma_last_pgoff() and explicitly insert dst VMA after src one with vma_interval_tree_insert_after(). But on move_vma() destination VMA can be merged into adjacent one and as result shifted left in interval tree. Fortunately, we can detect the situation and prevent race with rmap walk by moving page table entries under rmap lock. See commit 38a76013. Problem is that we miss the lock when we move transhuge PMD. Most likely this bug caused the crash[1]. [1] http://thread.gmane.org/gmane.linux.kernel.mm/96473 Fixes: 108d6642 ("mm anon rmap: remove anon_vma_moveto_tail") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Acked-by:
Michel Lespinasse <walken@google.com> Cc: Dave Jones <davej@redhat.com> Cc: David Miller <davem@davemloft.net> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Johannes Berg authored
commit b4b177a5 upstream. Jouni reported that if a remain-on-channel was active on the same channel as the current operating channel, then the ROC would start, but any frames transmitted using mgmt-tx on the same channel would get delayed until after the ROC. The reason for this is that the ROC starts, but doesn't have any handling for "remain on the same channel", so it stops the interface queues. The later mgmt-tx then puts the frame on the interface queues (since it's on the current operating channel) and thus they get delayed until after the ROC. To fix this, add some logic to handle remaining on the same channel specially and not stop the queues etc. in this case. This not only fixes the bug but also improves behaviour in this case as data frames etc. can continue to flow. Reported-by:
Jouni Malinen <j@w1.fi> Tested-by:
-
Emmanuel Grumbach authored
commit c52666ae upstream. If the association is in progress while we suspend, the stack will be in a messed up state. Clean it before we suspend. This patch completes Johannes's patch: 1a1cb744 Author: Johannes Berg <johannes.berg@intel.com> mac80211: fix suspend vs. authentication race Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by:
-
Eliad Peller authored
commit e669ba2d upstream. ieee80211_reconfig already holds rtnl, so calling cfg80211_sched_scan_stopped results in deadlock. Use the rtnl-version of this function instead. Fixes: d43c6b6e ("mac80211: reschedule sched scan after HW restart") Signed-off-by:
Eliad Peller <eliadx.peller@intel.com> Signed-off-by:
-
Eliad Peller authored
commit 792e6aa7 upstream. Add locked-version for cfg80211_sched_scan_stopped. This is used for some users that might want to call it when rtnl is already locked. Fixes: d43c6b6e ("mac80211: reschedule sched scan after HW restart") Signed-off-by:
-
Eliad Peller authored
commit c1fbb258 upstream. cfg80211 is notified about connection failures by __cfg80211_connect_result() call. However, this function currently does not free cfg80211 sme. This results in hanging connection attempts in some cases e.g. when mac80211 authentication attempt is denied, we have this function call: ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() -> cfg80211_process_auth() -> cfg80211_sme_rx_auth() -> __cfg80211_connect_result() but cfg80211_sme_free() is never get called. Fixes: ceca7b71 ("cfg80211: separate internal SME implementation") Signed-off-by:
-
Ilan Peer authored
commit 772f0389 upstream. Fix the following issues in reg_process_hint(): 1. Add verification that wiphy is valid before processing NL80211_REGDOMAIN_SET_BY_COUNTRY_IE. 2. Free the request in case of invalid initiator. 3. Remove WARN_ON check on reg_request->alpha2 as it is not a pointer. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by:
-
Corey Minyard authored
commit eb6d78ec upstream. The OBF timer in KCS was not reset in one situation when error recovery was started, resulting in an immediate timeout. Reported-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Bodo Stroesser authored
commit 48e8ac29 upstream. With recent changes it is possible for the timer handler to detect an idle interface and not start the timer, but the thread to start an operation at the same time. The thread will not start the timer in that instance, resulting in the timer not running. Instead, move all timer operations under the lock and start the timer in the thread if it detect non-idle and the timer is not already running. Moving under locks allows the last timeout to be set in both the thread and the timer. 'Timer is not running' means that the timer is not pending and smi_timeout() is not running. So we need a flag to detect this correctly. Also fix a few other timeout bugs: setting the last timeout when the interrupt has to be disabled and the timer started, and setting the last timeout in check_start_timer_thread possibly racing with the timer Signed-off-by:
-
Jiri Bohac authored
commit 98a01e77 upstream. On architectures with sizeof(int) < sizeof (long), the computation of mask inside apply_slack() can be undefined if the computed bit is > 32. E.g. with: expires = 0xffffe6f5 and slack = 25, we get: expires_limit = 0x20000000e bit = 33 mask = (1 << 33) - 1 /* undefined */ On x86, mask becomes 1 and and the slack is not applied properly. On s390, mask is -1, expires is set to 0 and the timer fires immediately. Use 1UL << bit to solve that issue. Suggested-by:
Deborah Townsend <dstownse@us.ibm.com> Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.czSigned-off-by:
-
Stephen Warren authored
commit 22bbd5d9 upstream. BIT_WORD() truncates rather than rounds, so the loops in syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <= rather than < in an attempt to process the correct number of registers when rounding of the conversion of count of bits to count of words is necessary. However, when rounding isn't necessary because the value is already a multiple of the divisor (as is the case for all values of nb_pts the code actually sees), this causes one too many registers to be processed. Solve this by using and explicit DIV_ROUND_UP() call, rather than BIT_WORD(), and comparing with < rather than <=. Fixes: 7ede0b0b ("gpu: host1x: Add syncpoint wait and interrupts") Signed-off-by:
Stephen Warren <swarren@nvidia.com> Acked-By:
Terje Bergstrom <tbergstrom@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 43103185 upstream. This will allow to load the new firmware. Signed-off-by:
-
Eyal Shapira authored
commit 87d5e415 upstream. After being idle for a long time (>5sec) the rs statistics will be stale so we prefer to reset rs and start from legacy rates again. This gives better results when the attenuation increased signficantly (e.g. we got further from the AP) and after a while we start Tx Note that the first Tx after the idle period will still go out in the old modulation and rate but this seemed a simpler approach compared to adding a timer or modifying mac80211 for this. The negative impact is negligble as we'll recover quickly. Signed-off-by:
Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by:
-
Eyal Shapira authored
commit e53839eb upstream. Change the down/upscale decision logic a bit to be based on different success ratio thresholds. This fixes the implementation compared to the rate scale algorithm which was planned to yield optimal results. Also fix a case where a lower rate wasn't explored despite being a potential for better throughput. While at it rewrite rs_get_rate_action to be more clear and clean. Signed-off-by:
-
Eyal Shapira authored
commit d8fff919 upstream. Don't search columns which are unlikely to succeed as previous columns searched with less aggressive modulation failed. Signed-off-by:
-
Eyal Shapira authored
commit fd7dbee5 upstream. Allow switching back to legacy Tx columns so we'll stop doing HT/VHT in case we're far from the AP. Stop active aggregation when making a deciding to stay in a legacy column. Despite having low legacy rates in the LQ table lower entries it doesn't help much in case we're doing aggregations as the aggregation was being transmitted in the initial rate of the table. This should help traffic stalls when far from the AP. Signed-off-by:
-
Oren Givon authored
commit 80f2679e upstream. Add 2 new HW IDs for the 7265 series. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Eyal Shapira authored
commit d9088f60 upstream. mimo_delim was always set to 0 instead of pointing to the first SISO entry after MIMO rates. This can cause keep transmitting in MIMO even when we shouldn't. For example when the peer is requesting static SMPS. Signed-off-by:
-
Emmanuel Grumbach authored
commit 08a732f4 upstream. It was missing. Signed-off-by:
-
Loic Poulain authored
commit b08c9c31 upstream. On transmit-hold-register empty, serial8250_tx_chars should be called only if we don't use DMA. DMA has its own tx cycle. Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
