aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-05-15Merge branches 'acpi-ac' and 'acpi-proc'Rafael J. Wysocki6-61/+509
* acpi-ac: ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus" * acpi-proc: ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig ACPI: Revert "ACPI / Battery: Remove battery's proc directory" ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"
2014-05-15Merge branches 'acpica', 'acpi-tpm' and 'acpi-processor'Rafael J. Wysocki340-2576/+3928
* acpica: ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table(). * acpi-tpm: ACPI / TPM: Fix resume regression on Chromebooks * acpi-processor: ACPI / processor: do not mark present at boot but not onlined CPU as onlined
2014-05-15drm/i915: Increase WM memory latency values on SNBVille Syrjälä1-0/+40
On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 Tested-by: Robert Navarro <[email protected]> Tested-by: Vitaly Minko <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-05-15KVM: s390: announce irqfd capabilityCornelia Huck2-1/+2
s390 has acquired irqfd support with commit "KVM: s390: irq routing for adapter interrupts" (84223598778ba08041f4297fda485df83414d57e) but failed to announce it. Let's fix that. Signed-off-by: Cornelia Huck <[email protected]> Acked-by: Christian Borntraeger <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]>
2014-05-15drm/i915: restore backlight precision when converting from ACPIAaron Lu1-4/+4
When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-05-15drm/i915: Use the first mode if there is no preferred mode in the EDIDChris Wilson1-0/+9
This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by: Knut Petersen <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655 Reviewed-by: Jesse Barnes <[email protected]> Tested-by: Knut Petersen <[email protected]> Signed-off-by: Chris Wilson <[email protected]> [Jani: applied Chris' "Please imagine that I wrote this correctly."] Signed-off-by: Jani Nikula <[email protected]>
2014-05-15drm/i915/dp: force eDP lane count to max available lanes on BDWJani Nikula1-1/+6
There are certain BDW high res eDP machines that regressed due to commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <[email protected]> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-05-14x86-64, modify_ldt: Make support for 16-bit segments a runtime optionLinus Torvalds2-1/+11
Checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Cc: <[email protected]>
2014-05-15asm-generic: remove _STK_LIM_MAXJames Hogan2-8/+1
_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from an arch's include/uapi/asm-generic/resource.h file, but is no longer used since both parisc and metag removed the override. Therefore remove it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY directly in include/asm-generic/resource.h. Signed-off-by: James Hogan <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: [email protected] Cc: Helge Deller <[email protected]> Cc: John David Anglin <[email protected]>
2014-05-15metag: Remove _STK_LIM_MAX overrideJames Hogan2-8/+1
Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to 256MB, apparently in an attempt to prevent setup_arg_pages's STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is far too large for Meta's limited virtual address space and hits a BUG_ON (stack_top is usually 0x3ffff000). However the commit "metag: Reduce maximum stack size to 256MB" reduces the absolute stack size limit to a safe value for metag. This allows the default _STK_LIM_MAX override to be removed, bringing the default behaviour in line with all other architectures. Parisc in particular recently removed their override of _STK_LIMT_MAX in commit e0d8898d76a7 (parisc: remove _STK_LIM_MAX override) since it subtly affects stack allocation semantics in userland. Meta's uapi/asm/resource.h can now be removed and switch to using generic-y. Suggested-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: [email protected] Cc: John David Anglin <[email protected]>
2014-05-15xfs: list_lru_init returns a negative errorDave Chinner1-12/+14
And we don't invert it properly when initialising the dquot lru list. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: negate xfs_icsb_init_counters error value Dave Chinner1-1/+1
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: negate mount workqueue init error valueDave Chinner1-1/+1
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: fix wrong err sign on xfs_set_acl()Dave Chinner1-2/+2
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: fix wrong errno from xfs_initxattrsDave Chinner1-4/+4
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: correct error sign on COLLAPSE_RANGE errorsDave Chinner1-2/+2
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: xfs_commit_metadata returns wrong errnoDave Chinner1-1/+1
Invert it. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: fix incorrect error sign in xfs_file_aio_readDave Chinner1-1/+1
Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15xfs: xfs_dir_fsync() returns positive errnoDave Chinner1-1/+1
And it should be negative. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jie Liu <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-05-15parisc,metag: Do not hardcode maximum userspace stack sizeHelge Deller4-5/+23
This patch affects only architectures where the stack grows upwards (currently parisc and metag only). On those do not hardcode the maximum initial stack size to 1GB for 32-bit processes, but make it configurable via a config option. The main problem with the hardcoded stack size is, that we have two memory regions which grow upwards: stack and heap. To keep most of the memory available for heap in a flexmap memory layout, it makes no sense to hard allocate up to 1GB of the memory for stack which can't be used as heap then. This patch makes the stack size for 32-bit processes configurable and uses 80MB as default value which has been in use during the last few years on parisc and which hasn't showed any problems yet. Signed-off-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]>
2014-05-15metag: Reduce maximum stack size to 256MBJames Hogan3-3/+7
Specify the maximum stack size for arches where the stack grows upward (parisc and metag) in asm/processor.h rather than hard coding in fs/exec.c so that metag can specify a smaller value of 256MB rather than 1GB. This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased beyond a safe value by root. E.g. when starting a process after running "ulimit -H -s unlimited" it will then attempt to use a stack size of the maximum 1GB which is far too big for metag's limited user virtual address space (stack_top is usually 0x3ffff000): BUG: failure at fs/exec.c:589/shift_arg_pages()! Signed-off-by: James Hogan <[email protected]> Cc: Helge Deller <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]> Cc: [email protected] # only needed for >= v3.9 (arch/metag)
2014-05-15metag: fix memory barriersMikulas Patocka1-0/+3
Volatile access doesn't really imply the compiler barrier. Volatile access is only ordered with respect to other volatile accesses, it isn't ordered with respect to general memory accesses. Gcc may reorder memory accesses around volatile access, as we can see in this simple example (if we compile it with optimization, both increments of *b will be collapsed to just one): void fn(volatile int *a, long *b) { (*b)++; *a = 10; (*b)++; } Consequently, we need the compiler barrier after a write to the volatile variable, to make sure that the compiler doesn't reorder the volatile write with something else. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: James Hogan <[email protected]>
2014-05-14dm mpath: fix lock order inconsistency in multipath_ioctlMike Snitzer1-1/+1
Commit 3e9f1be1b40 ("dm mpath: remove process_queued_ios()") did not consistently take the multipath device's spinlock (m->lock) before calling dm_table_run_md_queue_async() -- which takes the q->queue_lock. Found with code inspection using hint from reported lockdep warning. Reported-by: Bart Van Assche <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2014-05-14dm thin: add timeout to stop out-of-data-space mode holding IO foreverJoe Thornber1-0/+21
If the pool runs out of data space, dm-thin can be configured to either error IOs that would trigger provisioning, or hold those IOs until the pool is resized. Unfortunately, holding IOs until the pool is resized can result in a cascade of tasks hitting the hung_task_timeout, which may render the system unavailable. Add a fixed timeout so IOs can only be held for a maximum of 60 seconds. If LVM is going to resize a thin-pool that is out of data space it needs to be prompt about it. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+
2014-05-14dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE modeJoe Thornber1-1/+1
Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced a regression in the metadata commit() method by returning an error if the pool is in PM_OUT_OF_DATA_SPACE mode. This oversight caused a thin device to return errors even if the default queue_if_no_space ENOSPC handling mode is used. Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode. Reported-by: [email protected] Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+
2014-05-14dm crypt: fix cpu hotplug crash by removing per-cpu structureMikulas Patocka1-49/+12
The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0 [<ffffffff81052a28>] ? process_one_work+0x168/0x470 [<ffffffff8105366b>] ? worker_thread+0x10b/0x390 [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290 [<ffffffff81058d9f>] ? kthread+0xaf/0xc0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected]
2014-05-14net: filter: s390: fix JIT address randomizationHeiko Carstens1-1/+1
This is the s390 variant of Alexei's JIT bug fix. (patch description below stolen from Alexei's patch) bpf_alloc_binary() adds 128 bytes of room to JITed program image and rounds it up to the nearest page size. If image size is close to page size (like 4000), it is rounded to two pages: round_up(4000 + 4 + 128) == 8192 then 'hole' is computed as 8192 - (4000 + 4) = 4188 If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header) then kernel will crash during bpf_jit_free(): kernel BUG at arch/x86/mm/pageattr.c:887! Call Trace: [<ffffffff81037285>] change_page_attr_set_clr+0x135/0x460 [<ffffffff81694cc0>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff810378ff>] set_memory_rw+0x2f/0x40 [<ffffffffa01a0d8d>] bpf_jit_free_deferred+0x2d/0x60 [<ffffffff8106bf98>] process_one_work+0x1d8/0x6a0 [<ffffffff8106bf38>] ? process_one_work+0x178/0x6a0 [<ffffffff8106c90c>] worker_thread+0x11c/0x370 since bpf_jit_free() does: unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK; struct bpf_binary_header *header = (void *)addr; to compute start address of 'bpf_binary_header' and header->pages will pass junk to: set_memory_rw(addr, header->pages); Fix it by making sure that &header->image[prandom_u32() % hole] and &header are in the same page. Fixes: aa2d2c73c21f2 ("s390/bpf,jit: address randomize and write protect jit code") Reported-by: Alexei Starovoitov <[email protected]> Cc: <[email protected]> # v3.11+ Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-14ath9k_htc: Stop ANI before doing hw_resetRajkumar Manoharan1-1/+4
During remain on channel request, ANI worker thread is not stopped before doing hw reset. This is causing kernel crash in hw_per_calibration. This change ensures that ANI is stopped before doing chip reset and it will be rescheduled later when the chip is configured back to home channel and having valid bss. Reported-by: David Herrmann <[email protected]> Tested-by: David Herrmann <[email protected]> Signed-off-by: Rajkumar Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2014-05-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211John W. Linville4-15/+37
2014-05-14af_iucv: wrong mapping of sent and confirmed skbsUrsula Braun1-1/+1
When sending data through IUCV a MESSAGE COMPLETE interrupt signals that sent data memory can be freed or reused again. With commit f9c41a62bba3f3f7ef3541b2a025e3371bcbba97 "af_iucv: fix recvmsg by replacing skb_pull() function" the MESSAGE COMPLETE callback iucv_callback_txdone() identifies the wrong skb as being confirmed, which leads to data corruption. This patch fixes the skb mapping logic in iucv_callback_txdone(). Signed-off-by: Ursula Braun <[email protected]> Signed-off-by: Frank Blaschka <[email protected]> Cc: <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-14be2net: enable interrupts in EEH resumeKalesh AP1-0/+6
On some BE3 FW versions, after a HW reset, interrupts will remain disabled for each function. So, explicitly enable the interrupts in the eeh_resume handler, else after an eeh recovery interrupts wouldn't work. Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Sathya Perla <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-15ARM: dts: Remove g2d_pd node for exynos5420Arun Kumar K1-6/+0
G2D power domain also controls the CMU block of G2D. Since clock registers can be accessed anytime for viewing clk_summary, it can cause a system crash if g2d power domain is disabled. Signed-off-by: Arun Kumar K <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-15ARM: dts: Remove mau_pd node for exynos5420Tushar Behera1-5/+0
MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 Signed-off-by: Tushar Behera <[email protected]> Tested-by: Doug Anderson <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-15ARM: exynos_defconfig: enable HS-I2C to fix for mmc partition mountSachin Kamat1-0/+1
High speed I2C is used on Exynos5 based SoCs. Enable it. The MMC partition for Root filesystem cannot be mounted without this enabling HS-I2C and regulators on many boards are connected HS-I2C bus so the regulators don't come by default without this. Actually, we are not able to get arndale-octa board to boot and mount an MMC partition without this change. Signed-off-by: Sachin Kamat <[email protected]> Tested-by: Javi Merino <[email protected]> [[email protected]: modified description] Signed-off-by: Kukjin Kim <[email protected]>
2014-05-15ARM: dts: disable MDMA1 node for exynos5420Seungwon Jeon2-12/+7
This change places MDMA1 in disabled node for Exynos5420. If MDMA1 region is configured with secure mode, it makes the boot failure with the following on smdk5420 board. ("Unhandled fault: imprecise external abort (0x1406) at 0x00000000") Thus, arndale-octa board don't need to do the same thing anymore. Signed-off-by: Seungwon Jeon <[email protected]> Tested-by: Javi Merino <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-15ARM: EXYNOS: fix the secondary CPU boot of exynos4212Kyungmin Park1-1/+14
This patch fixes the offset of CPU boot address and changes the parameter of smc call for SMC_CMD_CPU1BOOT command on exynos4212. Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-14jme: Fix unmap loop counting error:Neil Horman1-5/+5
In my recent fix (76a691d0a: fix dma unmap warning), Ben Hutchings noted that my loop count was incorrect. Where j started at startidx, it should have started at zero, and gone on for count entries, not to endidx. Additionally, a DMA resource exhaustion should drop the frame and (for now), return NETDEV_TX_OK, not NETEV_TX_BUSY. This patch fixes both of those issues: Signed-off-by: Neil Horman <[email protected]> CC: Ben Hutchings <[email protected]> CC: "David S. Miller" <[email protected]> CC: Guo-Fu Tseng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-14Input: synaptics - add min/max quirk for the ThinkPad W540Hans de Goede1-0/+8
https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Cc: [email protected] Tested-and-reported-by: [email protected] Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2014-05-14ARM: omap5: hwmod_data: Correct IDLEMODE for McPDMPeter Ujfalusi1-1/+1
McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: Peter Ujfalusi <[email protected]> Cc: <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2014-05-14i2c: rcar: bail out on zero length transfersWolfram Sang1-1/+8
This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-05-14i2c: qup: Fix pm_runtime_get_sync usageAndy Gross1-1/+1
This patch corrects the error check on the call to pm_runtime_get_sync. Signed-off-by: Andy Gross <[email protected]> Reviewed-by: Ivan T. Ivanov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2014-05-14i2c: s3c2410: resume race fixOlof Johansson1-1/+1
Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Doug Anderson <[email protected]> Acked-by: Kukjin Kim <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-05-14i2c: nomadik: Don't use IS_ERR for devm_ioremapUlf Hansson1-1/+1
devm_ioremap() returns NULL on error, not an error. Signed-off-by: Ulf Hansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-05-14i2c: designware: Mask all interrupts during i2c controller enableDu, Wenkai1-0/+3
There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: Wenkai Du <[email protected]> Acked-by: Mika Westerberg <[email protected]> [wsa: improved the comment and removed typo in commit msg] Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-05-14MIPS: mm: Fix broken microMIPS kernel regression.Steven J. Hill2-4/+7
Commit f4ae17aa0f2122b52f642985b46210a1f2eceb0a [MIPS: mm: Use scratch for PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This patch refactors that code similar to what was done for the 'clear_page' and 'copy_page' functions. Signed-off-by: Steven J. Hill <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6744/ Signed-off-by: Ralf Baechle <[email protected]>
2014-05-14KVM: x86: disable master clock if TSC is reset during suspendMarcelo Tosatti1-1/+5
Updating system_time from the kernel clock once master clock has been enabled can result in time backwards event, in case kernel clock frequency is lower than TSC frequency. Disable master clock in case it is necessary to update it from the resume path. Signed-off-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-05-14ALSA: sb_mixer: missing return statementDan Carpenter1-6/+8
The if condition here was supposed to return on error but the return statement is missing. The effect is that the ->mixername is set to "???" instead of "DT019X". Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-05-14of: make of_update_property() usable earlier in the boot processThomas Petazzoni1-0/+4
Commit 75b57ecf9d1d1e17d099ab13b8f48e6e038676be ('of: Make device nodes kobjects so they show up in sysfs') has turned Device Tree nodes in kobjects and added a sysfs based representation for Device Tree nodes. Since the sysfs logic is only available after the execution of a core_initcall(), the patch took precautions in of_add_property() and of_remove_property() to not do any sysfs related manipulation early in the boot process. However, it forgot to do the same for of_update_property(), which if used early in the boot process (before core_initcalls have been called), tries to call sysfs_remove_bin_file(), and crashes: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /home/thomas/projets/linux-2.6/fs/kernfs/dir.c:1216 kernfs_remove_by_name_ns+0x80/0x88() kernfs: can not remove '(null)', no directory Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1-00127-g1d7e7b2-dirty #423 [<c0014910>] (unwind_backtrace) from [<c00110ec>] (show_stack+0x10/0x14) [<c00110ec>] (show_stack) from [<c04c84b8>] (dump_stack+0x84/0x94) [<c04c84b8>] (dump_stack) from [<c001d8c0>] (warn_slowpath_common+0x6c/0x88) [<c001d8c0>] (warn_slowpath_common) from [<c001d90c>] (warn_slowpath_fmt+0x30/0x40) [<c001d90c>] (warn_slowpath_fmt) from [<c0104468>] (kernfs_remove_by_name_ns+0x80/0x88) [<c0104468>] (kernfs_remove_by_name_ns) from [<c0394d98>] (of_update_property+0xc0/0xf0) [<c0394d98>] (of_update_property) from [<c0647248>] (mvebu_timer_and_clk_init+0xfc/0x194) [<c0647248>] (mvebu_timer_and_clk_init) from [<c0640934>] (start_kernel+0x218/0x350) [<c0640934>] (start_kernel) from [<00008070>] (0x8070) ---[ end trace 3406ff24bd97382e ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000003c pgd = c0004000 [0000003c] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.15.0-rc1-00127-g1d7e7b2-dirty #423 task: c10ad4d8 ti: c10a2000 task.ti: c10a2000 PC is at kernfs_find_ns+0x8/0xf0 LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [<c0103834>] lr : [<c010394c>] psr: 600001d3 sp : c10a3f34 ip : 00000073 fp : 00000000 r10: 00000000 r9 : cfffc240 r8 : cfdf2980 r7 : cf812c00 r6 : 00000000 r5 : 00000000 r4 : c10b45e0 r3 : c10ad4d8 r2 : 00000000 r1 : cf812c00 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 0000404a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc10a2240) Stack: (0xc10a3f34 to 0xc10a4000) 3f20: c10b45e0 00000000 00000000 3f40: cf812c00 c010394c 00000063 cf812c00 00000001 cf812c00 cfdf29ac c03932cc 3f60: 00000063 cf812bc0 cfdf29ac cf812c00 ffffffff c03943f8 cfdf2980 c0104468 3f80: cfdf2a04 cfdf2980 cf812bc0 c06634b0 c10aa3c0 c0394da4 c10f74dc cfdf2980 3fa0: cf812bc0 c0647248 c10aa3c0 ffffffff c10de940 c10aa3c0 ffffffff c0640934 3fc0: ffffffff ffffffff c06404ec 00000000 00000000 c06634b0 00000000 10c53c7d 3fe0: c10aa434 c06634ac c10ae4c8 0000406a 414fc091 00008070 00000000 00000000 [<c0103834>] (kernfs_find_ns) from [<00000001>] (0x1) Code: e5c89001 eaffffcf e92d40f0 e1a06002 (e1d023bc) ---[ end trace 3406ff24bd97382f ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! To fix this problem, we simply skip the sysfs related calls in of_update_property(), and rely on of_init() to fix up things when it will be called, exactly as is done in of_add_property() and of_remove_property(). Signed-off-by: Thomas Petazzoni <[email protected]> Fixes: 75b57ecf9d1d ("of: Make device nodes kobjects so they show up in sysfs") Signed-off-by: Grant Likely <[email protected]>
2014-05-14mac80211: fix on-channel remain-on-channelJohannes Berg2-7/+21
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. Cc: [email protected] Reported-by: Jouni Malinen <[email protected]> Tested-by: Jouni Malinen <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2014-05-14Merge tag 'asoc-v3.15-rc5-intel' of ↵Takashi Iwai11-59/+126
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Intel fixes for v3.15 This is a relatively large batch of fixes for the newly added Haswell/Baytrail drivers from Intel. It's a bit larger than is good for this point in the cycle but it's all for a newly added driver so not so worrying as it might otherwise be. Some of it's integration problems, some of it's the sort of problem usually turned up in stress tests.
Powered by cgit, Gruvboxed by Blaster4385.