Niklas Cassel [Mon, 19 Feb 2018 17:11:13 +0000 (18:11 +0100)]
net: stmmac: call correct function in stmmac_mac_config_rx_queues_routing()
[ Upstream commit
13138de01400762f706c5e956e70660770d61962 ]
stmmac_mac_config_rx_queues_routing() incorrectly calls rx_queue_prio()
instead of rx_queue_routing().
This looks like a copy paste issue, since
stmmac_mac_config_rx_queues_prio() already calls rx_queue_prio(),
and both stmmac_mac_config_rx_queues_routing() and
stmmac_mac_config_rx_queues_prio() are very similar in structure.
Fixes:
abe80fdc6ee6 ("net: stmmac: RX queue routing configuration")
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Guy Briggs [Wed, 21 Feb 2018 09:30:07 +0000 (04:30 -0500)]
audit: return on memory error to avoid null pointer dereference
[ Upstream commit
23138ead270045f1b3e912e667967b6094244999 ]
If there is a memory allocation error when trying to change an audit
kernel feature value, the ignored allocation error will trigger a NULL
pointer dereference oops on subsequent use of that pointer. Return
instead.
Passes audit-testsuite.
See: https://github.com/linux-audit/audit-kernel/issues/76
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
[PM: not necessary (other funcs check for NULL), but a good practice]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Wed, 21 Feb 2018 12:24:16 +0000 (13:24 +0100)]
PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
[ Upstream commit
dbdd0f58fd2cdde5cf945c9da67a2d52d32ba550 ]
There is a problem with PCMCIA system resume callbacks with respect
to suspend-to-idle in which the ->suspend_noirq() callback may be
invoked after the ->resume_noirq() one without resuming the system
entirely in some cases. This doesn't work for PCMCIA because of
the lack of symmetry between its system suspend and system resume
"noirq" callbacks.
The system resume handling in PCMCIA is split between
socket_early_resume() and socket_late_resume() which are called in
different phases of system resume and both need to run for
socket_suspend() (invoked by the system suspend "noirq" callback)
to work. Specifically, socket_suspend() returns an error when
called after socket_early_resume() without socket_late_resume(),
so if the suspend-to-idle core detects a spurious wakeup event and
attempts to put the system back to sleep, that is aborted by the
error coming from socket_suspend().
Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
to indicate that socket_early_resume() has already run for the
socket in which case socket_suspend() will do minimum handling
and return 0.
This change has been tested on my venerable Toshiba Portege R500
(which is where the problem has been discovered in the first place),
but admittedly I have no PCMCIA cards to test along with the socket
itself.
Fixes:
33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[linux@dominikbrodowski.net: follow same codepaths for both suspend variants; call ->suspend()]
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Henry Zhang [Thu, 18 Jan 2018 02:41:33 +0000 (18:41 -0800)]
ARM: dts: bcm283x: Fix pin function of JTAG pins
[ Upstream commit
1a012cb2569f2031b3636232c3ab21c20c92d281 ]
BCM2835 ARM Peripherals doc shows gpio pins 4, 5, 6, 12 and 13
carry altenate function, ALT5 for ARM JTAG
Fixes:
21ff843931b2 ("ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.")
Signed-off-by: Henry Zhang <henryzhang62@gmail.com>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Wahren [Fri, 16 Feb 2018 10:55:34 +0000 (11:55 +0100)]
ARM: dts: bcm283x: Fix probing of bcm2835-i2s
[ Upstream commit
79c81facdc0b43b1cef37b8d5689a8c8b78f8be0 ]
Since
517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
the bcm2835-i2s requires a clock as DT property. Unfortunately
the necessary DT change has never been applied. While we are at it
also fix the first PCM register range to cover the PCM_GRAY register.
Fixes:
517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ladislav Michl [Thu, 22 Feb 2018 17:21:36 +0000 (18:21 +0100)]
power: supply: ltc2941-battery-gauge: Fix temperature units
[ Upstream commit
dde5953f05a89eb63a0d666ffe51d447b2ac3e05 ]
Temperature is measured in tenths of degree Celsius.
Fixes:
085bc24d1553 ("Add LTC2941/LTC2943 Battery Gauge Driver")
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Sat, 24 Feb 2018 19:41:45 +0000 (22:41 +0300)]
sh_eth: fix TSU init on SH7734/R8A7740
[ Upstream commit
a94cf2a614f8bc5b2b33c708626ce695bf71e424 ]
It appears that the single port Ether controllers having TSU (like SH7734/
R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100
currently has -- they also don't have the TSU registers related e.g. to
passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port'
flag and use it as a new criterion for taking a "short path" in the TSU
init sequence in order to avoid writing to the non-existent registers...
Fixes:
f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
Fixes:
73a0d907301e ("net: sh_eth: add support R8A7740")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jacob Keller [Mon, 29 Jan 2018 23:57:48 +0000 (15:57 -0800)]
ixgbe: prevent ptp_rx_hang from running when in FILTER_ALL mode
[ Upstream commit
6704a3abf4cf4181a1ee64f5db4969347b88ca1d ]
On hardware which supports timestamping all packets, the timestamps are
recorded in the packet buffer, and the driver no longer uses or reads
the registers. This makes the logic for checking and clearing Rx
timestamp hangs meaningless.
If we run the ixgbe_ptp_rx_hang() function in this case, then the driver
will continuously spam the log output with "Clearing Rx timestamp hang".
These messages are spurious, and confusing to end users.
The original code in commit
a9763f3cb54c ("ixgbe: Update PTP to support
X550EM_x devices", 2015-12-03) did have a flag PTP_RX_TIMESTAMP_IN_REGISTER
which was intended to be used to avoid the Rx timestamp hang check,
however it did not actually check the flag before calling the function.
Do so now in order to stop the checks and prevent the spurious log
messages.
Fixes:
a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices", 2015-12-03)
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 22 Feb 2018 09:39:52 +0000 (10:39 +0100)]
udf: Provide saner default for invalid uid / gid
[ Upstream commit
116e5258e4115aca0c64ac0bf40ded3b353ed626 ]
Currently when UDF filesystem is recorded without uid / gid (ids are set
to -1), we will assign INVALID_[UG]ID to vfs inode unless user uses uid=
and gid= mount options. In such case filesystem could not be modified in
any way as VFS refuses to modify files with invalid ids (even by root).
This is confusing to users and not very useful default since such media
mode is generally used for removable media. Use overflow[ug]id instead
so that at least root can modify the filesystem.
Reported-by: Steve Kenton <skenton@ou.edu>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Vincent-Cross [Tue, 27 Feb 2018 09:20:36 +0000 (20:20 +1100)]
PCI: Add function 1 DMA alias quirk for Marvell 88SE9220
[ Upstream commit
832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]
Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Signed-off-by: Thomas Vincent-Cross <me@tvc.id.au>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Madalin Bucur [Mon, 26 Feb 2018 17:24:01 +0000 (11:24 -0600)]
dpaa_eth: fix SG mapping
[ Upstream commit
120d75ecf043044554abbba8507f6d22e4715beb ]
An issue in the code mapping the skb fragments into
scatter-gather frames was evidentiated by netperf
TCP_SENDFILE tests. The size was set wrong for all
fragments but the first, affecting the transmission
of any skb with more than one fragment.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Viresh Kumar [Thu, 22 Feb 2018 05:59:43 +0000 (11:29 +0530)]
cpufreq: Reorder cpufreq_online() error code path
[ Upstream commit
b24b6478e65f140610ab1ffaadc7bc6bf0be8aad ]
Ideally the de-allocation of resources should happen in the exact
opposite order in which they were allocated. It helps maintain the code
in long term, even if nothing really breaks with incorrect ordering.
That wasn't followed in cpufreq_online() and it has some
inconsistencies. For example, the symlinks were created from within
the locked region while they are removed only after putting the locks.
Also ->exit() should have been called only after the symlinks are
removed and the lock is dropped, as that was the case when ->init()
was first called.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niklas Cassel [Mon, 26 Feb 2018 21:47:06 +0000 (22:47 +0100)]
net: stmmac: ensure that the MSS desc is the last desc to set the own bit
[ Upstream commit
15d2ee42a3087089e73ad52fd8c1b37ab496b87c ]
A dma_wmb() is used to guarantee the ordering, with respect to
other writes, to cache coherent DMA memory.
There is a dma_wmb() in prepare_tx_desc()/prepare_tso_tx_desc() which
ensures that TDES0/1/2 is written before TDES3 (which contains the own
bit), for First Desc.
However, in the rare case that MSS changes, there will be a MSS
context descriptor in front of the regular DMA descriptors:
<MSS desc> <- DMA Next Descriptor
<First Desc>
<desc n>
<Last Desc>
Thus, for this special case, we need a dma_wmb()
after prepare_tso_tx_desc()/before writing the own bit to the MSS desc,
so that we flush the write to TDES3 for First Desc,
in order to ensure that the MSS descriptor is the last descriptor to
set the own bit.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niklas Cassel [Mon, 26 Feb 2018 21:47:08 +0000 (22:47 +0100)]
net: stmmac: ensure that the device has released ownership before reading data
[ Upstream commit
a6b25da5e7ba212af5826a662e6a035a79bffabd ]
According to Documentation/memory-barriers.txt, we need to use a
dma_rmb() after reading the status/own bit, to ensure that all
descriptor fields are read after reading the own bit.
This way, we ensure that the DMA engine is done with the DMA
descriptor before we read the other descriptor fields, e.g. reading
the tx hardware timestamp (if PTP is enabled).
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Monk Liu [Tue, 23 Jan 2018 10:26:20 +0000 (18:26 +0800)]
drm/amdgpu: adjust timeout for ib_ring_tests(v2)
[ Upstream commit
dbf797655a43c6318ebb90b899e6583fcadc6472 ]
issue:
sometime GFX/MM ib test hit timeout under SRIOV env, root cause
is that engine doesn't come back soon enough so the current
IB test considered as timed out.
fix:
for SRIOV GFX IB test wait time need to be expanded a lot during
SRIOV runtimei mode since it couldn't really begin before GFX engine
come back.
for SRIOV MM IB test it always need more time since MM scheduling
is not go together with GFX engine, it is controled by h/w MM
scheduler so no matter runtime or exclusive mode MM IB test
always need more time.
v2:
use ring type instead of idx to judge
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Monk Liu [Mon, 29 Jan 2018 11:24:32 +0000 (19:24 +0800)]
drm/amdgpu: disable GFX ring and disable PQ wptr in hw_fini
[ Upstream commit
9f0178fb67699992d38601cb923b434f9986dd68 ]
otherwise there will be DMAR reading error comes out from CP since
GFX is still alive and CPC's WPTR_POLL is still enabled, which would
lead to DMAR read error.
fix:
we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ
stil need to be alive to let RLCV invoke, but its WPTR_POLL could
be disabled.
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ravikumar Kattekola [Tue, 6 Feb 2018 12:58:02 +0000 (18:28 +0530)]
ARM: dts: dra71-evm: Correct evm_sd regulator max voltage
[ Upstream commit
f4aa1bd5b4fc80f5f4ecd184caad832fd62c25f7 ]
Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V
Fixes:
9868bc585ae2 ("ARM: dts: Add support for dra718-evm")
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Sun, 11 Feb 2018 13:07:44 +0000 (15:07 +0200)]
drm: omapdrm: dss: Move initialization code from component bind to probe
[ Upstream commit
215003b4ae1d47035092fef73b6a22aa82037091 ]
There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.
This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.
The bind handler performs the following sequence of PM operations:
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
... (access the hardware to read the device revision) ...
pm_runtime_put_sync(dev);
If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.
To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.
The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.
To fix this, move the initialization code from the bind handler to the
probe handler.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinivas Kandagatla [Thu, 15 Feb 2018 12:25:09 +0000 (12:25 +0000)]
dmaengine: qcom: bam_dma: get num-channels and num-ees from dt
[ Upstream commit
48d163b1aa6e7f650c0b7a4f9c61c387a6def868 ]
When Linux is master of BAM, it can directly read registers to know number
of supported channels, however when its remotely controlled reading these
registers would trigger a crash if the BAM is not yet initialized or
powered up on the remote side.
This patch allows driver to read num-channels and num-ees from Device Tree
for remotely controlled BAM.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cornelia Huck [Thu, 22 Feb 2018 14:35:43 +0000 (15:35 +0100)]
vfio-ccw: fence off transport mode
[ Upstream commit
9851bc77e62499957567e7c39a5beba7d6de6296 ]
vfio-ccw only supports command mode for channel programs, not transport
mode. User space is supposed to already take care of that and pass us
command-mode ORBs only, but better make sure and return an error to
the caller instead of trying to process tcws as ccws.
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Acked-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Niklas Cassel [Thu, 22 Feb 2018 15:22:46 +0000 (16:22 +0100)]
pinctrl: artpec6: dt: add missing pin group uart5nocts
[ Upstream commit
7e065fb9ccce89fe667fdbd9a177eaec59a359fc ]
Add missing pin group uart5nocts (all pins except cts), which has been
supported by the artpec6 pinctrl driver since its initial submission.
Fixes:
00df0582eab1 ("pinctrl: Add pincontrol driver for ARTPEC-6 SoC")
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Fitzgerald [Wed, 28 Feb 2018 15:53:06 +0000 (15:53 +0000)]
pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs
[ Upstream commit
b89405b6102fcc3746f43697b826028caa94c823 ]
When dt_to_map_one_config() is called with a pinctrl_dev passed
in, it should only be using this if the node being looked up
is a hog. The code was always using the passed pinctrl_dev
without checking whether the dt node referred to it.
A pin controller can have pinctrl-n dependencies on other pin
controllers in these cases:
- the pin controller hardware is external, for example I2C, so
needs other pin controller(s) to be setup to communicate with
the hardware device.
- it is a child of a composite MFD so its of_node is shared with
the parent MFD and other children of that MFD. Any part of that
MFD could have dependencies on other pin controllers.
Because of this, dt_to_map_one_config() can't assume that if it
has a pinctrl_dev passed in then the node it looks up must be
a hog. It could be a reference to some other pin controller.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lionel.debieve@st.com [Thu, 15 Feb 2018 13:03:08 +0000 (14:03 +0100)]
hwrng: stm32 - add reset during probe
[ Upstream commit
326ed382256475aa4b8b7eae8a2f60689fd25e78 ]
Avoid issue when probing the RNG without
reset if bad status has been detected previously
Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Sat, 10 Feb 2018 10:17:27 +0000 (13:17 +0300)]
watchdog: asm9260_wdt: fix error handling in asm9260_wdt_probe()
[ Upstream commit
3c829f47e33eb0398a9a14e357a05199a7be0277 ]
If devm_reset_control_get_exclusive() fails, asm9260_wdt_probe()
returns immediately. But clks has been already enabled at that point,
so it is required to disable them or to move the code around.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Govindarajulu Varadarajan [Thu, 1 Mar 2018 19:07:23 +0000 (11:07 -0800)]
enic: enable rq before updating rq descriptors
[ Upstream commit
e8588e268509292550634d9a35f2723a207683b2 ]
rq should be enabled before posting the buffers to rq desc. If not hw sees
stale value and casuses DMAR errors.
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Fri, 2 Feb 2018 10:05:15 +0000 (19:05 +0900)]
dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()
[ Upstream commit
3e081628d510b2ddbe493371d9c574d9275da17e ]
This patch fixes an issue that a race condition happens between a client
driver and the rcar-dmac driver:
- The rcar_dmac_isr_transfer_end() is called.
- The done list appears, and desc.running is the next active list.
- rcar_dmac_chan_get_residue() is called by a client driver before
rcar_dmac_isr_channel_thread() is called.
- The rcar_dmac_chan_get_residue() will not find any descriptors.
- And, the following WARNING happens:
WARN(1, "No descriptor for cookie!");
The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this
situation.
So, this patch checks the done lists in rcar_dmac_chan_get_residue()
and returns zero if the done lists has the argument cookie.
Tested-by: Nguyen Viet Dung <dung.nguyen.aj@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qi Hou [Tue, 6 Mar 2018 01:13:37 +0000 (09:13 +0800)]
dmaengine: pl330: fix a race condition in case of threaded irqs
[ Upstream commit
a3ca831249ca8c4c226e4ceafee04e280152e59d ]
When booting up with "threadirqs" in command line, all irq handlers of the DMA
controller pl330 will be threaded forcedly. These threads will race for the same
list, pl330->req_done.
Before the callback, the spinlock was released. And after it, the spinlock was
taken. This opened an race window where another threaded irq handler could steal
the spinlock and be permitted to delete entries of the list, pl330->req_done.
If the later deleted an entry that was still referred to by the former, there would
be a kernel panic when the former was scheduled and tried to get the next sibling
of the deleted entry.
The scenario could be depicted as below:
Thread: T1 pl330->req_done Thread: T2
| | |
| -A-B-C-D- |
Locked | |
| | Waiting
Del A | |
| -B-C-D- |
Unlocked | |
| | Locked
Waiting | |
| | Del B
| | |
| -C-D- Unlocked
Waiting | |
|
Locked
|
get C via B
\
- Kernel panic
The kernel panic looked like as below:
Unable to handle kernel paging request at virtual address
dead000000000108
pgd =
ffffff8008c9e000
[
dead000000000108] *pgd=
000000027fffe003, *pud=
000000027fffe003, *pmd=
0000000000000000
Internal error: Oops:
96000044 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 85 Comm: irq/59-
66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2
Hardware name: Broadcom NS2 SVK (DT)
task:
ffffffc1f5cc3c00 task.stack:
ffffffc1f5ce0000
PC is at pl330_irq_handler+0x27c/0x390
LR is at pl330_irq_handler+0x2a8/0x390
pc : [<
ffffff80084cb694>] lr : [<
ffffff80084cb6c0>] pstate:
800001c5
sp :
ffffffc1f5ce3d00
x29:
ffffffc1f5ce3d00 x28:
0000000000000140
x27:
ffffffc1f5c530b0 x26:
dead000000000100
x25:
dead000000000200 x24:
0000000000418958
x23:
0000000000000001 x22:
ffffffc1f5ccd668
x21:
ffffffc1f5ccd590 x20:
ffffffc1f5ccd418
x19:
dead000000000060 x18:
0000000000000001
x17:
0000000000000007 x16:
0000000000000001
x15:
ffffffffffffffff x14:
ffffffffffffffff
x13:
ffffffffffffffff x12:
0000000000000000
x11:
0000000000000001 x10:
0000000000000840
x9 :
ffffffc1f5ce0000 x8 :
ffffffc1f5cc3338
x7 :
ffffff8008ce2020 x6 :
0000000000000000
x5 :
0000000000000000 x4 :
0000000000000001
x3 :
dead000000000200 x2 :
dead000000000100
x1 :
0000000000000140 x0 :
ffffffc1f5ccd590
Process irq/59-
66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020)
Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000)
3d00:
ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600
3d20:
ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998
3d40:
ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000
3d60:
ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0
3d80:
ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001
3da0:
ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8
3dc0:
ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00
3de0:
ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000
3e00:
0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68
3e20:
0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80
3e40:
0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648
3e60:
ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00
3e80:
ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90
3ea0:
0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0
3ec0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3ee0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f00:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f20:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f40:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f60:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f80:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fa0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fc0:
0000000000000000 0000000000000005 0000000000000000 0000000000000000
3fe0:
0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8
Call trace:
Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60)
3b20:
dead000000000060 0000008000000000
3b40:
ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88
3b60:
ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4
3b80:
00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc
3ba0:
0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000
3bc0:
0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140
3be0:
dead000000000100 dead000000000200 0000000000000001 0000000000000000
3c00:
0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000
3c20:
0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff
3c40:
ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007
[<
ffffff80084cb694>] pl330_irq_handler+0x27c/0x390
[<
ffffff80080f09d0>] irq_forced_thread_fn+0x38/0x88
[<
ffffff80080f0d70>] irq_thread+0x140/0x200
[<
ffffff80080bf4f8>] kthread+0xd8/0xf0
[<
ffffff8008083690>] ret_from_fork+0x10/0x40
Code:
f2a00838 f9405763 aa1c03e1 aa1503e0 (
f9000443)
---[ end trace
f50005726d31199c ]---
Kernel panic - not syncing: Fatal exception in interrupt
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-1
Kernel Offset: disabled
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception in interrupt
To fix this, re-start with the list-head after dropping the lock then
re-takeing it.
Reviewed-by: Frank Mori Hess <fmh6jj@gmail.com>
Tested-by: Frank Mori Hess <fmh6jj@gmail.com>
Signed-off-by: Qi Hou <qi.hou@windriver.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Tue, 6 Mar 2018 04:07:13 +0000 (12:07 +0800)]
block: null_blk: fix 'Invalid parameters' when loading module
[ Upstream commit
66231ad3e2886ba99fbf440cea44cab547e5163f ]
On ARM64, the default page size has been 64K on some distributions, and
we should allow ARM64 people to play null_blk.
This patch fixes the issue by extend page bitmap size for supporting
other non-4KB PAGE_SIZE.
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: Shaohua Li <shli@kernel.org>
Cc: Kyungchan Koh <kkc6196@fb.com>,
Cc: weiping zhang <zhangweiping@didichuxing.com>
Cc: Yi Zhang <yi.zhang@redhat.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dexuan Cui [Mon, 5 Mar 2018 05:17:14 +0000 (22:17 -0700)]
tools: hv: fix compiler warnings about major/target_fname
[ Upstream commit
1330fc35327f3ecdfa1aa645e7321ced7349b2cd ]
This patch fixes the below warnings with new glibc and gcc:
hv_vss_daemon.c:100:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is currently
defined by <sys/types.h> as well, but we plan to remove this soon.
To use "major", include <sys/sysmacros.h> directly.
hv_fcopy_daemon.c:42:2: note: 'snprintf' output between 2 and 1040
bytes into a destination of size 260
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Mon, 5 Mar 2018 10:17:02 +0000 (11:17 +0100)]
drm/bridge: sii902x: Retry status read after DDI I2C
[ Upstream commit
2e7a66a8b5ebf1b04a866e5d7c981640f7f62934 ]
The following happens when connection a DVI output driven
from the SiI9022 using a DVI-to-VGA adapter plug:
i2c i2c-0: sendbytes: NAK bailout.
i2c i2c-0: sendbytes: NAK bailout.
Then no picture. Apparently the I2C engine inside the SiI9022
is not smart enough to try to fall back to DDC I2C. Or the
vendor have not integrated the electronics properly. I don't
know which one it is.
After this, the I2C bus seems stalled and the first attempt to
read the status register fails, and the code returns with
negative return value, and the display fails to initialized.
Instead, retry status readout five times and continue even
if this fails.
Tested on the ARM Versatile Express with a DVI-to-VGA
connector, it now gives picture.
Introduce a helper struct device *dev variable to make
the code more readable.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305101702.13441-1-linus.walleij@linaro.org
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vivek Gautam [Tue, 16 Jan 2018 10:56:56 +0000 (16:26 +0530)]
phy: qcom-qmp: Fix phy pipe clock gating
[ Upstream commit
f8ba22a39e985c93e278709b1d5f20857a26b49b ]
Pipe clock comes out of the phy and is available as long as
the phy is turned on. Clock controller fails to gate this
clock after the phy is turned off and generates a warning.
/ # [ 33.048561] gcc_usb3_phy_pipe_clk status stuck at 'on'
[ 33.048585] ------------[ cut here ]------------
[ 33.052621] WARNING: CPU: 1 PID: 18 at ../drivers/clk/qcom/clk-branch.c:97 clk_branch_wait+0xf0/0x108
[ 33.057384] Modules linked in:
[ 33.066497] CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G W 4.12.0-rc7-00024-gfe926e34c36d-dirty #96
[ 33.069451] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
...
[ 33.278565] [<
ffff00000849b27c>] clk_branch_wait+0xf0/0x108
[ 33.286375] [<
ffff00000849b2f4>] clk_branch2_disable+0x28/0x34
[ 33.291761] [<
ffff0000084868dc>] clk_core_disable+0x5c/0x88
[ 33.297660] [<
ffff000008487d68>] clk_core_disable_lock+0x20/0x34
[ 33.303129] [<
ffff000008487d98>] clk_disable+0x1c/0x24
[ 33.309384] [<
ffff0000083ccd78>] qcom_qmp_phy_poweroff+0x20/0x48
[ 33.314328] [<
ffff0000083c53f4>] phy_power_off+0x80/0xdc
[ 33.320492] [<
ffff00000875c950>] dwc3_core_exit+0x94/0xa0
[ 33.325784] [<
ffff00000875c9ac>] dwc3_suspend_common+0x50/0x60
[ 33.331080] [<
ffff00000875ca04>] dwc3_runtime_suspend+0x48/0x6c
[ 33.336810] [<
ffff0000085b82f4>] pm_generic_runtime_suspend+0x28/0x38
[ 33.342627] [<
ffff0000085bace0>] __rpm_callback+0x150/0x254
[ 33.349222] [<
ffff0000085bae08>] rpm_callback+0x24/0x78
[ 33.354604] [<
ffff0000085b9fd8>] rpm_suspend+0xe0/0x4e4
[ 33.359813] [<
ffff0000085bb784>] pm_runtime_work+0xdc/0xf0
[ 33.365028] [<
ffff0000080d7b30>] process_one_work+0x12c/0x28c
[ 33.370576] [<
ffff0000080d7ce8>] worker_thread+0x58/0x3b8
[ 33.376393] [<
ffff0000080dd4a8>] kthread+0x100/0x12c
[ 33.381776] [<
ffff0000080836c0>] ret_from_fork+0x10/0x50
Fix this by disabling it as the first thing in phy_exit().
Fixes:
e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 8 Mar 2018 07:26:48 +0000 (08:26 +0100)]
ALSA: vmaster: Propagate slave error
[ Upstream commit
2e2c177ca84aff092c3c96714b0f6a12900f3946 ]
In slave_update() of vmaster code ignores the error from the slave
get() callback and copies the values. It's not only about the missing
error code but also that this may potentially lead to a leak of
uninitialized variables when the slave get() don't clear them.
This patch fixes slave_update() not to copy the potentially
uninitialized values when an error is returned from the slave get()
callback, and to propagate the error value properly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Thu, 11 Jan 2018 02:40:26 +0000 (10:40 +0800)]
phy: rockchip-emmc: retry calpad busy trimming
[ Upstream commit
a4781c2a74b249cad814ceea7272997bbd20051e ]
It turns out that 5us isn't enough for all cases, so let's
retry some more times to wait for caldone.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Gorinov [Wed, 7 Mar 2018 19:46:53 +0000 (11:46 -0800)]
x86/devicetree: Fix device IRQ settings in DT
[ Upstream commit
0a5169add90e43ab45ab1ba34223b8583fcaf675 ]
IRQ parameters for the SoC devices connected directly to I/O APIC lines
(without PCI IRQ routing) may be specified in the Device Tree.
Called from DT IRQ parser, irq_create_fwspec_mapping() calls
irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.
But x86-specific DT IRQ allocation code casts @arg to of_phandle_args
structure pointer and crashes trying to read the IRQ parameters. The
function was not converted when the mapping descriptor was changed to
irq_fwspec in the generic irqdomain code.
Fixes:
11e4438ee330 ("irqdomain: Introduce a firmware-specific IRQ specifier structure")
Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lkml.kernel.org/r/a234dee27ea60ce76141872da0d6bdb378b2a9ee.1520450752.git.ivan.gorinov@intel.com
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Gorinov [Wed, 7 Mar 2018 19:46:29 +0000 (11:46 -0800)]
x86/devicetree: Initialize device tree before using it
[ Upstream commit
628df9dc5ad886b0a9b33c75a7b09710eb859ca1 ]
Commit
08d53aa58cb1 added CRC32 calculation in early_init_dt_verify() and
checking in late initcall of_fdt_raw_init(), making early_init_dt_verify()
mandatory.
The required call to early_init_dt_verify() was not added to the
x86-specific implementation, causing failure to create the sysfs entry in
of_fdt_raw_init().
Fixes:
08d53aa58cb1 ("of/fdt: export fdt blob as /sys/firmware/fdt")
Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: https://lkml.kernel.org/r/c8c7e941efc63b5d25ebf9b6350b0f3df38f6098.1520450752.git.ivan.gorinov@intel.com
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Gruenbacher [Tue, 20 Feb 2018 15:03:24 +0000 (08:03 -0700)]
gfs2: Fix fallocate chunk size
[ Upstream commit
174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ]
The chunk size of allocations in __gfs2_fallocate is calculated
incorrectly. The size can collapse, causing __gfs2_fallocate to
allocate one block at a time, which is very inefficient. This needs
fixing in two places:
In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate
that there is no quota limit. This fixes callers that rely on
ap->allowed to be set even when quotas are off.
In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the
loop to make sure that allocation limits from one resource group won't
spill over into another resource group.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Andersson [Wed, 28 Feb 2018 00:45:25 +0000 (16:45 -0800)]
soc: qcom: wcnss_ctrl: Fix increment in NV upload
[ Upstream commit
90c29ed7627b6b4aeb603ee197650173c8434512 ]
hdr.len includes both the size of the header and the fragment, so using
this when stepping through the firmware causes us to skip 16 bytes every
chunk of 3072 bytes; causing only the first fragment to actually be
valid data.
Instead use fragment size steps through the firmware blob.
Fixes:
ea7a1f275cf0 ("soc: qcom: Introduce WCNSS_CTRL SMD client")
Reported-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Lin [Tue, 23 Jan 2018 07:36:18 +0000 (09:36 +0200)]
arm64: dts: qcom: Fix SPI5 config on MSM8996
[ Upstream commit
e723795c702b52cfceb3bb3faa63059eb4658313 ]
Set correct clocks and interrupt values.
Fixes the incorrect SPI master configuration. This is
mandatory to make the SPI5 interface functional.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kan Liang [Mon, 12 Feb 2018 22:20:31 +0000 (14:20 -0800)]
perf/x86/intel: Fix event update for auto-reload
[ Upstream commit
d31fc13fdcb20e1c317f9a7dd6273c18fbd58308 ]
There is a bug when reading event->count with large PEBS enabled.
Here is an example:
# ./read_count
0x71f0
0x122c0
0x1000000001c54
0x100000001257d
0x200000000bdc5
In fixed period mode, the auto-reload mechanism could be enabled for
PEBS events, but the calculation of event->count does not take the
auto-reload values into account.
Anyone who reads event->count will get the wrong result, e.g x86_pmu_read().
This bug was introduced with the auto-reload mechanism enabled since
commit:
851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible")
Introduce intel_pmu_save_and_restart_reload() to calculate the
event->count only for auto-reload.
Since the counter increments a negative counter value and overflows on
the sign switch, giving the interval:
[-period, 0]
the difference between two consequtive reads is:
A) value2 - value1;
when no overflows have happened in between,
B) (0 - value1) + (value2 - (-period));
when one overflow happened in between,
C) (0 - value1) + (n - 1) * (period) + (value2 - (-period));
when @n overflows happened in between.
Here A) is the obvious difference, B) is the extension to the discrete
interval, where the first term is to the top of the interval and the
second term is from the bottom of the next interval and C) the extension
to multiple intervals, where the middle term is the whole intervals
covered.
The equation for all cases is:
value2 - value1 + n * period
Previously the event->count is updated right before the sample output.
But for case A, there is no PEBS record ready. It needs to be specially
handled.
Remove the auto-reload code from x86_perf_event_set_period() since
we'll not longer call that function in this case.
Based-on-code-from: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Fixes:
851559e35fd5 ("perf/x86/intel: Use the PEBS auto reload mechanism when possible")
Link: http://lkml.kernel.org/r/1518474035-21006-2-git-send-email-kan.liang@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kan Liang [Thu, 1 Mar 2018 17:54:54 +0000 (12:54 -0500)]
perf/x86/intel: Fix large period handling on Broadwell CPUs
[ Upstream commit
f605cfca8c39ffa2b98c06d2b9f30ba64f1e54e3 ]
Large fixed period values could be truncated on Broadwell, for example:
perf record -e cycles -c
10000000000
Here the fixed period is 0x2540BE400, but the period which finally applied is
0x540BE400 - which is wrong.
The reason is that x86_pmu::limit_period() uses an u32 parameter, so the
high 32 bits of 'period' get truncated.
This bug was introduced in:
commit
294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
It's safe to use u64 instead of u32:
- Although the 'left' is s64, the value of 'left' must be positive when
calling limit_period().
- bdw_limit_period() only modifies the lowest 6 bits, it doesn't touch
the higher 32 bits.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes:
294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
Link: http://lkml.kernel.org/r/1519926894-3520-1-git-send-email-kan.liang@linux.intel.com
[ Rewrote unacceptably bad changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Thu, 8 Mar 2018 08:00:09 +0000 (08:00 +0000)]
efi/arm*: Only register page tables when they exist
[ Upstream commit
6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ]
Currently the arm/arm64 runtime code registers the runtime servies
pagetables with ptdump regardless of whether runtime services page
tables have been created.
As efi_mm.pgd is NULL in these cases, attempting to dump the efi page
tables results in a NULL pointer dereference in the ptdump code:
/sys/kernel/debug# cat efi_page_tables
[ 479.522600] Unable to handle kernel NULL pointer dereference at virtual address
00000000
[ 479.522715] Mem abort info:
[ 479.522764] ESR = 0x96000006
[ 479.522850] Exception class = DABT (current EL), IL = 32 bits
[ 479.522899] SET = 0, FnV = 0
[ 479.522937] EA = 0, S1PTW = 0
[ 479.528200] Data abort info:
[ 479.528230] ISV = 0, ISS = 0x00000006
[ 479.528317] CM = 0, WnR = 0
[ 479.528317] user pgtable: 4k pages, 48-bit VAs, pgd =
0000000064ab0cb0
[ 479.528449] [
0000000000000000] *pgd=
00000000fbbe4003, *pud=
00000000fb66e003, *pmd=
0000000000000000
[ 479.528600] Internal error: Oops:
96000006 [#1] PREEMPT SMP
[ 479.528664] Modules linked in:
[ 479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7
[ 479.528799] Hardware name: FVP Base (DT)
[ 479.528899] pstate:
00400009 (nzcv daif +PAN -UAO)
[ 479.528941] pc : walk_pgd.isra.1+0x20/0x1d0
[ 479.529011] lr : ptdump_walk_pgd+0x30/0x50
[ 479.529105] sp :
ffff00000bf4bc20
[ 479.529185] x29:
ffff00000bf4bc20 x28:
0000ffff9d22e000
[ 479.529271] x27:
0000000000020000 x26:
ffff80007b4c63c0
[ 479.529358] x25:
00000000014000c0 x24:
ffff80007c098900
[ 479.529445] x23:
ffff00000bf4beb8 x22:
0000000000000000
[ 479.529532] x21:
ffff00000bf4bd70 x20:
0000000000000001
[ 479.529618] x19:
ffff00000bf4bcb0 x18:
0000000000000000
[ 479.529760] x17:
000000000041a1c8 x16:
ffff0000082139d8
[ 479.529800] x15:
0000ffff9d3c6030 x14:
0000ffff9d2527f4
[ 479.529924] x13:
00000000000003f3 x12:
0000000000000038
[ 479.530000] x11:
0000000000000003 x10:
0101010101010101
[ 479.530099] x9 :
0000000017e94050 x8 :
000000000000003f
[ 479.530226] x7 :
0000000000000000 x6 :
0000000000000000
[ 479.530313] x5 :
0000000000000001 x4 :
0000000000000000
[ 479.530416] x3 :
ffff000009069fd8 x2 :
0000000000000000
[ 479.530500] x1 :
0000000000000000 x0 :
0000000000000000
[ 479.530599] Process cat (pid: 2457, stack limit = 0x000000005d1b0e6f)
[ 479.530660] Call trace:
[ 479.530746] walk_pgd.isra.1+0x20/0x1d0
[ 479.530833] ptdump_walk_pgd+0x30/0x50
[ 479.530907] ptdump_show+0x10/0x20
[ 479.530920] seq_read+0xc8/0x470
[ 479.531023] full_proxy_read+0x60/0x90
[ 479.531100] __vfs_read+0x18/0x100
[ 479.531180] vfs_read+0x88/0x160
[ 479.531267] SyS_read+0x48/0xb0
[ 479.531299] el0_svc_naked+0x20/0x24
[ 479.531400] Code:
91400420 f90033a0 a90707a2 f9403fa0 (
f9400000)
[ 479.531499] ---[ end trace
bfe8e28d8acb2b67 ]---
Segmentation fault
Let's avoid this problem by only registering the tables after their
successful creation, which is also less confusing when EFI runtime
services are not in use.
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maurizio Lombardi [Fri, 9 Mar 2018 12:59:06 +0000 (13:59 +0100)]
cdrom: do not call check_disk_change() inside cdrom_open()
[ Upstream commit
2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]
when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.
PID: 6766 TASK:
ffff88007b2a6dd0 CPU: 0 COMMAND: "mount"
#0 [
ffff880078447ae0] __schedule at
ffffffff8168d605
#1 [
ffff880078447b48] schedule_preempt_disabled at
ffffffff8168ed49
#2 [
ffff880078447b58] __mutex_lock_slowpath at
ffffffff8168c995
#3 [
ffff880078447bb8] mutex_lock at
ffffffff8168bdef
#4 [
ffff880078447bd0] sr_block_ioctl at
ffffffffa00b6818 [sr_mod]
#5 [
ffff880078447c10] blkdev_ioctl at
ffffffff812fea50
#6 [
ffff880078447c70] ioctl_by_bdev at
ffffffff8123a8b3
#7 [
ffff880078447c90] isofs_fill_super at
ffffffffa04fb1e1 [isofs]
#8 [
ffff880078447da8] mount_bdev at
ffffffff81202570
#9 [
ffff880078447e18] isofs_mount at
ffffffffa04f9828 [isofs]
#10 [
ffff880078447e28] mount_fs at
ffffffff81202d09
#11 [
ffff880078447e70] vfs_kern_mount at
ffffffff8121ea8f
#12 [
ffff880078447ea8] do_mount at
ffffffff81220fee
#13 [
ffff880078447f28] sys_mount at
ffffffff812218d6
#14 [
ffff880078447f80] system_call_fastpath at
ffffffff81698c49
RIP:
00007fd9ea914e9a RSP:
00007ffd5d9bf648 RFLAGS:
00010246
RAX:
00000000000000a5 RBX:
ffffffff81698c49 RCX:
0000000000000010
RDX:
00007fd9ec2bc210 RSI:
00007fd9ec2bc290 RDI:
00007fd9ec2bcf30
RBP:
0000000000000000 R8:
0000000000000000 R9:
0000000000000010
R10:
00000000c0ed0001 R11:
0000000000000206 R12:
00007fd9ec2bc040
R13:
00007fd9eb6b2380 R14:
00007fd9ec2bc210 R15:
00007fd9ec2bcf30
ORIG_RAX:
00000000000000a5 CS: 0033 SS: 002b
This task was trying to mount the cdrom. It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.
PID: 6785 TASK:
ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd"
#0 [
ffff880078417898] __schedule at
ffffffff8168d605
#1 [
ffff880078417900] schedule at
ffffffff8168dc59
#2 [
ffff880078417910] rwsem_down_read_failed at
ffffffff8168f605
#3 [
ffff880078417980] call_rwsem_down_read_failed at
ffffffff81328838
#4 [
ffff8800784179d0] down_read at
ffffffff8168cde0
#5 [
ffff8800784179e8] get_super at
ffffffff81201cc7
#6 [
ffff880078417a10] __invalidate_device at
ffffffff8123a8de
#7 [
ffff880078417a40] flush_disk at
ffffffff8123a94b
#8 [
ffff880078417a88] check_disk_change at
ffffffff8123ab50
#9 [
ffff880078417ab0] cdrom_open at
ffffffffa00a29e1 [cdrom]
#10 [
ffff880078417b68] sr_block_open at
ffffffffa00b6f9b [sr_mod]
#11 [
ffff880078417b98] __blkdev_get at
ffffffff8123ba86
#12 [
ffff880078417bf0] blkdev_get at
ffffffff8123bd65
#13 [
ffff880078417c78] blkdev_open at
ffffffff8123bf9b
#14 [
ffff880078417c90] do_dentry_open at
ffffffff811fc7f7
#15 [
ffff880078417cd8] vfs_open at
ffffffff811fc9cf
#16 [
ffff880078417d00] do_last at
ffffffff8120d53d
#17 [
ffff880078417db0] path_openat at
ffffffff8120e6b2
#18 [
ffff880078417e48] do_filp_open at
ffffffff8121082b
#19 [
ffff880078417f18] do_sys_open at
ffffffff811fdd33
#20 [
ffff880078417f70] sys_open at
ffffffff811fde4e
#21 [
ffff880078417f80] system_call_fastpath at
ffffffff81698c49
RIP:
00007f29438b0c20 RSP:
00007ffc76624b78 RFLAGS:
00010246
RAX:
0000000000000002 RBX:
ffffffff81698c49 RCX:
0000000000000000
RDX:
00007f2944a5fa70 RSI:
00000000000a0800 RDI:
00007f2944a5fa70
RBP:
00007f2944a5f540 R8:
0000000000000000 R9:
0000000000000020
R10:
00007f2943614c40 R11:
0000000000000246 R12:
ffffffff811fde4e
R13:
ffff880078417f78 R14:
000000000000000c R15:
00007f2944a4b010
ORIG_RAX:
0000000000000002 CS: 0033 SS: 002b
This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.
The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.
This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kan Liang [Tue, 20 Feb 2018 10:11:50 +0000 (02:11 -0800)]
perf/x86/intel: Properly save/restore the PMU state in the NMI handler
[ Upstream commit
82d71ed0277efc45360828af8c4e4d40e1b45352 ]
The PMU is disabled in intel_pmu_handle_irq(), but cpuc->enabled is not updated
accordingly.
This is fine in current usage because no-one checks it - but fix it
for future code: for example, the drain_pebs() will be modified to
fix an auto-reload bug.
Properly save/restore the old PMU state.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: kernel test robot <fengguang.wu@intel.com>
Link: http://lkml.kernel.org/r/6f44ee84-56f8-79f1-559b-08e371eaeb78@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sun, 11 Mar 2018 01:55:47 +0000 (17:55 -0800)]
hwmon: (pmbus/adm1275) Accept negative page register values
[ Upstream commit
ecb29abd4cb0670c616fb563a078f25d777ce530 ]
A negative page register value means that no page needs to be
selected. This is used by status register read operations and needs
to be accepted. The failure to do so so results in missed status
and limit registers.
Fixes:
da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sun, 11 Mar 2018 01:49:47 +0000 (17:49 -0800)]
hwmon: (pmbus/max8688) Accept negative page register values
[ Upstream commit
a46f8cd696624ef757be0311eb28f119c36778e8 ]
A negative page register value means that no page needs to be
selected. This is used by status register evaluations and needs
to be accepted.
Fixes:
da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Anholt [Fri, 9 Mar 2018 23:33:32 +0000 (15:33 -0800)]
drm/panel: simple: Fix the bus format for the Ontat panel
[ Upstream commit
5651e5e094591f479adad5830ac1bc45196a39b3 ]
This fixes bad color output. When I was first testing the device I
had the DPI hardware set to 666 mode, but apparently in the refactor
to use the bus_format information from the panel driver, I failed to
actually update the panel.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes:
e8b6f561b2ee ("drm/panel: simple: Add the 7" DPI panel from Adafruit")
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.net
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Fri, 9 Mar 2018 11:52:04 +0000 (12:52 +0100)]
perf/core: Fix perf_output_read_group()
[ Upstream commit
9e5b127d6f33468143d90c8a45ca12410e4c3fa7 ]
Mark reported his arm64 perf fuzzer runs sometimes splat like:
armv8pmu_read_counter+0x1e8/0x2d8
armpmu_event_update+0x8c/0x188
armpmu_read+0xc/0x18
perf_output_read+0x550/0x11e8
perf_event_read_event+0x1d0/0x248
perf_event_exit_task+0x468/0xbb8
do_exit+0x690/0x1310
do_group_exit+0xd0/0x2b0
get_signal+0x2e8/0x17a8
do_signal+0x144/0x4f8
do_notify_resume+0x148/0x1e8
work_pending+0x8/0x14
which asserts that we only call pmu::read() on ACTIVE events.
The above callchain does:
perf_event_exit_task()
perf_event_exit_task_context()
task_ctx_sched_out() // INACTIVE
perf_event_exit_event()
perf_event_set_state(EXIT) // EXIT
sync_child_event()
perf_event_read_event()
perf_output_read()
perf_output_read_group()
leader->pmu->read()
Which results in doing a pmu::read() on an !ACTIVE event.
I _think_ this is 'new' since we added attr.inherit_stat, which added
the perf_event_read_event() to the exit path, without that
perf_event_read_output() would only trigger from samples and for
@event to trigger a sample, it's leader _must_ be ACTIVE too.
Still, adding this check makes it consistent with the @sub case for
the siblings.
Reported-and-Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pierre Bourdon [Tue, 20 Feb 2018 15:03:18 +0000 (16:03 +0100)]
max17042: propagate of_node to power supply device
[ Upstream commit
66ec32fc7cd116dab5c02603ea8ec28ff92da3b5 ]
max17042_get_status uses the core power_supply_am_i_supplied. That
function relies on DT properties to figure out the power supply
topology, and will error out without DT.
Fixes max17042 battery status being reported as "unknown".
Signed-off-by: Pierre Bourdon <delroth@google.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
leilei.lin [Tue, 6 Mar 2018 09:36:37 +0000 (17:36 +0800)]
perf/core: Fix installing cgroup events on CPU
[ Upstream commit
33801b94741d6c3be9713c10aa627477216c21e2 ]
There's two problems when installing cgroup events on CPUs: firstly
list_update_cgroup_event() only tries to set cpuctx->cgrp for the
first event, if that mismatches on @cgrp we'll not try again for later
additions.
Secondly, when we install a cgroup event into an active context, only
issue an event reprogram when the event matches the current cgroup
context. This avoids a pointless event reprogramming.
Signed-off-by: leilei.lin <leilei.lin@alibaba-inc.com>
[ Improved the changelog and comments. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: brendan.d.gregg@gmail.com
Cc: eranian@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: yang_oliver@hotmail.com
Link: http://lkml.kernel.org/r/20180306093637.28247-1-linxiulei@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chao Yu [Sat, 27 Jan 2018 09:29:49 +0000 (17:29 +0800)]
f2fs: fix to check extent cache in f2fs_drop_extent_tree
[ Upstream commit
bf617f7a92edc6bb2909db2bfa4576f50b280ee5 ]
If noextent_cache mount option is on, we will never initialize extent tree
in inode, but still we're going to access it in f2fs_drop_extent_tree,
result in kernel panic as below:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000038
IP: _raw_write_lock+0xc/0x30
Call Trace:
? f2fs_drop_extent_tree+0x41/0x70 [f2fs]
f2fs_fallocate+0x5a0/0xdd0 [f2fs]
? common_file_perm+0x47/0xc0
? apparmor_file_permission+0x1a/0x20
vfs_fallocate+0x15b/0x290
SyS_fallocate+0x44/0x70
do_syscall_64+0x6e/0x160
entry_SYSCALL64_slow_path+0x25/0x25
This patch fixes to check extent cache status before using in
f2fs_drop_extent_tree.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chao Yu [Wed, 31 Jan 2018 01:30:34 +0000 (09:30 +0800)]
f2fs: fix to clear CP_TRIMMED_FLAG
[ Upstream commit
cd36d7a17f9da68be9aa67185ba3ad7969934a19 ]
Once CP_TRIMMED_FLAG is set, after a reboot, we will never issue discard
before LBA becomes invalid again, fix it by clearing the flag in
checkpoint without CP_TRIMMED reason.
Fixes:
1f43e2ad7bff ("f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard")
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chao Yu [Sun, 25 Feb 2018 15:38:21 +0000 (23:38 +0800)]
f2fs: fix to set KEEP_SIZE bit in f2fs_zero_range
[ Upstream commit
17cd07ae95073c298af92c1ba14ac58ce84de33b ]
As Jayashree Mohan reported:
A simple workload to reproduce this would be :
1. create foo
2. Write (8K - 16K) // foo size = 16K now
3. fsync()
4. falloc zero_range , keep_size (4202496 - 4210688) // foo size must be 16K
5. fdatasync()
Crash now
On recovery, we see that the file size is 4210688 and not 16K, which
violates the semantics of keep_size flag. We have a test case to
reproduce this using CrashMonkey on 4.15 kernel. Try this out by
simply running :
./c_harness -f /dev/sda -d /dev/cow_ram0 -t f2fs -e 102400 -P -v
tests/generic_468_zero.so
The root cause is that we miss to set KEEP_SIZE bit correctly in zero_range
when zeroing block cross EOF with FALLOC_FL_KEEP_SIZE, let's fix this
missing case.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vaibhav Jain [Thu, 15 Feb 2018 15:49:24 +0000 (21:19 +0530)]
cxl: Check if PSL data-cache is available before issue flush request
[ Upstream commit
94322ed8e857e3b2a33cf75118051af9baaa110f ]
PSL9D doesn't have a data-cache that needs to be flushed before
resetting the card. However when cxl tries to flush data-cache on such
a card, it times-out as PSL_Control register never indicates flush
operation complete due to missing data-cache. This is usually
indicated in the kernel logs with this message:
"WARNING: cache flush timed out"
To fix this the patch checks PSL_Debug register CDC-Field(BIT:27)
which indicates the absence of a data-cache and sets a flag
'no_data_cache' in 'struct cxl_native' to indicate this. When
cxl_data_cache_flush() is called it checks the flag and if set bails
out early without requesting a data-cache flush operation to the PSL.
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: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alistair Popple [Fri, 2 Mar 2018 05:18:45 +0000 (16:18 +1100)]
powerpc/powernv/npu: Fix deadlock in mmio_invalidate()
[ Upstream commit
2b74e2a9b39df40a2b489af2d24079617c61ee0e ]
When sending TLB invalidates to the NPU we need to send extra flushes due
to a hardware issue. The original implementation would lock the all the
ATSD MMIO registers sequentially before unlocking and relocking each of
them sequentially to do the extra flush.
This introduced a deadlock as it is possible for one thread to hold one
ATSD register whilst waiting for another register to be freed while the
other thread is holding that register waiting for the one in the first
thread to be freed.
For example if there are two threads and two ATSD registers:
Thread A Thread B
----------------------
Acquire 1
Acquire 2
Release 1 Acquire 1
Wait 1 Wait 2
Both threads will be stuck waiting to acquire a register resulting in an
RCU stall warning or soft lockup.
This patch solves the deadlock by refactoring the code to ensure registers
are not released between flushes and to ensure all registers are either
acquired or released together and in order.
Fixes:
bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when sending an ATSD")
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathieu Malaterre [Sun, 25 Feb 2018 17:22:29 +0000 (18:22 +0100)]
powerpc: Add missing prototype for arch_irq_work_raise()
[ Upstream commit
f5246862f82f1e16bbf84cda4cddf287672b30fe ]
In commit
4f8b50bbbe63 ("irq_work, ppc: Fix up arch hooks") a new
function arch_irq_work_raise() was added without a prototype in header
irq_work.h.
Fix the following warning (treated as error in W=1):
arch/powerpc/kernel/time.c:523:6: error: no previous prototype for ‘arch_irq_work_raise’
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Mon, 12 Mar 2018 20:15:08 +0000 (21:15 +0100)]
drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
[ Upstream commit
e770f6bf18182bc3af6ceec30189b6c323cbc157 ]
'drm_vblank_init()' can fail. So handle this (unlikely) error.
Fixes:
bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6cbf3d70ac3904489c7194c895225c4103aebb96.1520885192.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Mon, 12 Mar 2018 20:15:10 +0000 (21:15 +0100)]
drm/meson: Fix some error handling paths in 'meson_drv_bind_master()'
[ Upstream commit
2c18107b9d58972588cd45d89b8f58d0f033c110 ]
If one of these functions fail, we whould free 'drm', as alreadry done in
the other error handling paths, below and above.
Fixes:
bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/df47e03d36c2cf7bc37ec3105fc47c16555bd946.1520885192.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kamlakant Patel [Tue, 13 Mar 2018 11:02:27 +0000 (16:32 +0530)]
ipmi_ssif: Fix kernel panic at msg_done_handler
[ Upstream commit
f002612b9d86613bc6fde0a444e0095225f6053e ]
This happens when BMC doesn't return any data and the code is trying
to print the value of data[2].
Getting following crash:
[ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address
00000002
[ 484.736496] pgd =
ffff0000094a2000
[ 484.739885] [
00000002] *pgd=
00000047fcffe003, *pud=
00000047fcffd003, *pmd=
0000000000000000
[ 484.748158] Internal error: Oops:
96000005 [#1] SMP
[...]
[ 485.101451] Call trace:
[...]
[ 485.188473] [<
ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif]
[ 485.195249] [<
ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif]
[ 485.202038] [<
ffff0000080f1430>] kthread+0x108/0x138
[ 485.206994] [<
ffff0000080838e0>] ret_from_fork+0x10/0x30
[ 485.212294] Code:
aa1903e1 aa1803e0 b900227f 95fef6a5 (
39400aa3)
Adding a check to validate the data len before printing data[2] to fix this issue.
Signed-off-by: Kamlakant Patel <kamlakant.patel@cavium.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Milton Miller [Fri, 9 Mar 2018 21:58:19 +0000 (15:58 -0600)]
watchdog: aspeed: Fix translation of reset mode to ctrl register
[ Upstream commit
d2fc8db691bf3197d43b2afb553311a9bf257bff ]
Assert RESET_SYSTEM bit for any reset and set MODE field from reset
type.
The watchdog control register has a RESET_SYSTEM bit that is really
closer to activate a reset, and RESET_SYSTEM_MODE field that chooses
how much to reset.
Before this patch, a node without these optional property would do a
SOC reset, but a node with properties requesting a cpu or SOC reset
would do nothing and a node requesting a system reset would do a
SOC reset.
Fixes:
b7f0b8ad25f3 ("drivers/watchdog: ASPEED reference dev tree properties for config")
Signed-off-by: Milton Miller <miltonm@us.ibm.com>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Sat, 10 Mar 2018 03:46:06 +0000 (19:46 -0800)]
watchdog: dw: RMW the control register
[ Upstream commit
a81abbb412341e9e3b2d42ed7d310cf71fbb84a8 ]
RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length
of pulse to issue for system reset. We shouldn't clobber this value,
because that might make the system reset ineffective. On RK3399, we're
seeing that a value of 000b (meaning 2 cycles) yields an unreliable
(partial?) reset, and so we only fully reset after the watchdog fires a
second time. If we retain the system default (010b, or 8 clock cycles),
then the watchdog reset is much more reliable.
Read-modify-write retains the system value and improves reset
reliability.
It seems we were intentionally clobbering the response mode previously,
to ensure we performed a system reset (we don't support an interrupt
notification), so retain that explicitly.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Sat, 3 Mar 2018 09:53:24 +0000 (10:53 +0100)]
PCI: Restore config space on runtime resume despite being unbound
[ Upstream commit
5775b843a619b3c93f946e2b55a208d9f0f48b59 ]
We leave PCI devices not bound to a driver in D0 during runtime suspend.
But they may have a parent which is bound and can be transitioned to
D3cold at runtime. Once the parent goes to D3cold, the unbound child
may go to D3cold as well. When the child goes to D3cold, its internal
state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.
One example are recent hybrid graphics laptops which cut power to the
discrete GPU when the root port above it goes to ACPI power state D3.
Users may provoke this by unbinding the GPU driver and allowing runtime
PM on the GPU via sysfs: The PM core will then treat the GPU as
"suspended", which in turn allows the root port to runtime suspend,
causing the power resources listed in its _PR3 object to be powered off.
The GPU's BARs will be uninitialized when a driver later probes it.
Another example are hybrid graphics laptops where the GPU itself (rather
than the root port) is capable of runtime suspending to D3cold. If the
GPU's integrated HDA controller is not bound and the GPU's driver
decides to runtime suspend to D3cold, the HDA controller's BARs will be
uninitialized when a driver later probes it.
Fix by saving and restoring config space over a runtime suspend cycle
even if the device is not bound.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus
Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Kresin [Thu, 11 May 2017 06:18:24 +0000 (08:18 +0200)]
MIPS: ath79: Fix AR724X_PLL_REG_PCIE_CONFIG offset
[ Upstream commit
05454c1bde91fb013c0431801001da82947e6b5a ]
According to the QCA u-boot source the "PCIE Phase Lock Loop
Configuration (PCIE_PLL_CONFIG)" register is for all SoCs except the
QCA955X and QCA956X at offset 0x10.
Since the PCIE PLL config register is only defined for the AR724x fix
only this value. The value is wrong since the day it was added and isn't
used by any driver yet.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16048/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ursula Braun [Wed, 14 Mar 2018 10:01:00 +0000 (11:01 +0100)]
net/smc: pay attention to MAX_ORDER for CQ entries
[ Upstream commit
c9f4c6cf53bfafb639386a4c094929f13f573e04 ]
smc allocates a certain number of CQ entries for used RoCE devices. For
mlx5 devices the chosen constant number results in a large allocation
causing this warning:
[13355.124656] WARNING: CPU: 3 PID: 16535 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0x2be/0x10c0
[13355.124657] Modules linked in: smc_diag(O) smc(O) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter mlx5_ib ib_core sunrpc mlx5_core s390_trng rng_core ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common ptp pps_core eadm_sch dm_multipath dm_mod vhost_net tun vhost tap sch_fq_codel kvm ip_tables x_tables autofs4 [last unloaded: smc]
[13355.124672] CPU: 3 PID: 16535 Comm: kworker/3:0 Tainted: G O 4.14.0uschi #1
[13355.124673] Hardware name: IBM 3906 M04 704 (LPAR)
[13355.124675] Workqueue: events smc_listen_work [smc]
[13355.124677] task:
00000000e2f22100 task.stack:
0000000084720000
[13355.124678] Krnl PSW :
0704c00180000000 000000000029da76 (__alloc_pages_nodemask+0x2be/0x10c0)
[13355.124681] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
[13355.124682] Krnl GPRS:
0000000000000000 00550e00014080c0 0000000000000000 0000000000000001
[13355.124684]
000000000029d8b6 00000000f3bfd710 0000000000000000 00000000014080c0
[13355.124685]
0000000000000009 00000000ec277a00 0000000000200000 0000000000000000
[13355.124686]
0000000000000000 00000000000001ff 000000000029d8b6 0000000084723720
[13355.124708] Krnl Code:
000000000029da6a:
a7110200 tmll %r1,512
000000000029da6e:
a774ff29 brc 7,29d8c0
#
000000000029da72:
a7f40001 brc 15,29da74
>
000000000029da76:
a7f4ff25 brc 15,29d8c0
000000000029da7a:
a7380000 lhi %r3,0
000000000029da7e:
a7f4fef1 brc 15,29d860
000000000029da82:
5820f0c4 l %r2,196(%r15)
000000000029da86:
a53e0048 llilh %r3,72
[13355.124720] Call Trace:
[13355.124722] ([<
000000000029d8b6>] __alloc_pages_nodemask+0xfe/0x10c0)
[13355.124724] [<
000000000013bd1e>] s390_dma_alloc+0x6e/0x148
[13355.124733] [<
000003ff802eeba6>] mlx5_dma_zalloc_coherent_node+0x8e/0xe0 [mlx5_core]
[13355.124740] [<
000003ff802eee18>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core]
[13355.124744] [<
000003ff804eb410>] mlx5_ib_create_cq+0x558/0x898 [mlx5_ib]
[13355.124749] [<
000003ff80407d40>] ib_create_cq+0x48/0x88 [ib_core]
[13355.124751] [<
000003ff80109fba>] smc_ib_setup_per_ibdev+0x52/0x118 [smc]
[13355.124753] [<
000003ff8010bcb6>] smc_conn_create+0x65e/0x728 [smc]
[13355.124755] [<
000003ff801081a2>] smc_listen_work+0x2d2/0x540 [smc]
[13355.124756] [<
0000000000162c66>] process_one_work+0x1be/0x440
[13355.124758] [<
0000000000162f40>] worker_thread+0x58/0x458
[13355.124759] [<
0000000000169e7e>] kthread+0x14e/0x168
[13355.124760] [<
00000000009ce8be>] kernel_thread_starter+0x6/0xc
[13355.124762] [<
00000000009ce8b8>] kernel_thread_starter+0x0/0xc
[13355.124762] Last Breaking-Event-Address:
[13355.124764] [<
000000000029da72>] __alloc_pages_nodemask+0x2ba/0x10c0
[13355.124764] ---[ end trace
34be38b581c0b585 ]---
This patch reduces the smc constant for the maximum number of allocated
completion queue entries SMC_MAX_CQE by 2 to avoid high round up values
in the mlx5 code, and reduces the number of allocated completion queue
entries even more, if the final allocation for an mlx5 device hits the
MAX_ORDER limit.
Reported-by: Ihnken Menssen <menssen@de.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe Jaillet [Tue, 13 Mar 2018 18:36:58 +0000 (19:36 +0100)]
spi: bcm-qspi: fIX some error handling paths
[ Upstream commit
bc3cc75281b3c2b1c5355d88d147b66a753bb9a5 ]
For some reason, commit
c0368e4db4a3 ("spi: bcm-qspi: Fix use after free
in bcm_qspi_probe() in error path") has updated some gotos, but not all of
them.
This looks spurious, so fix it.
Fixes:
fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe Jaillet [Tue, 13 Mar 2018 20:33:11 +0000 (21:33 +0100)]
regulator: gpio: Fix some error handling paths in 'gpio_regulator_probe()'
[ Upstream commit
ed8cffda27dea6fd3dafb3ee881c5a786edac9ca ]
Re-order error handling code and gotos to avoid leaks in error handling
paths.
Fixes:
9f946099fe19 ("regulator: gpio: fix parsing of gpio list")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leo Yan [Tue, 13 Mar 2018 17:24:30 +0000 (11:24 -0600)]
coresight: Use %px to print pcsr instead of %p
[ Upstream commit
831c326fcd0e8e2a6ece952f898a1ec9b1dc1004 ]
Commit
ad67b74d2469 ("printk: hash addresses printed with %p") lets
printk specifier %p to hash all addresses before printing, this was
resulting in the high 32 bits of pcsr can only output zeros. So
module cannot completely print pc value and it's pointless for debugging
purpose.
This patch fixes this by using %px to print pcsr instead.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oded Gabbay [Thu, 15 Mar 2018 08:08:35 +0000 (10:08 +0200)]
drm/amdkfd: add missing include of mm.h
[ Upstream commit
7420f482ea5163bf6dae39a5c7628d5397cd6307 ]
This patch fixes kernel build in ARCH=frv
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parav Pandit [Tue, 13 Mar 2018 14:06:14 +0000 (16:06 +0200)]
IB/core: Honor port_num while resolving GID for IB link layer
[ Upstream commit
563c4ba3bd2b8b0b21c65669ec2226b1cfa1138b ]
ah_attr contains the port number to which cm_id is bound. However, while
searching for GID table for matching GID entry, the port number is
ignored.
This could cause the wrong GID to be used when the ah_attr is converted to
an AH.
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Richter [Thu, 8 Mar 2018 14:57:35 +0000 (15:57 +0100)]
perf stat: Fix core dump when flag T is used
[ Upstream commit
fca32340a5e8b896f57d41fd94b8b1701df25eb1 ]
Executing command 'perf stat -T -- ls' dumps core on x86 and s390.
Here is the call back chain (done on x86):
# gdb ./perf
....
(gdb) r stat -T -- ls
...
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6
(gdb) where
#0 0x00007ffff56d1963 in vasprintf () from /lib64/libc.so.6
#1 0x00007ffff56ae484 in asprintf () from /lib64/libc.so.6
#2 0x00000000004f1982 in __parse_events_add_pmu (parse_state=0x7fffffffd580,
list=0xbfb970, name=0xbf3ef0 "cpu",
head_config=0xbfb930, auto_merge_stats=false) at util/parse-events.c:1233
#3 0x00000000004f1c8e in parse_events_add_pmu (parse_state=0x7fffffffd580,
list=0xbfb970, name=0xbf3ef0 "cpu",
head_config=0xbfb930) at util/parse-events.c:1288
#4 0x0000000000537ce3 in parse_events_parse (_parse_state=0x7fffffffd580,
scanner=0xbf4210) at util/parse-events.y:234
#5 0x00000000004f2c7a in parse_events__scanner (str=0x6b66c0
"task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}",
parse_state=0x7fffffffd580, start_token=258) at util/parse-events.c:1673
#6 0x00000000004f2e23 in parse_events (evlist=0xbe9990, str=0x6b66c0
"task-clock,{instructions,cycles,cpu/cycles-t/,cpu/tx-start/}", err=0x0)
at util/parse-events.c:1713
#7 0x000000000044e137 in add_default_attributes () at builtin-stat.c:2281
#8 0x000000000044f7b5 in cmd_stat (argc=1, argv=0x7fffffffe3b0) at
builtin-stat.c:2828
#9 0x00000000004c8b0f in run_builtin (p=0xab01a0 <commands+288>, argc=4,
argv=0x7fffffffe3b0) at perf.c:297
#10 0x00000000004c8d7c in handle_internal_command (argc=4,
argv=0x7fffffffe3b0) at perf.c:349
#11 0x00000000004c8ece in run_argv (argcp=0x7fffffffe20c,
argv=0x7fffffffe200) at perf.c:393
#12 0x00000000004c929c in main (argc=4, argv=0x7fffffffe3b0) at perf.c:537
(gdb)
It turns out that a NULL pointer is referenced. Here are the
function calls:
...
cmd_stat()
+---> add_default_attributes()
+---> parse_events(evsel_list, transaction_attrs, NULL);
3rd parameter set to NULL
Function parse_events(xx, xx, struct parse_events_error *err) dives
into a bison generated scanner and creates
parser state information for it first:
struct parse_events_state parse_state = {
.list = LIST_HEAD_INIT(parse_state.list),
.idx = evlist->nr_entries,
.error = err, <--- NULL POINTER !!!
.evlist = evlist,
};
Now various functions inside the bison scanner are called to end up in
__parse_events_add_pmu(struct parse_events_state *parse_state, ..) with
first parameter being a pointer to above structure definition.
Now the PMU event name is not found (because being executed in a VM) and
this function tries to create an error message with
asprintf(&parse_state->error.str, ....)
which references a NULL pointer and dumps core.
Fix this by providing a pointer to the necessary error information
instead of NULL. Technically only the else part is needed to avoid the
core dump, just lets be safe...
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Link: http://lkml.kernel.org/r/20180308145735.64717-1-tmricht@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yisheng Xie [Mon, 12 Mar 2018 11:25:56 +0000 (19:25 +0800)]
perf top: Fix top.call-graph config option reading
[ Upstream commit
a3a4a3b37c9b911af4c375b2475cea0fd2b84d38 ]
When trying to add the "call-graph" variable for top into the
.perfconfig file, like:
[top]
call-graph = fp
I that perf_top_config() do not parse this variable.
Fix it by calling perf_default_config() when the top.call-graph variable
is set.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes:
b8cbb349061e ("perf config: Bring perf_default_config to the very beginning at main()")
Link: http://lkml.kernel.org/r/1520853957-36106-1-git-send-email-xieyisheng1@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vitaly Kuznetsov [Fri, 9 Feb 2018 13:01:33 +0000 (14:01 +0100)]
KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use
[ Upstream commit
0bcc3fb95b97ac2ca223a5a870287b37f56265ac ]
Devices which use level-triggered interrupts under Windows 2016 with
Hyper-V role enabled don't work: Windows disables EOI broadcast in SPIV
unconditionally. Our in-kernel IOAPIC implementation emulates an old IOAPIC
version which has no EOI register so EOI never happens.
The issue was discovered and discussed a while ago:
https://www.spinics.net/lists/kvm/msg148098.html
While this is a guest OS bug (it should check that IOAPIC has the required
capabilities before disabling EOI broadcast) we can workaround it in KVM:
advertising DIRECTED_EOI with in-kernel IOAPIC makes little sense anyway.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gregory CLEMENT [Wed, 14 Mar 2018 17:03:40 +0000 (18:03 +0100)]
i2c: mv64xxx: Apply errata delay only in standard mode
[ Upstream commit
31184d8c6ea49ea0676d100cdd7e1f102ad025b5 ]
The errata FE-8471889 description has been updated. There is still a
timing violation for repeated start. But the errata now states that it
was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz)
there is no issue.
This patch limit the errata fix to the Standard mode.
It has been tesed successfully on the clearfog (Aramda 388 based board).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arjun Vynipadath [Thu, 15 Mar 2018 12:04:14 +0000 (17:34 +0530)]
cxgb4: Fix queue free path of ULD drivers
[ Upstream commit
d7cb44496a9bb458632cb3c18acb08949c210448 ]
Setting sge_uld_rxq_info to NULL in free_queues_uld().
We are referencing sge_uld_rxq_info in cxgb_up(). This
will fix a panic when interface is brought up after a
ULDq creation failure.
Fixes:
94cdb8bb993a (cxgb4: Add support for dynamic allocation
of resources for ULD)
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudhar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seunghun Han [Wed, 14 Mar 2018 23:12:56 +0000 (16:12 -0700)]
ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c
[ Upstream commit
97f3c0a4b0579b646b6b10ae5a3d59f0441cc12c ]
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[ 0.464168] ACPI: Added _OSI(Module Device)
>[ 0.467022] ACPI: Added _OSI(Processor Device)
>[ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
>[ 0.471647] ACPI: Added _OSI(Processor Aggregator Device)
>[ 0.477997] ACPI Error: Null stack entry at
ffff880215c0aad8 (
20170303/exresop-174)
>[ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (
20170303/dswexec-461)
>[ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node
ffff88021710ab40), AE_AML_INTERNAL (
20170303/psparse-543)
>[ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node
ffff88021710a618), AE_AML_INTERNAL (
20170303/psparse-543)
>[ 0.497683] ACPI: Interpreter enabled
>[ 0.499385] ACPI: (supports S0)
>[ 0.501151] ACPI: Using IOAPIC for interrupt routing
>[ 0.503342] ACPI Error: Null stack entry at
ffff880215c0aad8 (
20170303/exresop-174)
>[ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (
20170303/dswexec-461)
>[ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node
ffff88021710ab40), AE_AML_INTERNAL (
20170303/psparse-543)
>[ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node
ffff88021710ab18), AE_AML_INTERNAL (
20170303/psparse-543)
>[ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (
20170303/bus-991)
>[ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[ 0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006
>[ 0.529668] Call Trace:
>[ 0.530811] ? dump_stack+0x5c/0x81
>[ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0
>[ 0.533905] ? acpi_os_delete_cache+0xa/0x10
>[ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b
>[ 0.537237] ? acpi_terminate+0xa/0x14
>[ 0.538701] ? acpi_init+0x2af/0x34f
>[ 0.540008] ? acpi_sleep_proc_init+0x27/0x27
>[ 0.541593] ? do_one_initcall+0x4e/0x1a0
>[ 0.543008] ? kernel_init_freeable+0x19e/0x21f
>[ 0.546202] ? rest_init+0x80/0x80
>[ 0.547513] ? kernel_init+0xa/0x100
>[ 0.548817] ? ret_from_fork+0x25/0x30
>[ 0.550587] vgaarb: loaded
>[ 0.551716] EDAC MC: Ver: 3.0.0
>[ 0.553744] PCI: Probing PCI hardware
>[ 0.555038] PCI host bridge to bus 0000:00
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ns_evaluate() function
only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is
also not null. Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Moore [Wed, 14 Mar 2018 23:13:01 +0000 (16:13 -0700)]
ACPICA: Fix memory leak on unusual memory leak
[ Upstream commit
1c29c372b2d1d2415601041532745ce859f24126 ]
Fixes a single-object memory leak on a store-to-reference method
invocation. ACPICA BZ 1439.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Erik Schmauss [Wed, 14 Mar 2018 23:13:08 +0000 (16:13 -0700)]
ACPICA: Events: add a return on failure from acpi_hw_register_read
[ Upstream commit
b4c0de312613ca676db5bd7e696a44b56795612a ]
This ensures that acpi_ev_fixed_event_detect() does not use fixed_status
and and fixed_enable as uninitialized variables.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Icenowy Zheng [Fri, 16 Mar 2018 14:02:12 +0000 (22:02 +0800)]
dt-bindings: add device tree binding for Allwinner H6 main CCU
[ Upstream commit
2e08e4d2ff488424919d69dd211ac860a019ac1d ]
The Allwinner H6 main CCU uses the internal oscillator of the SoC, which
is different with old SoCs' main CCU.
Add device tree binding for the Allwinner H6 main CCU.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Wed, 14 Mar 2018 19:56:37 +0000 (20:56 +0100)]
remoteproc: imx_rproc: Fix an error handling path in 'imx_rproc_probe()'
[ Upstream commit
de6f83f85be94e0b7d0d324c29ccc9d78a6bb4e7 ]
If 'of_device_get_match_data()' fails, we must undo the previous
'rproc_alloc()' call.
Fixes:
a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Coly Li [Mon, 19 Mar 2018 00:36:15 +0000 (17:36 -0700)]
bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set
[ Upstream commit
fadd94e05c02afec7b70b0b14915624f1782f578 ]
In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()",
cached_dev_get() is called when creating dc->writeback_thread, and
cached_dev_put() is called when exiting dc->writeback_thread. This
modification works well unless people detach the bcache device manually by
'echo 1 > /sys/block/bcache<N>/bcache/detach'
Because this sysfs interface only calls bch_cached_dev_detach() which wakes
up dc->writeback_thread but does not stop it. The reason is, before patch
"bcache: fix cached_dev->count usage for bch_cache_set_error()", inside
bch_writeback_thread(), if cache is not dirty after writeback,
cached_dev_put() will be called here. And in cached_dev_make_request() when
a new write request makes cache from clean to dirty, cached_dev_get() will
be called there. Since we don't operate dc->count in these locations,
refcount d->count cannot be dropped after cache becomes clean, and
cached_dev_detach_finish() won't be called to detach bcache device.
This patch fixes the issue by checking whether BCACHE_DEV_DETACHING is
set inside bch_writeback_thread(). If this bit is set and cache is clean
(no existing writeback_keys), break the while-loop, call cached_dev_put()
and quit the writeback thread.
Please note if cache is still dirty, even BCACHE_DEV_DETACHING is set the
writeback thread should continue to perform writeback, this is the original
design of manually detach.
It is safe to do the following check without locking, let me explain why,
+ if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
+ (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) {
If the kenrel thread does not sleep and continue to run due to conditions
are not updated in time on the running CPU core, it just consumes more CPU
cycles and has no hurt. This should-sleep-but-run is safe here. We just
focus on the should-run-but-sleep condition, which means the writeback
thread goes to sleep in mistake while it should continue to run.
1, First of all, no matter the writeback thread is hung or not,
kthread_stop() from cached_dev_detach_finish() will wake up it and
terminate by making kthread_should_stop() return true. And in normal
run time, bit on index BCACHE_DEV_DETACHING is always cleared, the
condition
!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags)
is always true and can be ignored as constant value.
2, If one of the following conditions is true, the writeback thread should
go to sleep,
"!atomic_read(&dc->has_dirty)" or "!dc->writeback_running)"
each of them independently controls the writeback thread should sleep or
not, let's analyse them one by one.
2.1 condition "!atomic_read(&dc->has_dirty)"
If dc->has_dirty is set from 0 to 1 on another CPU core, bcache will
call bch_writeback_queue() immediately or call bch_writeback_add() which
indirectly calls bch_writeback_queue() too. In bch_writeback_queue(),
wake_up_process(dc->writeback_thread) is called. It sets writeback
thread's task state to TASK_RUNNING and following an implicit memory
barrier, then tries to wake up the writeback thread.
In writeback thread, its task state is set to TASK_INTERRUPTIBLE before
doing the condition check. If other CPU core sets the TASK_RUNNING state
after writeback thread setting TASK_INTERRUPTIBLE, the writeback thread
will be scheduled to run very soon because its state is not
TASK_INTERRUPTIBLE. If other CPU core sets the TASK_RUNNING state before
writeback thread setting TASK_INTERRUPTIBLE, the implict memory barrier
of wake_up_process() will make sure modification of dc->has_dirty on
other CPU core is updated and observed on the CPU core of writeback
thread. Therefore the condition check will correctly be false, and
continue writeback code without sleeping.
2.2 condition "!dc->writeback_running)"
dc->writeback_running can be changed via sysfs file, every time it is
modified, a following bch_writeback_queue() is alwasy called. So the
change is always observed on the CPU core of writeback thread. If
dc->writeback_running is changed from 0 to 1 on other CPU core, this
condition check will observe the modification and allow writeback
thread to continue to run without sleeping.
Now we can see, even without a locking protection, multiple conditions
check is safe here, no deadlock or process hang up will happen.
I compose a separte patch because that patch "bcache: fix cached_dev->count
usage for bch_cache_set_error()" already gets a "Reviewed-by:" from Hannes
Reinecke. Also this fix is not trivial and good for a separate patch.
Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Huijun Tang <tang.junhui@zte.com.cn>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Schmitz [Fri, 2 Mar 2018 23:04:13 +0000 (12:04 +1300)]
zorro: Set up z->dev.dma_mask for the DMA API
[ Upstream commit
55496d3fe2acd1a365c43cbd613a20ecd4d74395 ]
The generic DMA API uses dev->dma_mask to check the DMA addressable
memory bitmask, and warns if no mask is set or even allocated.
Set z->dev.dma_coherent_mask on Zorro bus scan, and make z->dev.dma_mask
to point to z->dev.dma_coherent_mask so device drivers that need DMA have
everything set up to avoid warnings from dma_alloc_coherent(). Drivers can
still use dma_set_mask_and_coherent() to explicitly set their DMA bit mask.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
[geert: Handle Zorro II with 24-bit address space]
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Honggang Li [Fri, 16 Mar 2018 02:37:13 +0000 (10:37 +0800)]
IB/mlx5: Set the default active rate and width to QDR and 4X
[ Upstream commit
7672ed33c4c15dbe9d56880683baaba4227cf940 ]
Before commit
f1b65df5a232 ("IB/mlx5: Add support for active_width and
active_speed in RoCE"), the mlx5_ib driver set the default active_width
and active_speed to IB_WIDTH_4X and IB_SPEED_QDR.
When the RoCE port is down, the RoCE port does not negotiate the active
width with the remote side, causing the active width to be zero. When
running userspace ibstat to view the port status, ibstat will panic as it
reads an invalid width from sys file.
This patch restores the original behavior.
Fixes:
f1b65df5a232 ("IB/mlx5: Add support for active_width and active_speed in RoCE").
Signed-off-by: Honggang Li <honli@redhat.com>
Reviewed-by: Hal Rosenstock <hal@mellanox.com>
Reviewed-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunyu Hu [Mon, 5 Mar 2018 05:40:38 +0000 (13:40 +0800)]
cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path
[ Upstream commit
55b55abc17f238c61921360e61dde90dd9a326d1 ]
Kmemleak reported the below leak. When cppc_cpufreq_init went into
failure path, the cpu mask is not freed. After fix, this report is
gone. And to avaoid potential NULL pointer reference, check the cpu
value first.
unreferenced object 0xffff800fd5ea4880 (size 128):
comm "swapper/0", pid 1, jiffies
4294939510 (age 668.680s)
hex dump (first 32 bytes):
00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffff0000082c4ae4>] __kmalloc_node+0x278/0x634
[<
ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60
[<
ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c
[<
ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c
[<
ffff000008083828>] do_one_initcall+0xec/0x15c
[<
ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4
[<
ffff0000089099b0>] kernel_init+0x18/0x10c
[<
ffff000008084d50>] ret_from_fork+0x10/0x18
[<
ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yong Wu [Sun, 18 Mar 2018 01:52:54 +0000 (09:52 +0800)]
iommu/mediatek: Fix protect memory setting
[ Upstream commit
70ca608b2ec6dafa6bb1c2b0691852fc78f8f717 ]
In MediaTek's IOMMU design, When a iommu translation fault occurs
(HW can NOT translate the destination address to a valid physical
address), the IOMMU HW output the dirty data into a special memory
to avoid corrupting the main memory, this is called "protect memory".
the register(0x114) for protect memory is a little different between
mt8173 and mt2712.
In the mt8173, bit[30:6] in the register represents [31:7] of the
physical address. In the 4GB mode, the register bit[31] should be 1.
While in the mt2712, the bits don't shift. bit[31:7] in the register
represents [31:7] in the physical address, and bit[1:0] in the
register represents bit[33:32] of the physical address if it has.
Fixes:
e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support")
Reported-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Thu, 22 Mar 2018 09:35:18 +0000 (10:35 +0100)]
drm/vmwgfx: Unpin the screen object backup buffer when not used
[ Upstream commit
20fb5a635a0c8478ac98f15cfafc2ea83df29565 ]
We were relying on the pinned screen object backup buffer to be destroyed
when not used. But if we hold a copy of the atomic state, like when
hibernating, the backup buffer might not be destroyed since it's
refcounted by the atomic state. This causes us to hibernate with a
buffer pinned in VRAM.
Fix this by only having the buffer pinned when it is actually used by a
screen object.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sandeen [Thu, 22 Mar 2018 15:59:00 +0000 (11:59 -0400)]
ext4: don't complain about incorrect features when probing
[ Upstream commit
0d9366d67bcf066b028e57d09c9a86ce879bcc28 ]
If mount is auto-probing for filesystem type, it will try various
filesystems in order, with the MS_SILENT flag set. We get
that flag as the silent arg to ext4_fill_super.
If we're probing (silent==1) then don't complain about feature
incompatibilities that are found if it looks like it's actually
a different valid extN type - failed probes should be silent
in this case.
If the on-disk features are unknown even to ext4, then complain.
Reported-by: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Tested-by: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philipp Puschmann [Fri, 23 Mar 2018 09:22:15 +0000 (10:22 +0100)]
arm: dts: socfpga: fix GIC PPI warning
[ Upstream commit
6d97d5aba08b26108f95dc9fb7bbe4d9436c769c ]
Fixes the warning "GIC: PPI13 is secure or misconfigured" by
changing the interrupt type from level_low to edge_raising
Signed-off-by: Philipp Puschmann <pp@emlix.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jay Vosburgh [Thu, 22 Mar 2018 14:42:41 +0000 (14:42 +0000)]
virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS
[ Upstream commit
bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ]
The operstate update logic will leave an interface in the
default UNKNOWN operstate if the interface carrier state never changes
from the default carrier up state set at creation. This includes the
case of an explicit call to netif_carrier_on, as the carrier on to on
transition has no effect on operstate.
This affects virtio-net for the case that the virtio peer does
not support VIRTIO_NET_F_STATUS (the feature that provides carrier state
updates). Without this feature, the virtio specification states that
"the link should be assumed active," so, logically, the operstate should
be UP instead of UNKNOWN. This has impact on user space applications
that use the operstate to make availability decisions for the interface.
Resolve this by changing the virtio probe logic slightly to call
netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS
cases, and then the existing call to netif_carrier_on for the "without"
case will cause an operstate transition.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Milton Miller [Thu, 15 Mar 2018 16:02:06 +0000 (11:02 -0500)]
watchdog: aspeed: Allow configuring for alternate boot
[ Upstream commit
6ffa3402211acc30e47e691e14d62f3fd065a54e ]
Allow the device tree to specify a watchdog to fallover to
the alternate boot source.
The aspeeed watchdog can set a latch directing flash chip select 0 to
chip select 1, allowing boot from an alternate media if the watchdog
is not reset in time. On the ast2400 bank 1 also goes to flash bank 1,
while on the ast2500 the chip selects are swapped.
Also clear the secondary boot bit during the machine restart operation.
Otherwise, the system will switch to the alternate boot after every
reboot, which is not desired.
Signed-off-by: Milton Miller <miltonm@us.ibm.com>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Petr Vorel [Fri, 23 Mar 2018 13:41:08 +0000 (14:41 +0100)]
ima: Fallback to the builtin hash algorithm
[ Upstream commit
ab60368ab6a452466885ef4edf0cefd089465132 ]
IMA requires having it's hash algorithm be compiled-in due to it's
early use. The default IMA algorithm is protected by Kconfig to be
compiled-in.
The ima_hash kernel parameter allows to choose the hash algorithm. When
the specified algorithm is not available or available as a module, IMA
initialization fails, which leads to a kernel panic (mknodat syscall calls
ima_post_path_mknod()). Therefore as fallback we force IMA to use
the default builtin Kconfig hash algorithm.
Fixed crash:
$ grep CONFIG_CRYPTO_MD4 .config
CONFIG_CRYPTO_MD4=m
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=
74ae8202-9ca7-4e39-813b-
22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4
...
[ 1.545190] ima: Can not allocate md4 (reason: -2)
...
[ 2.610120] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 2.611903] IP: ima_match_policy+0x23/0x390
[ 2.612967] PGD 0 P4D 0
[ 2.613080] Oops: 0000 [#1] SMP
[ 2.613080] Modules linked in: autofs4
[ 2.613080] Supported: Yes
[ 2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1
[ 2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[ 2.613080] task:
ffff88003e2d0040 task.stack:
ffffc90000190000
[ 2.613080] RIP: 0010:ima_match_policy+0x23/0x390
[ 2.613080] RSP: 0018:
ffffc90000193e88 EFLAGS:
00010296
[ 2.613080] RAX:
0000000000000000 RBX:
000000000000000c RCX:
0000000000000004
[ 2.613080] RDX:
0000000000000010 RSI:
0000000000000001 RDI:
ffff880037071728
[ 2.613080] RBP:
0000000000008000 R08:
0000000000000000 R09:
0000000000000000
[ 2.613080] R10:
0000000000000008 R11:
61c8864680b583eb R12:
00005580ff10086f
[ 2.613080] R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000008000
[ 2.613080] FS:
00007f5c1da08940(0000) GS:
ffff88003fc00000(0000) knlGS:
0000000000000000
[ 2.613080] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 2.613080] CR2:
0000000000000000 CR3:
0000000037002000 CR4:
00000000003406f0
[ 2.613080] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 2.613080] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 2.613080] Call Trace:
[ 2.613080] ? shmem_mknod+0xbf/0xd0
[ 2.613080] ima_post_path_mknod+0x1c/0x40
[ 2.613080] SyS_mknod+0x210/0x220
[ 2.613080] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 2.613080] RIP: 0033:0x7f5c1bfde570
[ 2.613080] RSP: 002b:
00007ffde1c90dc8 EFLAGS:
00000246 ORIG_RAX:
0000000000000085
[ 2.613080] RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007f5c1bfde570
[ 2.613080] RDX:
0000000000000000 RSI:
0000000000008000 RDI:
00005580ff10086f
[ 2.613080] RBP:
00007ffde1c91040 R08:
00005580ff10086f R09:
0000000000000000
[ 2.613080] R10:
0000000000104000 R11:
0000000000000246 R12:
00005580ffb99660
[ 2.613080] R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000002
[ 2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20
[ 2.613080] RIP: ima_match_policy+0x23/0x390 RSP:
ffffc90000193e88
[ 2.613080] CR2:
0000000000000000
[ 2.613080] ---[ end trace
9a9f0a8a73079f6a ]---
[ 2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 2.673052]
[ 2.675337] Kernel Offset: disabled
[ 2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiandi An [Wed, 7 Mar 2018 05:26:26 +0000 (23:26 -0600)]
ima: Fix Kconfig to select TPM 2.0 CRB interface
[ Upstream commit
fac37c628fd5d68fd7298d9b57ae8601ee1b4723 ]
TPM_CRB driver provides TPM CRB 2.0 support. If it is built as a
module, the TPM chip is registered after IMA init. tpm_pcr_read() in
IMA fails and displays the following message even though eventually
there is a TPM chip on the system.
ima: No TPM chip found, activating TPM-bypass! (rc=-19)
Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is built in the kernel
and initializes before IMA.
Signed-off-by: Jiandi An <anjiandi@codeaurora.org>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arjun Vynipadath [Fri, 23 Mar 2018 09:55:10 +0000 (15:25 +0530)]
cxgb4: Setup FW queues before registering netdev
[ Upstream commit
843bd7db79c861b49e2912d723625f5fa8e94502 ]
When NetworkManager is enabled, there are chances that interface up
is called even before probe completes. This means we have not yet
allocated the FW sge queues, hence rest of ingress queue allocation
wont be proper. Fix this by calling setup_fw_sge_queues() before
register_netdev().
Fixes:
0fbc81b3ad51 ('chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's')
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Gottschall [Sat, 3 Mar 2018 04:10:44 +0000 (05:10 +0100)]
ath9k: fix crash in spectral scan
[ Upstream commit
221b6ec69ed9c56b6cd9a124a387a9472f14284e ]
Fixes crash seen on arm smp systems (gateworks ventana imx6):
Unable to handle kernel NULL pointer dereference at virtual address
00000014
pgd =
80004000
[
00000014] *pgd=
00000000
Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM
Modules linked in: ip6table_filter nf_conntrack_ipv6 ip6_tables nf_log_ipv6 nf_defrag_ipv6 shortcut_fe ipcomp6 xfrm_ipcomp xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet ip6_tunnel tunnel6 mip6 ah6 esp6 xfrm_algo sit ip_tunnel tunnel4 ipv6 ath10k_pci ath10k_core ath9k ath mac80211 cfg80211 compat ath_pci ath_hal(P) caamalg authencesn authenc caamrng caamhash caam_jr caam cdc_ncm usbnet usbcore sky2 imx2_wdt
CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: P 4.9.85 #19
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task:
bf064980 task.stack:
bf07c000
PC is at relay_buf_full+0xc/0x30
LR is at _674+0x740/0xf10 [ath9k]
pc : [<
8018bce0>] lr : [<
7f1aa604>] psr:
80000013
sp :
bf07dbf0 ip :
bf07dc00 fp :
bf07dbfc
r10:
0000003f r9 :
bf130e00 r8 :
809044b0
r7 :
00000000 r6 :
be67a9f0 r5 :
00000000 r4 :
809043e4
r3 :
c0864c24 r2 :
00000000 r1 :
00000004 r0 :
00000000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control:
10c5387d Table:
4e6a004a DAC:
00000055
Process ksoftirqd/0 (pid: 3, stack limit = 0xbf07c210)
Stack: (0xbf07dbf0 to 0xbf07e000)
dbe0:
bf07dd04 bf07dc00 7f1aa604 8018bce0
dc00:
00004014 be59e010 bf07dc34 bf07dc18 7f1a7084 7f19c07c be59c010 be6470a0
dc20:
0000096c be648954 bf07dc6c bf07dc38 7f1c286c bf07dd90 bf07dc5c bf07dc48
dc40:
8029ea4c 0000003c 00000001 be59c010 00000094 00000000 00000000 00000000
dc60:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dc80:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dca0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dcc0:
00000000 00000000 00000000 00000000 00000000 00000000 8010ef24 00000030
dce0:
be94f5e8 be6485a0 bddf0200 be59c010 be6465a0 be6415a0 bf07ddf4 bf07dd08
dd00:
7f1cf800 7f1aa55c 1fc38c4c 00000000 bf07dd58 cccccccd 66666667 be640bc0
dd20:
bf07dd54 be6415a0 1fc38c4c 00000000 00000000 be59c038 be67a9c0 be59e010
dd40:
be67a9f0 be647170 8090c904 be59c010 00000000 00000001 1fc38e84 00000000
dd60:
be640bc0 bddf0200 00000200 00000010 0000003f 00000002 20000013 be59c010
dd80:
8092d940 bf7ca2c0 bf07ddb4 bf07dd98 1fc38c4c 2602003f 0100ff1b 80ff1b00
dda0:
00808080 00000000 00000000 80808080 80808080 80808080 80808080 00008080
ddc0:
00000000 00000000 7f1b62b8 00000002 be6470ec be6470f0 00000000 bf07de98
dde0:
8092d940 be6415a0 bf07de94 bf07ddf8 7f1d1ed8 7f1cf1fc 00000000 00000000
de00:
bf7cc4c0 00000400 be6470f0 bf07de18 8015165c be59c010 8090453c 8090453c
de20:
bf07dec4 be6465a0 8014f614 80148884 0000619a 00000001 bf07c000 00000100
de40:
bf07de78 00000001 7f327850 00000002 afb50401 bf064980 bf07de9c bf07de68
de60:
bf064a00 803cc668 bf064a00 be6470b4 be6470b8 80844180 00000000 bf07de98
de80:
8092d940 bf07c000 bf07dec4 bf07de98 80124d18 7f1d1c44 80124c94 00000000
dea0:
00000006 80902098 80902080 40000006 00000100 bf07c000 bf07df24 bf07dec8
dec0:
8012501c 80124ca0 bf7cc4c0 bf064980 be95e1c0 04208040 80902d00 000061c7
dee0:
0000000a 80600b54 8092d940 808441f8 80902080 bf07dec8 bf03b200 bf07c000
df00:
bf03b200 8090fe54 00000000 00000000 00000000 00000000 bf07df34 bf07df28
df20:
80125148 80124f28 bf07df5c bf07df38 8013deb4 8012511c 00000000 bf03b240
df40:
bf03b200 8013dc90 00000000 00000000 bf07dfac bf07df60 8013ad40 8013dc9c
df60:
70448040 00000001 00000000 bf03b200 00000000 00030003 bf07df78 bf07df78
df80:
00000000 00000000 bf07df88 bf07df88 bf03b240 8013ac48 00000000 00000000
dfa0:
00000000 bf07dfb0 80107760 8013ac54 00000000 00000000 00000000 00000000
dfc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0:
00000000 00000000 00000000 00000000 00000013 00000000 8c120004 1190ad04
Backtrace:
[<
8018bcd4>] (relay_buf_full) from [<
7f1aa604>] (_674+0x740/0xf10 [ath9k])
[<
7f1aa550>] (_674 [ath9k]) from [<
7f1cf800>] (_582+0x14b4/0x3708 [ath9k])
r10:
be6415a0 r9:
be6465a0 r8:
be59c010 r7:
bddf0200 r6:
be6485a0 r5:
be94f5e8
r4:
00000030
[<
7f1cf1f0>] (_582 [ath9k]) from [<
7f1d1ed8>] (_735+0x2a0/0xec4 [ath9k])
r10:
be6415a0 r9:
8092d940 r8:
bf07de98 r7:
00000000 r6:
be6470f0 r5:
be6470ec
r4:
00000002
[<
7f1d1c38>] (_735 [ath9k]) from [<
80124d18>] (tasklet_action+0x84/0xf8)
r10:
bf07c000 r9:
8092d940 r8:
bf07de98 r7:
00000000 r6:
80844180 r5:
be6470b8
r4:
be6470b4
[<
80124c94>] (tasklet_action) from [<
8012501c>] (__do_softirq+0x100/0x1f4)
r10:
bf07c000 r9:
00000100 r8:
40000006 r7:
80902080 r6:
80902098 r5:
00000006
r4:
00000000 r3:
80124c94
[<
80124f1c>] (__do_softirq) from [<
80125148>] (run_ksoftirqd+0x38/0x4c)
r10:
00000000 r9:
00000000 r8:
00000000 r7:
00000000 r6:
8090fe54 r5:
bf03b200
r4:
bf07c000
[<
80125110>] (run_ksoftirqd) from [<
8013deb4>] (smpboot_thread_fn+0x224/0x260)
[<
8013dc90>] (smpboot_thread_fn) from [<
8013ad40>] (kthread+0xf8/0x100)
r9:
00000000 r8:
00000000 r7:
8013dc90 r6:
bf03b200 r5:
bf03b240 r4:
00000000
[<
8013ac48>] (kthread) from [<
80107760>] (ret_from_fork+0x14/0x34)
r7:
00000000 r6:
00000000 r5:
8013ac48 r4:
bf03b240
Code:
e89da800 e1a0c00d e92dd800 e24cb004 (
e5901014)
---[ end trace
dddf11ac9111b272 ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D 4.9.85 #19
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<
8010a708>] (dump_backtrace) from [<
8010a99c>] (show_stack+0x18/0x1c)
r7:
bf093f58 r6:
20000193 r5:
809168e8 r4:
00000000
[<
8010a984>] (show_stack) from [<
802a09c4>] (dump_stack+0x94/0xa8)
[<
802a0930>] (dump_stack) from [<
8010d184>] (handle_IPI+0xe8/0x180)
r7:
bf093f58 r6:
00000000 r5:
00000001 r4:
808478c4
[<
8010d09c>] (handle_IPI) from [<
801013e8>] (gic_handle_irq+0x78/0x7c)
r7:
f4000100 r6:
bf093f58 r5:
f400010c r4:
8090467c
[<
80101370>] (gic_handle_irq) from [<
8010b378>] (__irq_svc+0x58/0x8c)
Exception stack(0xbf093f58 to 0xbf093fa0)
3f40:
bf7d62a0 00000000
3f60:
0010a5f4 80113460 bf092000 809043e4 00000002 80904434 bf092008 412fc09a
3f80:
00000000 bf093fb4 bf093fb8 bf093fa8 8010804c 80108050 60000013 ffffffff
r9:
bf092000 r8:
bf092008 r7:
bf093f8c r6:
ffffffff r5:
60000013 r4:
80108050
[<
80108014>] (arch_cpu_idle) from [<
80553c2c>] (default_idle_call+0x30/0x34)
[<
80553bfc>] (default_idle_call) from [<
80158394>] (cpu_startup_entry+0xc4/0xfc)
[<
801582d0>] (cpu_startup_entry) from [<
8010ce40>] (secondary_start_kernel+0x168/0x174)
r7:
8092d2f8 r4:
80913568
[<
8010ccd8>] (secondary_start_kernel) from [<
10101488>] (0x10101488)
r5:
00000055 r4:
4f07806a
Rebooting in 10 seconds..
Reboot failed -- System halted
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jarosław Janik [Sun, 11 Mar 2018 18:51:56 +0000 (19:51 +0100)]
nvme-pci: disable APST for Samsung NVMe SSD 960 EVO + ASUS PRIME Z370-A
[ Upstream commit
467c77d4cbefaaf65e2f44fe102d543a52fcae5b ]
Yet another "incompatible" Samsung NVMe SSD 960 EVO and Asus motherboard
combination. 960 EVO device disappears from PCIe bus within few minutes
after boot-up when APST is in use and never gets back. Forcing
NVME_QUIRK_NO_APST is the only way to make this drive work with this
particular motherboard. NVME_QUIRK_NO_DEEPEST_PS doesn't work, upgrading
motherboard's BIOS didn't help either.
Since this is a desktop motherboard, the only drawback of not using APST
is increased device temperature.
Signed-off-by: Jarosław Janik <jaroslaw.janik@gmail.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Karthikeyan Periyasamy [Mon, 12 Mar 2018 11:39:40 +0000 (17:09 +0530)]
ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)
[ Upstream commit
8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ]
When attempt to run worker (ath10k_sta_rc_update_wk) after the station object
(ieee80211_sta) delete will trigger the kernel panic.
This problem arise in AP + Mesh configuration, Where the current node AP VAP
and neighbor node mesh VAP MAC address are same. When the current mesh node
try to establish the mesh link with neighbor node, driver peer creation for
the neighbor mesh node fails due to duplication MAC address. Already the AP
VAP created with same MAC address.
It is caused by the following scenario steps.
Steps:
1. In above condition, ath10k driver sta_state callback (ath10k_sta_state)
fails to do the state change for a station from IEEE80211_STA_NOTEXIST
to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is
called from ieee80211_add_station() to handle the new station
(neighbor mesh node) request from the wpa_supplicant.
2. Concurrently ath10k receive the sta_rc_update callback notification from
the mesh_neighbour_update() to handle the beacon frames of the above
neighbor mesh node. since its atomic callback, ath10k driver queue the
work (ath10k_sta_rc_update_wk) to handle rc update.
3. Due to driver sta_state callback fails (step 1), mac80211 free the station
object.
4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access
the station object which is already deleted. so it will trigger kernel
panic.
Added the peer exist check in sta_rc_update callback before queue the work.
Kernel Panic log:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd =
c0204000
[
00000000] *pgd=
00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1
task:
dcef0000 ti:
d72b6000 task.ti:
d72b6000
PC is at pwq_activate_delayed_work+0x10/0x40
LR is at pwq_activate_delayed_work+0xc/0x40
pc : [<
c023f988>] lr : [<
c023f984>] psr:
40000193
sp :
d72b7f18 ip :
0000007a fp :
d72b6000
r10:
00000000 r9 :
dd404414 r8 :
d8c31998
r7 :
d72b6038 r6 :
00000004 r5 :
d4907ec8 r4 :
dcee1300
r3 :
ffffffe0 r2 :
00000000 r1 :
00000001 r0 :
00000000
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control:
10c5787d Table:
595bc06a DAC:
00000015
...
Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238)
Stack: (0xd72b7f18 to 0xd72b8000)
7f00:
00000001 dcee1300
7f20:
00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089
7f40:
00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000
7f60:
00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000
7f80:
d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340
7fa0:
c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000
7fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0:
00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<
c023f988>] (pwq_activate_delayed_work) from [<
c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4)
[<
c02410dc>] (pwq_dec_nr_in_flight) from [<
c0242790>] (worker_thread+0x228/0x360)
[<
c0242790>] (worker_thread) from [<
c02474dc>] (kthread+0xd8/0xec)
[<
c02474dc>] (kthread) from [<
c0208d20>] (ret_from_fork+0x14/0x34)
Code:
e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs
Rebooting in 3 seconds..
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Fri, 23 Mar 2018 21:36:46 +0000 (00:36 +0300)]
watchdog: davinci_wdt: fix error handling in davinci_wdt_probe()
[ Upstream commit
d66e53649c18377edc08d48901e658e4fd491d46 ]
clk_disable_unprepare() was added to one error path,
but there is another one. The patch makes sure clk is
disabled at the both of them.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leon Romanovsky [Tue, 2 Jan 2018 14:49:56 +0000 (16:49 +0200)]
net/mlx5: Protect from command bit overflow
[ Upstream commit
957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ]
The system with CONFIG_UBSAN enabled on produces the following error
during driver initialization. The reason to it that max_reg_cmds can be
larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long.
================================================================================
UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42
signed integer overflow:
-
2147483648 - 1 cannot be represented in type 'int'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xe9/0x18f
? dma_virt_alloc+0x81/0x81
ubsan_epilogue+0xe/0x4e
handle_overflow+0x187/0x20c
mlx5_cmd_init+0x73a/0x12b0
mlx5_load_one+0x1c3d/0x1d30
init_one+0xd02/0xf10
pci_device_probe+0x26c/0x3b0
driver_probe_device+0x622/0xb40
__driver_attach+0x175/0x1b0
bus_for_each_dev+0xef/0x190
bus_add_driver+0x2db/0x490
driver_register+0x16b/0x1e0
__pci_register_driver+0x177/0x1b0
init+0x6d/0x92
do_one_initcall+0x15b/0x270
kernel_init_freeable+0x2d8/0x3d0
kernel_init+0x14/0x190
ret_from_fork+0x24/0x30
================================================================================
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Fri, 23 Mar 2018 09:44:27 +0000 (20:44 +1100)]
selftests: Print the test we're running to /dev/kmsg
[ Upstream commit
88893cf787d3062c631cc20b875068eb11756e03 ]
Some tests cause the kernel to print things to the kernel log
buffer (ie. printk), in particular oops and warnings etc. However when
running all the tests in succession it's not always obvious which
test(s) caused the kernel to print something.
We can narrow it down by printing which test directory we're running
in to /dev/kmsg, if it's writable.
Example output:
[ 170.149149] kselftest: Running tests in powerpc
[ 305.300132] kworker/dying (71) used greatest stack depth: 7776 bytes
left
[ 808.915456] kselftest: Running tests in pstore
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frank Asseg [Mon, 12 Mar 2018 18:57:06 +0000 (19:57 +0100)]
tools/thermal: tmon: fix for segfault
[ Upstream commit
6c59f64b7ecf2bccbe73931d7d573d66ed13b537 ]
Fixes a segfault occurring when e.g. <TAB> is pressed multiple times in the
ncurses tmon application. The segfault is caused by incrementing
cur_thermal_record in the main function without checking if it's value reached
NR_THERMAL_RECORD immediately. Since the boundary check only occurred in
update_thermal_data a race condition existed, which lead to an attempted read
beyond the last element of the trec array.
The fix was implemented by moving the cur_thermal_record incrementation to the
update_thermal_data function using a temporary variable on which the boundary
condition is checked before updating cur_thread_record, so that the variable is
never incremented beyond the trec array's boundary.
It seems the segfault does not occur on every machine: On a HP EliteBook G4 the
segfault happens, while it does not happen on a Thinkpad T540p.
Signed-off-by: Frank Asseg <frank.asseg@objecthunter.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amitkumar Karwar [Tue, 20 Mar 2018 13:40:41 +0000 (19:10 +0530)]
rsi: fix kernel panic observed on 64bit machine
[ Upstream commit
864db4d5085349fcfa1f260b5bcd2adde3d7f2ed ]
Following kernel panic is observed on 64bit machine while loading
the driver. It is fixed if we pass dynamically allocated memory to
SDIO for DMA.
BUG: unable to handle kernel paging request at
ffffeb04000172e0
IP: sg_miter_stop+0x56/0x70
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Modules linked in: rsi_sdio(OE+) rsi_91x(OE) btrsi(OE) rfcomm bluetooth
ecdh_generic mac80211 mmc_block fuse xt_CHECKSUM iptable_mangle
drm_kms_helper mmc_core serio_raw drm firewire_ohci tg3
CPU: 0 PID: 4003 Comm: insmod Tainted: G OE 4.16.0-rc1+ #27
Hardware name: Dell Inc. Latitude E5500 /0DW634, BIOS
A19 06/13/2013
RIP: 0010:sg_miter_stop+0x56/0x70
RSP: 0018:
ffff88007d003e78 EFLAGS:
00010002
RAX:
0000000000000003 RBX:
0000000000000004 RCX:
0000000000000000
RDX:
ffffeb04000172c0 RSI:
ffff88002f58002c RDI:
ffff88007d003e80
RBP:
0000000000000004 R08:
ffff88007d003e80 R09:
0000000000000008
R10:
0000000000000003 R11:
0000000000000001 R12:
0000000000000004
R13:
ffff88002f580028 R14:
0000000000000000 R15:
0000000000000004
FS:
00007f35c29db700(0000) GS:
ffff88007d000000(0000)
knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
ffffeb04000172e0 CR3:
000000007038e000 CR4:
00000000000406f0
Call Trace:
<IRQ>
sg_copy_buffer+0xc6/0xf0
sdhci_tasklet_finish+0x170/0x260 [sdhci]
tasklet_action+0xf4/0x100
__do_softirq+0xef/0x26e
irq_exit+0xbe/0xd0
do_IRQ+0x4a/0xc0
common_interrupt+0xa2/0xa2
</IRQ>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Wed, 21 Mar 2018 11:40:24 +0000 (17:10 +0530)]
powerpc/perf: Fix kernel address leak via sampling registers
[ Upstream commit
e1ebd0e5b9d0a10ba65e63a3514b6da8c6a5a819 ]
Current code in power_pmu_disable() does not clear the sampling
registers like Sampling Instruction Address Register (SIAR) and
Sampling Data Address Register (SDAR) after disabling the PMU. Since
these are userspace readable and could contain kernel addresses, add
code to explicitly clear the content of these registers.
Also add a "context synchronizing instruction" to enforce no further
updates to these registers as suggested by Power ISA v3.0B. From
section 9.4, on page 1108:
"If an mtspr instruction is executed that changes the value of a
Performance Monitor register other than SIAR, SDAR, and SIER, the
change is not guaranteed to have taken effect until after a
subsequent context synchronizing instruction has been executed (see
Chapter 11. "Synchronization Requirements for Context Alterations"
on page 1133)."
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[mpe: Massage change log and add ISA reference]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-rpi.git / log