aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-02-08Merge remote-tracking branch 'spi/topic/xilinx' into spi-nextMark Brown1-135/+163
2015-02-08Merge remote-tracking branches 'spi/topic/sirf', 'spi/topic/spidev', ↵Mark Brown8-33/+696
'spi/topic/st-ssc' and 'spi/topic/ti-qspi' into spi-next
2015-02-08Merge remote-tracking branches 'spi/topic/orion', 'spi/topic/pxa2xx', ↵Mark Brown10-212/+180
'spi/topic/qup', 'spi/topic/rockchip' and 'spi/topic/samsung' into spi-next
2015-02-08Merge remote-tracking branches 'spi/topic/img-spfi', 'spi/topic/imx', ↵Mark Brown6-69/+131
'spi/topic/inline', 'spi/topic/meson' and 'spi/topic/mxs' into spi-next
2015-02-08Merge remote-tracking branches 'spi/topic/falcon', 'spi/topic/fsf', ↵Mark Brown38-238/+105
'spi/topic/fsl', 'spi/topic/fsl-dspi' and 'spi/topic/gpio' into spi-next
2015-02-08Merge remote-tracking branches 'spi/topic/atmel', 'spi/topic/config', ↵Mark Brown8-28/+940
'spi/topic/dln2' and 'spi/topic/dw' into spi-next
2015-02-08Merge remote-tracking branch 'spi/topic/sh-msiof' into spi-nextMark Brown3-25/+84
2015-02-08Merge remote-tracking branch 'spi/topic/core' into spi-nextMark Brown1-1/+1
2015-02-08Merge tag 'spi-v3.19-rc7' into spi-linusMark Brown2-2/+16
spi: Fixes for v3.19 A couple of driver specific fixes: - Disable DMA mode for i.MX6DL chips due to a hardware bug. - Don't use devm_kzalloc() outside of bind/unbind paths in the fsl-dspi driver, fixing memory leaks. # gpg: Signature made Thu 05 Feb 2015 05:06:57 HKT using RSA key ID 5D5487D0 # gpg: WARNING: digest algorithm MD5 is deprecated # gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: key AF88CD16: no public key for trusted key - skipped # gpg: key AF88CD16 marked as ultimately trusted # gpg: key 5621E907: no public key for trusted key - skipped # gpg: key 5621E907 marked as ultimately trusted # gpg: Good signature from "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>"
2015-02-08Merge remote-tracking branches 'regulator/topic/rk808', ↵Mark Brown4-11/+21
'regulator/topic/rpm', 'regulator/topic/rt5033' and 'regulator/topic/tps65023' into regulator-next
2015-02-08Merge remote-tracking branches 'regulator/topic/max8649', ↵Mark Brown11-89/+878
'regulator/topic/mode', 'regulator/topic/mt6397', 'regulator/topic/pfuze100' and 'regulator/topic/qcom-rpm' into regulator-next
2015-02-08Merge remote-tracking branches 'regulator/topic/isl9305', ↵Mark Brown9-76/+340
'regulator/topic/lp872x', 'regulator/topic/max14577', 'regulator/topic/max7686' and 'regulator/topic/max77843' into regulator-next
2015-02-08Merge remote-tracking branches 'regulator/topic/axp20x', ↵Mark Brown5-61/+61
'regulator/topic/da9211' and 'regulator/topic/fan53555' into regulator-next
2015-02-08Merge remote-tracking branch 'regulator/topic/dt-cb' into regulator-nextMark Brown4-5/+43
2015-02-08Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown1-130/+111
2015-02-08Merge remote-tracking branch 'regulator/fix/qcom-rpm' into regulator-linusMark Brown1-1/+1
2015-02-08Merge tag 'regulator-v3.19-rc7' into regulator-linusMark Brown1-3/+10
regulator: Fix !REGULATOR builds of systems using system suspend calls The system suspend calls (used to synchronize between system suspend of the CPU and it's PMIC) are called from board code but not stubbed when regulator is disabled causing build failures in such cases. This patch fixes those build failures. # gpg: Signature made Thu 05 Feb 2015 05:10:43 HKT using RSA key ID 5D5487D0 # gpg: WARNING: digest algorithm MD5 is deprecated # gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: key AF88CD16: no public key for trusted key - skipped # gpg: key AF88CD16 marked as ultimately trusted # gpg: key 5621E907: no public key for trusted key - skipped # gpg: key 5621E907 marked as ultimately trusted # gpg: Good signature from "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>" # gpg: aka "Mark Brown <[email protected]>"
2015-02-08Merge remote-tracking branches 'regmap/topic/ac97', 'regmap/topic/doc' and ↵Mark Brown5-7/+56
'regmap/topic/smbus' into regmap-next
2015-02-08Merge remote-tracking branch 'regmap/topic/core' into regmap-nextMark Brown1-2/+4
2015-02-07x86/tlb/trace: Do not trace on CPU that is offlineSteven Rostedt (Red Hat)1-1/+3
When taking a CPU down for suspend and resume, a tracepoint may be called when the CPU has been designated offline. As tracepoints require RCU for protection, they must not be called if the current CPU is offline. Unfortunately, trace_tlb_flush() is called in this scenario as was noted by LOCKDEP: ... Disabling non-boot CPUs ... intel_pstate CPU 1 exiting =============================== smpboot: CPU 1 didn't die... [ INFO: suspicious RCU usage. ] 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted ------------------------------- include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 0 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011 ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600 0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78 Call Trace: [<ffffffff817e370d>] dump_stack+0x4c/0x65 [<ffffffff810d6847>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff810b71a5>] idle_task_exit+0x205/0x2c0 [<ffffffff81054c4e>] play_dead_common+0xe/0x50 [<ffffffff81054ca5>] native_play_dead+0x15/0x140 [<ffffffff8102963f>] arch_cpu_idle_dead+0xf/0x20 [<ffffffff810cd89e>] cpu_startup_entry+0x37e/0x580 [<ffffffff81053e20>] start_secondary+0x140/0x150 intel_pstate CPU 2 exiting ... By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected code when the CPU is offline. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Cc: [email protected] # 3.17+ Fixes: d17d8f9dedb9 "x86/mm: Add tracepoints for TLB flushes" Reported-by: Sedat Dilek <[email protected]> Tested-by: Sedat Dilek <[email protected]> Suggested-by: Paul E. McKenney <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Dave Hansen <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2015-02-07tracing: Add condition check to RCU lockdep checksSteven Rostedt (Red Hat)1-1/+1
The trace_tlb_flush() tracepoint can be called when a CPU is going offline. When a CPU is offline, RCU is no longer watching that CPU and since the tracepoint is protected by RCU, it must not be called. To prevent the tlb_flush tracepoint from being called when the CPU is offline, it was converted to a TRACE_EVENT_CONDITION where the condition checks if the CPU is online before calling the tracepoint. Unfortunately, this was not enough to stop lockdep from complaining about it. Even though the RCU protected code of the tracepoint will never be called, the condition is hidden within the tracepoint, and even though the condition prevents RCU code from being called, the lockdep checks are outside the tracepoint (this is to test tracepoints even when they are not enabled). Even though tracepoints should be checked to be RCU safe when they are not enabled, the condition should still be considered when checking RCU. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are disabled" Cc: [email protected] # 3.18+ Acked-by: Dave Hansen <[email protected]> Reported-by: Sedat Dilek <[email protected]> Tested-by: Sedat Dilek <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2015-02-07Merge tag 'rdma-for-linus' of ↵Linus Torvalds5-130/+42
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband Pull one more infiniband revert from Roland Dreier: "One more last-second RDMA change for 3.19: Yann realized that the previous revert of new userspace ABI did not go far enough, and we're still exposing a change that we don't want. Revert even closer to 3.18 interface to make sure we get things right in the long run" Yann Droneaud pipes up: "I hope this could go in v3.19 as, at this stage, we don't want to expose any bits of this ABI in a released kernel" * tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband: Revert "IB/core: Add support for extended query device caps"
2015-02-07Merge branch 'for-linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fix from Chris Mason: "Forrest Liu tracked down a missing blk_finish_plug in the btrfs logging code. This isn't a new bug, and it's hard to hit. But, it's safe enough for inclusion now, and in my for-linus branch" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: add missing blk_finish_plug in btrfs_sync_log()
2015-02-07Merge branch 'pci/misc' into nextBjorn Helgaas1-0/+2
* pci/misc: PCI: Add pci_device_to_OF_node() stub for !CONFIG_OF
2015-02-06Merge branches 'timers-urgent-for-linus' and 'x86-urgent-for-linus' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer and x86 fix from Ingo Molnar: "A CLOCK_TAI early expiry fix and an x86 microcode driver oops fix" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hrtimer: Fix incorrect tai offset calculation for non high-res timer systems * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, microcode: Return error from driver init code when loader is disabled
2015-02-06intel_pstate: provide option to only use intel_pstate with HWPKristen Carlson Accardi2-0/+9
Allow users the option to disable the driver for any hardware which does not support HWP. Signed-off-by: Kristen Carlson Accardi <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds4-8/+34
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: "Misc fixes" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/deadline: Fix deadline parameter modification handling sched/wait: Remove might_sleep() from wait_event_cmd() sched: Fix crash if cpuset_cpumask_can_shrink() is passed an empty cpumask sched/fair: Avoid using uninitialized variable in preferred_group_nid()
2015-02-06Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds3-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull core kernel fixes from Ingo Molnar: "Two liblockdep fixes and a CPU hotplug race fix" * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tools/liblockdep: don't include host headers tools/liblockdep: ignore generated .so file smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()
2015-02-06Merge tag 'sound-3.19' of ↵Linus Torvalds18-69/+109
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Hopefully the final pull request for 3.19: this ended up with a slightly higher volume than wished, but I put them all as they are either stable or 3.19 regression fixes. Most of commits are from ASoC, and have been stewed for a while in linux-next. The only change in the common code is the regression fixes for ASoC AC97 stuff wrt device registrations. The rest are device-specific, mostly small fixes in various ASoC drivers and ak411x on ice1724 boards" * tag 'sound-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: Intel: fix sst firmware path for cht-bsw-rt5672 ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs ASoC: sgtl5000: add delay before first I2C access MAINTAINERS: ASoC: add maintainer for Intel BDW/HSW ASoC driver ASoC: atmel_ssc_dai: fix the setting for DSP mode ASoC: sgtl5000: Use shift mask when setting codec mode ASoC: tlv320aic3x: Fix data delay configuration ALSA: ak411x: Fix stall in work callback ASoC: Intel: Used lock version to update shim registers ASoC: wm8731: init mutex in i2c init path ASoC: atmel_ssc_dai: fix start event for I2S mode ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail ASoC: wm97xx: Reset AC'97 device before registering it ASoC: Add support for allocating AC'97 device before registering it
2015-02-06Merge branch 'akpm' (patches from Andrew Morton)Linus Torvalds13-34/+52
Merge misc fixes from Andrew Morton: "7 fixes" * emailed patches from Andrew Morton <[email protected]>: mm/debug_pagealloc: fix build failure on ppc and some other archs nilfs2: fix deadlock of segment constructor over I_SYNC flag MAINTAINERS: remove SUPERH website memcg, shmem: fix shmem migration to use lrucare mm: export "high_memory" symbol on !MMU .mailmap: update Konstantin Khlebnikov's email address mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
2015-02-06Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds26-111/+186
Pull MIPS fixes from Ralf Baechle: "The pending MIPS fixes for 3.19. All across the field and nothing particularly severe or dramatic" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (23 commits) IRQCHIP: mips-gic: Avoid rerouting timer IRQs for smp-cmp MIPS: Fix syscall_get_nr for the syscall exit tracing. MIPS: elf2ecoff: Ignore PT_MIPS_ABIFLAGS program headers. MIPS: elf2ecoff: Rewrite main processing loop to switch. MIPS: fork: Fix MSA/FPU/DSP context duplication race MIPS: Fix C0_Pagegrain[IEC] support. MIPS: traps: Fix inline asm ctc1 missing .set hardfloat MIPS: mipsregs.h: Add write_32bit_cp1_register() MIPS: Fix kernel lockup or crash after CPU offline/online MIPS: OCTEON: fix kernel crash when offlining a CPU MIPS: ARC: Fix build error. MIPS: IRQ: Fix disable_irq on CPU IRQs MIPS: smp-mt,smp-cmp: Enable all HW IRQs on secondary CPUs MIPS: Fix restart of indirect syscalls MIPS: ELF: fix loading o32 binaries on 64-bit kernels MIPS: mips-cm: Fix sparse warnings MIPS: Kconfig: Fix recursive dependency. MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI. MIPS: JZ4740: Fixup #include's (sparse) MIPS: Wire up execveat(2). ...
2015-02-06xen/manage: Fix USB interaction issues when resumingRoss Lagerwall1-1/+7
Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when suspend/resuming") ensured that userspace processes were always frozen before suspending to reduce interaction issues when resuming devices. However, freeze_processes() does not freeze kernel threads. Freeze kernel threads as well to prevent deadlocks with the khubd thread when resuming devices. This is what native suspend and resume does. Example deadlock: [ 7279.648010] [<ffffffff81446bde>] ? xen_poll_irq_timeout+0x3e/0x50 [ 7279.648010] [<ffffffff81448d60>] xen_poll_irq+0x10/0x20 [ 7279.648010] [<ffffffff81011723>] xen_lock_spinning+0xb3/0x120 [ 7279.648010] [<ffffffff810115d1>] __raw_callee_save_xen_lock_spinning+0x11/0x20 [ 7279.648010] [<ffffffff815620b6>] ? usb_control_msg+0xe6/0x120 [ 7279.648010] [<ffffffff81747e50>] ? _raw_spin_lock_irq+0x50/0x60 [ 7279.648010] [<ffffffff8174522c>] wait_for_completion+0xac/0x160 [ 7279.648010] [<ffffffff8109c520>] ? try_to_wake_up+0x2c0/0x2c0 [ 7279.648010] [<ffffffff814b60f2>] dpm_wait+0x32/0x40 [ 7279.648010] [<ffffffff814b6eb0>] device_resume+0x90/0x210 [ 7279.648010] [<ffffffff814b7d71>] dpm_resume+0x121/0x250 [ 7279.648010] [<ffffffff8144c570>] ? xenbus_dev_request_and_reply+0xc0/0xc0 [ 7279.648010] [<ffffffff814b80d5>] dpm_resume_end+0x15/0x30 [ 7279.648010] [<ffffffff81449fba>] do_suspend+0x10a/0x200 [ 7279.648010] [<ffffffff8144a2f0>] ? xen_pre_suspend+0x20/0x20 [ 7279.648010] [<ffffffff8144a1d0>] shutdown_handler+0x120/0x150 [ 7279.648010] [<ffffffff8144c60f>] xenwatch_thread+0x9f/0x160 [ 7279.648010] [<ffffffff810ac510>] ? finish_wait+0x80/0x80 [ 7279.648010] [<ffffffff8108d189>] kthread+0xc9/0xe0 [ 7279.648010] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7279.648010] [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0 [ 7279.648010] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds. [ 7441.219457] Tainted: G X 3.13.11-ckt12.kz #1 [ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 7441.225827] khubd D ffff88003f433440 0 89 2 0x00000000 [ 7441.229258] ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440 [ 7441.232959] ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000 [ 7441.236658] 0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e [ 7441.240415] Call Trace: [ 7441.241614] [<ffffffff817442f9>] schedule+0x29/0x70 [ 7441.243930] [<ffffffff81743406>] schedule_timeout+0x166/0x2c0 [ 7441.246681] [<ffffffff81075b80>] ? call_timer_fn+0x110/0x110 [ 7441.249339] [<ffffffff8174357e>] schedule_timeout_uninterruptible+0x1e/0x20 [ 7441.252644] [<ffffffff81077710>] msleep+0x20/0x30 [ 7441.254812] [<ffffffff81555f00>] hub_port_reset+0xf0/0x580 [ 7441.257400] [<ffffffff81558465>] hub_port_init+0x75/0xb40 [ 7441.259981] [<ffffffff814bb3c9>] ? update_autosuspend+0x39/0x60 [ 7441.262817] [<ffffffff814bb4f0>] ? pm_runtime_set_autosuspend_delay+0x50/0xa0 [ 7441.266212] [<ffffffff8155a64a>] hub_thread+0x71a/0x1750 [ 7441.268728] [<ffffffff810ac510>] ? finish_wait+0x80/0x80 [ 7441.271272] [<ffffffff81559f30>] ? usb_port_resume+0x670/0x670 [ 7441.274067] [<ffffffff8108d189>] kthread+0xc9/0xe0 [ 7441.276305] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 [ 7441.279131] [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0 [ 7441.281659] [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80 Signed-off-by: Ross Lagerwall <[email protected]> Cc: [email protected] Signed-off-by: David Vrabel <[email protected]>
2015-02-06ACPI / EC: Add GPE reference counting debugging messagesLv Zheng1-2/+22
This patch enhances debugging with the GPE reference count messages added. No functional changes. Signed-off-by: Lv Zheng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06ACPI / EC: Add query flushing supportLv Zheng1-16/+85
This patch implementes the QR_EC flushing support. Grace periods are implemented from the detection of an SCI_EVT to the submission/completion of the QR_EC transaction. During this period, all EC command transactions are allowed to be submitted. Note that query periods and event periods are intentionally distiguished to allow further improvements. 1. Query period: from the detection of an SCI_EVT to the sumission of the QR_EC command. This period is used for storming prevention, as currently QR_EC is deferred to a work queue rather than directly issued from the IRQ context even there is no other transactions pending, so malicous SCI_EVT GPE can act like "level triggered" to trigger a GPE storm. We need to be prepared for this. And in the future, we may change it to be a part of the advance_transaction() where we will try QR_EC submission in appropriate positions to avoid such GPE storming. 2. Event period: from the detection of an SCI_EVT to the completion of the QR_EC command. We may extend it to the completion of _Qxx evaluation. This is actually a grace period for event flushing, but we only flush queries due to the reason stated in known issue 1. That's also why we use EC_FLAGS_EVENT_xxx. During this period, QR_EC transactions need to pass the flushable submission check. In this patch, the following flags are implemented: 1. EC_FLAGS_EVENT_ENABLED: this is derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT handlings. With this flag, the logics implemented by the original flag are extended: 1. Old logic: unless both of the flags are set, the event poller will not be scheduled, and 2. New logic: as soon as both of the flags are set, the evet poller will be scheduled. 2. EC_FLAGS_EVENT_DETECTED: this is also derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT detection. It thus can be used to indicate the storming prevention period for query submission. acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that acpi_set_gpe() can be invoked under the "reference count > 0" condition. 3. EC_FLAGS_EVENT_PENDING: this is newly added to indicate the grace period for event flushing (query flushing for now). acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that the flushing process can wait until the event handling (query transaction for now) to be completed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Signed-off-by: Lv Zheng <[email protected]> Tested-by: Ortwin Glück <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06ACPI / EC: Refine command storm prevention supportLv Zheng1-19/+36
This patch refines EC command storm prevention support. Current command storming code is wrong, when the storming condition is detected, it only flags the condition without doing anything for the current command but performing storming prevention for the follow-up commands. So: 1. The first command which suffers from the storming still suffers from storming. 2. The follow-up commands which may not suffer from the storming are unconditionally forced into the storming prevention mode. Ideally, we should only enable storm prevention immediately after detection for the current command so that the next command can try the power/performance efficient interrupt mode again. This patch improves the command storm prevention by disabling GPE right after the detection and re-enabling it right before completing the command transaction using the GPE storming prevention APIs. This thus deploys the following GPE handling model: 1. acpi_enable_gpe()/acpi_disable_gpe() for reference count changes: This set of APIs are used for EC usage reference counting. 2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE): This set of APIs are used for preventing GPE storm. They must be invoked when the reference count > 0. Note that as the storming prevention should always happen when there is an outstanding request, or GPE enabling value will be messed up by the races. This patch also adds BUG_ON() to enforces this rule to prevent future bugs. The msleep(1) used after completing a transaction is useless now as this sounds like a guard time only useful for platforms that need the EC_FLAGS_MSI quirks while we have fixed GPE race issues using the previous raw handler mode enabling. It is kept to avoid regressions. A seperate patch which deletes EC_FLAGS_MSI quirks should take care of deleting it. Signed-off-by: Lv Zheng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06ACPI / EC: Add command flushing support.Lv Zheng2-3/+66
This patch implements the EC command flushing support. During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED, all submitted EC command transactions can be completed and new submissions are prevented before suspending so that the EC hardware can be ensured to be in the idle state when the system is resumed. There is a good indicator for flush support: All acpi_ec_submit_request() is invoked after checking driver state with acpi_ec_started() except the first one. This means all code paths can be flushed as fast as possible by discarding the requests occurred after the flush operation. The reference increased for such kind of code path is wrapped by acpi_ec_submit_flushable_request(). Signed-off-by: Lv Zheng <[email protected]> Tested-by: Ortwin Glück <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flagLv Zheng1-11/+54
By using the 2 flags, we can indicate an inter-mediate state where the current transactions should be completed while the new transactions should be dropped. The comparison of the old flag and the new flags: Old New about to set BLOCKED STOPPED set / STARTED set BLOCKED set STOPPED clear / STARTED clear BLOCKED clear STOPPED clear / STARTED set A new period can be indicated by the 2 flags. The new period is between the point where we are about to set BLOCKED and the point when the BLOCKED is set. The new flags facilitate us with acpi_ec_started() check to allow the EC transaction to be submitted during the new period. This period thus can be used as a grace period for the EC transaction flushing. The only functional change after applying this patch is: 1. The GPE enabling/disabling is protected by the EC specific lock. We can do this because of recent ACPICA GPE API enhancement. This is reasonable as the GPE disabling/enabling state should only be determined by the EC driver's state machine which is protected by the EC spinlock. Signed-off-by: Lv Zheng <[email protected]> Tested-by: Ortwin Glück <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06ACPI: add AMD ACPI2Platform device support for x86 systemKen Xue5-1/+165
This new feature is to interpret AMD specific ACPI device to platform device such as I2C, UART, GPIO found on AMD CZ and later chipsets. It based on example intel LPSS. Now, it can support AMD I2C, UART and GPIO. Signed-off-by: Ken Xue <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06Merge back earlier 'acpi-lpss' material for v3.20Rafael J. Wysocki1-1/+3
2015-02-06Revert "IB/core: Add support for extended query device caps"Yann Droneaud5-130/+42
While commit 7e36ef8205ff ("IB/core: Temporarily disable ex_query_device uverb") is correct as it makes the extended QUERY_DEVICE uverb (which came as part of commit 5a77abf9a97a ("IB/core: Add support for extended query device caps") and commit 860f10a799c8 ("IB/core: Add flags for on demand paging support")) not available to userspace, it doesn't address the initial issue regarding ib_copy_to_udata() [1][2]. Additionally, further discussions around this new uverb seems to conclude it would require a different data structure than the one currently described in <rdma/ib_user_verbs.h> [3]. Both of these issues require a revert of the changes, so this patch partially reverts commit 8cdd312cfed7 ("IB/mlx5: Implement the ODP capability query verb") and commit 860f10a799c8 ("IB/core: Add flags for on demand paging support") and fully reverts commit 5a77abf9a97a ("IB/core: Add support for extended query device caps"). [1] "Re: [PATCH v3 06/17] IB/core: Add support for extended query device caps" http://mid.gmane.org/[email protected] [2] "Re: [PATCH] IB/core: Temporarily disable ex_query_device uverb" http://mid.gmane.org/[email protected] [3] "RE: [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask" http://mid.gmane.org/2807E5FD2F6FDA4886F6618EAC48510E0CC12C30@CRSMSX101.amr.corp.intel.com Cc: Eli Cohen <[email protected]> Cc: Haggai Eran <[email protected]> Cc: Ira Weiny <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Sagi Grimberg <[email protected]> Cc: Shachar Raindel <[email protected]> Signed-off-by: Yann Droneaud <[email protected]> Signed-off-by: Roland Dreier <[email protected]>
2015-02-06ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse()Hanjun Guo3-30/+4
In acpi_table_parse(), pointer of the table to pass to handler() is checked before handler() called, so remove all the duplicate NULL check in the handler function. CC: Tony Luck <[email protected]> CC: Thomas Gleixner <[email protected]> Signed-off-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-02-06xfs: report proper f_files in statfs if we overshoot imaxpctEric Sandeen1-0/+5
Normally, a statfs syscall reports m_maxicount as f_files (total file nodes in file system) because it is supposed to be the upper limit for dynamically-allocated inodes. It's possible, however, to overshoot imaxpct / m_maxicount. If this happens, we should report the actual number of allocated inodes, which is contained in sb_icount. Add one more adjustment to the statfs code to make this happen. Reported-by: Alexander Tsvetkov <[email protected]> Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2015-02-06xfs: fix panic_mask documentationEric Sandeen1-2/+3
This bit of the docs didn't quite reflect reality. Signed-off-by: Eric Sandeen <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2015-02-05mm/debug_pagealloc: fix build failure on ppc and some other archsJoonsoo Kim4-23/+0
Kim Phillips reported following build failure. LD init/built-in.o mm/built-in.o: In function `free_pages_prepare': mm/page_alloc.c:770: undefined reference to `.kernel_map_pages' mm/built-in.o: In function `prep_new_page': mm/page_alloc.c:933: undefined reference to `.kernel_map_pages' mm/built-in.o: In function `map_pages': mm/compaction.c:61: undefined reference to `.kernel_map_pages' make: *** [vmlinux] Error 1 Reason for this problem is that commit 031bc5743f15 ("mm/debug-pagealloc: make debug-pagealloc boottime configurable") forgot to remove the old declaration of kernel_map_pages() for some architectures. This patch removes them to fix build failure. Reported-by: Kim Phillips <[email protected]> Signed-off-by: Joonsoo Kim <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Martin Schwidefsky <[email protected]> Cc: David Miller <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05nilfs2: fix deadlock of segment constructor over I_SYNC flagRyusuke Konishi3-7/+44
Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes(): nilfs_segctor_thread() nilfs_segctor_thread_construct() nilfs_segctor_unlock() nilfs_dispose_list() iput() iput_final() evict() inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes() * set I_SYNC flag on inode->i_state __writeback_single_inode() do_writepages() nilfs_writepages() nilfs_construct_dsync_segment() nilfs_segctor_sync() * wait for completion of segment constructor inode_sync_complete() * clear I_SYNC flag after __writeback_single_inode() completed writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback(). Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0. Signed-off-by: Ryusuke Konishi <[email protected]> Cc: Al Viro <[email protected]> Tested-by: Ryusuke Konishi <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05MAINTAINERS: remove SUPERH websiteSudip Mukherjee1-1/+0
The mentioned website only displays information about buying and selling domains. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05memcg, shmem: fix shmem migration to use lrucareMichal Hocko2-2/+2
It has been reported that 965GM might trigger VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage) in mem_cgroup_migrate when shmem wants to replace a swap cache page because of shmem_should_replace_page (the page is allocated from an inappropriate zone). shmem_replace_page expects that the oldpage is not on LRU list and calls mem_cgroup_migrate without lrucare. This is obviously incorrect because swapcache pages might be on the LRU list (e.g. swapin readahead page). Fix this by enabling lrucare for the migration in shmem_replace_page. Also clarify that lrucare should be used even if one of the pages might be on LRU list. The BUG_ON will trigger only when CONFIG_DEBUG_VM is enabled but even without that the migration code might leave the old page on an inappropriate memcg' LRU which is not that critical because the page would get removed with its last reference but it is still confusing. Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") Signed-off-by: Michal Hocko <[email protected]> Reported-by: Chris Wilson <[email protected]> Reported-by: Dave Airlie <[email protected]> Acked-by: Hugh Dickins <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: <[email protected]> [3.17+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05mm: export "high_memory" symbol on !MMUArnd Bergmann1-0/+1
The symbol 'high_memory' is provided on both MMU- and NOMMU-kernels, but only one of them is exported, which leads to module build errors in drivers that work fine built-in: ERROR: "high_memory" [drivers/net/virtio_net.ko] undefined! ERROR: "high_memory" [drivers/net/ppp/ppp_mppe.ko] undefined! ERROR: "high_memory" [drivers/mtd/nand/nand.ko] undefined! ERROR: "high_memory" [crypto/tcrypt.ko] undefined! ERROR: "high_memory" [crypto/cts.ko] undefined! This exports the symbol to get these to work on NOMMU as well. Signed-off-by: Arnd Bergmann <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Acked-by: Greg Ungerer <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05.mailmap: update Konstantin Khlebnikov's email addressKim Phillips1-0/+1
get_maintainer.pl returns [email protected] via git history, for which emails get rejected: RCPT TO:<[email protected]> 550 5.1.1 Recipient address rejected: User unknown Use his other address that passes vger's mxverify: RCPT TO:<[email protected]> 250 2.1.5 OK ir10si13843754pbc.62 - gsmtp and add his old email address in the wrong email address field. Signed-off-by: Kim Phillips <[email protected]> Acked-by: Konstantin Khlebnikov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-02-05mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_rangeShiraz Hashim1-1/+4
walk_page_range() silently skips vma having VM_PFNMAP set, which leads to undesirable behaviour at client end (who called walk_page_range). Userspace applications get the wrong data, so the effect is like just confusing users (if the applications just display the data) or sometimes killing the processes (if the applications do something with misunderstanding virtual addresses due to the wrong data.) For example for pagemap_read, when no callbacks are called against VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual address range at wrong index. Eventually userspace may get wrong pagemap data for a task. Corresponding to a VM_PFNMAP marked vma region, kernel may report mappings from subsequent vma regions. User space in turn may account more pages (than really are) to the task. In my case I was using procmem, procrack (Android utility) which uses pagemap interface to account RSS pages of a task. Due to this bug it was giving a wrong picture for vmas (with VM_PFNMAP set). Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas") Signed-off-by: Shiraz Hashim <[email protected]> Acked-by: Naoya Horiguchi <[email protected]> Cc: <[email protected]> [3.10+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>