Ioana Radulescu [Thu, 28 Sep 2017 14:10:33 +0000 (09:10 -0500)]
staging: fsl-mc/dpio: Fix incorrect comparison
[ Upstream commit
8dabf52ffb6445fa5bcc8b6d2ecb615f60d0dd12 ]
For some dpio functions, a cpu id parameter value of -1 is
valid and means "any". But when trying to validate this param
value against an upper limit, in this case num_possible_cpus(),
we risk obtaining the wrong result due to an implicit cast.
Avoid an incorrect check result by explicitly comparing the
cpu id with the "any" value before verifying the upper bound.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Jamison [Thu, 21 Sep 2017 08:13:12 +0000 (10:13 +0200)]
serial: imx: Update cached mctrl value when changing RTS
[ Upstream commit
a0983c742a5885f82afb282166f83f1d3d8addf4 ]
UART core function uart_update_mctrl relies on a cached value of
modem control lines. This was used but not updated by local RTS
control functions within imx.c. These are used for RS485 line
driver enable signalling. Having an out-of-date value in the cached
mctrl can result in the transmitter being enabled when it shouldn't
be.
Fix this by updating the mctrl value before applying it.
Signed-off-by: Ian Jamison <ian.dev@arkver.com>
Origin: id:
8195c96e674517b82a6ff7fe914c7ba0f86e702b.
1505375165.git.ian.dev@arkver.com
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sun, 1 Oct 2017 01:18:37 +0000 (02:18 +0100)]
usbip: tools: Install all headers needed for libusbip development
[ Upstream commit
c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes:
021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes:
3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lowe [Fri, 22 Sep 2017 18:29:30 +0000 (20:29 +0200)]
serial: sh-sci: suppress warning for ports without dma channels
[ Upstream commit
7464779fa8551b90d5797d4020b0bdb7e6422eb9 ]
If a port has no dma channel defined in the device tree, then
don't attempt to allocate a dma channel for the port.
Also suppress the warning message concerning the failure to allocate
a dma channel. Continue to emit the warning message if a dma
channel is defined but cannot be allocated.
Signed-off-by: Andy Lowe <andy_lowe@mentor.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jibin Xu [Mon, 11 Sep 2017 03:11:42 +0000 (20:11 -0700)]
sysrq : fix Show Regs call trace on ARM
[ Upstream commit
b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [
00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[<
ffffff8008088e80>] dump_backtrace+0x0/0x1d0
[<
ffffff8008089074>] show_stack+0x24/0x30
[<
ffffff8008447970>] dump_stack+0x90/0xb0
[<
ffffff8008463950>] check_preemption_disabled+0x100/0x108
[<
ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20
[<
ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40
[<
ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0
[<
ffffff80084ca140>] write_sysrq_trigger+0x60/0x70
[<
ffffff8008251e00>] proc_reg_write+0x90/0xd0
[<
ffffff80081f1788>] __vfs_write+0x48/0x90
[<
ffffff80081f241c>] vfs_write+0xa4/0x190
[<
ffffff80081f3354>] SyS_write+0x54/0xb0
[<
ffffff80080833f0>] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu <jibin.xu@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lu Baolu [Thu, 5 Oct 2017 08:21:43 +0000 (11:21 +0300)]
usb: xhci: Return error when host is dead in xhci_disable_slot()
[ Upstream commit
dcabc76fa9361186e6b88c30a68db8fa9d5b4a1c ]
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead host.
Fixes:
f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang <guoqing.zhang@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leo Yan [Tue, 10 Oct 2017 05:47:55 +0000 (13:47 +0800)]
ARM: cpuidle: Correct driver unregistration if init fails
[ Upstream commit
0f87855d969a87f02048ff5ced7503465d5ab2f1 ]
If cpuidle init fails, the code misses to unregister the driver for
current CPU. Furthermore, we also need to rollback to cancel all
previous CPUs registration; but the code retrieves driver handler by
using function cpuidle_get_driver(), this function returns back
current CPU driver handler but not previous CPU's handler, which leads
to the failure handling code cannot unregister previous CPUs driver.
This commit fixes two mentioned issues, it adds error handling path
'goto out_unregister_drv' for current CPU driver unregistration; and
it is to replace cpuidle_get_driver() with cpuidle_get_cpu_driver(),
the later function can retrieve driver handler for previous CPUs
according to the CPU device handler so can unregister the driver
properly.
This patch also adds extra error handling paths 'goto out_kfree_dev'
and 'goto out_kfree_drv' and adjusts the freeing sentences for previous
CPUs; so make the code more readable for freeing 'dev' and 'drv'
structures.
Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Fixes:
d50a7d8acd78 (ARM: cpuidle: Support asymmetric idle definition)
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sun, 24 Sep 2017 00:36:04 +0000 (19:36 -0500)]
staging: rtl8822be: Keep array subscript no lower than zero
[ Upstream commit
43d15c2013130a9fa230c2f5203aca818ae0bb86 ]
The kbuild test robot reports the following:
drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig':
drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript is below array bounds [-Warray-bounds]
odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
This condition is caused when a loop falls through. The fix is to pin
max_level to be >= 0.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
c: kbuild test robot <fengguang.wu@intel.com>
Fixes:
9ce99b04b5b82fdf11e4c76b60a5f82c1e541297 staging: r8822be: Add phydm mini driver
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ioana Radulescu [Wed, 11 Oct 2017 13:29:44 +0000 (08:29 -0500)]
staging: fsl-dpaa2/eth: Account for Rx FD buffers on error path
[ Upstream commit
cbb3ea40fc495bf04070200b35c1c4cd05d11bd3 ]
On Rx path, if we fail to build an skb from the incoming FD,
we still need to update the channel buffer count accordingly,
otherwise we risk depleting the pool while the software counter
still sees available buffers.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunfeng Yun [Fri, 13 Oct 2017 09:10:37 +0000 (17:10 +0800)]
usb: mtu3: fix error return code in ssusb_gadget_init()
[ Upstream commit
c162ff0aaaac456ef29aebd1e9d4d3e305cd3279 ]
When failing to get IRQ number, platform_get_irq() may return
-EPROBE_DEFER, but we ignore it and always return -ENODEV,
so fix it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Mon, 16 Oct 2017 17:40:29 +0000 (12:40 -0500)]
EDAC, sb_edac: Fix missing break in switch
[ Upstream commit
a8e9b186f153a44690ad0363a56716e7077ad28c ]
Add missing break statement in order to prevent the code from falling
through.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Mon, 18 Sep 2017 13:46:41 +0000 (15:46 +0200)]
dt-bindings: timer: renesas, cmt: Fix SoC-specific compatible values
[ Upstream commit
e20824e944c3bf4352fcd8d9f446c41b53901e7b ]
While the new family-specific compatible values introduced by commit
6f54cc1adcc8957f ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1
bindings") use the recommended order "<vendor>,<family>-<device>", the
new SoC-specific compatible values still use the old and deprecated
order "<vendor>,<device>-<soc>".
Switch the SoC-specific compatible values to the recommended order while
there are no upstream users of these compatible values yet.
Fixes:
7f03a0ecfdc786c1 ("devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings")
Fixes:
63d9e8ca0dd4bfa4 ("devicetree: bindings: Deprecate property, update example")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Mon, 16 Oct 2017 15:28:38 +0000 (16:28 +0100)]
clocksource/drivers/arm_arch_timer: Validate CNTFRQ after enabling frame
[ Upstream commit
21492e1333a0d07af6968667f128e19088cf5ead ]
The ACPI GTDT code validates the CNTFRQ field of each MMIO timer
frame against the CNTFRQ system register of the current CPU, to
ensure that they are equal, which is mandated by the architecture.
However, reading the CNTFRQ field of a frame is not possible until
the RFRQ bit in the frame's CNTACRn register is set, and doing so
before that willl produce the following error:
arch_timer: [Firmware Bug]: CNTFRQ mismatch: frame @ 0x00000000e0be0000: (0x00000000), CPU: (0x0ee6b280)
arch_timer: Disabling MMIO timers due to CNTFRQ mismatch
arch_timer: Failed to initialize memory-mapped timer.
The reason is that the CNTFRQ field is RES0 if access is not enabled.
So move the validation of CNTFRQ into the loop that iterates over the
timers to find the best frame, but defer it until after we have selected
the best frame, which should also have enabled the RFRQ bit.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Hansen [Wed, 18 Oct 2017 17:21:07 +0000 (10:21 -0700)]
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
[ Upstream commit
da20ab35180780e4a6eadc804544f1fa967f3567 ]
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Brian Gerst <brgerst@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Thu, 19 Oct 2017 23:43:39 +0000 (08:43 +0900)]
kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT=y
[ Upstream commit
a30b85df7d599f626973e9cd3056fe755bd778e0 ]
We want to wait for all potentially preempted kprobes trampoline
execution to have completed. This guarantees that any freed
trampoline memory is not in use by any task in the system anymore.
synchronize_rcu_tasks() gives such a guarantee, so use it.
Also, this guarantees to wait for all potentially preempted tasks
on the instructions which will be replaced with a jump.
Since this becomes a problem only when CONFIG_PREEMPT=y, enable
CONFIG_TASKS_RCU=y for synchronize_rcu_tasks() in that case.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/150845661962.5443.17724352636247312231.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaron Sierra [Wed, 4 Oct 2017 15:01:28 +0000 (10:01 -0500)]
serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
[ Upstream commit
0ab84da2e076948c49d36197ee7d254125c53eab ]
The upper four bits of the XR17V35x fractional divisor register (DLD)
control general chip function (RS-485 direction pin polarity, multidrop
mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits
to be clobbered when setting the baudrate.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reinette Chatre [Fri, 20 Oct 2017 09:16:59 +0000 (02:16 -0700)]
x86/intel_rdt: Fix potential deadlock during resctrl mount
[ Upstream commit
87943db7dfb0c5ee5aa74a9ac06346fadd9695c8 ]
Sai reported a warning during some MBA tests:
[ 236.755559] ======================================================
[ 236.762443] WARNING: possible circular locking dependency detected
[ 236.769328] 4.14.0-rc4-yocto-standard #8 Not tainted
[ 236.774857] ------------------------------------------------------
[ 236.781738] mount/10091 is trying to acquire lock:
[ 236.787071] (cpu_hotplug_lock.rw_sem){++++}, at: [<
ffffffff8117f892>] static_key_enable+0x12/0x30
[ 236.797058]
but task is already holding lock:
[ 236.803552] (&type->s_umount_key#37/1){+.+.}, at: [<
ffffffff81208b2f>] sget_userns+0x32f/0x520
[ 236.813247]
which lock already depends on the new lock.
[ 236.822353]
the existing dependency chain (in reverse order) is:
[ 236.830686]
-> #4 (&type->s_umount_key#37/1){+.+.}:
[ 236.837756] __lock_acquire+0x1100/0x11a0
[ 236.842799] lock_acquire+0xdf/0x1d0
[ 236.847363] down_write_nested+0x46/0x80
[ 236.852310] sget_userns+0x32f/0x520
[ 236.856873] kernfs_mount_ns+0x7e/0x1f0
[ 236.861728] rdt_mount+0x30c/0x440
[ 236.866096] mount_fs+0x38/0x150
[ 236.870262] vfs_kern_mount+0x67/0x150
[ 236.875015] do_mount+0x1df/0xd50
[ 236.879286] SyS_mount+0x95/0xe0
[ 236.883464] entry_SYSCALL_64_fastpath+0x18/0xad
[ 236.889183]
-> #3 (rdtgroup_mutex){+.+.}:
[ 236.895292] __lock_acquire+0x1100/0x11a0
[ 236.900337] lock_acquire+0xdf/0x1d0
[ 236.904899] __mutex_lock+0x80/0x8f0
[ 236.909459] mutex_lock_nested+0x1b/0x20
[ 236.914407] intel_rdt_online_cpu+0x3b/0x4a0
[ 236.919745] cpuhp_invoke_callback+0xce/0xb80
[ 236.925177] cpuhp_thread_fun+0x1c5/0x230
[ 236.930222] smpboot_thread_fn+0x11a/0x1e0
[ 236.935362] kthread+0x152/0x190
[ 236.939536] ret_from_fork+0x27/0x40
[ 236.944097]
-> #2 (cpuhp_state-up){+.+.}:
[ 236.950199] __lock_acquire+0x1100/0x11a0
[ 236.955241] lock_acquire+0xdf/0x1d0
[ 236.959800] cpuhp_issue_call+0x12e/0x1c0
[ 236.964845] __cpuhp_setup_state_cpuslocked+0x13b/0x2f0
[ 236.971242] __cpuhp_setup_state+0xa7/0x120
[ 236.976483] page_writeback_init+0x43/0x67
[ 236.981623] pagecache_init+0x38/0x3b
[ 236.986281] start_kernel+0x3c6/0x41a
[ 236.990931] x86_64_start_reservations+0x2a/0x2c
[ 236.996650] x86_64_start_kernel+0x72/0x75
[ 237.001793] verify_cpu+0x0/0xfb
[ 237.005966]
-> #1 (cpuhp_state_mutex){+.+.}:
[ 237.012364] __lock_acquire+0x1100/0x11a0
[ 237.017408] lock_acquire+0xdf/0x1d0
[ 237.021969] __mutex_lock+0x80/0x8f0
[ 237.026527] mutex_lock_nested+0x1b/0x20
[ 237.031475] __cpuhp_setup_state_cpuslocked+0x54/0x2f0
[ 237.037777] __cpuhp_setup_state+0xa7/0x120
[ 237.043013] page_alloc_init+0x28/0x30
[ 237.047769] start_kernel+0x148/0x41a
[ 237.052425] x86_64_start_reservations+0x2a/0x2c
[ 237.058145] x86_64_start_kernel+0x72/0x75
[ 237.063284] verify_cpu+0x0/0xfb
[ 237.067456]
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
[ 237.074436] check_prev_add+0x401/0x800
[ 237.079286] __lock_acquire+0x1100/0x11a0
[ 237.084330] lock_acquire+0xdf/0x1d0
[ 237.088890] cpus_read_lock+0x42/0x90
[ 237.093548] static_key_enable+0x12/0x30
[ 237.098496] rdt_mount+0x406/0x440
[ 237.102862] mount_fs+0x38/0x150
[ 237.107035] vfs_kern_mount+0x67/0x150
[ 237.111787] do_mount+0x1df/0xd50
[ 237.116058] SyS_mount+0x95/0xe0
[ 237.120233] entry_SYSCALL_64_fastpath+0x18/0xad
[ 237.125952]
other info that might help us debug this:
[ 237.134867] Chain exists of:
cpu_hotplug_lock.rw_sem --> rdtgroup_mutex --> &type->s_umount_key#37/1
[ 237.148425] Possible unsafe locking scenario:
[ 237.155015] CPU0 CPU1
[ 237.160057] ---- ----
[ 237.165100] lock(&type->s_umount_key#37/1);
[ 237.169952] lock(rdtgroup_mutex);
[ 237.176641]
lock(&type->s_umount_key#37/1);
[ 237.184287] lock(cpu_hotplug_lock.rw_sem);
[ 237.189041]
*** DEADLOCK ***
When the resctrl filesystem is mounted the locks must be acquired in the
same order as was done when the cpus came online:
cpu_hotplug_lock before rdtgroup_mutex.
This also requires to switch the static_branch_enable() calls to the
_cpulocked variant because now cpu hotplug lock is held already.
[ tglx: Switched to cpus_read_[un]lock ]
Reported-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: fenghua.yu@intel.com
Cc: tony.luck@intel.com
Link: https://lkml.kernel.org/r/9c41b91bc2f47d9e95b62b213ecdb45623c47a9f.1508490116.git.reinette.chatre@intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reinette Chatre [Fri, 20 Oct 2017 09:16:57 +0000 (02:16 -0700)]
x86/intel_rdt: Initialize bitmask of shareable resource if CDP enabled
[ Upstream commit
95953034fb24c16ad0047a98b16427e5935830c4 ]
The platform informs via CPUID.(EAX=0x10, ECX=res#):EBX[31:0] (valid res#
are only 1 for L3 and 2 for L2) which unit of the allocation may be used by
other entities in the platform. This information is valid whether CDP (Code
and Data Prioritization) is enabled or not.
Ensure that the bitmask of shareable resource is initialized when CDP is
enabled.
Fixes:
0dd2d7494cd8 ("x86/intel_rdt: Show bitmask of shareable resource with other executing units"
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/815747bddc820ca221a8924edaf4d1a7324547e4.1508490116.git.reinette.chatre@intel.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kishon Vijay Abraham I [Mon, 9 Oct 2017 09:03:37 +0000 (14:33 +0530)]
PCI: dra7xx: Create functional dependency between PCIe and PHY
[ Upstream commit
7a4db656a6350f8dd46f711bdef3b0e9c6e3f4cb ]
PCI core access configuration space registers in resume_noirq callbacks.
In the case of dra7xx, PIPE3 PHY connected to PCIe controller has to be
enabled before accessing configuration space registers. Since
PIPE3 PHY is enabled by only configuring control module registers, no
aborts has been observed so far (though during noirq stage, interface
clock of PIPE3 PHY is not enabled).
With new TRM updates, PIPE3 PHY has to be initialized (PIPE3 PHY
registers has to be accessed) as well which requires the interface
clock of PIPE3 PHY to be enabled. The interface clock of PIPE3 PHY is
derived from OCP2SCP and hence PCIe PHY is modeled as a child of
OCP2SCP. Since pm_runtime is not enabled during noirq stage,
pm_runtime_get_sync done in phy_init doesn't enable
OCP2SCP clocks resulting in abort when PIPE3 PHY registers are
accessed.
Create a function dependency between PCIe and PHY here to make
sure PCIe is suspended before PCIe PHY/OCP2SCP and resumed after
PCIe PHY/OCP2SCP.
Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Fri, 20 Oct 2017 22:02:07 +0000 (01:02 +0300)]
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
[ Upstream commit
ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Fixes:
860d2686fda7 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API")
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Tue, 5 Sep 2017 11:38:24 +0000 (13:38 +0200)]
perf/core: Fix __perf_read_group_add() locking
[ Upstream commit
a9cd8194e1e6bd09619954721dfaf0f94fe2003e ]
Event timestamps are serialized using ctx->lock, make sure to hold it
over reading all values.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Edward A. James [Fri, 27 Oct 2017 16:55:05 +0000 (11:55 -0500)]
hwmon: (pmbus/core) Prevent unintentional setting of page to 0xFF
[ Upstream commit
6dcf2fb5e8db3704f50af1f198256cb4e2453f8b ]
The pmbus core may call read/write word data functions with a page value
of -1, intending to perform the operation without setting the page.
However, the read/write word data functions accept only unsigned 8-bit
page numbers, and therefore cannot check for negative page number to
avoid setting the page. This results in setting the page number to 0xFF.
This may result in errors or undefined behavior of some devices
(specifically the ir35221, which allows the page to be set to 0xFF,
but some subsequent operations to read registers may fail).
Switch the pmbus_set_page page parameter to an integer and perform the
check for negative page there. Make read/write functions consistent in
accepting an integer page number parameter.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Fixes:
cbcdec6202c9 ("hwmon: (pmbus): Access word data for STATUS_WORD")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subhash Jadavani [Wed, 27 Sep 2017 05:34:40 +0000 (11:04 +0530)]
mmc: sdhci-msm: fix issue with power irq
[ Upstream commit
c7ccee224d2d551f712752c4a16947f6529d6506 ]
SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabrizio Castro [Fri, 22 Sep 2017 11:22:17 +0000 (12:22 +0100)]
mmc: tmio: check mmc_regulator_get_supply return value
[ Upstream commit
a3d95d1d4007b1fefd6d8b12db26fda05de05cfb ]
mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or
vqmmc regulators had their probing deferred.
vqmmc regulator is needed by UHS to work properly, therefore this
patch checks the value returned by mmc_regulator_get_supply to
make sure we have a reference to both vmmc and vqmmc (if found in
the DT).
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 30 Oct 2017 10:35:27 +0000 (11:35 +0100)]
spi: spi-axi: fix potential use-after-free after deregistration
[ Upstream commit
4d5e0689dc9d5640ad46cdfbe1896b74d8df1661 ]
Take an extra reference to the controller before deregistering it to
prevent use-after-free in the interrupt handler in case an interrupt
fires before the line is disabled.
Fixes:
b1353d1c1d45 ("spi: Add Analog Devices AXI SPI Engine controller support")
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hiromitsu Yamasaki [Thu, 2 Nov 2017 09:32:36 +0000 (10:32 +0100)]
spi: sh-msiof: Fix DMA transfer size check
[ Upstream commit
36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes:
b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Fri, 20 Oct 2017 18:40:24 +0000 (20:40 +0200)]
staging: rtl8188eu: avoid a null dereference on pmlmepriv
[ Upstream commit
123c0aab0050cd0e07ce18e453389fbbb0a5a425 ]
There is a check on pmlmepriv before dereferencing it when
vfree'ing pmlmepriv->free_bss_buf however the previous call
to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing
a null pointer deference if it is null. Avoid this by also
calling rtw_free_mlme_priv_ie_data if the pointer is non-null.
Detected by CoverityScan, CID#1230262 ("Dereference before null check")
Fixes:
7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Mon, 23 Oct 2017 09:35:59 +0000 (11:35 +0200)]
staging: rtl8822be: fix wrong dma unmap len
[ Upstream commit
c40a45a465e9eab72cfdd3ab69d15cf8ef8b89c8 ]
Patch fixes splat:
r8822be 0000:04:00.0: DMA-API: device driver frees DMA memory with different size
[device address=0x0000000078477000] [map size=4096 bytes] [unmap size=424 bytes]
<snip>
Call Trace:
debug_dma_unmap_page+0xa5/0xb0
? unmap_single+0x2f/0x40
_rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
? _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
rtl8822b_halmac_cb_write_data_rsvd_page+0x51/0xc0 [r8822be]
_halmac_write_data_rsvd_page+0x22/0x30 [r8822be]
halmac_download_rsvd_page_88xx+0xee/0x1f0 [r8822be]
halmac_dlfw_to_mem_88xx+0x80/0x120 [r8822be]
halmac_download_firmware_88xx.part.47+0x477/0x600 [r8822be]
halmac_download_firmware_88xx+0x32/0x40 [r8822be]
rtl_halmac_dlfw+0x70/0x120 [r8822be]
rtl_halmac_init_hal+0x5f/0x1b0 [r8822be]
rtl8822be_hw_init+0x8a2/0x1040 [r8822be]
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Wunner [Sat, 28 Oct 2017 09:35:49 +0000 (11:35 +0200)]
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
[ Upstream commit
3236a965486ba0c6043cf2c7b51943d8b382ae29 ]
This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending. In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.
Fixes:
28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Ungerer [Tue, 5 Sep 2017 12:57:06 +0000 (22:57 +1000)]
m68k: fix ColdFire node shift size calculation
[ Upstream commit
f55ab8f27548ff3431a6567d400c6757c49fd520 ]
The m68k pg_data_table is a fix size array defined in arch/m68k/mm/init.c.
Index numbers within it are defined based on memory size. But for Coldfire
these don't take into account a non-zero physical RAM base address, and this
causes us to access past the end of this array at system start time.
Change the node shift calculation so that we keep the index inside its range.
Reported-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bryan O'Donoghue [Mon, 6 Nov 2017 01:32:20 +0000 (01:32 +0000)]
staging: greybus: loopback: Fix iteration count on async path
[ Upstream commit
44b02da39210e6dd67e39ff1f48d30c56d384240 ]
Commit
12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support") does what it says on the tin - namely, adds support for
asynchronous bi-directional loopback operations.
What it neglects to do though is increment the per-connection
gb->iteration_count on an asynchronous operation error. This patch fixes
that omission.
Fixes:
12927835d211 ("greybus: loopback: Add asynchronous bi-directional support")
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reported-by: Mitch Tasman <tasman@leaflabs.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Cc: Alex Elder <elder@kernel.org>
Cc: Mitch Tasman <tasman@leaflabs.com>
Cc: greybus-dev@lists.linaro.org
Cc: devel@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Sat, 4 Nov 2017 11:19:49 +0000 (04:19 -0700)]
selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities
[ Upstream commit
d60ad744c9741586010d4bea286f09a063a90fbd ]
Bits 19:16 of LAR's result are undefined, and some upcoming
improvements to the test case seem to trigger this. Mask off those
bits to avoid spurious failures.
commit
5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS
segments") adds a valid case in which LAR's output doesn't quite
agree with set_thread_area()'s input. This isn't triggered in the
test as is, but it will be if we start calling set_thread_area()
with the accessed bit clear. Work around this discrepency.
I've added a Fixes tag so that -stable can pick this up if neccesary.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes:
5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS segments")
Link: http://lkml.kernel.org/r/b82f3f89c034b53580970ac865139fd8863f44e2.1509794321.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Sat, 4 Nov 2017 11:19:52 +0000 (04:19 -0700)]
selftests/x86/ldt_get: Add a few additional tests for limits
[ Upstream commit
fec8f5ae1715a01c72ad52cb2ecd8aacaf142302 ]
We weren't testing the .limit and .limit_in_pages fields very well.
Add more tests.
This addition seems to trigger the "bits 16:19 are undefined" issue
that was fixed in an earlier patch. I think that, at least on my
CPU, the high nibble of the limit ends in LAR bits 16:19.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.1509794321.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Borntraeger [Mon, 30 Oct 2017 13:38:58 +0000 (14:38 +0100)]
s390/pci: do not require AIS facility
[ Upstream commit
48070c73058be6de9c0d754d441ed7092dfc8f12 ]
As of today QEMU does not provide the AIS facility to its guest. This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.
Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulf Hansson [Wed, 8 Nov 2017 09:11:02 +0000 (10:11 +0100)]
PM / Domains: Fix genpd to deal with drivers returning 1 from ->prepare()
[ Upstream commit
5241ab40f6e742f8a1631f8826faf6dc6412b3b5 ]
During system-wide PM, genpd relies on its PM callbacks to be invoked for
all its attached devices, as to deal with powering off/on the PM domain. In
other words, genpd is not compatible with the direct_complete path, if
executed by the PM core for any of its attached devices.
However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it
does not take into account that it may return 1. Instead it treats that as
an error internally and expects the PM core to abort the prepare phase and
roll back. This leads to genpd not properly powering on/off the PM domain,
because its internal counters gets wrongly balanced.
To fix the behaviour, allow drivers to return 1 from their ->prepare()
callbacks, but let's return 0 from genpd's ->prepare() callback in such
case, as that prevents the PM core from running the direct_complete path
for the device.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason J. Herne [Tue, 7 Nov 2017 15:22:32 +0000 (10:22 -0500)]
s390: vfio-ccw: Do not attempt to free no-op, test and tic cda.
[ Upstream commit
408358b50deaf59b07c82a7bff8c7e7cce031fae ]
Because we do not make use of the cda (channel data address) for test,
no-op ccws no address translation takes place. This means cda could
contain a guest address which we do not want to attempt to free. Let's
check the command type and skip cda free when it is not needed.
For a TIC ccw, ccw->cda points to either a ccw in an existing chain or
it points to a whole new allocated chain. In either case the data will
be freed when the owning chain is freed.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Message-Id: <
1510068152-21988-1-git-send-email-jjherne@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Boshi Wang [Fri, 20 Oct 2017 08:01:03 +0000 (16:01 +0800)]
ima: fix hash algorithm initialization
[ Upstream commit
ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ]
The hash_setup function always sets the hash_setup_done flag, even
when the hash algorithm is invalid. This prevents the default hash
algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used.
This patch sets hash_setup_done flag only for valid hash algorithms.
Fixes:
e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms"
Signed-off-by: Boshi Wang <wangboshi@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Redfearn [Tue, 28 Nov 2017 15:22:20 +0000 (15:22 +0000)]
MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
commit
c8ec2041f549e7f2dee0c34d25381be6f7805f99 upstream.
Add a custom serial.h header for MIPS, allowing platforms to override
the asm-generic version if required.
The generic platform uses this header to set BASE_BAUD to 0. The
generic platform supports multiple boards, which may have different
UART clocks. Also one of the boards supported is the Boston FPGA board,
where the UART clock depends on the loaded FPGA bitfile. As such there
is no way that the generic kernel can set a compile time default
BASE_BAUD.
Commit
31cb9a8575ca ("earlycon: initialise baud field of earlycon device
structure") changed the behavior of of_setup_earlycon such that any baud
rate set in the device tree is now set in the earlycon structure. The
UART driver will then calculate a divisor based on BASE_BAUD and set it.
With MIPS generic kernels this resulted in garbage output due to the
incorrect uart clock rate being used to calculate a divisor. This
commit, combined with "serial: 8250_early: Only set divisor if valid clk
& baud" prevents the earlycon code setting a bad divisor and restores
earlycon output.
Fixes:
31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Redfearn [Wed, 22 Nov 2017 09:57:28 +0000 (09:57 +0000)]
serial: 8250_early: Only set divisor if valid clk & baud
commit
0ff3ab701963a845d52337ded7eebf2d1a14fe00 upstream.
If either uartclk or baud are 0, avoid calculating and setting a divisor
based on them since the output will almost certainly be garbage.
This also allows platforms such as the MIPS generic kernel, which has no
way to know a valid BASE_BASE for the board it is actually booted on at
compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad
divisor.
This fixes a regression caused by commit
31cb9a8575ca ("earlycon:
initialise baud field of earlycon device structure"), which changed the
behavior of of_setup_earlycon such that it sets a baud rate in the
earlycon structure where previously it was left as 0. All boards
supported by the MIPS generic kernel started outputting garbage from the
boot console due to an incorrect divisor being set.
Fixes:
31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lu Baolu [Tue, 28 Nov 2017 04:40:59 +0000 (12:40 +0800)]
USB: serial: usb_debug: add new USB device id
commit
762ff4678e89a5e3f8b2237533e04d3ef2737e78 upstream.
USB vendor id and product id for Linux USB Debug Target is added.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Sjoholm [Mon, 20 Nov 2017 18:29:32 +0000 (19:29 +0100)]
USB: serial: option: add Quectel BG96 id
commit
c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm@mac.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martijn Coenen [Mon, 13 Nov 2017 09:06:08 +0000 (10:06 +0100)]
ANDROID: binder: fix transaction leak.
commit
fb2c445277e7b0b4ffe10de8114bad4eccaca948 upstream.
If a call to put_user() fails, we failed to
properly free a transaction and send a failed
reply (if necessary).
Signed-off-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Wilson [Mon, 13 Nov 2017 19:31:31 +0000 (11:31 -0800)]
serial: 8250_pci: Add Amazon PCI serial device ID
commit
3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.html
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai-Heng Feng [Tue, 14 Nov 2017 06:31:15 +0000 (01:31 -0500)]
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
commit
e43a12f1793ae1fe006e26fe9327a8840a92233c upstream.
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("
7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Tue, 14 Nov 2017 18:27:22 +0000 (19:27 +0100)]
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
commit
7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuyang Du [Thu, 30 Nov 2017 02:22:40 +0000 (10:22 +0800)]
usbip: Fix USB device hang due to wrong enabling of scatter-gather
commit
770b2edece42fa55bbe7d4cbe53347a07b8968d4 upstream.
The previous USB3 SuperSpeed enabling patches mistakenly enabled
URB scatter-gather chaining, which is actually not supported by
the VHCI HCD. This patch fixes that.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867
Fixes:
03cd00d538a6feb ("usbip: vhci-hcd: Set the vhci structure up to work")
Reported-by: Juan Zea <juan.zea@qindel.com>
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shuah Khan [Wed, 29 Nov 2017 22:24:22 +0000 (15:24 -0700)]
usbip: fix usbip attach to find a port that matches the requested speed
commit
1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 upstream.
usbip attach fails to find a free port when the device on the first port
is a USB_SPEED_SUPER device and non-super speed device is being attached.
It keeps checking the first port and returns without a match getting stuck
in a loop.
Fix it check to find the first port with matching speed.
Reported-by: Juan Zea <juan.zea@qindel.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Mon, 11 Sep 2017 09:24:22 +0000 (11:24 +0200)]
s390/runtime instrumentation: simplify task exit handling
commit
8d9047f8b967ce6181fd824ae922978e1b055cc0 upstream.
Free data structures required for runtime instrumentation from
arch_release_task_struct(). This allows to simplify the code a bit,
and also makes the semantics a bit easier: arch_release_task_struct()
is never called from the task that is being removed.
In addition this allows to get rid of exit_thread() in a later patch.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Dänzer [Wed, 22 Nov 2017 14:55:21 +0000 (15:55 +0100)]
drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map
commit
fa7c7939b4bf112cd06ba166b739244077898990 upstream.
This matches the corresponding UAPI fields. Treating the ring index as
signed could result in accessing random unrelated memory if the MSB was
set.
Fixes:
effd924d2f3b ("drm/amdgpu: untie user ring ids from kernel ring ids v6")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Agner [Fri, 10 Nov 2017 09:15:28 +0000 (10:15 +0100)]
drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()
commit
9fd99f4f3f5e13ce959900ae57d64b1bdb51d823 upstream.
The resume helpers wait for a vblank to occurre hence IRQ need
to be enabled. This avoids a warning as follows during resume:
WARNING: CPU: 0 PID: 314 at drivers/gpu/drm/drm_atomic_helper.c:1249 drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[CRTC:28:crtc-0] vblank wait timed out
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Agner [Thu, 9 Nov 2017 14:39:56 +0000 (15:39 +0100)]
drm/fsl-dcu: avoid disabling pixel clock twice on suspend
commit
9306e996574f7f57136a62e49cd0075f85713623 upstream.
With commit
0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when
enabling CRTC") the pixel clock is controlled by the CRTC code.
Disabling the pixel clock in suspend leads to a warning due to
the second clk_disable_unprepare call:
WARNING: CPU: 0 PID: 359 at drivers/clk/clk.c:594 clk_core_disable+0x8c/0x90
Remove clk_disable_unprepare call for pixel clock to avoid
unbalanced clock disable on suspend.
Fixes:
0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when enabling CRTC")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 5 Dec 2017 10:26:38 +0000 (11:26 +0100)]
Linux 4.14.4
Greg Kroah-Hartman [Mon, 4 Dec 2017 11:59:57 +0000 (12:59 +0100)]
Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()"
This reverts commit
f9a64e23a9da528e7d8aa1bd2c7bb92be4ebb724 which is
commit
0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream.
Andy writes:
I think the thing to do is to revert the patch from -stable.
The bug it fixes is very minor, and the regression is that it
made a pre-existing bug in some nearly-undebuggable core resume
code much easier to hit. I don't feel comfortable with a
backport of the latter fix until it has a good long soak in
Linus' tree.
Reported-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Thu, 23 Nov 2017 19:41:57 +0000 (21:41 +0200)]
drm/i915: Prevent zero length "index" write
commit
56350fb8978bbf4aafe08f21234e161dd128b417 upstream.
The hardware always writes one or two bytes in the index portion of
an indexed transfer. Make sure the message we send as the index
doesn't have a zero length.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Fixes:
56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit
bb9e0d4bca50f429152e74a459160b41f3d60fb2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Thu, 23 Nov 2017 19:41:56 +0000 (21:41 +0200)]
drm/i915: Don't try indexed reads to alternate slave addresses
commit
ae5c631e605a452a5a0e73205a92810c01ed954b upstream.
We can only specify the one slave address to indexed reads/writes.
Make sure the messages we check are destined to the same slave
address before deciding to do an indexed transfer.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Fixes:
56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit
c4deb62d7821672265b87952bcd1c808f3bf3e8f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiong Zhang [Mon, 27 Nov 2017 23:29:54 +0000 (07:29 +0800)]
drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
commit
b721b65af4eb46df6a1d9e34b14003225e403565 upstream.
For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
should be 0. The current definition wrongly set bit[46] as 1
also. This path fixes this.
v2: Add commit message, fixes and cc stable.(Zhenyu)
Fixes:
2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Sat, 25 Nov 2017 19:41:55 +0000 (19:41 +0000)]
drm/i915/fbdev: Serialise early hotplug events with async fbdev config
commit
a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream.
As both the hotplug event and fbdev configuration run asynchronously, it
is possible for them to run concurrently. If configuration fails, we were
freeing the fbdev causing a use-after-free in the hotplug event.
<7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
<7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
<7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
<7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
<7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
<7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
<7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
<4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
<0>[ 3069.977453] ---------------------------------
<4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
<4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G U 4.14.0-CI-CI_DRM_3388+ #1
<4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.
1708222146 08/22/2017
<4>[ 3069.977508] Workqueue: events output_poll_execute
<4>[ 3069.977512] task:
ffff880177734e40 task.stack:
ffffc90001fe4000
<4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
<4>[ 3069.977523] RSP: 0018:
ffffc90001fe7bb0 EFLAGS:
00010002
<4>[ 3069.977526] RAX:
6b6b6b6b6b6b6b6b RBX:
0000000000000282 RCX:
0000000000000000
<4>[ 3069.977530] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff880170d4efd0
<4>[ 3069.977534] RBP:
ffffc90001fe7c70 R08:
0000000000000001 R09:
0000000000000000
<4>[ 3069.977538] R10:
0000000000000000 R11:
ffffffff81899609 R12:
ffff880170d4efd0
<4>[ 3069.977542] R13:
ffff880177734e40 R14:
0000000000000001 R15:
0000000000000000
<4>[ 3069.977547] FS:
0000000000000000(0000) GS:
ffff88017fc80000(0000) knlGS:
0000000000000000
<4>[ 3069.977551] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 3069.977555] CR2:
00007f7e8b7bcf04 CR3:
0000000003e0f000 CR4:
00000000003406e0
<4>[ 3069.977559] Call Trace:
<4>[ 3069.977565] ? mark_held_locks+0x64/0x90
<4>[ 3069.977571] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977575] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977579] ? trace_hardirqs_on_caller+0xde/0x1c0
<4>[ 3069.977583] ? _raw_spin_unlock_irq+0x2f/0x50
<4>[ 3069.977588] ? finish_task_switch+0xa5/0x210
<4>[ 3069.977592] ? lock_acquire+0xaf/0x200
<4>[ 3069.977596] lock_acquire+0xaf/0x200
<4>[ 3069.977600] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977604] _raw_spin_lock+0x2a/0x40
<4>[ 3069.977608] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977612] __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977616] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977621] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977625] drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977630] output_poll_execute+0x8d/0x180
<4>[ 3069.977635] process_one_work+0x22e/0x660
<4>[ 3069.977640] worker_thread+0x48/0x3a0
<4>[ 3069.977644] ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[ 3069.977649] kthread+0x102/0x140
<4>[ 3069.977653] ? process_one_work+0x660/0x660
<4>[ 3069.977657] ? kthread_create_on_node+0x40/0x40
<4>[ 3069.977662] ret_from_fork+0x27/0x40
<4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
<1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP:
ffffc90001fe7bb0
<4>[ 3069.977712] ---[ end trace
4ad012eb3af62df7 ]---
In order to keep the dev_priv->ifbdev alive after failure, we have to
avoid the free and leave it empty until we unload the module (which is
less than ideal, but a necessary evil for simplicity). Then we can use
intel_fbdev_sync() to serialise the hotplug event with the configuration.
The serialisation between the two was removed in commit
934458c2c95d
("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
older, commit
366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
fails")
Fixes:
366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
Fixes:
934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
(cherry picked from commit
ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Tue, 14 Nov 2017 13:55:17 +0000 (14:55 +0100)]
drm/i915: Re-register PMIC bus access notifier on runtime resume
commit
294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream.
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Reported-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
(cherry picked from commit
bedf4d79c3654921839b62246b0965ddb308b201)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Fri, 10 Nov 2017 15:03:01 +0000 (16:03 +0100)]
drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
commit
f4359cedfb43b934f38c50d1604db21333abe57b upstream.
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Reported-by: FKr <bugs-freedesktop@ubermail.me>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
(cherry picked from commit
ce30560c80dead91e98a03d90fb8791e57a9b69d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Tue, 17 Oct 2017 03:24:09 +0000 (14:24 +1100)]
md: forbid a RAID5 from having both a bitmap and a journal.
commit
230b55fa8d64007339319539f8f8e68114d08529 upstream.
Having both a bitmap and a journal is pointless.
Attempting to do so can corrupt the bitmap if the journal
replay happens before the bitmap is initialized.
Rather than try to avoid this corruption, simply
refuse to allow arrays with both a bitmap and a journal.
So:
- if raid5_run sees both are present, fail.
- if adding a bitmap finds a journal is present, fail
- if adding a journal finds a bitmap is present, fail.
Signed-off-by: NeilBrown <neilb@suse.com>
Tested-by: Joshua Kinard <kumba@gentoo.org>
Acked-by: Joshua Kinard <kumba@gentoo.org>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Neftin [Mon, 6 Nov 2017 06:31:59 +0000 (08:31 +0200)]
e1000e: fix the use of magic numbers for buffer overrun issue
commit
c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream.
This is a follow on to commit
b10effb92e27 ("fix buffer overrun while the
I219 is processing DMA transactions") to address David Laights concerns
about the use of "magic" numbers. So define masks as well as add
additional code comments to give a better understanding of what needs to
be done to avoid a buffer overrun.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Reviewed-by: Alexander H Duyck <alexander.h.duyck@intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don Hiatt [Mon, 2 Oct 2017 18:04:55 +0000 (11:04 -0700)]
IB/hfi1: Do not warn on lid conversions for OPA
commit
4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream.
On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID
is Extended. In such cases, it is okay to lose the upper 16 bits of the
LID as this information is obtained elsewhere. Do not issue a warning
when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.
[75920.148985] ------------[ cut here ]------------
[75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
[75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.
021120151325 02/11/2015
[75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75920.274934] task:
ffff88084a718000 task.stack:
ffffc9000a424000
[75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.288881] RSP: 0018:
ffffc9000a427c38 EFLAGS:
00010206
[75920.295265] RAX:
0000000000010001 RBX:
ffff8808361420e8 RCX:
ffff880837811d80
[75920.303784] RDX:
0000000000000002 RSI:
0000000000007fff RDI:
ffff880837811d80
[75920.312302] RBP:
ffffc9000a427d38 R08:
0000000000000000 R09:
ffff8808361420e8
[75920.320819] R10:
ffff88083841f0e8 R11:
ffffc9000a427da8 R12:
0000000000000001
[75920.329335] R13:
ffff880837810000 R14:
0000000000000000 R15:
ffff88084f1a4800
[75920.337849] FS:
0000000000000000(0000) GS:
ffff88085f400000(0000) knlGS:
0000000000000000
[75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[75920.354405] CR2:
00007f9e4b3d9000 CR3:
0000000001c09000 CR4:
00000000001406f0
[75920.362947] Call Trace:
[75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.378652] ? __kmalloc+0x1df/0x210
[75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core]
[75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core]
[75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core]
[75920.400777] process_one_work+0x149/0x360
[75920.405836] worker_thread+0x4d/0x3c0
[75920.410505] kthread+0x109/0x140
[75920.414681] ? rescuer_thread+0x380/0x380
[75920.419731] ? kthread_park+0x60/0x60
[75920.424406] ret_from_fork+0x25/0x30
[75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff
[75921.451269] ---[ end trace
cf26df27c9597265 ]---
Fixes:
62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Don Hiatt <don.hiatt@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don Hiatt [Mon, 2 Oct 2017 18:04:48 +0000 (11:04 -0700)]
IB/core: Do not warn on lid conversions for OPA
commit
6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream.
On OPA devices the user_mad recv_handler can receive 32Bit LIDs
(e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits
of the LID as this information is obtained elsewhere. Do not issue
a warning when calling ib_lid_be16() in this case by masking out
the upper 16Bits.
[75667.310846] ------------[ cut here ]------------
[75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad]
[75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
[75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.
021120151325 02/11/2015
[75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75667.436360] task:
ffff88084a718000 task.stack:
ffffc9000a424000
[75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad]
[75667.450090] RSP: 0018:
ffffc9000a427ce8 EFLAGS:
00010286
[75667.456508] RAX:
00000000ffffffff RBX:
ffff88085159ce80 RCX:
0000000000000000
[75667.465094] RDX:
ffff88085a47b068 RSI:
0000000000000000 RDI:
ffff88085159cf00
[75667.473668] RBP:
ffffc9000a427d38 R08:
000000000001efc0 R09:
ffff88085159ce80
[75667.482228] R10:
ffff88085f007480 R11:
ffff88084acf20e8 R12:
ffff88085a47b020
[75667.490824] R13:
ffff881056842e10 R14:
ffff881056840200 R15:
ffff88104c8d0800
[75667.499390] FS:
0000000000000000(0000) GS:
ffff88085f400000(0000) knlGS:
0000000000000000
[75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[75667.516080] CR2:
00007f9e4b3d9000 CR3:
0000000001c09000 CR4:
00000000001406f0
[75667.524664] Call Trace:
[75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core]
[75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core]
[75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core]
[75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core]
[75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core]
[75667.557766] process_one_work+0x149/0x360
[75667.562844] worker_thread+0x4d/0x3c0
[75667.567529] kthread+0x109/0x140
[75667.571713] ? rescuer_thread+0x380/0x380
[75667.576775] ? kthread_park+0x60/0x60
[75667.581447] ret_from_fork+0x25/0x30
[75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
[75667.608323] ---[ end trace
cf26df27c9597264 ]---
Fixes:
62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Don Hiatt <don.hiatt@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sandipan Das [Fri, 17 Nov 2017 23:27:28 +0000 (15:27 -0800)]
include/linux/compiler-clang.h: handle randomizable anonymous structs
commit
4ca59b14e588f873795a11cdc77a25c686a29d23 upstream.
The GCC randomize layout plugin can randomize the member offsets of
sensitive kernel data structures. To use this feature, certain
annotations and members are added to the structures which affect the
member offsets even if this plugin is not used.
All of these structures are completely randomized, except for task_struct
which leaves out some of its members. All the other members are wrapped
within an anonymous struct with the __randomize_layout attribute. This is
done using the randomized_struct_fields_start and
randomized_struct_fields_end defines.
When the plugin is disabled, the behaviour of this attribute can vary
based on the GCC version. For GCC 5.1+, this attribute maps to
__designated_init otherwise it is just an empty define but the anonymous
structure is still present. For other compilers, both
randomized_struct_fields_start and randomized_struct_fields_end default
to empty defines meaning the anonymous structure is not introduced at
all.
So, if a module compiled with Clang, such as a BPF program, needs to
access task_struct fields such as pid and comm, the offsets of these
members as recognized by Clang are different from those recognized by
modules compiled with GCC. If GCC 4.6+ is used to build the kernel,
this can be solved by introducing appropriate defines for Clang so that
the anonymous structure is seen when determining the offsets for the
members.
Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Dänzer [Wed, 22 Nov 2017 14:55:21 +0000 (15:55 +0100)]
drm/amdgpu: Set adev->vcn.irq.num_types for VCN
commit
89ce6e0afee8eafa679093207dabd717af9d09c5 upstream.
We were setting adev->uvd.irq.num_types instead.
Fixes:
9b257116e784 ("drm/amdgpu: add vcn enc irq support")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leo Liu [Tue, 21 Nov 2017 14:08:07 +0000 (09:08 -0500)]
drm/amdgpu: move UVD/VCE and VCN structure out from union
commit
b43aaee69d4327d05e7624d9471c17d015b4d67d upstream.
With the enablement of VCN Dec and Enc from user space, User space queries
kernel for the IP information, if HW has UVD/VCE, the info comes from these
IP blocks, but this could end up mis-interpret for VCN when they are in the
union, the other way same when HW with VCN block.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes:
95d0906f8506 ("drm/amdgpu: add initial vcn support and decode tests")
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Wed, 8 Nov 2017 15:25:04 +0000 (17:25 +0200)]
drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
commit
9271c0ca573e02a360b636ecd8cb408852f4e9f6 upstream.
Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.
Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Neil Kownacki <njkkow@gmail.com>
Reported-by: Neil Kownacki <njkkow@gmail.com>
Tested-by: Neil Kownacki <njkkow@gmail.com>
Fixes:
fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.com
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Fri, 10 Nov 2017 16:38:34 +0000 (17:38 +0100)]
drm/fsl-dcu: Don't set connector DPMS property
commit
daee54263c1202cbdab85c5e15ae30b417602efb upstream.
Since commit
4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.
The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.
Fixes:
4a97a3da420b ("drm: Don't update property values for atomic drivers")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Lankhorst [Tue, 28 Nov 2017 11:16:03 +0000 (12:16 +0100)]
drm/fb_helper: Disable all crtc's when initial setup fails.
commit
52dd06506e9bbc2a37b352df7dfc5468f8da21fd upstream.
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes:
ca91a2758fce ("drm/fb-helper: Support deferred setup")
Reported-by: Thomas Voegtle <tv@lio96.de>
Tested-by: Thomas Voegtle <tv@lio96.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Fri, 17 Nov 2017 08:41:16 +0000 (16:41 +0800)]
drm/amd/pp: fix typecast error in powerplay.
commit
8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream.
resulted in unexpected data truncation
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Mon, 30 Oct 2017 13:57:43 +0000 (14:57 +0100)]
drm/ttm: once more fix ttm_buffer_object_transfer
commit
4d98e5ee6084f6d7bc578c5d5f86de7156aaa4cb upstream.
When the mutex is locked just in the moment we copy it we end up with a
warning that we release a locked mutex.
Fix this by properly reinitializing the mutex.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Griffin [Tue, 15 Aug 2017 14:14:25 +0000 (15:14 +0100)]
drm/hisilicon: Ensure LDI regs are properly configured.
commit
a2f042430784d86eb2b7a6d2a869f552da30edba upstream.
This patch fixes the following soft lockup:
BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.
This state loss is caused by ade_crtc_atomic_begin() not
calling ade_ldi_set_mode(). With this patch applied
resuming from Weston idle-timeout works well.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Xinliang Liu <xinliang.liu@linaro.org>
Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Liu [Mon, 7 Aug 2017 11:55:45 +0000 (21:55 +1000)]
drm/panel: simple: Add missing panel_simple_unprepare() calls
commit
f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream.
During panel removal or system shutdown panel_simple_disable() is called
which disables the panel backlight but the panel is still powered due to
missing calls to panel_simple_unprepare().
Fixes:
d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown")
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roman Kapl [Mon, 30 Oct 2017 10:56:13 +0000 (11:56 +0100)]
drm/radeon: fix atombios on big endian
commit
4f626a4ac8f57ddabf06d03870adab91e463217f upstream.
The function for byteswapping the data send to/from atombios was buggy for
num_bytes not divisible by four. The function must be aware of the fact
that after byte-swapping the u32 units, valid bytes might end up after the
num_bytes boundary.
This patch was tested on kernel 3.12 and allowed us to sucesfully use
DisplayPort on and Radeon SI card. Namely it fixed the link training and
EDID readout.
The function is patched both in radeon and amd drivers, since the functions
and the fixes are identical.
Signed-off-by: Roman Kapl <rka@sysgo.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jyri Sarha [Thu, 12 Oct 2017 09:19:46 +0000 (12:19 +0300)]
drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
commit
ce99f7206c9105851d97202ed08c058af6f11ac4 upstream.
We need the total frame refresh time to check if we are too close to
vertical sync when updating the two framebuffer DMA registers and risk
a collision. This new method is more accurate that the previous that
based on mode's vrefresh value, which itself is inaccurate or may not
even be initialized.
Reported-by: Kevin Hao <kexin.hao@windriver.com>
Fixes:
11abbc9f39e0 ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled")
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Mon, 23 Oct 2017 15:25:40 +0000 (18:25 +0300)]
drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug
commit
a111fbc4c44d2981f1a8fef64418685be5e30280 upstream.
Since commit
632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
even drivers that don't implement accurate vblank timestamps will end
up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
time drm_crtc_arm_vblank_event() gets called. The could be as often
as every frame for each active crtc.
Considering drm_crtc_accurate_vblank_count() is never any worse than
the drm_vblank_count() we used previously, let's just skip the WARN
unless DRM_UT_VBL is enabled. That way people won't be bothered by
this unless they're debugging vblank code. And let's also change it
to WARN_ONCE() so that even when you're debugging vblank code you
won't get drowned by constant WARNs.
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: "Szyprowski, Marek" <m.szyprowski@samsung.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Reported-by: Andrzej Hajda <a.hajda@samsung.com>
Fixes:
632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171023152540.15364-1-ville.syrjala@linux.intel.com
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Tue, 10 Oct 2017 13:33:22 +0000 (16:33 +0300)]
drm/vblank: Fix flip event vblank count
commit
632c6e4edef17c40bba3be67c980d959790d142f upstream.
On machines where the vblank interrupt fires some time after the start
of vblank (or we just manage to race with the vblank interrupt handler)
we will currently stuff a stale vblank counter value into the flip event,
and thus we'll prematurely complete the flip.
Switch over to drm_crtc_accurate_vblank_count() to make sure we have an
up to date counter value, crucially also remember to add the +1 so that
the delayed vblank interrupt won't complete the flip prematurely.
Cc: Daniel Vetter <daniel@ffwll.ch>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010133322.24029-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel@ffwll.ch> #irc
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Dänzer [Fri, 3 Nov 2017 15:00:35 +0000 (16:00 +0100)]
drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list
commit
e1fc12c5d9ad06a2a74e97a91f1b0c5f4c723b50 upstream.
Fixes a use-after-free due to a race condition in
ttm_bo_cleanup_refs_and_unlock, which allows one task to reserve a BO
and destroy its ttm_resv while another task is waiting for it to signal
in reservation_object_wait_timeout_rcu.
v2:
* Always initialize bo->ttm_resv in ttm_bo_init_reserved
(Christian König)
Fixes:
0d2bd2ae045d "drm/ttm: fix memory leak while individualizing BOs"
Reviewed-by: Chunming Zhou <david1.zhou@amd.com> # v1
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>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Fri, 13 Oct 2017 15:24:31 +0000 (17:24 +0200)]
drm/amdgpu: reserve root PD while releasing it
commit
2642cf110d08a403f585a051e4cbf45a90b3adea upstream.
Otherwise somebody could try to evict it at the same time and try to use
half torn down structures.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Mon, 4 Sep 2017 19:02:45 +0000 (21:02 +0200)]
dma-buf: make reservation_object_copy_fences rcu save
commit
39e16ba16c147e662bf9fbcee9a99d70d420382f upstream.
Stop requiring that the src reservation object is locked for this operation.
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1504551766-5093-1-git-send-email-deathsimple@vodafone.de
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Mon, 4 Sep 2017 18:58:45 +0000 (20:58 +0200)]
drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
commit
378e2d5b504fe0231c557751e58b80fcf717cc20 upstream.
With shared reservation objects __ttm_bo_reserve() can easily fail even on
destroyed BOs. This prevents correct handling when we need to individualize
the reservation object.
Fix this by individualizing the object before even trying to reserve it.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ken Wang [Wed, 8 Nov 2017 06:48:50 +0000 (14:48 +0800)]
drm/amdgpu: Remove check which is not valid for certain VBIOS
commit
ab6613b7eaefe85dadfc86025e901c55d71c0379 upstream.
Fixes vbios fetching on certain headless boards.
Signed-off-by: Ken Wang <Ken.Wang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ozeng [Tue, 6 Jun 2017 15:53:28 +0000 (10:53 -0500)]
drm/amdgpu: Properly allocate VM invalidate eng v2
commit
c5066129af4436ab0da8eefe4289774a5409706d upstream.
v1: Properly allocate TLB invalidation engine to avoid conflict.
v2: Added comments to codes
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Tue, 31 Oct 2017 08:36:13 +0000 (09:36 +0100)]
drm/amdgpu: fix error handling in amdgpu_bo_do_create
commit
a695e43712242c354748e9bae5d137d4337a7694 upstream.
The bo structure is freed up in case of an error, so we can't do any
accounting if that happens.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ken Wang [Fri, 29 Sep 2017 07:41:43 +0000 (15:41 +0800)]
drm/amdgpu: correct reference clock value on vega10
commit
76d6172b6fab16455af4b67bb18a3f66011592f8 upstream.
Old value from bringup was wrong.
Signed-off-by: Ken Wang <Ken.Wang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 30 Sep 2017 08:14:13 +0000 (11:14 +0300)]
drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
commit
78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 upstream.
After commit
ea09729c9302 ("drm/amdgpu: rework page directory filling
v2") then it becomes a lot harder to verify that "r" is initialized. My
static checker complains and so I've reviewed the code. It does look
like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
at the start.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 30 Sep 2017 08:13:28 +0000 (11:13 +0300)]
drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
commit
40a9960b046290939b56ce8e51f365258f27f264 upstream.
We shifted some code around in commit
9cca0b8e5df0 ("drm/amdgpu: move
amdgpu_cs_sysvm_access_required into find_mapping") and now my static
checker complains that "r" might not be initialized at the end of the
function. I've reviewed the code, and that seems possible, but it's
also possible I may have missed something.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 14 Nov 2017 22:19:29 +0000 (17:19 -0500)]
Revert "drm/radeon: dont switch vt on suspend"
commit
18c437caa5b18a235dd65cec224eab54bebcee65 upstream.
Fixes distorted colors on some cards on resume from suspend.
This reverts commit
b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Lien [Tue, 21 Nov 2017 16:44:37 +0000 (10:44 -0600)]
nvme-pci: add quirk for delay before CHK RDY for WDC SN200
commit
8c97eeccf0ad8783c057830119467b877bdfced7 upstream.
And increase the existing delay to cover this device as well.
Signed-off-by: Jeff Lien <jeff.lien@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Rosin [Mon, 27 Nov 2017 16:31:00 +0000 (17:31 +0100)]
hwmon: (jc42) optionally try to disable the SMBUS timeout
commit
68615eb01f82256c19e41967bfb3eef902f77033 upstream.
With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver
is not always capable of avoiding the 25-35 ms timeout as specified by
the SMBUS protocol. This may cause silent corruption of the last bit of
any transfer, e.g. a one is read instead of a zero if the sensor chip
times out. This also affects the eeprom half of the nxp-se97 chip, where
this silent corruption was originally noticed. Other I2C adapters probably
suffer similar issues, e.g. bit-banging comes to mind as risky...
The SMBUS register in the nxp chip is not a standard Jedec register, but
it is not special to the nxp chips either, at least the atmel chips
have the same mechanism. Therefore, do not special case this on the
manufacturer, it is opt-in via the device property anyway.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rui Hua [Fri, 24 Nov 2017 23:14:26 +0000 (15:14 -0800)]
bcache: recover data from backing when data is clean
commit
e393aa2446150536929140739f09c6ecbcbea7f0 upstream.
When we send a read request and hit the clean data in cache device, there
is a situation called cache read race in bcache(see the commit in the tail
of cache_look_up(), the following explaination just copy from there):
The bucket we're reading from might be reused while our bio is in flight,
and we could then end up reading the wrong data. We guard against this
by checking (in bch_cache_read_endio()) if the pointer is stale again;
if so, we treat it as an error (s->iop.error = -EINTR) and reread from
the backing device (but we don't pass that error up anywhere)
It should be noted that cache read race happened under normal
circumstances, not the circumstance when SSD failed, it was counted
and shown in /sys/fs/bcache/XXX/internal/cache_read_races.
Without this patch, when we use writeback mode, we will never reread from
the backing device when cache read race happened, until the whole cache
device is clean, because the condition
(s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in
cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR)
will be passed up, at last, user will receive -EINTR when it's bio end,
this is not suitable, and wield to up-application.
In this patch, we use s->read_dirty_data to judge whether the read
request hit dirty data in cache device, it is safe to reread data from
the backing device when the read request hit clean data. This can not
only handle cache read race, but also recover data when failed read
request from cache device.
[edited by mlyle to fix up whitespace, commit log title, comment
spelling]
Fixes:
d59b23795933 ("bcache: only permit to recovery read error when cache device is clean")
Signed-off-by: Hua Rui <huarui.dev@gmail.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Coly Li [Mon, 30 Oct 2017 21:46:31 +0000 (14:46 -0700)]
bcache: only permit to recovery read error when cache device is clean
commit
d59b23795933678c9638fd20c942d2b4f3cd6185 upstream.
When bcache does read I/Os, for example in writeback or writethrough mode,
if a read request on cache device is failed, bcache will try to recovery
the request by reading from cached device. If the data on cached device is
not synced with cache device, then requester will get a stale data.
For critical storage system like database, providing stale data from
recovery may result an application level data corruption, which is
unacceptible.
With this patch, for a failed read request in writeback or writethrough
mode, recovery a recoverable read request only happens when cache device
is clean. That is to say, all data on cached device is up to update.
For other cache modes in bcache, read request will never hit
cached_dev_read_error(), they don't need this patch.
Please note, because cache mode can be switched arbitrarily in run time, a
writethrough mode might be switched from a writeback mode. Therefore
checking dc->has_data in writethrough mode still makes sense.
Changelog:
V4: Fix parens error pointed by Michael Lyle.
v3: By response from Kent Oversteet, he thinks recovering stale data is a
bug to fix, and option to permit it is unnecessary. So this version
the sysfs file is removed.
v2: rename sysfs entry from allow_stale_data_on_failure to
allow_stale_data_on_failure, and fix the confusing commit log.
v1: initial patch posted.
[small change to patch comment spelling by mlyle]
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Reported-by: Arne Wolf <awolf@lenovo.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Nix <nix@esperi.org.uk>
Cc: Kai Krakow <hurikhan77@gmail.com>
Cc: Eric Wheeler <bcache@lists.ewheeler.net>
Cc: Junhui Tang <tang.junhui@zte.com.cn>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Fri, 24 Nov 2017 23:14:25 +0000 (15:14 -0800)]
bcache: Fix building error on MIPS
commit
cf33c1ee5254c6a430bc1538232b49c3ea13e613 upstream.
This patch try to fix the building error on MIPS. The reason is MIPS
has already defined the PTR macro, which conflicts with the PTR macro
in include/uapi/linux/bcache.h.
[fixed by mlyle: corrected a line-length issue]
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vaibhav Jain [Thu, 23 Nov 2017 03:38:57 +0000 (09:08 +0530)]
cxl: Check if vphb exists before iterating over AFU devices
commit
12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes:
9e8df8a21963 ("cxl: EEH support")
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Wed, 22 Nov 2017 11:28:17 +0000 (12:28 +0100)]
i2c: i801: Fix Failed to allocate irq -
2147483648 error
commit
6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.
On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.
Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -
2147483648: -107
BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiner Kallweit [Fri, 24 Nov 2017 06:47:50 +0000 (07:47 +0100)]
eeprom: at24: check at24_read/write arguments
commit
d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream.
So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bartosz Golaszewski [Mon, 27 Nov 2017 21:06:13 +0000 (22:06 +0100)]
eeprom: at24: correctly set the size for at24mac402
commit
5478e478eee3b096b8d998d4ed445da30da2dfbc upstream.
There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down
the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6,
making it impossible to read it all.
Fix it by manually adjusting the value in probe().
This patch contains a temporary fix that is suitable for stable
branches. Eventually we'll probably remove the call to ilog2() while
converting the magic values to actual structs.
Fixes:
0b813658c115 ("eeprom: at24: add support for at24mac series")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiner Kallweit [Mon, 27 Nov 2017 19:46:22 +0000 (20:46 +0100)]
eeprom: at24: fix reading from 24MAC402/24MAC602
commit
644a1f19c6c8393d0c4168a5adf79056da6822eb upstream.
Chip datasheet mentions that word addresses other than the actual
start position of the MAC delivers undefined results. So fix this.
Current implementation doesn't work due to this wrong offset.
Fixes:
0b813658c115 ("eeprom: at24: add support for at24mac series")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Tue, 26 Sep 2017 08:54:09 +0000 (16:54 +0800)]
ACPI / EC: Fix regression related to PM ops support in ECDT device
commit
a64a62ce9a380213dc9e192f762266d70c9b40ec upstream.
On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
ACPI device. Thus the following commit actually removed post-resume
acpi_ec_enable_event() invocation for such platforms, and triggered a
regression on them that after being resumed, EC (actually should be ECDT)
driver stops handling EC events:
Commit:
c2b46d679b30c5c0d7eb47a21085943242bdd8dc
Subject: ACPI / EC: Add PM operations to improve event handling for resume process
Notice that the root cause actually is "ECDT is not an ACPI device" rather
than "the timing of acpi_ec_enable_event() invocation", this patch fixes
this issue by enumerating ECDT EC as an ACPI device. Due to the existence
of the noirq stage, the ability of tuning the timing of
acpi_ec_enable_event() invocation is still meaningful.
This patch is a little bit different from the posted fix by moving
acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
sure that EC event handling won't be stopped as long as the ACPI EC driver
is bound. Thus the following sequence shouldn't disable EC event handling:
unbind,suspend,resume,bind.
Fixes:
c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847
Reported-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bastian Stender [Tue, 28 Nov 2017 08:24:07 +0000 (09:24 +0100)]
mmc: core: prepend 0x to OCR entry in sysfs
commit
c892b0d81705c566f575e489efc3c50762db1bde upstream.
The sysfs entry "ocr" was missing the 0x prefix to identify it as hex
formatted.
Fixes:
5fb06af7a33b ("mmc: core: Extend sysfs with OCR register")
Signed-off-by: Bastian Stender <bst@pengutronix.de>
[Ulf: Amended change to also cover SD-cards]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>