- 24 Apr, 2015 1 commit
-
-
Konstantin Khlebnikov authored
[ Upstream commit 7a3ef208 ] Constantly forking task causes unlimited grow of anon_vma chain. Each next child allocates new level of anon_vmas and links vma to all previous levels because pages might be inherited from any level. This patch adds heuristic which decides to reuse existing anon_vma instead of forking new one. It adds counter anon_vma->degree which counts linked vmas and directly descending anon_vmas and reuses anon_vma if counter is lower than two. As a result each anon_vma has either vma or at least two descending anon_vmas. In such trees half of nodes are leafs with alive vmas, thus count of anon_vmas is no more than two times bigger than count of vmas. This heuristic reuses anon_vmas as few as possible because each reuse adds false aliasing among vmas and rmap walker ought to scan more ptes when it searches where page is might be mapped. Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu Fixes: 5beb4930 ("mm: change anon_vma linking to fix multi-process server scalability issue") [akpm@linux-foundation.org: fix typo, per Rik] Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Reported-by:
Daniel Forrest <dan.forrest@ssec.wisc.edu> Tested-by:
Michal Hocko <mhocko@suse.cz> Tested-by:
Jerome Marchand <jmarchan@redhat.com> Reviewed-by:
Rik van Riel <riel@redhat.com> Cc: <stable@vger.kernel.org> [2.6.34+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
- 23 Apr, 2015 37 commits
-
-
Johannes Berg authored
[ Upstream commit 788211d8 ] There's an issue with the way the RX A-MPDU reorder timer is deleted that can cause a kernel crash like this: * tid_rx is removed - call_rcu(ieee80211_free_tid_rx) * station is destroyed * reorder timer fires before ieee80211_free_tid_rx() runs, accessing the station, thus potentially crashing due to the use-after-free The station deletion is protected by synchronize_net(), but that isn't enough -- ieee80211_free_tid_rx() need not have run when that returns (it deletes the timer.) We could use rcu_barrier() instead of synchronize_net(), but that's much more expensive. Instead, to fix this, add a field tracking that the session is being deleted. In this case, the only re-arming of the timer happens with the reorder spinlock held, so make that code not rearm it if the session is being deleted and also delete the timer after setting that field. This ensures the timer cannot fire after ___ieee80211_stop_rx_ba_session() returns, which fixes the problem. Cc: stable@vger.kernel.org Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sudip Mukherjee authored
[ Upstream commit ff6b8090 ] we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Acked-by:
Paul Clements <Paul.Clements@SteelEye.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Paul Clarke authored
[ Upstream commit fea559f3 ] Implement arch_irq_work_has_interrupt() for powerpc Commit 9b01f5bf introduced a dependency on "IRQ work self-IPIs" for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt() routine. Several arches have implemented this routine, including x86 (3010279f) and arm (09f6edd4), but powerpc was omitted. This patch implements this routine for powerpc. The symptom, at boot (on powerpc systems) with "nohz_full=<CPU list>" is displayed: NO_HZ: Can't run full dynticks because arch doesn't support irq work self-IPIs after this patch: NO_HZ: Full dynticks CPUs: <CPU list>. Tested against 3.19. powerpc implements "IRQ work self-IPIs" by setting the decrementer to 1 in arch_irq_work_raise(), which causes a decrementer exception on the next timebase tick. We then handle the work in __timer_interrupt(). CC: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
Paul A. Clarke <pc@us.ibm.com> Reviewed-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> [mpe: Flesh out change log, fix ws & include guards, remove include of processor.h] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jan Stancek authored
[ Upstream commit d52356e7 ] Space allocated for paca is based off nr_cpu_ids, but pnv_alloc_idle_core_states() iterates paca with cpu_nr_cores()*threads_per_core, which is using NR_CPUS. This causes pnv_alloc_idle_core_states() to write over memory, which is outside of paca array and may later lead to various panics. Fixes: 7cba160a (powernv/cpuidle: Redesign idle states management) Signed-off-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
[ Upstream commit 340f0ba1 ] alloc_init_lock_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. Noticed by inspection after Jeff Layton fixed the same bug for open owners. Depending on client behavior, this one may be trickier to trigger in practice. Fixes: c58c6610 "nfsd: Protect adding/removing lock owners using client_lock" Cc: <stable@vger.kernel.org> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Acked-by:
Jeff Layton <jeff.layton@primarydata.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Jeff Layton authored
[ Upstream commit c5952338 ] alloc_init_open_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. In commit 7ffb5880, we changed it so that we allocate and initialize an openowner, and then check to see if a matching one got stuffed into the hashtable in the meantime. If it did, then we free the one we just allocated and take a reference on the one already there. There is a bug here though. The code will then return the pointer to the one that was allocated (and has now been freed). This wasn't evident before as this race almost never occurred. The Linux kernel client used to serialize requests for a single openowner. That has changed now with v4.0 kernels, and this race can now easily occur. Fixes: 7ffb5880 Cc: <stable@vger.kernel.org> # v3.17+ Cc: Trond Myklebust <trond.myklebust@primarydata.com> Reported-by:
Christoph Hellwig <hch@infradead.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Juergen Gross authored
[ Upstream commit 3c56b3a1 ] Commit 25b884a8 ("x86/xen: set regions above the end of RAM as 1:1") introduced a regression. To be able to add memory pages which were added via memory hotplug to a pv domain, the pages must be "invalid" instead of "identity" in the p2m list before they can be added. Suggested-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Cc: <stable@vger.kernel.org> # 3.16+ Reviewed-by:
Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit 9c8928f5 ] The assumption before this patch was that we don't need to run again the INIT firmware after the system booted. The INIT firmware runs calibrations which impact the physical layer's behavior. Users reported that it may be helpful to run these calibrations again every time the interface is brought up. The penatly is minimal, since the calibrations run fast. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=94341 CC: <stable@vger.kernel.org> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Shachar Raindel authored
[ Upstream commit 8494057a ] Properly verify that the resulting page aligned end address is larger than both the start address and the length of the memory area requested. Both the start and length arguments for ib_umem_get are controlled by the user. A misbehaving user can provide values which will cause an integer overflow when calculating the page aligned end address. This overflow can cause also miscalculation of the number of pages mapped, and additional logic issues. Addresses: CVE-2014-8159 Cc: <stable@vger.kernel.org> Signed-off-by:
Shachar Raindel <raindel@mellanox.com> Signed-off-by:
Jack Morgenstein <jackm@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
David Sterba authored
[ Upstream commit 9c4f61f0 ] We can search and add the orphan item in one go, btrfs_insert_orphan_item will find out if the item already exists. Signed-off-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
-
Daniel Vetter authored
[ Upstream commit f37b5c2b ] Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: stable@vger.kernel.org Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by:
Johannes W <jargon@molb.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jesse Barnes authored
[ Upstream commit 5df0582b ] Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
Darren Hart <dvhart@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by:
-
Jesse Barnes authored
[ Upstream commit 9c25210f ] Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Deepak S authored
[ Upstream commit 5df0582b ] Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by:
-
Christian König authored
[ Upstream commit 22e2e865 ] We need to wait for all fences, not just the exclusive one. Signed-off-by:
Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
[ Upstream commit 863653fe ] We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 3899ca84 ] Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796Signed-off-by:
-
Ville Syrjälä authored
[ Upstream commit 840a1cf0 ] The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Cc: stable@vger.kernel.org Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.comReported-and-tested-by:
Tommi Rantala <tt.rantala@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
[ Upstream commit ad692b46 ] If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691Reported-by:
Emil <emilsvennesson@gmail.com> Reported-by:
Rob Engle <grenoble@gmail.com> Tested-by:
Jolan Luff <jolan@gormsby.com> Reviewed-by:
-
Daniel Vetter authored
[ Upstream commit 8218c3f4 ] Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Wenbo Wang authored
[ Upstream commit 7ee8e4f3 ] Use the right array index to reference the last element of rq->biotail->bi_io_vec[] Signed-off-by:
Wenbo Wang <wenbo.wang@memblaze.com> Reviewed-by:
Chong Yuan <chong.yuan@memblaze.com> Fixes: 66cb45aa ("block: add support for limiting gaps in SG lists") Cc: stable@kernel.org Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Mike Snitzer authored
[ Upstream commit 9a30b096 ] If percpu_ref_init() fails the allocated q and hctxs must get cleaned up; using 'err_map' doesn't allow that to happen. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Reviewed-by:
Ming Lei <ming.lei@canonical.com> Cc: stable@kernel.org Signed-off-by:
-
Joe Perches authored
[ Upstream commit 6436a123 ] Return a negative error value like the rest of the entries in this function. Cc: <stable@vger.kernel.org> Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> [PM: tweaked subject line] Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit fdc0074c ] As the sunxi usb clocks all contain a reset controller, it is not possible to build the sunxi clock driver without RESET_CONTROLLER enabled. Doing so results in an undefined symbol error: drivers/built-in.o: In function `sunxi_gates_clk_setup': linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to `reset_controller_register' This is possible if building a minimal kernel without PHY_SUN4I_USB. The dependency issue is made visible at compile time instead of link time by the new A80 mmc clocks, which also use a reset control itself. This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER. Fixes: 559482d1 ARM: sunxi: Split the various SoCs support in Kconfig Cc: <stable@vger.kernel.org> # 3.16+ Reported-by:
Lourens Rozema <ik@lourensrozema.nl> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit e4140819 ] A malicious signal handler / restorer can DOS the system by fudging the user regs saved on stack, causing weird things such as sigreturn returning to user mode PC but cpu state still being kernel mode.... Ensure that in sigreturn path status32 always has U bit; any other bogosity (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms. Reproducer signal handler: void handle_sig(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); regs->scratch.status32 = 0; } Before the fix, kernel would go off to weeds like below: --------->8----------- [ARCLinux]$ ./signal-test Path: /signal-test CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65 task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000 [ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698 [EFA ]: 0x00000010 [BLINK ]: 0x2007c1ee [ERET ]: 0x10698 [STAT32]: 0x00000000 : <-------- BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000 LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000 ... --------->8----------- Reported-by:
Alexey Brodkin <abrodkin@synopsys.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 6914e1e3 ] The regfile provided to SA_SIGINFO signal handler as ucontext was off by one due to pt_regs gutter cleanups in 2013. Before handling signal, user pt_regs are copied onto user_regs_struct and copied back later. Both structs are binary compatible. This was all fine until commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot at top of pt_regs (corresponding to first pad) and made the corresponding fixup in struct user_regs_struct (the pad in there was moved out of @scratch - not removed altogether as it is part of ptrace ABI) struct user_regs_struct { + long pad; struct { - long pad; long bta, lp_start, lp_end,.... } scratch; ... } This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and signal code needs to user_regs_struct.scratch to reflect it as pt_regs, which is what this commit does. This problem was hidden for 2 years, because both save/restore, despite using wrong location, were using the same location. Only an interim inspection (reproducer below) exposed the issue. void handle_segv(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); printf("regs %x %x\n", <=== prints 7 8 (vs. 8 9) regs->scratch.r8, regs->scratch.r9); } int main() { struct sigaction sa; sa.sa_sigaction = handle_segv; sa.sa_flags = SA_SIGINFO; sigemptyset(&sa.sa_mask); sigaction(SIGSEGV, &sa, NULL); asm volatile( "mov r7, 7 \n" "mov r8, 8 \n" "mov r9, 9 \n" "mov r10, 10 \n" :::"r7","r8","r9","r10"); *((unsigned int*)0x10) = 0; } Fixes: 2fa91904 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs" CC: <stable@vger.kernel.org> Signed-off-by:
-
Matwey V. Kornilov authored
[ Upstream commit a43f32d6 ] Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it to platform_driver_register(), which can use the pointer at arbitrary times in the future, even after the initdata is freed. That leads to crashes. Move spear13xx_pcie_driver and things referenced by it (spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata. [bhelgaas: changelog] Fixes: 6675ef21 ("PCI: spear: Fix Section mismatch compilation warning for probe()") Signed-off-by:
Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> CC: stable@vger.kernel.org # v3.17+ Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 8647ca9a ] Booting a v3.18 or newer Xen domU kernel with PCI devices passed through results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0 hypervisor and 32-bit domU): BUG: unable to handle kernel paging request at 0030303e IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a Call Trace: [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0 [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30 [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4 [<c0699d34>] ? pci_device_add+0x24/0x450 Don't look for ACPI configuration information if ACPI has been disabled. I don't think this is the best fix, because we can boot plain Linux (no Xen) with "acpi=off", and we don't need this check in pci_get_hp_params(). There should be a better fix that would make Xen domU work the same way. The domU kernel has ACPI support but it has no AML. There should be a way to initialize the ACPI data structures so things fail gracefully rather than oopsing. This is an interim fix to address the regression. Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by:
Michael D Labriola <mlabriol@gdeb.com> Tested-by:
-
Dan Carpenter authored
[ Upstream commit bc3b5b47 ] I don't have this hardware but it looks like we weren't adding bridge devices as intended. Maybe the bridge is always the last device? Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Yijing Wang <wangyijing@huawei.com> CC: stable@vger.kernel.org # v3.9+ Signed-off-by:
-
Rasmus Villemoes authored
[ Upstream commit a1b7f2f6 ] Commit fab4c256 ("PCI/AER: Add a TLP header print helper") introduced the helper function __print_tlp_header(), but contrary to the intention, the behaviour did change: Since we're taking the address of the parameter t, the first 4 or 8 bytes printed will be the value of the pointer t itself, and the remaining 12 or 8 bytes will be who-knows-what (something from the stack). We want to show the values of the four members of the struct aer_header_log_regs; that can be done without ugly and error-prone casts. On little-endian this should produce the same output as originally intended, and since no-one has complained about getting garbage output so far, I think big-endian should be ok too. Fixes: fab4c256 ("PCI/AER: Add a TLP header print helper") Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Borislav Petkov <bp@suse.de> CC: stable@vger.kernel.org # v3.14+ Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit cc7016ab ] Some BIOS version of Fujitsu Lifebook T731 seems to set up the headphone pin (0x21) without the assoc number 0x0f while it's set only to the output on the docking port (0x1a). With the recent commit [03ad6a8c: ALSA: hda - Fix "PCM" name being used on one DAC when there are two DACs], this resulted in the weird mixer element mapping where the headphone on the laptop is assigned as a shared volume with the speaker and the docking port is assigned as an individual headphone. This patch improves the situation by correcting the headphone pin config to the more appropriate value. Reported-and-tested-by:
Taylor Smock <smocktaylor@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
[ Upstream commit a59d7199 ] Pin sense will active when power pin is wake up. Power pin will not wake up immediately during resume state. Add some delay to wait for power pin activated. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Sakamoto authored
[ Upstream commit a053fc31 ] Some M-Audio devices require to receive bootup command just after powering on, while codes in BeBoB driver doesn't work properly in big-endian machine because the command should be aligned by little-endian. This commit fixes this bug. This fix should go to stable kernel. Cc: Takayuki Shiroma <t.shiroma.oki@gmail.com> Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dmitry M. Fedin authored
[ Upstream commit 3dc8523f ] Adds an entry for Creative USB X-Fi to the rc_config array in mixer_quirks.c to allow use of volume knob on the device. Adds support for newer X-Fi Pro card, known as "Model No. SB1095" with USB ID "041e:3237" Signed-off-by:
Dmitry M. Fedin <dmitry.fedin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hui Wang authored
[ Upstream commit af95b414 ] We have a HP machine which use the codec node 0x17 connecting the internal speaker, and from the node capability, we saw the EAPD, if we don't set the EAPD on for this node, the internal speaker can't output any sound. Cc: <stable@vger.kernel.org> BugLink: https://bugs.launchpad.net/bugs/1436745Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Sebastian Wicki authored
[ Upstream commit 80b311d3 ] This model uses the same dock port as the previous generation. Signed-off-by:
Sebastian Wicki <gandro@gmx.net> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Peter Hurley authored
[ Upstream commit fb5ef9e7 ] BugLink: http://bugs.launchpad.net/bugs/1381005 In canon mode, the read buffer head will advance over the buffer tail if the input > 4095 bytes without receiving a line termination char. Discard additional input until a line termination is received. Before evaluating for overflow, the 'room' value is normalized for I_PARMRK and 1 byte is reserved for line termination (even in !icanon mode, in case the mode is switched). The following table shows the transform: actual buffer | 'room' value before overflow calc space avail | !I_PARMRK | I_PARMRK -------------------------------------------------- 0 | -1 | -1 1 | 0 | 0 2 | 1 | 0 3 | 2 | 0 4+ | 3 | 1 When !icanon or when icanon and the read buffer contains newlines, normalized 'room' values of -1 and 0 are clamped to 0, and 'overflow' is 0, so read_head is not adjusted and the input i/o loop exits (setting no_room if called from flush_to_ldisc()). No input is discarded since the reader does have input available to read which ensures forward progress. When icanon and the read buffer does not contain newlines and the normalized 'room' value is 0, then overflow and room are reset to 1, so that the i/o loop will process the next input char normally (except for parity errors which are ignored). Thus, erasures, signalling chars, 7-bit mode, etc. will continue to be handled properly. If the input char processed was not a line termination char, then the canon_head index will not have advanced, so the normalized 'room' value will now be -1 and 'overflow' will be set, which indicates the read_head can safely be reset, effectively erasing the last char processed. If the input char processed was a line termination, then the canon_head index will have advanced, so 'overflow' is cleared to 0, the read_head is not reset, and 'room' is cleared to 0, which exits the i/o loop (because the reader now have input available to read which ensures forward progress). Note that it is possible for a line termination to be received, and for the reader to copy the line to the user buffer before the input i/o loop is ready to process the next input char. This is why the i/o loop recomputes the room/overflow state with every input char while handling overflow. Finally, if the input data was processed without receiving a line termination (so that overflow is still set), the pty driver must receive a write wakeup. A pty writer may be waiting to write more data in n_tty_write() but without unthrottling here that wakeup will not arrive, and forward progress will halt. (Normally, the pty writer is woken when the reader reads data out of the buffer and more space become available). Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit fb5ef9e7) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com>
-
- 20 Apr, 2015 1 commit
-
-
Sasha Levin authored
Signed-off-by:
-
- 17 Apr, 2015 1 commit
-
-
Ameya Palande authored
[ Upstream commit c8648508 ] On success, callback function returns 0. So invert the if condition check so that we can break out of loop. Cc: stable@vger.kernel.org Signed-off-by:
Ameya Palande <2ameya@gmail.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
