18 Jul, 2014
40 commits
-
commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.
Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.[ backport to 3.14.5: removed second parameter in acpi_battery_update(),
introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI /
battery: Accelerate battery resume callback)][naszar : backport to 3.14.5]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar
Cc: All applicable
Signed-off-by: Lan Tianyu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream.
In __ioremap_caller() (the guts of ioremap), we loop over the range of
pfns being remapped and checks each one individually with page_is_ram().
For large ioremaps, this can be very slow. For example, we have a
device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
seconds -- sometimes long enough to trigger the soft lockup detector!Internally, page_is_ram() calls walk_system_ram_range() on a single
page. Instead, we can make a single call to walk_system_ram_range()
from __ioremap_caller(), and do our further checks only for any RAM
pages that we find. For the common case of MMIO, this saves an enormous
amount of work, since the range being ioremapped doesn't intersect
system RAM at all.With this change, ioremap on our 256 GiB BAR takes less than 1 second.
Signed-off-by: Roland Dreier
Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.org
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit fb43e8477ed9006c4f397f904c691a120503038c upstream.
powerpc:allmodconfig has been failing for some time with the following
error.arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1A number of attempts to fix the problem by moving around code have been
unsuccessful and resulted in failed builds for some configurations and
the discovery of toolchain bugs.Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
While this is less than perfect, it avoids substantial code changes
which would otherwise be necessary just to make COMPILE_TEST builds
happy and might have undesired side effects.Signed-off-by: Guenter Roeck
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit c863810cefc7ffd782e5648a21bfb36a32c8b081 upstream.
It is only a typo issue, the related commit:
"1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()"
The related error (unicore32 with allmodconfig):
CC [M] drivers/rtc/rtc-puv3.o
drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setpie':
drivers/rtc/rtc-puv3.c:74: error: implicit declaration of function 'dev_debug'Signed-off-by: Chen Gang
Acked-by: Xuetao Guan
Signed-off-by: Xuetao Guan
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 73fa540618d8b1f8c2266934f23bd84bb9e28d9e upstream.
It is only a typo issue, the related commit:
"1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()"
The related error (for unicore32 with allmodconfig):
CC [M] drivers/rtc/rtc-puv3.o
drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setalarm':
drivers/rtc/rtc-puv3.c:143: error: 'struct device' has no member named 'dev'Signed-off-by: Chen Gang
Acked-by: Xuetao Guan
Signed-off-by: Xuetao Guan
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 8b8b36834d0fff67fc8668093f4312dd04dcf21d upstream.
The per_cpu buffers are created one per possible CPU. But these do
not mean that those CPUs are online, nor do they even exist.With the addition of the ring buffer polling, it assumes that the
caller polls on an existing buffer. But this is not the case if
the user reads trace_pipe from a CPU that does not exist, and this
causes the kernel to crash.Simple fix is to check the cpu against buffer bitmask against to see
if the buffer was allocated or not and return -ENODEV if it is
not.More updates were done to pass the -ENODEV back up to userspace.
Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com
Reported-by: Sasha Levin
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit fe8eea4f4a3f299ef83ed090d5354698ebe4fda8 upstream.
We should free memory for bitmap when we find zone mismatch, otherwise
this memory will leak.Additionally, I copy code comment from PPC KVM's CMA code to inform why
we need to check zone mis-match.Signed-off-by: Joonsoo Kim
Acked-by: Zhang Yanfei
Reviewed-by: Michal Nazarewicz
Reviewed-by: Aneesh Kumar K.V
Acked-by: Minchan Kim
Cc: "Aneesh Kumar K.V"
Cc: Marek Szyprowski
Cc: Michal Nazarewicz
Cc: Paolo Bonzini
Cc: Gleb Natapov
Cc: Alexander Graf
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f1e1c2129b79cfdaf07bca37c5a10569fe021abe upstream.
On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.v2: Deal with gen4 36 bit physical address
Signed-off-by: Ville Syrjälä
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream.
When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.For stable inclusion the patch probably needs to be modified a bit.
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 6abafb78f9881b4891baf74ab4e9f090ae45230e upstream.
Fixes hangs on driver load on some cards.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76998Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit ed96377132e564d797c48a5490fd46bed01c4273 upstream.
Need to use the RREG32_SMC() accessor since the register
is an smc indirect index.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 41959341ac7e33dd360c7a881d13566f9eca37b2 upstream.
It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that
Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.This depends on b0880e87c1fd038b84498944f52e52c3e86ebe59
(drm/radeon/dpm: fix vddci setup typo on cayman).Signed-off-by: Alexandre Demers
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 3f1f9b851311a76226140b55b1ea22111234a7c2 upstream.
This fixes the following lockdep complaint:
[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G O
-------------------------------------------------------
kworker/u24:0/4356 is trying to acquire lock:
(&(&sbi->s_es_lru_lock)->rlock){+.+.-.}, at: [] __ext4_es_shrink+0x4f/0x2e0but task is already holding lock:
(&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180which lock already depends on the new lock.
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->i_es_lock);
lock(&(&sbi->s_es_lru_lock)->rlock);
lock(&ei->i_es_lock);
lock(&(&sbi->s_es_lru_lock)->rlock);*** DEADLOCK ***
6 locks held by kworker/u24:0/4356:
#0: ("writeback"){.+.+.+}, at: [] process_one_work+0x180/0x560
#1: ((&(&wb->dwork)->work)){+.+.+.}, at: [] process_one_work+0x180/0x560
#2: (&type->s_umount_key#22){++++++}, at: [] grab_super_passive+0x44/0x90
#3: (jbd2_handle){+.+...}, at: [] start_this_handle+0x189/0x5f0
#4: (&ei->i_data_sem){++++..}, at: [] ext4_map_blocks+0x132/0x550
#5: (&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G O 3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007
ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568
ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930
Call Trace:
[] dump_stack+0x4e/0x68
[] print_circular_bug+0x1fb/0x20c
[] __lock_acquire+0x163e/0x1d00
[] ? retint_restore_args+0xe/0xe
[] ? __slab_alloc+0x4a8/0x4ce
[] ? __ext4_es_shrink+0x4f/0x2e0
[] lock_acquire+0x87/0x120
[] ? __ext4_es_shrink+0x4f/0x2e0
[] ? ext4_es_free_extent+0x5d/0x70
[] _raw_spin_lock+0x39/0x50
[] ? __ext4_es_shrink+0x4f/0x2e0
[] ? kmem_cache_alloc+0x18b/0x1a0
[] __ext4_es_shrink+0x4f/0x2e0
[] ext4_es_insert_extent+0xc8/0x180
[] ext4_map_blocks+0x1c4/0x550
[] ext4_writepages+0x6d4/0xd00
...Reported-by: Minchan Kim
Signed-off-by: Theodore Ts'o
Reported-by: Minchan Kim
Cc: Zheng Liu
Signed-off-by: Greg Kroah-Hartman -
commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream.
The mount manpage says of the max_batch_time option,
This optimization can be turned off entirely
by setting max_batch_time to 0.But the code doesn't do that. So fix the code to do
that.Signed-off-by: Eric Sandeen
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit 94d4c066a4ff170a2671b1a9b153febbf36796f6 upstream.
We are spending a lot of time explaining to users what this error
means. Let's try to improve the message to avoid this problem.Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.
Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.Signed-off-by: Pavel Machek
Signed-off-by: Theodore Ts'o
Reviewed-by: Andreas Dilger
Signed-off-by: Greg Kroah-Hartman -
commit 61c219f5814277ecb71d64cb30297028d6665979 upstream.
The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc. Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit d066c946a866268c14a120b33e7226e899981998 upstream.
pci_wait_for_pending() uses word access, so we shouldn't be passing
an offset that is only byte aligned. Use the control register offset
instead, shifting the mask to match.Fixes: d0b4cc4e3270 ("PCI: Wrong register used to check pending traffic")
Fixes: 157e876ffe0b ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())
Reported-by: Ben Hutchings
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Acked-by: Gavin Shan
Signed-off-by: Greg Kroah-Hartman -
commit 179e8471673ce0249cd4ecda796008f7757e5bad upstream.
Ensure that cpu->cpu is set before writing MSR_IA32_PERF_CTL during CPU
initialization. Otherwise only cpu0 has its P-state set and all other
cores are left with their values unchanged.In most cases, this is not too serious because the P-states will be set
correctly when the timer function is run. But when the default governor
is set to performance, the per-CPU current_pstate stays the same forever
and no attempts are made to write the MSRs again.Signed-off-by: Vincent Minet
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 41629a8233470325bfbb60377f555f9e8acc879f upstream.
Update documentation to make the interpretation of the values clearer
Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit dd5fbf70f96dbfd7ee432096a1f979b2b3267856 upstream.
If turbo is disabled in the BIOS bit 38 should be set in
MSR_IA32_MISC_ENABLE register per section 14.3.2.1 of the SDM Vol 3
document 325384-050US Feb 2014. If this bit is set do *not* attempt
to disable trubo via the MSR_IA32_PERF_CTL register. On some systems
trying to disable turbo via MSR_IA32_PERF_CTL will cause subsequent
writes to MSR_IA32_PERF_CTL not take affect, in fact reading
MSR_IA32_PERF_CTL will not show the IDA/Turbo DISENGAGE bit(32) as
set. A write of bit 32 to zero returns to normal operation.Also deal with the case where the processor does not support
turbo and the BIOS does not report the fact in MSR_IA32_MISC_ENABLE
but does report the max and turbo P states as the same value.Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit c16ed06024a6e699c332831dd50d8276744e3de8 upstream.
Commit 21855ff5 (intel_pstate: Set turbo VID for BayTrail) introduced
setting the turbo VID which is required to prevent a machine check on
some Baytrail SKUs under heavy graphics based workloads. The
docmumentation update that brought the requirement to light also
changed the bit mask used for enumerating P state and VID values from
0x7f to 0x3f.This change returns the mask value to 0x7f.
Tested with the Intel NUC DN2820FYK,
BIOS version FYBYT10H.86A.0034.2014.0513.1413 with v3.16-rc1 and
v3.14.8 kernel versions.Fixes: 21855ff5 (intel_pstate: Set turbo VID for BayTrail)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77951
Reported-and-tested-by: Rune Reterson
Reported-and-tested-by: Eric Eickmeyer
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit acfe0ad74d2e1bfc81d1d7bf5e15b043985d3650 upstream.
The commit 2c140a246dc ("dm: allow remove to be deferred") introduced a
deferred removal feature for the device mapper. When this feature is
used (by passing a flag DM_DEFERRED_REMOVE to DM_DEV_REMOVE_CMD ioctl)
and the user tries to remove a device that is currently in use, the
device will be removed automatically in the future when the last user
closes it.Device mapper used the system workqueue to perform deferred removals.
However, some targets (dm-raid1, dm-mpath, dm-stripe) flush work items
scheduled for the system workqueue from their destructor. If the
destructor itself is called from the system workqueue during deferred
removal, it introduces a possible deadlock - the workqueue tries to flush
itself.Fix this possible deadlock by introducing a new workqueue for deferred
removals. We allocate just one workqueue for all dm targets. The
ability of dm targets to process IOs isn't dependent on deferred removal
of unused targets, so a deadlock due to shared workqueue isn't possible.Also, cleanup local_init() to eliminate potential for returning success
on failure.Signed-off-by: Mikulas Patocka
Signed-off-by: Dan Carpenter
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 10f1d5d111e8aed46a0f1179faf9a3cf422f689e upstream.
There's a race condition between the atomic_dec_and_test(&io->count)
in dec_count() and the waking of the sync_io() thread. If the thread
is spuriously woken immediately after the decrement it may exit,
making the on stack io struct invalid, yet the dec_count could still
be using it.Fix this race by using a completion in sync_io() and dec_count().
Reported-by: Minfei Huang
Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Acked-by: Mikulas Patocka
Signed-off-by: Greg Kroah-Hartman -
commit affb1aff300ddee54df307812b38f166e8a865ef upstream.
Starting with Win8, we have implemented several optimizations to improve the
scalability and performance of the VMBUS transport between the Host and the
Guest. Some of the non-performance critical services cannot leverage these
optimization since they only read and process one message at a time.
Make adjustments to the callback dispatch code to account for the way
non-performance critical drivers handle reading of the channel.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
commit c556bcddc78096caeb46dbe3ad0314dd951f1665 upstream.
The HDMI PLL input to the tv mux is supposed to be 3, not 2. Fix
the code so that we can properly select the HDMI PLL.Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Reported-by: Rob Clark
Signed-off-by: Stephen Boyd
Signed-off-by: Mike Turquette
Signed-off-by: Greg Kroah-Hartman -
commit 2a96dfa49c83a2a7cbdb11382976aaa6b2636764 upstream.
After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.Kernel panic log:
[ 30.839284] Unable to handle kernel paging request at virtual address 5f343173
[ 30.846476] pgd = dee14000
[ 30.849165] [5f343173] *pgd=00000000
[ 30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[ 30.858166] Modules linked in:
[ 30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[ 30.869364] task: df478000 ti: df480000 task.ti: df480000
[ 30.874752] PC is at clkdev_add+0x2c/0x38
[ 30.878738] LR is at clkdev_add+0x18/0x38
[ 30.882732] pc : [] lr : [] psr: 60000013
[ 30.882732] sp : df481e78 ip : 00000001 fp : c0700ed8
[ 30.894187] r10: 0000000c r9 : 00000000 r8 : c07b0e3c
[ 30.899396] r7 : 00000002 r6 : df45f9d0 r5 : df421390 r4 : c0700d6c
[ 30.905906] r3 : 5f343173 r2 : c0700d84 r1 : 60000013 r0 : c0700d6c
[ 30.912417] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 30.919534] Control: 10c53c7d Table: 5ee1406a DAC: 00000015
[ 30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[ 30.930817] Stack: (0xdf481e78 to 0xdf482000)
[ 30.935159] 1e60: 00001000 df6de610
[ 30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[ 30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[ 30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[ 30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[ 30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[ 30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[ 30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[ 31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[ 31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[ 31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[ 31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[ 31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[ 31.041248] [] (clkdev_add) from [] (s2mps11_clk_probe+0x2b4/0x3b4)
[ 31.049223] [] (s2mps11_clk_probe) from [] (platform_drv_probe+0x18/0x48)
[ 31.057728] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x384)
[ 31.066579] [] (driver_probe_device) from [] (bind_store+0x88/0xd8)
[ 31.074564] [] (bind_store) from [] (drv_attr_store+0x20/0x2c)
[ 31.082118] [] (drv_attr_store) from [] (sysfs_kf_write+0x44/0x48)
[ 31.090016] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc0/0x17c)
[ 31.098176] [] (kernfs_fop_write) from [] (vfs_write+0xa0/0x1c4)
[ 31.105899] [] (vfs_write) from [] (SyS_write+0x40/0x8c)
[ 31.112931] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)
[ 31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[ 31.126596] ---[ end trace efad45bfa3a61b05 ]---
[ 31.131181] Kernel panic - not syncing: Fatal exception
[ 31.136368] CPU1: stopping
[ 31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[ 31.148697] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 31.156419] [] (show_stack) from [] (dump_stack+0x80/0xcc)
[ 31.163622] [] (dump_stack) from [] (handle_IPI+0x130/0x15c)
[ 31.170998] [] (handle_IPI) from [] (gic_handle_irq+0x60/0x68)
[ 31.178549] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x70)
[ 31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[ 31.191046] df80: ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[ 31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[ 31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[ 31.212402] [] (__irq_svc) from [] (arch_cpu_idle+0x28/0x30)
[ 31.219783] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c4/0x3f0)
[ 31.228027] [] (cpu_startup_entry) from [] (0x400086c4)
[ 31.234968] ---[ end Kernel panic - not syncing: Fatal exceptionFixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Yadwinder Singh Brar
Signed-off-by: Mike Turquette
Signed-off-by: Greg Kroah-Hartman -
commit 15ebb05248d025534773c9ef64915bd888f04e4b upstream.
The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62c (SPEAr: Switch to common clock framework).Signed-off-by: Thomas Gleixner
Acked-by: Viresh Kumar
Signed-off-by: Mike Turquette
Signed-off-by: Greg Kroah-Hartman -
commit e73b49f1c4e75c44d62585cc3e5b9c7894b61c32 upstream.
Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.Signed-off-by: Roger Quadros
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Greg Kroah-Hartman -
commit fa2ec3ea10bd377f9d55772b1dab65178425a1a2 upstream.
include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it
is not set by the architecture headers. TASK_SIZE uses the
current task to determine the size of the virtual address space.
On a 64-bit kernel this will cause reading /proc/pid/pagemap of a
64-bit process from a 32-bit process to return EOF when it reads
past 0xffffffff.Implement TASK_SIZE_OF exactly the same as TASK_SIZE with
test_tsk_thread_flag instead of test_thread_flag.Signed-off-by: Colin Cross
Acked-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit 0378c9a855bfa395f595fbfb049707093e270f69 upstream.
This patch fixes a memory leak that appears when caam_jr module is unloaded.
Signed-off-by: Cristian Stoica
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit cfe82d4f45c7cc39332a2be7c4c1d3bf279bbd3d upstream.
Byte-to-bit-count computation is only partly converted to big-endian and is
mixing in CPU-endian values. Problem was noticed by sparce with warning:CHECK arch/x86/crypto/sha512_ssse3_glue.c
arch/x86/crypto/sha512_ssse3_glue.c:144:19: warning: restricted __be64 degrades to integer
arch/x86/crypto/sha512_ssse3_glue.c:144:17: warning: incorrect type in assignment (different base types)
arch/x86/crypto/sha512_ssse3_glue.c:144:17: expected restricted __be64
arch/x86/crypto/sha512_ssse3_glue.c:144:17: got unsigned long longSigned-off-by: Jussi Kivilinna
Acked-by: Tim Chen
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5a90af67c2126fe1d04ebccc1f8177e6ca70d3a9 upstream.
Since commtit 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to
drivers/cpufreq) this added dependancy only for CONFIG_ARCH_DAVINCI_DA850
where as davinci_cpufreq_init() call is used by all davinci platform.This patch fixes following build error:
arch/arm/mach-davinci/built-in.o: In function `davinci_init_late':
:(.init.text+0x928): undefined reference to `davinci_cpufreq_init'
make: *** [vmlinux] Error 1Fixes: 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq)
Signed-off-by: Lad, Prabhakar
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit b50a6c584bb47b370f84bfd746770c0bbe7129b7 upstream.
On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze
the PMU counters. Aside from on boot they are then never reset,
resulting in stuck perf counters for any user in the guest or host.We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane
state for perf to use the PMU counters under either the guest or the
host.This was manifesting as a bug with ppc64_cpu --frequency:
$ sudo ppc64_cpu --frequency
WARNING: couldn't run on cpu 0
WARNING: couldn't run on cpu 8
...
WARNING: couldn't run on cpu 144
WARNING: couldn't run on cpu 152
min: 18446744073.710 GHz (cpu -1)
max: 0.000 GHz (cpu -1)
avg: 0.000 GHzThe command uses a perf counter to measure CPU cycles over a fixed
amount of time, in order to approximate the frequency of the machine.
The counters were returning zero once a guest was started, regardless of
weather it was still running or had been shut down.By dumping the value of MMCR2, it was observed that once a guest is
running MMCR2 is set to 1s - which stops counters from running:$ sudo sh -c 'echo p > /proc/sysrq-trigger'
CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6
PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000
PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef
MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000
MMCR2: fffffffffffffc00 EBBHR: 0000000000000000
EBBRR: 0000000000000000 BESCR: 0000000000000000
SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000This is done unconditionally in book3s_hv_interrupts.S upon entering the
guest, and the original value is only save/restored if the host has
indicated it was using the PMU. This is okay, however the user of the
PMU needs to ensure that it is in a defined state when it starts using
it.Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support")
Signed-off-by: Joel Stanley
Acked-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 4d9690dd56b0d18f2af8a9d4a279cb205aae3345 upstream.
Instead of separate bits for every POWER8 PMU feature, have a single one
for v2.07 of the architecture.This saves us adding a MMCR2 define for a future patch.
Signed-off-by: Joel Stanley
Acked-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream.
We are seeing a lot of PMU warnings on POWER8:
Can't find PMC that caused IRQ
Looking closer, the active PMC is 0 at this point and we took a PMU
exception on the transition from negative to 0. Some versions of POWER8
have an issue where they edge detect and not level detect PMC overflows.A number of places program the PMC with (0x80000000 - period_left),
where period_left can be negative. We can either fix all of these or
just ensure that period_left is always >= 1.This patch takes the second option.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.
There is a race condition in ec_transaction_completed().
When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.
After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
If IBF=1 blocked the first command byte write invoked in the task
context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
out and retried again in the task context.Remove this seperate and duplicate IBF=0 waiter. By doing so we can
reduce the overall number of times to access the EC_SC(R) status
register.Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream.
Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
1. The first command byte can be written in the interrupt context;
2. The command completion waiter can also be used to wait the first command
byte's timeout;
3. In BURST mode, the follow-up command bytes can be written in the
interrupt context directly, so that it doesn't need to return to the
task context. Returning to the task context reduces the throughput of
the BURST mode and in the worst cases where the system workload is very
high, this leads to the hardware driven automatic BURST mode exit.In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
indicating the completion of the command transaction.
2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
command byte. A new command can utilize this flag to compete for the
right of accessing the underlying hardware. There is a follow-up bug
fix that has utilized this new flag.The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
