We need to delete un-finished td from current request's td list
at ep_dequeue API, otherwise, this non-user td will be remained
at td list before this request is freed. So if we do ep_queue->
ep_dequeue->ep_queue sequence, when the complete interrupt for
the second ep_queue comes, we search td list for this request,
the first td (added by the first ep_queue) will be handled, and
its status is still active, so we will consider the this transfer
still not be completed, but in fact, it has completed. It causes
the peripheral side considers it never receives current data for
this transfer.
We met this problem when do "Error Recovery Test - Device Configured"
test item for USBCV2 MSC test, the host has never received ACK for
the IN token for CSW due to peripheral considers it does not get this
CBW, the USBCV test log like belows:
--------------------------------------------------------------------------
INFO
Issuing BOT MSC Reset, reset should always succeed
INFO
Retrieving status on CBW endpoint
INFO
CBW endpoint status = 0x0
INFO
Retrieving status on CSW endpoint
INFO
CSW endpoint status = 0x0
INFO
Issuing required command (Test Unit Ready) to verify device has recovered
INFO
Issuing CBW (attempt #1):
INFO
|----- CBW LUN = 0x0
INFO
|----- CBW Flags = 0x0
INFO
|----- CBW Data Transfer Length = 0x0
INFO
|----- CBW CDB Length = 0x6
INFO
|----- CBW CDB-00 = 0x0
INFO
|----- CBW CDB-01 = 0x0
INFO
|----- CBW CDB-02 = 0x0
INFO
|----- CBW CDB-03 = 0x0
INFO
|----- CBW CDB-04 = 0x0
INFO
|----- CBW CDB-05 = 0x0
INFO
Issuing CSW : try 1
INFO
CSW Bulk Request timed out!
ERROR
Failed CSW phase : should have been success or stall
FAIL
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
ERROR
BOTCommonMSCRequest failed: error=80004000
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes a typo that named the read_mostly section of percpu as
readmostly. It works fine with SMP because the linker script specifies
.data..percpu..readmostly. However, UP kernel builds don't have percpu
sections defined and the non-percpu version of the section is called
data..read_mostly, so .data..readmostly will float around and may break
things unexpectedly.
Looking at the original change that introduced data..percpu..readmostly
(commit c957ef2c59), it looks like this
was the original intention.
Tested: Built UP kernel and confirmed the sections got merged.
- Before the patch:
$ objdump -h vmlinux.o | grep '\.data\.\.read.*mostly'
38 .data..read_mostly 00004418 0000000000000000 0000000000000000 00431ac0 2**6
50 .data..readmostly 00000014 0000000000000000 0000000000000000 00444000 2**3
- After the patch:
$ objdump -h vmlinux.o | grep '\.data\.\.read.*mostly'
38 .data..read_mostly 00004438 0000000000000000 0000000000000000 00431ac0 2**6
Signed-off-by: Zhengyu He <hzy@google.com>
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Writing to either "cpuset.cpus" or "cpuset.mems" file flushes
cpuset_hotplug_work so that cpu or memory hotunplug doesn't end up
migrating tasks off a cpuset after new resources are added to it.
As cpuset_hotplug_work calls into cgroup core via
cgroup_transfer_tasks(), this flushing adds the dependency to cgroup
core locking from cpuset_write_resmak(). This used to be okay because
cgroup interface files were protected by a different mutex; however,
8353da1f91 ("cgroup: remove cgroup_tree_mutex") simplified the
cgroup core locking and this dependency became a deadlock hazard -
cgroup file removal performed under cgroup core lock tries to drain
on-going file operation which is trying to flush cpuset_hotplug_work
blocked on the same cgroup core lock.
The locking simplification was done because kernfs added an a lot
easier way to deal with circular dependencies involving kernfs active
protection. Let's use the same strategy in cpuset and break active
protection in cpuset_write_resmask(). While it isn't the prettiest,
this is a very rare, likely unique, situation which also goes away on
the unified hierarchy.
The commands to trigger the deadlock warning without the patch and the
lockdep output follow.
localhost:/ # mount -t cgroup -o cpuset xxx /cpuset
localhost:/ # mkdir /cpuset/tmp
localhost:/ # echo 1 > /cpuset/tmp/cpuset.cpus
localhost:/ # echo 0 > cpuset/tmp/cpuset.mems
localhost:/ # echo $$ > /cpuset/tmp/tasks
localhost:/ # echo 0 > /sys/devices/system/cpu/cpu1/online
======================================================
[ INFO: possible circular locking dependency detected ]
3.16.0-rc1-0.1-default+ #7 Not tainted
-------------------------------------------------------
kworker/1:0/32649 is trying to acquire lock:
(cgroup_mutex){+.+.+.}, at: [<ffffffff8110e3d7>] cgroup_transfer_tasks+0x37/0x150
but task is already holding lock:
(cpuset_hotplug_work){+.+...}, at: [<ffffffff81085412>] process_one_work+0x192/0x520
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (cpuset_hotplug_work){+.+...}:
...
-> #1 (s_active#175){++++.+}:
...
-> #0 (cgroup_mutex){+.+.+.}:
...
other info that might help us debug this:
Chain exists of:
cgroup_mutex --> s_active#175 --> cpuset_hotplug_work
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(cpuset_hotplug_work);
lock(s_active#175);
lock(cpuset_hotplug_work);
lock(cgroup_mutex);
*** DEADLOCK ***
2 locks held by kworker/1:0/32649:
#0: ("events"){.+.+.+}, at: [<ffffffff81085412>] process_one_work+0x192/0x520
#1: (cpuset_hotplug_work){+.+...}, at: [<ffffffff81085412>] process_one_work+0x192/0x520
stack backtrace:
CPU: 1 PID: 32649 Comm: kworker/1:0 Not tainted 3.16.0-rc1-0.1-default+ #7
...
Call Trace:
[<ffffffff815a5f78>] dump_stack+0x72/0x8a
[<ffffffff810c263f>] print_circular_bug+0x10f/0x120
[<ffffffff810c481e>] check_prev_add+0x43e/0x4b0
[<ffffffff810c4ee6>] validate_chain+0x656/0x7c0
[<ffffffff810c53d2>] __lock_acquire+0x382/0x660
[<ffffffff810c57a9>] lock_acquire+0xf9/0x170
[<ffffffff815aa13f>] mutex_lock_nested+0x6f/0x380
[<ffffffff8110e3d7>] cgroup_transfer_tasks+0x37/0x150
[<ffffffff811129c0>] hotplug_update_tasks_insane+0x110/0x1d0
[<ffffffff81112bbd>] cpuset_hotplug_update_tasks+0x13d/0x180
[<ffffffff811148ec>] cpuset_hotplug_workfn+0x18c/0x630
[<ffffffff810854d4>] process_one_work+0x254/0x520
[<ffffffff810875dd>] worker_thread+0x13d/0x3d0
[<ffffffff8108e0c8>] kthread+0xf8/0x100
[<ffffffff815acaec>] ret_from_fork+0x7c/0xb0
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Li Zefan <lizefan@huawei.com>
Tested-by: Li Zefan <lizefan@huawei.com>
Disabling reading and writing to the trace file should not be able to
disable all function tracing callbacks. There's other users today
(like kprobes and perf). Reading a trace file should not stop those
from happening.
Cc: stable@vger.kernel.org # 3.0+
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
A few minor fbdev fixes for bfin_adv7393fb, omapdss, vt8500lcdfb, atmel_lcdfb.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTspgHAAoJEPo9qoy8lh71nK4QAIRU3nHYgdRufpRKlXy64BqP
ckDRi6ngtNwqcRW5Cno51hVwxCK+/xpfXFtXqg65lZZFjg0DAmUIwChjh6JUqvl+
EZGJ6xjoNVuwSwB5I6K9apwFslYJGW6sJGTpavryJd1gsuQqmuLnUenwC9TOyUCW
W4SaoT6zLFoD8XgFMPeckoBpPugqCOYmnw6GcT0LGpe3ddnyyeaqyBPed9IF4g6h
thy2wgq8c+ZQO1t/c3C37MaV1bYs/MrilHiRMm+7/SPcxPb7xLS0WMyOxC5QYnpe
l0e6O96oHc51DaKo8gVCpK662OIzch3u7geiWPG9kdHyhZJiK3fGuVz1T7s2xvEB
4RDW7gDN7Tj/nbEFSEb/vyrp6ztuPI6BjSeMw4yNFnNjIuc++Duk1A0U+82ioGEB
cGlECkBErktJu+I11R+YBNhOG4L0BQBeybRXLexXOM4Hjuk7T/AJ4sNvTFf5d6J7
y/sOzmag+P+DrUf7acvkBmAqVYnwpjthnMr4SQez5VbEURKpIK7IKQShJctRM+V/
m+bzjt3UTf9oVc8MxVtWoopwyxoxRC58On5/DhUVGHvR4qJfEH1HqJsPFxsnovRn
C9kI1FoCgGOJlFOh3bGSKOo3Urm2hBvR91p1cZIFw19MzNFV1/zRW3eCilpk2N2D
rWzkQ8dTKjohRhjH68OJ
=jr3e
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux
Pull fbdev fixes from Tomi Valkeinen:
"A few minor fbdev fixes for bfin_adv7393fb, omapdss, vt8500lcdfb,
atmel_lcdfb"
* tag 'fbdev-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
fb: adv7393: add missing semicolon
video: omapdss: Fix potential null pointer dereference
video: vt8500lcdfb: Remove kfree call since devm_kzalloc() is used
drivers:video:fbdev atmel_lcdfb.c power GPIO registration bug
The two more serious bugs ("KVM: SVM: Fix CPL export via SS.DPL" and
"KVM: s390: add sie.h uapi header file to Kbuild and remove header
dependency") were introduced in the 3.16 merge window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTso6OAAoJEBvWZb6bTYbyB5IP/j/1d0hKsVjOGMco+dJ3uwjh
X2gYBVxT3Nm9fyjAjSM6OjbFF2mj9zFNEGu0NvEaDnIlWtifvtXckFB1asp/o3/M
UTbeaaN5US9Ou9W87KpJQLp7Wp9ENMgXeFsywpf9qMNyV04OHSP5cCwIspShCkNH
r21oEwgvrnc4Trh4oBVUaykuPuU4mzAMBSiXxbQWVXkkPYBVBjGYNzdas7K3EfS9
YmY1NgS1HDrUvRuM0b3guHqEizA717xFxpVpXAYhuxRqb1fRWMDuIy7q21hEoXxE
RtuFjztfpAWIgK9O2j4mTuqR32nedzsieVMzF486oMPXRrUs+oQ16/AYV7K5eOZF
Q1QJ5zx7890ncfxjXYMdUTI7d5sDFCc7F3DmRwtWh1jYrsNh8p+VRDTbNdmiNuIa
1wXkoNpTsFHidXA6Uhl2pfI+o9OOWleEP3bB746RanS4bk54cDrx6UK2gJK6MMHl
bekjzQrXRlh3qN1mqS+nMShq/vd2G6cCG0Y9ez8/aHrJoU5DPIOQ7IcOt2IZGtwZ
MiBZAoWgHuYpEV4tXzqjHQy8IAddvGnM3RqWfNc0XLlVwcKosdI4fusg8wKnR02Z
sLYRfe5BTnHG/ieIlx/iQmRXN04hhIUJiggFZrLizGemGYi16SaN/ixwb4YoA3nH
ksZxlGKUi9SUftnv0Ph6
=Rjb4
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"A bunch of one-liners (except the s390 one).
The two more serious bugs ("KVM: SVM: Fix CPL export via SS.DPL" and
"KVM: s390: add sie.h uapi header file to Kbuild and remove header
dependency") were introduced in the 3.16 merge window"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: SVM: Fix CPL export via SS.DPL
KVM: s390: add sie.h uapi header file to Kbuild and remove header dependency
MIPS: KVM: Fix memory leak on VCPU
KVM: x86: preserve the high 32-bits of the PAT register
kvm: fix wrong address when writing Hyper-V tsc page
KVM: x86: Increase the number of fixed MTRR regs to 10
This prevents a panic: radeon_crtc_handle_page_flip() could run before
radeon_flip_work_func(), triggering the BUG_ON() in drm_vblank_put().
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some monitors seem to have problems with deep color enabled, even
though they claim to support it. I'm not sure if the monitor
need a quirk or if the driver is doing something the monitor doesn't
like. At this point lets just disable deep color by default like
we did for hdmi audio and work through the bugs so we can eventually
enable it by default.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80531
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
bapm enabled the GPU and CPU to share TDP headroom. It was
disabled by default since some laptops hung when it was enabled
in conjunction with dpm. It seems to be stable on desktop
boards and fixes hangs on boot with dpm enabled on certain
boards, so enable it by default on desktop boards.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72921
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
bapm allows the GPU and CPU to share TDP. This allows
for additional performance out of the GPU and CPU when
the headroom is available.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Set the default to 600Mhz if it's not set in the bios,
and bump the default to 600Mhz if it's lower than that.
This fixes display issues with certain 4k DP monitors when
using 5.4 Ghz DP clocks.
v2: fix typo.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently, the tmon umask value is set to 0, which means whatever the permission
mask in the shell are when starting tmon in daemon mode are what the permissions
of any created files will be. We should likely set something more explicit, so
lets go with the usual 022
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The tmon logging system blindly opens its log file on a static path, making it
very easy for someone to redirect that log information to inappropriate places
or overwrite other users data. Do some easy checking to make sure we're not
logging to a symlink or a file owned by another user.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Commit f8bd493456 by Jingoo Han
introduced this problem. This makes bfin_adv7393fb.c failed to compile.
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Drop WA to fix Voltage not getting dropped to Vmin when Gfx is power
gated for latest VLV revision.
Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed,
and Requesting the min freq should bring bring the voltage Vnn.
v2: Drop WA for Latest VLV revision (Ville)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: modified code comment, reformatted the commit message a bit.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I received a report this morning from one of the Novena developers that
the behaviour of the iMX6 ASoC codec driver (using imx-pcm-dma.c) was
sub-optimal under high system load.
While there are issues relating to system load remaining, upon reviewing
the ASoC imx-pcm-dma.c driver, it was noticed that it not using the
residue support, because SDMA doesn't support it. This has the effect
that SDMA has to make multiple calls into the ASoC and ALSA code, one
for each period.
Since ALSA's snd_pcm_elapsed() does not need to be called multiple times
and it is entirely sufficient to call it once to update ALSA with the
current buffer position via the pointer method, we can do better here.
We can also avoid stopping the DMA entirely, just like real cyclic DMA
implementations behave. While this means that we replay some old samples,
this is a nicer behaviour than having audio stop and restart.
The changes to achieve this are relatively minor - imx-sdma.c can track
where the DMA is to the nearest descriptor boundary - it does this
already when deciding how many callbacks to issue. In doing this,
buf_tail always points at the descriptor which will complete next.
The residue is defined by the bytes remaining to the end of the buffer,
when the buffer is viewed as a single block of memory [start...end].
So, when we start out, there's a full buffer worth of residue, and this
counts down as we approach the end of the buffer, eventually becoming
zero at the end, before returning to the full buffer worth when we
wrap back to the start.
Moving the walking of the descriptors into the interrupt handler means
that we can update the BD_DONE flag at interrupt time, thus avoiding
a delayed tasklet stopping the cyclic DMA.
This means that the residue can be calculated from (total descriptors -
buf_tail) * descriptor size. This is what the change below does. We
update imx-pcm-dma.c to remove the NO_RESIDUE flag since we now provide
the residue.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
When a 0-length packet is received on the bus, desc->pd0 yields 1,
which confuses the driver's users. This information is clearly wrong
and not in accordance to the datasheet, but it's been observed on an
AM335x board, very reproducible.
Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore the value in PD0 and report a total length of 0 instead.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
This patch makes the msm ehci driver available to use on QCOM SOCs,
which have the same IP.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs. This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Michael Büsch <m@bues.ch>
Tested-by: Michael Büsch <m@bues.ch>
Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A few more fixes for this RC cycle. There's a revert of a previous patch
which ended up being the wrong version, so we reverted that commit and
applied a better fix.
CPPI41 got a race condition fix which was found by Thomas Gleixner.
The MSM PHY driver got a runtime pm usage fix so that it wouldn't
kill the PHY while it was still being used.
We also have a fix for a panic caused when removing musb_am335x driver.
Other than that, a few other minor fixes.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTsa7CAAoJEIaOsuA1yqREC7kP/RRECPS8UrZgrVlU9Gch5iqw
WtV3TdkTVuB6bhwvtRGIAjiXOdr8INvRkKvlzVN082cROAdSWjElbD9A/830a2Iv
5sMOWbM6HIkrwr51cGXIMul+0wNhcszftCn4+8UUiuKoP7dFnqTGZBgcyoDhfkHQ
BjQ3/RlzeZ3XjLiBtnA4gTVko9i9L77TMayskOyjDpEEBKJ4HBKcD9Ged2xfgDxV
P7lc5lkehUF9l3BAP4xfJq+vV8nxpRwq5J4OkBmJpODUPmim8XlSTNxA3EJQ+3SQ
1NusKOT/pVcSNYzVtB23C9Qvj6pvocso0ktvJOzwMLmW95GNMwN6NzbJUiSXIUzG
cOGXGA6dJYKVFZ/7QNsV99ZAjEYBrgszZqtDHYmitYdo29ABMSuZ/3ZdfAT09a9P
+Fqm4gqTDLJ9y72PHSc1CPJq4whTINGpIKcyRiVaxl+jFXl4v5rs3BywKV2gMIlM
EhXaNz/AG+wGZVOiZzg0zHSjAhCw0GbthysMmd87z7Ynjcu97pDBEIw+xl1aI3wS
eyFFt16WtRxujXFYqfDtArU0pdqrTxLgTBisxf949LKZJiB6Ta7v+MZOfFKVu//O
5K8KCN1l4vMUPOvTghT0BIGsCg4Td9zi0LTEQOBEwavYzXyATdqGAYnYeLgoqO4z
82XvxgC4fqXzXLhAntC5
=7Mt5
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.16-rc4
A few more fixes for this RC cycle. There's a revert of a previous patch
which ended up being the wrong version, so we reverted that commit and
applied a better fix.
CPPI41 got a race condition fix which was found by Thomas Gleixner.
The MSM PHY driver got a runtime pm usage fix so that it wouldn't
kill the PHY while it was still being used.
We also have a fix for a panic caused when removing musb_am335x driver.
Other than that, a few other minor fixes.
Signed-of-by: Felipe Balbi <balbi@ti.com>
tmon fails to build statically with the following error:
$ make LDFLAGS=-static
gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration -Wimplicit-int -fstack-protector -D VERSION=\"1.0\" -static tmon.o tui.o sysfs.o pid.o -o tmon -lm -lpanel -lncursesw -lpthread
tmon.o: In function `tmon_sig_handler':
tmon.c:(.text+0x21): undefined reference to `stdscr'
tmon.o: In function `tmon_cleanup':
tmon.c:(.text+0xb9): undefined reference to `stdscr'
tmon.c:(.text+0x11e): undefined reference to `stdscr'
tmon.c:(.text+0x123): undefined reference to `keypad'
tmon.c:(.text+0x12d): undefined reference to `nocbreak'
tmon.o: In function `main':
tmon.c:(.text+0x785): undefined reference to `stdscr'
tmon.c:(.text+0x78a): undefined reference to `nodelay'
tui.o: In function `setup_windows':
tui.c:(.text+0x131): undefined reference to `stdscr'
tui.c:(.text+0x176): undefined reference to `stdscr'
tui.c:(.text+0x19f): undefined reference to `stdscr'
tui.c:(.text+0x1cc): undefined reference to `stdscr'
tui.c:(.text+0x1ff): undefined reference to `stdscr'
tui.o:tui.c:(.text+0x229): more undefined references to `stdscr' follow
tui.o: In function `show_cooling_device':
[...]
stdscr() and friends are in libtinfo (part of ncurses) so add it to
the libraries that are linked in when compiling tmon to fix it.
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
On latest i.MX6 SOC with thermal calibration data of 0x5A100000,
the critical trip temperature will be an invalid value and
cause system auto shutdown as below log:
thermal thermal_zone0: critical temperature reached(42 C),shutting down
So, with universal formula for thermal sensor, only room
temperature point is calibrated, which means the calibration
data read from fuse only has valid data of bit [31:20], others
are all 0, the critical trip point temperature can NOT depend
on the hot point calibration data, here we set it to 20 C higher
than default passive temperature.
Signed-off-by: Anson Huang <b20788@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
commit 943c13971c "usb: musb: dsps: implement ->set_mode()"
should have made it possible to use the driver with boards that have
the USBID pin unconnected. This doesn't actually work, since the
driver uses the wrong base address to access the mode register.
Furthermore it uses different base addresses in different places to
access the same register (phy_utmi).
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format. Fix by wrapping the numbers in
cpu_to_le32.
Cc: stable@vger.kernel.org
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Use case is when the phy is configured in host mode and a usb device is
attached to board before bootup. On bootup, with the existing code and
runtime pm enabled, the driver would decrement the pm usage count
without checking the current state of the phy. This pm usage count
decrement would trigger the runtime pm which than would abort the
usb enumeration which was in progress. In my case a usb stick gets
detected and then immediatly the driver goes to low power mode which is
not correct.
log:
[ 1.631412] msm_hsusb_host 12520000.usb: EHCI Host Controller
[ 1.636556] msm_hsusb_host 12520000.usb: new USB bus registered, assigned bus number 1
[ 1.642563] msm_hsusb_host 12520000.usb: irq 220, io mem 0x12520000
[ 1.658197] msm_hsusb_host 12520000.usb: USB 2.0 started, EHCI 1.00
[ 1.659473] hub 1-0:1.0: USB hub found
[ 1.663415] hub 1-0:1.0: 1 port detected
...
[ 1.973352] usb 1-1: new high-speed USB device number 2 using msm_hsusb_host
[ 2.107707] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 2.108993] scsi0 : usb-storage 1-1:1.0
[ 2.678341] msm_otg 12520000.phy: USB in low power mode
[ 3.168977] usb 1-1: USB disconnect, device number 2
This issue was detected on IFC6410 board.
This patch fixes the intial runtime pm trigger by checking the phy
state and decrementing the pm use count only when the phy state is IDLE.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On Marvell Armada XP, when a CPU comes back from deep idle state of
cpuidle, it restarts its execution at armada_370_xp_cpu_resume(),
which puts back the CPU into the coherency, and then calls the generic
cpu_resume() function.
While this works on little-endian configurations, it doesn't work on
big-endian configurations because the CPU restarts in little-endian,
and therefore must be switched back to big-endian to operate
properly. To achieve this, a 'setend be' instruction must be executed
in big-endian configurations. However, the ARM_BE8() macro that is
used to implement nice compile-time conditional for ARM LE vs. ARM BE8
is not easily usable in inline assembly.
Therefore, this patch moves the armada_370_xp_cpu_resume() C function,
which was anyway just a block of inline assembly, into a proper
pmsu_ll.S file, and adds the appropriate ARM_BE8(setend be)
instruction.
Without this patch, an Armada XP big endian configuration with cpuidle
enabled fails to boot, as it hangs as soon as one of the CPU hits the
deep idle state.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1404130165-3593-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Commit 497a92308a ("ARM: mvebu:
implement L2/PCIe deadlock workaround") introduced some logic in
coherency.c to adjust the PL310 cache controller Device Tree node of
Armada 375 and Armada 38x platform to include the 'arm,io-coherent'
property if the system is running with hardware I/O coherency enabled.
However, with the L2CC driver cleanup done by Russell King, the
initialization of the L2CC driver has been moved earlier, and is now
part of the init_IRQ() ARM function in
arch/arm/kernel/irq.c. Therefore, calling coherency_init() in
->init_time() is now too late, as the Device Tree property gets added
too late (after the L2CC driver has been initialized).
In order to fix this, this commit removes the ->init_time() callback
use in board-v7.c and replaces it with an ->init_irq() callback. We
therefore no longer use the default ->init_irq() callback, but we now
use the default ->init_time() callback.
In this newly introduced ->init_irq() callback, we call irqchip_init()
which is the default behavior when ->init_irq() isn't defined, and
then do the initialization related to the coherency: SCU, coherency
fabric, and mvebu-mbus (which is needed to start secondary CPUs).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1402585772-10405-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
In preparation to a small re-organization of the initialization
sequence in board-v7.c, this commit moves the registration of the
custom external abort handler on Armada 375 later in the boot
sequence, and makes it more similar to the other quirks that we
already have. There is indeed no need to register this abort handler
particularly early, it simply needs to be registered before switching
to userspace.
In addition to this, this commit makes the registration of the custom
abort handler conditional on Armada 375 Z1, because Armada 375 A0 and
later iterations are not affected by the issue.
This commit was tested on both Armada 375 Z1 and Armada 375 A0
platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1402585772-10405-3-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The usage of uprobe_buffer_enable() added by dcad1a20 is very wrong,
1. uprobe_buffer_enable() and uprobe_buffer_disable() are not balanced,
_enable() should be called only if !enabled.
2. If uprobe_buffer_enable() fails probe_event_enable() should clear
tp.flags and free event_file_link.
3. If uprobe_register() fails it should do uprobe_buffer_disable().
Link: http://lkml.kernel.org/p/20140627170146.GA18332@redhat.com
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Fixes: dcad1a204f "tracing/uprobes: Fetch args before reserving a ring buffer"
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I do not know why dd9fa555d7 "tracing/uprobes: Move argument fetching
to uprobe_dispatcher()" added the UPROBE_HANDLER_REMOVE, but it looks
wrong.
OK, perhaps it makes sense to avoid store_trace_args() if the tracee is
nacked by uprobe_perf_filter(). But then we should kill the same code
in uprobe_perf_func() and unify the TRACE/PROFILE filtering (we need to
do this anyway to mix perf/ftrace). Until then this code actually adds
the pessimization because uprobe_perf_filter() will be called twice and
return T in likely case.
Link: http://lkml.kernel.org/p/20140627170143.GA18329@redhat.com
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add WARN_ON's into uprobe_unregister() and uprobe_apply() to ensure
that nobody tries to play with the dead uprobe/consumer. This helps
to catch the bugs like the one fixed by the previous patch.
In the longer term we should fix this poorly designed interface.
uprobe_register() should return "struct uprobe *" which should be
passed to apply/unregister. Plus other semantic changes, see the
changelog in commit 41ccba029e.
Link: http://lkml.kernel.org/p/20140627170140.GA18322@redhat.com
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
This reverts commit 43fe98913c.
This patch is very wrong. Firstly, this change leads to unbalanced
uprobe_unregister(). Just for example,
# perf probe -x /lib/libc.so.6 syscall
# echo 1 >> /sys/kernel/debug/tracing/events/probe_libc/enable
# perf record -e probe_libc:syscall whatever
after that uprobe is dead (unregistered) but the user of ftrace/perf
can't know this, and it looks as if nobody hits this probe.
This would be easy to fix, but there are other reasons why it is not
simple to mix ftrace and perf. If nothing else, they can't share the
same ->consumer.filter. This is fixable too, but probably we need to
fix the poorly designed uprobe_register() interface first. At least
"register" and "apply" should be clearly separated.
Link: http://lkml.kernel.org/p/20140627170136.GA18319@redhat.com
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: "zhangwei(Jovi)" <jovi.zhangwei@huawei.com>
Cc: stable@vger.kernel.org # v3.14
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
We import the CPL via SS.DPL since ae9fedc793. However, we fail to
export it this way so far. This caused spurious guest crashes, e.g. of
Linux when accessing the vmport from guest user space which triggered
register saving/restoring to/from host user space.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We've converted cgroup to kernfs so cgroup won't be intertwined with
vfs objects and locking, but there are dark areas.
Run two instances of this script concurrently:
for ((; ;))
{
mount -t cgroup -o cpuacct xxx /cgroup
umount /cgroup
}
After a while, I saw two mount processes were stuck at retrying, because
they were waiting for a subsystem to become free, but the root associated
with this subsystem never got freed.
This can happen, if thread A is in the process of killing superblock but
hasn't called percpu_ref_kill(), and at this time thread B is mounting
the same cgroup root and finds the root in the root list and performs
percpu_ref_try_get().
To fix this, we try to increase both the refcnt of the superblock and the
percpu refcnt of cgroup root.
v2:
- we should try to get both the superblock refcnt and cgroup_root refcnt,
because cgroup_root may have no superblock assosiated with it.
- adjust/add comments.
tj: Updated comments. Renamed @sb to @pinned_sb.
Cc: <stable@vger.kernel.org> # 3.15
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
kernfs_pin_sb() tries to get a refcnt of the superblock.
This will be used by cgroupfs.
v2:
- make kernfs_pin_sb() return the superblock.
- drop kernfs_drop_sb().
tj: Updated the comment a bit.
[ This is a prerequisite for a bugfix. ]
Cc: <stable@vger.kernel.org> # 3.15
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
# cat test.sh
#! /bin/bash
mount -t cgroup -o cpu xxx /cgroup
umount /cgroup
mount -t cgroup -o cpu,cpuacct xxx /cgroup
umount /cgroup
# ./test.sh
mount: xxx already mounted or /cgroup busy
mount: according to mtab, xxx is already mounted on /cgroup
It's because the cgroupfs_root of the first mount was under destruction
asynchronously.
Fix this by delaying and then retrying mount for this case.
v3:
- put the refcnt immediately after getting it. (Tejun)
v2:
- use percpu_ref_tryget_live() rather that introducing
percpu_ref_alive(). (Tejun)
- adjust comment.
tj: Updated the comment a bit.
Cc: <stable@vger.kernel.org> # 3.15
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The "aclk66_peric" clock is a gate clock with a whole bunch of gates
underneath it. This big gate isn't very useful to include in our
clock tree. If any of the children need to be turned on then the big
gate will need to be on anyway. ...and there are plenty of other "big
gates" that aren't described in our clock tree, some of which shut off
collections of clocks that have no relationship in the hierarchy so
are hard to model.
"aclk66_peric" is causing earlyprintk problems since it gets disabled
as part of the boot process, so let's just remove it.
Strangely (and for no good reason) this clock is exported as part of
the common clock bindings. Remove it since there are no in-kernel
device trees using it and no reason anyone out of tree should refer to
it either.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Change bit from 2 to 9 for tv (mixer) sysmmu clock.
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Reviewed-by: Sachin Kamat <sachin.kamat@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
In the move to this clock driver the hookups for the SPI clocks were
dropped, which causes my system Cragganmore (s3c6410 based) to be unable
to locate any spibus clocks. This patch adds them back in.
When taking the clock from the epll clock (SCLK) the rates on the SPI
bus are incorrect, this needs further debugging but the hookup here
should be correct and the problem should be else where.
The USBCLK case has been dropped because this requires the USB PHY to be
enabled.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
ISP special clocks have dedicated gating registers and so MUX SRC_MASK
register should not be used. This patch fixes the problem of
Exynos4x12-based boards freezing on system suspend, because those
mux outputs need not to be masked while suspending.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Cc: Mike Turquette <mturquette@linaro.org>
