Takashi Iwai [Fri, 10 Jul 2020 13:33:51 +0000 (15:33 +0200)]
ALSA: line6: Perform sanity check for each URB creation
commit
6e8a914ad619042c5f25a4feb663357c4170fd8d upstream.
LINE6 drivers create stream URBs with a fixed pipe without checking
its validity, and this may lead to a kernel WARNING at the submission
when a malformed USB descriptor is passed.
For avoiding the kernel warning, perform the similar sanity checks for
each pipe type at creating a URB.
Reported-by: syzbot+c190f6858a04ea7fbc52@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/s5hv9iv4hq8.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hilliard [Tue, 23 Jun 2020 19:24:15 +0000 (13:24 -0600)]
HID: quirks: Ignore Simply Automated UPB PIM
commit
1ee1369b46de1083238fced60ff718f59de4b8aa upstream.
As this is a cypress HID->COM RS232 style device that is handled
by the cypress_M8 driver we also need to add it to the ignore list
in hid-quirks.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Parschauer [Tue, 9 Jun 2020 10:00:53 +0000 (12:00 +0200)]
HID: quirks: Always poll Obins Anne Pro 2 keyboard
commit
ca28aff0e1dc7dce9e12a7fd9276b7118ce5e73a upstream.
The Obins Anne Pro 2 keyboard (04d9:a293) disconnects after a few
minutes of inactivity when using it wired and typing does not result
in any input events any more. This is a common firmware flaw. So add
the ALWAYS_POLL quirk for this device.
GitHub user Dietrich Moerman (dietrichm) tested the quirk and
requested my help in my project
https://github.com/sriemer/fix-linux-mouse issue 22 to provide
this patch.
Link: https://www.reddit.com/r/AnnePro/comments/gruzcb/anne_pro_2_linux_cant_type_after_inactivity/
Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Sun, 24 May 2020 23:51:34 +0000 (16:51 -0700)]
HID: magicmouse: do not set up autorepeat
commit
6363d2065cd399cf9d6dc9d08c437f8658831100 upstream.
Neither the trackpad, nor the mouse want input core to generate autorepeat
events for their buttons, so let's reset the bit (as hid-input sets it for
these devices based on the usage vendor code).
Cc: stable@vger.kernel.org
Reported-by: Yariv <oigevald+kernel@gmail.com>
Tested-by: Yariv <oigevald+kernel@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej S. Szmigiero [Sun, 5 Jul 2020 17:34:57 +0000 (19:34 +0200)]
HID: logitech-hidpp: avoid repeated "multiplier = " log messages
commit
e13762abf38ead29071407f32b9dcec38f21dc34 upstream.
These messages appear each time the mouse wakes from sleep, in my case
(Logitech M705), every minute or so.
Let's downgrade them to the "debug" level so they don't fill the kernel log
by default.
While we are at it, let's make clear that this is a wheel multiplier (and
not, for example, XY movement multiplier).
Fixes:
4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on Logitech mice")
Cc: stable@vger.kernel.org
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: Harry Cutts <hcutts@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Saravana Kannan [Mon, 11 May 2020 15:13:34 +0000 (16:13 +0100)]
slimbus: core: Fix mismatch in of_node_get/put
commit
01360857486c0e4435dea3aa2f78b47213b7cf6a upstream.
Adding missing corresponding of_node_put
Fixes:
7588a511bdb4 ("slimbus: core: add support to device tree helper")
Signed-off-by: Saravana Kannan <saravanak@google.com>
[Srini: added fixes tag, removed NULL check and updated log]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200511151334.362-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Taniya Das [Sun, 17 May 2020 10:04:19 +0000 (15:34 +0530)]
clk: qcom: gcc: Add support for a new frequency for SC7180
commit
1b70061f5939ff1cacd728821b4f378cb0fb7961 upstream.
There is a requirement to support 51.2MHz from GPLL6 for qup clocks,
thus update the frequency table and parent data/map to use the GPLL6
source PLL.
Fixes:
17269568f7267 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180")
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Link: https://lkml.kernel.org/r/1589709861-27580-2-git-send-email-tdas@codeaurora.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vinod Koul [Wed, 13 May 2020 06:54:20 +0000 (12:24 +0530)]
clk: qcom: gcc: Add missing UFS clocks for SM8150
commit
37c72e4cae37f0dace1abb3711ede7fbc6d0862a upstream.
Add the missing ufs card and ufs phy clocks for SM8150. They were missed
in earlier addition of clock driver.
Fixes:
2a1d7eb854bb ("clk: qcom: gcc: Add global clock controller driver for SM8150")
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lkml.kernel.org/r/20200513065420.32735-2-vkoul@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vinod Koul [Wed, 13 May 2020 06:54:19 +0000 (12:24 +0530)]
clk: qcom: gcc: Add GPU and NPU clocks for SM8150
commit
f73a4230d5bbc8fc7e1a2479ac997f786111c7bb upstream.
Add the GPU and NPU clocks for SM8150. They were missed in earlier
addition of clock driver.
Fixes:
2a1d7eb854bb ("clk: qcom: gcc: Add global clock controller driver for SM8150")
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lkml.kernel.org/r/20200513065420.32735-1-vkoul@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 19 May 2020 13:00:11 +0000 (15:00 +0200)]
mtd: rawnand: oxnas: Release all devices in the _remove() path
commit
0a5f45e57e35d0840bedb816974ce2e63406cd8b upstream.
oxnans_nand_remove() should release all MTD devices and clean all NAND
devices, not only the first one registered.
Fixes:
668592492409 ("mtd: nand: Add OX820 NAND Support")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-39-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 19 May 2020 13:00:10 +0000 (15:00 +0200)]
mtd: rawnand: oxnas: Unregister all devices on error
commit
b60391eb17b2956ff2fc4c348e5a464da21ff9cb upstream.
On error, the oxnas probe path just frees the device which failed and
aborts the probe, leaving unreleased resources.
Fix this situation by calling mtd_device_unregister()/nand_cleanup()
on these.
Fixes:
668592492409 ("mtd: nand: Add OX820 NAND Support")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-38-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 19 May 2020 13:00:08 +0000 (15:00 +0200)]
mtd: rawnand: oxnas: Keep track of registered devices
commit
383fc3f613e7eac9f2e3c13b6f9fb8c1f39cb9d5 upstream.
All initialized and registered devices should be listed somewhere so
that we can unregister/free them in the _remove() path.
This patch is not a fix per-se but is needed to apply three other
fixes coming right after, explaining the Fixes/Cc: stable tags.
Fixes:
668592492409 ("mtd: nand: Add OX820 NAND Support")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-36-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Álvaro Fernández Rojas [Fri, 22 May 2020 12:15:21 +0000 (14:15 +0200)]
mtd: rawnand: brcmnand: fix CS0 layout
commit
3d3fb3c5be9ce07fa85d8f67fb3922e4613b955b upstream.
Only v3.3-v5.0 have a different CS0 layout.
Controllers before v3.3 use the same layout for every CS.
Fixes:
27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200522121524.4161539-3-noltari@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Álvaro Fernández Rojas [Tue, 12 May 2020 08:24:51 +0000 (10:24 +0200)]
mtd: rawnand: brcmnand: correctly verify erased pages
commit
dcb351c03f2fa6a599de1061b174167e03ee312b upstream.
The current code checks that the whole OOB area is erased.
This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
fail due to the usable OOB bytes not being 0xff.
Correct this by only checking that data and ECC bytes aren't 0xff.
Fixes:
02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200512082451.771212-1-noltari@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 28 Apr 2020 09:42:55 +0000 (11:42 +0200)]
mtd: rawnand: timings: Fix default tR_max and tCCS_min timings
commit
4d8ec041d9c454029f6cd90622f6d81eb61e781c upstream.
tR and tCCS are currently wrongly expressed in femtoseconds, while we
expect these values to be expressed in picoseconds. Set right
hardcoded values.
Fixes:
6a943386ee36 mtd: rawnand: add default values for dynamic timings
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-3-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Fri, 24 Apr 2020 16:44:59 +0000 (18:44 +0200)]
mtd: rawnand: marvell: Fix probe error path
commit
c525b7af96714f72e316c70781570a4a3e1c2856 upstream.
Ensure all chips are deregistered and cleaned in case of error during
the probe.
Fixes:
02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-5-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Fri, 24 Apr 2020 16:44:58 +0000 (18:44 +0200)]
mtd: rawnand: marvell: Use nand_cleanup() when the device is not yet registered
commit
7a0c18fb5c71c6ac7d4662a145e4227dcd4a36a3 upstream.
Do not call nand_release() while the MTD device has not been
registered, use nand_cleanup() instead.
Fixes:
02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-4-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Fri, 24 Apr 2020 16:44:56 +0000 (18:44 +0200)]
mtd: rawnand: marvell: Fix the condition on a return code
commit
c27075772d1f1c8aaf276db9943b35adda8a8b65 upstream.
In a previous fix, I changed the condition on which the timeout of an
IRQ is reached from:
if (!ret)
into:
if (ret && !pending)
While having a non-zero return code is usual in the Linux kernel, here
ret comes from a wait_for_completion_timeout() which returns 0 when
the waiting period is too long.
Hence, the revised condition should be:
if (!ret && !pending)
The faulty patch did not produce any error because of the !pending
condition so this change is finally purely cosmetic and does not
change the actual driver behavior.
Fixes:
cafb56dd741e ("mtd: rawnand: marvell: prevent timeouts on a loaded machine")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-2-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Mon, 20 Apr 2020 19:13:58 +0000 (22:13 +0300)]
mtd: spi-nor: spansion: fix writes on S25FS512S
commit
5587fa489747a8e6cbd0558890458c862b797485 upstream.
Spansion S25FS-S family has an issue in the Basic Flash Parameter Table
(BFPT): Dword-11 bits 7:4 specify a page size of 512 bytes. Actually
this is configurable in the vendor unique register (CR3V) and even the
factory default setting is to "wrap at 256 bytes", so blindly relying
on BFPT breaks the page writes on these chips. Add the post-BFPT fixup
which restores the default page size of 256 bytes -- to properly read
CR3V this early is quite intrusive and should better be done as a new
feature; Alexander Sverdlin had the patch doing that:
https://patchwork.ozlabs.org/project/linux-mtd/patch/
20200227123657.26030-1-alexander.sverdlin@nokia.com/
Fixes:
dfd2b74530e ("mtd: spi-nor: add Spansion S25FS512S ID")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Tested-by: Kuldeep Singh <kuldeep.singh@nxp.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mantas Pucka [Wed, 15 Apr 2020 13:48:30 +0000 (16:48 +0300)]
mtd: spi-nor: winbond: Fix 4-byte opcode support for w25q256
commit
e8aec15dd5842b5b11b0e621a2293348d3574a61 upstream.
There are 2 different chips (w25q256fv and w25q256jv) that share
the same JEDEC ID. Only w25q256jv fully supports 4-byte opcodes.
Use SFDP header version to differentiate between them.
Fixes:
10050a02f7d5 ("mtd: spi-nor: Add 4B_OPCODES flag to w25q256")
Signed-off-by: Mantas Pucka <mantas@8devices.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeffrey Hugo [Thu, 28 May 2020 14:22:05 +0000 (07:22 -0700)]
clk: qcom: Add missing msm8998 ufs_unipro_core_clk_src
commit
b1e8d713e6b2d59ee3a7b57c0dab88a19ec0cf33 upstream.
ufs_unipro_core_clk_src is required to allow UFS to clock scale for power
savings.
Fixes:
b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lkml.kernel.org/r/20200528142205.44003-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aharon Landau [Mon, 27 Apr 2020 15:46:36 +0000 (18:46 +0300)]
RDMA/mlx5: Verify that QP is created with RQ or SQ
commit
0eacc574aae7300bf46c10c7116c3ba5825505b7 upstream.
RAW packet QP and underlay QP must be created with either
RQ or SQ, check that.
Fixes:
e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Link: https://lore.kernel.org/r/20200427154636.381474-37-leon@kernel.org
Signed-off-by: Aharon Landau <aharonl@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maulik Shah [Sun, 12 Apr 2020 14:50:04 +0000 (20:20 +0530)]
soc: qcom: rpmh-rsc: Allow using free WAKE TCS for active request
commit
38427e5a47bf83299da930bd474c6cb2632ad810 upstream.
When there are more than one WAKE TCS available and there is no dedicated
ACTIVE TCS available, invalidating all WAKE TCSes and waiting for current
transfer to complete in first WAKE TCS blocks using another free WAKE TCS
to complete current request.
Remove rpmh_rsc_invalidate() to happen from tcs_write() when WAKE TCSes
is re-purposed to be used for Active mode. Clear only currently used
WAKE TCS's register configuration.
Fixes:
2de4b8d33eab (drivers: qcom: rpmh-rsc: allow active requests from wake TCS)
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1586703004-13674-7-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Raju P.L.S.S.S.N [Sun, 12 Apr 2020 14:50:03 +0000 (20:20 +0530)]
soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCS
commit
15b3bf61b8d48f8e0ccd9d7f1bcb468b543da396 upstream.
For RSCs that have sleep & wake TCS but no dedicated active TCS, wake
TCS can be re-purposed to send active requests. Once the active requests
are sent and response is received, the active mode configuration needs
to be cleared so that controller can use wake TCS for sending wake
requests.
Introduce enable_tcs_irq() to enable completion IRQ for repurposed TCSes.
Fixes:
2de4b8d33eab (drivers: qcom: rpmh-rsc: allow active requests from wake TCS)
Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org>
[mkshah: call enable_tcs_irq() within drv->lock, update commit message]
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1586703004-13674-6-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maulik Shah [Sun, 12 Apr 2020 14:50:01 +0000 (20:20 +0530)]
soc: qcom: rpmh: Invalidate SLEEP and WAKE TCSes before flushing new data
commit
f5ac95f9ca2f439179a5baf48e1c0f22f83d936e upstream.
TCSes have previously programmed data when rpmh_flush() is called.
This can cause old data to trigger along with newly flushed.
Fix this by cleaning SLEEP and WAKE TCSes before new data is flushed.
With this there is no need to invoke rpmh_rsc_invalidate() call from
rpmh_invalidate().
Simplify rpmh_invalidate() by moving invalidate_batch() inside.
Fixes:
600513dfeef3 ("drivers: qcom: rpmh: cache sleep/wake state requests")
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1586703004-13674-4-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maulik Shah [Sun, 12 Apr 2020 14:50:00 +0000 (20:20 +0530)]
soc: qcom: rpmh: Update dirty flag only when data changes
commit
bb7000677a1b287206c8d4327c62442fa3050a8f upstream.
Currently rpmh ctrlr dirty flag is set for all cases regardless of data
is really changed or not. Add changes to update dirty flag when data is
changed to newer values. Update dirty flag everytime when data in batch
cache is updated since rpmh_flush() may get invoked from any CPU instead
of only last CPU going to low power mode.
Also move dirty flag updates to happen from within cache_lock and remove
unnecessary INIT_LIST_HEAD() call and a default case from switch.
Fixes:
600513dfeef3 ("drivers: qcom: rpmh: cache sleep/wake state requests")
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Srinivas Rao L <lsrao@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1586703004-13674-3-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jin Yao [Thu, 9 Apr 2020 07:07:55 +0000 (15:07 +0800)]
perf stat: Zero all the 'ena' and 'run' array slot stats for interval mode
commit
0e0bf1ea1147fcf74eab19c2d3c853cc3740a72f upstream.
As the code comments in perf_stat_process_counter() say, we calculate
counter's data every interval, and the display code shows ps->res_stats
avg value. We need to zero the stats for interval mode.
But the current code only zeros the res_stats[0], it doesn't zero the
res_stats[1] and res_stats[2], which are for ena and run of counter.
This patch zeros the whole res_stats[] for interval mode.
Fixes:
51fd2df1e882 ("perf stat: Fix interval output values")
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200409070755.17261-1-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 7 Apr 2020 23:23:15 +0000 (18:23 -0500)]
PCI/PM: Call .bridge_d3() hook only if non-NULL
commit
c3aaf086701d05a82c8156ee8620af41e5a7d6fe upstream.
26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") added
the struct pci_platform_pm_ops.bridge_d3() function pointer and
platform_pci_bridge_d3() to use it.
The .bridge_d3() op is implemented by acpi_pci_platform_pm, but not by
mid_pci_platform_pm. We don't expect platform_pci_bridge_d3() to be called
on Intel MID platforms, but nothing in the code itself would prevent that.
Check the .bridge_d3() pointer for NULL before calling it.
Fixes:
26ad34d510a8 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhu Yanjun [Mon, 6 Apr 2020 17:35:01 +0000 (20:35 +0300)]
RDMA/rxe: Set default vendor ID
commit
0184afd15a141d7ce24c32c0d86a1e3ba6bc0eb3 upstream.
The RXE driver doesn't set vendor_id and user space applications see
zeros. This causes to pyverbs tests to fail with the following traceback,
because the expectation is to have valid vendor_id.
Traceback (most recent call last):
File "tests/test_device.py", line 51, in test_query_device
self.verify_device_attr(attr)
File "tests/test_device.py", line 77, in verify_device_attr
assert attr.vendor_id != 0
In order to fix it, we will set vendor_id 0XFFFFFF, according to the IBTA
v1.4 A3.3.1 VENDOR INFORMATION section.
"""
A vendor that produces a generic controller (i.e., one that supports a
standard I/O protocol such as SRP), which does not have vendor specific
device drivers, may use the value of 0xFFFFFF in the VendorID field.
"""
Before:
hca_id: rxe0
transport: InfiniBand (0)
fw_ver: 0.0.0
node_guid: 5054:00ff:feaa:5363
sys_image_guid: 5054:00ff:feaa:5363
vendor_id: 0x0000
After:
hca_id: rxe0
transport: InfiniBand (0)
fw_ver: 0.0.0
node_guid: 5054:00ff:feaa:5363
sys_image_guid: 5054:00ff:feaa:5363
vendor_id: 0xffffff
Fixes:
8700e3e7c485 ("Soft RoCE driver")
Link: https://lore.kernel.org/r/20200406173501.1466273-1-leon@kernel.org
Signed-off-by: Zhu Yanjun <yanjunz@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomer Tayar [Wed, 1 Apr 2020 16:30:29 +0000 (19:30 +0300)]
habanalabs: Align protection bits configuration of all TPCs
commit
79c823c57e69d9e584a5ee4ee6406eb3854393ae upstream.
Align the protection bits configuration of all TPC cores to be as of TPC
core 0.
Fixes:
a513f9a7eca5 ("habanalabs: make tpc registers secured")
Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Johansen [Tue, 31 Mar 2020 06:37:54 +0000 (23:37 -0700)]
apparmor: ensure that dfa state tables have entries
commit
c27c6bd2c4d6b6bb779f9b722d5607993e1d5e5c upstream.
Currently it is possible to specify a state machine table with 0 length,
this is not valid as optional tables are specified by not defining
the table as present. Further this allows by-passing the base tables
range check against the next/check tables.
Fixes:
d901d6a298dc ("apparmor: dfa split verification of table headers")
Reported-by: Mike Salvatore <mike.salvatore@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Fri, 27 Mar 2020 14:42:28 +0000 (16:42 +0200)]
dmaengine: ti: k3-udma: Disable memcopy via MCU NAVSS on am654
commit
a4e688535a0829980d5ef1516c0713777a874c62 upstream.
Trace of a test for DMA memcpy domains slipped into the glue layer commit.
The memcpy support should be disabled on the MCU UDMAP.
Fixes:
d702419134133 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200327144228.11101-1-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinivas Kandagatla [Thu, 19 Mar 2020 12:14:18 +0000 (12:14 +0000)]
soc: qcom: socinfo: add missing soc_id sysfs entry
commit
27a344139c186889d742764d3c2a62b395949cef upstream.
Looks like SoC ID is not exported to sysfs for some reason.
This patch adds it!
This is mostly used by userspace libraries like Snapdragon
Neural Processing Engine (SNPE) SDK for checking supported SoC info.
Fixes:
efb448d0a3fc ("soc: qcom: Add socinfo driver")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200319121418.5180-1-srinivas.kandagatla@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Wang [Sun, 8 Mar 2020 06:34:37 +0000 (14:34 +0800)]
arm: dts: mt7623: add phy-mode property for gmac2
commit
ff5b89c2858f28006f9f9c0a88c55a679488192c upstream.
Add phy-mode property required by phylink on gmac2
Fixes:
b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Link: https://lore.kernel.org/r/70e3eff31ecd500ed4862d9de28325a4dbd15105.1583648927.git.sean.wang@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Buettner [Sat, 18 Jul 2020 07:20:03 +0000 (00:20 -0700)]
copy_xstate_to_kernel: Fix typo which caused GDB regression
commit
5714ee50bb4375bd586858ad800b1d9772847452 upstream.
This fixes a regression encountered while running the
gdb.base/corefile.exp test in GDB's test suite.
In my testing, the typo prevented the sw_reserved field of struct
fxregs_state from being output to the kernel XSAVES area. Thus the
correct mask corresponding to XCR0 was not present in the core file for
GDB to interrogate, resulting in the following behavior:
[kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/corefile/corefile testsuite/outputs/gdb.base/corefile/corefile.core
Reading symbols from testsuite/outputs/gdb.base/corefile/corefile...
[New LWP 232880]
warning: Unexpected size of section `.reg-xstate/232880' in core file.
With the typo fixed, the test works again as expected.
Signed-off-by: Kevin Buettner <kevinb@redhat.com>
Fixes:
9e4636545933 ("copy_xstate_to_kernel(): don't leave parts of destination uninitialized")
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Anderson [Wed, 15 Jul 2020 23:46:15 +0000 (16:46 -0700)]
regmap: debugfs: Don't sleep while atomic for fast_io regmaps
[ Upstream commit
299632e54b2e692d2830af84be51172480dc1e26 ]
If a regmap has "fast_io" set then its lock function uses a spinlock.
That doesn't work so well with the functions:
* regmap_cache_only_write_file()
* regmap_cache_bypass_write_file()
Both of the above functions have the pattern:
1. Lock the regmap.
2. Call:
debugfs_write_file_bool()
copy_from_user()
__might_fault()
__might_sleep()
Let's reorder things a bit so that we do all of our sleepable
functions before we grab the lock.
Fixes:
d3dc5430d68f ("regmap: debugfs: Allow writes to cache state settings")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200715164611.1.I35b3533e8a80efde0cec1cc70f71e1e74b2fa0da@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anthony Iliopoulos [Tue, 14 Jul 2020 11:11:59 +0000 (13:11 +0200)]
nvme: explicitly update mpath disk capacity on revalidation
[ Upstream commit
05b29021fba5e725dd385151ef00b6340229b500 ]
Commit
3b4b19721ec652 ("nvme: fix possible deadlock when I/O is
blocked") reverted multipath head disk revalidation due to deadlocks
caused by holding the bd_mutex during revalidate.
Updating the multipath disk blockdev size is still required though for
userspace to be able to observe any resizing while the device is
mounted. Directly update the bdev inode size to avoid unnecessarily
holding the bdev->bd_mutex.
Fixes:
3b4b19721ec652 ("nvme: fix possible deadlock when I/O is
blocked")
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Wed, 15 Jul 2020 22:28:38 +0000 (23:28 +0100)]
keys: asymmetric: fix error return code in software_key_query()
[ Upstream commit
6cbba1f9114a8134cff9138c79add15012fd52b9 ]
Fix to return negative error code -ENOMEM from kmalloc() error handling
case instead of 0, as done elsewhere in this function.
Fixes:
f1774cb8956a ("X.509: parse public key parameters from x509 for akcipher")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Krzysztof Kozlowski [Mon, 29 Jun 2020 08:16:29 +0000 (10:16 +0200)]
arm64: dts: spcfpga: Align GIC, NAND and UART nodenames with dtschema
[ Upstream commit
681a5c71fb829fc2193e3bb524af41525477f5c3 ]
Fix dtschema validator warnings like:
intc@
fffc1000: $nodename:0:
'intc@
fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$'
Fixes:
78cd6a9d8e15 ("arm64: dts: Add base stratix 10 dtsi")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Krzysztof Kozlowski [Fri, 26 Jun 2020 08:06:02 +0000 (10:06 +0200)]
ARM: dts: socfpga: Align L2 cache-controller nodename with dtschema
[ Upstream commit
d7adfe5ffed9faa05f8926223086b101e14f700d ]
Fix dtschema validator warnings like:
l2-cache@
fffff000: $nodename:0:
'l2-cache@
fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
Fixes:
475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Wed, 15 Jul 2020 16:26:04 +0000 (17:26 +0100)]
xprtrdma: fix incorrect header size calculations
[ Upstream commit
912288442cb2f431bf3c8cb097a5de83bc6dbac1 ]
Currently the header size calculations are using an assignment
operator instead of a += operator when accumulating the header
size leading to incorrect sizes. Fix this by using the correct
operator.
Addresses-Coverity: ("Unused value")
Fixes:
302d3deb2068 ("xprtrdma: Prevent inline overflow")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Enric Balletbo i Serra [Tue, 7 Jul 2020 10:34:12 +0000 (12:34 +0200)]
Revert "thermal: mediatek: fix register index error"
[ Upstream commit
a8f62f183021be389561570ab5f8c701a5e70298 ]
This reverts commit
eb9aecd90d1a39601e91cd08b90d5fee51d321a6
The above patch is supposed to fix a register index error on mt2701. It
is not clear if the problem solved is a hang or just an invalid value
returned, my guess is the second. The patch introduces, though, a new
hang on MT8173 device making them unusable. So, seems reasonable, revert
the patch because introduces a worst issue.
The reason I send a revert instead of trying to fix the issue for MT8173
is because the information needed to fix the issue is in the datasheet
and is not public. So I am not really able to fix it.
Fixes the following bug when CONFIG_MTK_THERMAL is set on MT8173
devices.
[ 2.222488] Unable to handle kernel paging request at virtual address
ffff8000125f5001
[ 2.230421] Mem abort info:
[ 2.233207] ESR = 0x96000021
[ 2.236261] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.241571] SET = 0, FnV = 0
[ 2.244623] EA = 0, S1PTW = 0
[ 2.247762] Data abort info:
[ 2.250640] ISV = 0, ISS = 0x00000021
[ 2.254473] CM = 0, WnR = 0
[ 2.257544] swapper pgtable: 4k pages, 48-bit VAs, pgdp=
0000000041850000
[ 2.264251] [
ffff8000125f5001] pgd=
000000013ffff003, pud=
000000013fffe003, pmd=
000000013fff9003, pte=
006800001100b707
[ 2.274867] Internal error: Oops:
96000021 [#1] PREEMPT SMP
[ 2.280432] Modules linked in:
[ 2.283483] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc6+ #162
[ 2.289914] Hardware name: Google Elm (DT)
[ 2.294003] pstate:
20000005 (nzCv daif -PAN -UAO)
[ 2.298792] pc : mtk_read_temp+0xb8/0x1c8
[ 2.302793] lr : mtk_read_temp+0x7c/0x1c8
[ 2.306794] sp :
ffff80001003b930
[ 2.310100] x29:
ffff80001003b930 x28:
0000000000000000
[ 2.315404] x27:
0000000000000002 x26:
ffff0000f9550b10
[ 2.320709] x25:
ffff0000f9550a80 x24:
0000000000000090
[ 2.326014] x23:
ffff80001003ba24 x22:
00000000610344c0
[ 2.331318] x21:
0000000000002710 x20:
00000000000001f4
[ 2.336622] x19:
0000000000030d40 x18:
ffff800011742ec0
[ 2.341926] x17:
0000000000000001 x16:
0000000000000001
[ 2.347230] x15:
ffffffffffffffff x14:
ffffff0000000000
[ 2.352535] x13:
ffffffffffffffff x12:
0000000000000028
[ 2.357839] x11:
0000000000000003 x10:
ffff800011295ec8
[ 2.363143] x9 :
000000000000291b x8 :
0000000000000002
[ 2.368447] x7 :
00000000000000a8 x6 :
0000000000000004
[ 2.373751] x5 :
0000000000000000 x4 :
ffff800011295cb0
[ 2.379055] x3 :
0000000000000002 x2 :
ffff8000125f5001
[ 2.384359] x1 :
0000000000000001 x0 :
ffff0000f9550a80
[ 2.389665] Call trace:
[ 2.392105] mtk_read_temp+0xb8/0x1c8
[ 2.395760] of_thermal_get_temp+0x2c/0x40
[ 2.399849] thermal_zone_get_temp+0x78/0x160
[ 2.404198] thermal_zone_device_update.part.0+0x3c/0x1f8
[ 2.409589] thermal_zone_device_update+0x34/0x48
[ 2.414286] of_thermal_set_mode+0x58/0x88
[ 2.418375] thermal_zone_of_sensor_register+0x1a8/0x1d8
[ 2.423679] devm_thermal_zone_of_sensor_register+0x64/0xb0
[ 2.429242] mtk_thermal_probe+0x690/0x7d0
[ 2.433333] platform_drv_probe+0x5c/0xb0
[ 2.437335] really_probe+0xe4/0x448
[ 2.440901] driver_probe_device+0xe8/0x140
[ 2.445077] device_driver_attach+0x7c/0x88
[ 2.449252] __driver_attach+0xac/0x178
[ 2.453082] bus_for_each_dev+0x78/0xc8
[ 2.456909] driver_attach+0x2c/0x38
[ 2.460476] bus_add_driver+0x14c/0x230
[ 2.464304] driver_register+0x6c/0x128
[ 2.468131] __platform_driver_register+0x50/0x60
[ 2.472831] mtk_thermal_driver_init+0x24/0x30
[ 2.477268] do_one_initcall+0x50/0x298
[ 2.481098] kernel_init_freeable+0x1ec/0x264
[ 2.485450] kernel_init+0x1c/0x110
[ 2.488931] ret_from_fork+0x10/0x1c
[ 2.492502] Code:
f9401081 f9400402 b8a67821 8b010042 (
b9400042)
[ 2.498599] ---[ end trace
e43e3105ed27dc99 ]---
[ 2.503367] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.511020] SMP: stopping secondary CPUs
[ 2.514941] Kernel Offset: disabled
[ 2.518421] CPU features: 0x090002,
25006005
[ 2.522595] Memory Limit: none
[ 2.525644] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--
Cc: Michael Kao <michael.kao@mediatek.com>
Fixes:
eb9aecd90d1a ("thermal: mediatek: fix register index error")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200707103412.1010823-1-enric.balletbo@collabora.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
dillon min [Tue, 14 Jul 2020 06:35:07 +0000 (14:35 +0800)]
ARM: dts: Fix dcan driver probe failed on am437x platform
[ Upstream commit
2a4117df9b436a0e4c79d211284ab2097bcd00dc ]
Got following d_can probe errors with kernel 5.8-rc1 on am437x
[ 10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[ OK ] Reached target Network.
[ 10.787363] c_can_platform
481cc000.can: probe failed
[ 10.792484] c_can_platform: probe of
481cc000.can failed with error -2
[ 10.799457] c_can_platform
481d0000.can: probe failed
[ 10.804617] c_can_platform: probe of
481d0000.can failed with error -2
actually, Tony has fixed this issue on am335x with the patch [3]
Since am437x has the same clock structure with am335x
[1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.
[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit
516f1117d0fb ("ARM: dts: Configure osc clock for d_can on
am335x")
Fixes:
1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision")
Signed-off-by: dillon min <dillon.minfei@gmail.com>
[tony@atomide.com: aligned commit message a bit for readability]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vasily Averin [Thu, 25 Jun 2020 09:39:51 +0000 (12:39 +0300)]
fuse: don't ignore errors from fuse_writepages_fill()
[ Upstream commit
7779b047a57f6824a43d0e1f70de2741b7426b9d ]
fuse_writepages() ignores some errors taken from fuse_writepages_fill() I
believe it is a bug: if .writepages is called with WB_SYNC_ALL it should
either guarantee that all data was successfully saved or return error.
Fixes:
26d614df1da9 ("fuse: Implement writepages callback")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anna Schumaker [Wed, 8 Jul 2020 14:33:40 +0000 (10:33 -0400)]
NFS: Fix interrupted slots by sending a solo SEQUENCE operation
[ Upstream commit
913fadc5b105c3619d9e8d0fe8899ff1593cc737 ]
We used to do this before
3453d5708b33, but this was changed to better
handle the NFS4ERR_SEQ_MISORDERED error code. This commit fixed the slot
re-use case when the server doesn't receive the interrupted operation,
but if the server does receive the operation then it could still end up
replying to the client with mis-matched operations from the reply cache.
We can fix this by sending a SEQUENCE to the server while recovering from
a SEQ_MISORDERED error when we detect that we are in an interrupted slot
situation.
Fixes:
3453d5708b33 (NFSv4.1: Avoid false retries when RPC calls are interrupted)
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuck Lever [Sat, 27 Jun 2020 16:35:20 +0000 (12:35 -0400)]
xprtrdma: Fix handling of connect errors
[ Upstream commit
af667527b0e34912d2cb3586d585f66db4e4f486 ]
Ensure that the connect worker is awoken if an attempt to establish
a connection is unsuccessful. Otherwise the worker waits forever
and the transport workload hangs.
Connect errors should not attempt to destroy the ep, since the
connect worker continues to use it after the handler runs, so these
errors are now handled independently of DISCONNECTED events.
Reported-by: Dan Aloni <dan@kernelim.com>
Fixes:
e28ce90083f0 ("xprtrdma: kmalloc rpcrdma_ep separate from rpcrdma_xprt")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuck Lever [Sat, 27 Jun 2020 16:35:15 +0000 (12:35 -0400)]
xprtrdma: Fix return code from rpcrdma_xprt_connect()
[ Upstream commit
dda9a951dd6dd6073bbaf2c8d3119da2f8fe2d5b ]
I noticed that when rpcrdma_xprt_connect() returns -ENOMEM,
instead of retrying the connect, the RPC client kills the
RPC task that requested the connection. We want a retry
here.
Fixes:
cb586decbb88 ("xprtrdma: Make sendctx queue lifetime the same as connection lifetime")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuck Lever [Sat, 27 Jun 2020 16:35:09 +0000 (12:35 -0400)]
xprtrdma: Fix recursion into rpcrdma_xprt_disconnect()
[ Upstream commit
4cf44be6f1e86da302085bf3e1dc2c86f3cdaaaa ]
Both Dan and I have observed two processes invoking
rpcrdma_xprt_disconnect() concurrently. In my case:
1. The connect worker invokes rpcrdma_xprt_disconnect(), which
drains the QP and waits for the final completion
2. This causes the newly posted Receive to flush and invoke
xprt_force_disconnect()
3. xprt_force_disconnect() sets CLOSE_WAIT and wakes up the RPC task
that is holding the transport lock
4. The RPC task invokes xprt_connect(), which calls ->ops->close
5. xprt_rdma_close() invokes rpcrdma_xprt_disconnect(), which tries
to destroy the QP.
Deadlock.
To prevent xprt_force_disconnect() from waking anything, handle the
clean up after a failed connection attempt in the xprt's sndtask.
The retry loop is removed from rpcrdma_xprt_connect() to ensure
that the newly allocated ep and id are properly released before
a REJECTED connection attempt can be retried.
Reported-by: Dan Aloni <dan@kernelim.com>
Fixes:
e28ce90083f0 ("xprtrdma: kmalloc rpcrdma_ep separate from rpcrdma_xprt")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuck Lever [Sat, 27 Jun 2020 16:35:04 +0000 (12:35 -0400)]
xprtrdma: Fix double-free in rpcrdma_ep_create()
[ Upstream commit
85bfd71bc34e20d9fadb745131f6314c36d0f75b ]
In the error paths, there's no need to call kfree(ep) after calling
rpcrdma_ep_put(ep).
Fixes:
e28ce90083f0 ("xprtrdma: kmalloc rpcrdma_ep separate from rpcrdma_xprt")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eddie James [Thu, 9 Jul 2020 19:57:05 +0000 (14:57 -0500)]
clk: AST2600: Add mux for EMMC clock
[ Upstream commit
c2407ab3bd55064d459bc822efd1c134e852798c ]
The EMMC clock can be derived from either the HPLL or the MPLL. Register
a clock mux so that the rate is calculated correctly based upon the
parent.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20200709195706.12741-2-eajames@linux.ibm.com
Acked-by: Joel Stanley <joel@jms.id.au>
Fixes:
d3d04f6c330a ("clk: Add support for AST2600 SoC")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 1 Jul 2020 20:11:29 +0000 (13:11 -0700)]
clk: mvebu: ARMADA_AP_CPU_CLK needs to select ARMADA_AP_CP_HELPER
[ Upstream commit
8e3709d7e3a67e2d3f42bd1fc2052353a5678944 ]
When building arm32 allmodconfig:
ld.lld: error: undefined symbol: ap_cp_unique_name
>>> referenced by ap-cpu-clk.c
>>> clk/mvebu/ap-cpu-clk.o:(ap_cpu_clock_probe) in archive drivers/built-in.a
ap_cp_unique_name is only compiled into the kernel image when
CONFIG_ARMADA_AP_CP_HELPER is selected (as it is not user selectable).
However, CONFIG_ARMADA_AP_CPU_CLK does not select it.
This has been a problem since the driver was added to the kernel but it
was not built before commit
c318ea261749 ("cpufreq: ap806: fix cpufreq
driver needs ap cpu clk") so it was never noticed.
Fixes:
f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20200701201128.2448427-1-natechancellor@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Mon, 6 Jul 2020 21:49:03 +0000 (00:49 +0300)]
serial: core: Initialise spin lock before use in uart_configure_port()
[ Upstream commit
f743061a85f5e9989df22ccbf07c80c98fc90e08 ]
The comment near to uart_port_spin_lock_init() says:
Ensure that the serial console lock is initialised early.
If this port is a console, then the spinlock is already initialised.
and there is nothing about enabled or disabled consoles. The commit
a3cb39d258ef ("serial: core: Allow detach and attach serial device
for console") made a change, which follows the comment, and also to
prevent reinitialisation of the lock in use, when user detaches and
attaches back the same console device. But this change discovers
another issue, that uart_add_one_port() tries to access a spin lock
that now may be uninitialised. This happens when a driver expects
the serial core to register a console on its behalf. In this case
we must initialise a spin lock before use.
Fixes:
a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
Reported-by: Marc Zyngier <maz@kernel.org>
Reported-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20200706214903.56148-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 9 Jul 2020 10:29:36 +0000 (13:29 +0300)]
staging: comedi: verify array index is correct before using it
[ Upstream commit
ef75e14a6c935eec82abac07ab68e388514e39bc ]
This code reads from the array before verifying that "trig" is a valid
index. If the index is wildly out of bounds then reading from an
invalid address could lead to an Oops.
Fixes:
a8c66b684efa ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200709102936.GA20875@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michał Mirosław [Thu, 28 May 2020 18:35:54 +0000 (20:35 +0200)]
usb: gadget: udc: atmel: fix uninitialized read in debug printk
[ Upstream commit
30517ffeb3bff842e1355cbc32f1959d9dbb5414 ]
Fixed commit moved the assignment of 'req', but did not update a
reference in the DBG() call. Use the argument as it was renamed.
Fixes:
5fb694f96e7c ("usb: gadget: udc: atmel: fix possible oops when unloading module")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Kleine-Budde [Mon, 6 Jul 2020 14:34:34 +0000 (16:34 +0200)]
spi: spi-sun6i: sun6i_spi_transfer_one(): fix setting of clock rate
[ Upstream commit
ed7815db70d17b1741883f2da8e1d80bc2efe517 ]
A SPI transfer defines the _maximum_ speed of the SPI transfer. However the
driver doesn't take into account that the clock divider is always rounded down
(due to integer arithmetics). This results in a too high clock rate for the SPI
transfer.
E.g.: with a mclk_rate of 24 MHz and a SPI transfer speed of 10 MHz, the
original code calculates a reg of "0", which results in a effective divider of
"2" and a 12 MHz clock for the SPI transfer.
This patch fixes the issue by using DIV_ROUND_UP() instead of a plain
integer division.
While there simplify the divider calculation for the CDR1 case, use
order_base_2() instead of two ilog2() calculations.
Fixes:
3558fe900e8a ("spi: sunxi: Add Allwinner A31 SPI controller driver")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200706143443.9855-2-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Ujfalusi [Wed, 1 Jul 2020 10:12:25 +0000 (13:12 +0300)]
dmaengine: dmatest: stop completed threads when running without set channel
[ Upstream commit
fd17d1abce426b4224a916a242b57be94272771b ]
The completed threads were not cleared and consequent run would result
threads accumulating:
echo 800000 > /sys/module/dmatest/parameters/test_buf_size
echo 2000 > /sys/module/dmatest/parameters/timeout
echo 50 > /sys/module/dmatest/parameters/iterations
echo 1 > /sys/module/dmatest/parameters/max_channels
echo "" > /sys/module/dmatest/parameters/channel
[ 237.507265] dmatest: Added 1 threads using dma1chan2
echo 1 > /sys/module/dmatest/parameters/run
[ 244.713360] dmatest: Started 1 threads using dma1chan2
[ 246.117680] dmatest: dma1chan2-copy0: summary 50 tests, 0 failures 2437.47 iops 977623 KB/s (0)
echo 1 > /sys/module/dmatest/parameters/run
[ 292.381471] dmatest: No channels configured, continue with any
[ 292.389307] dmatest: Added 1 threads using dma1chan3
[ 292.394302] dmatest: Started 1 threads using dma1chan2
[ 292.399454] dmatest: Started 1 threads using dma1chan3
[ 293.800835] dmatest: dma1chan3-copy0: summary 50 tests, 0 failures 2624.53 iops 975014 KB/s (0)
echo 1 > /sys/module/dmatest/parameters/run
[ 307.301429] dmatest: No channels configured, continue with any
[ 307.309212] dmatest: Added 1 threads using dma1chan4
[ 307.314197] dmatest: Started 1 threads using dma1chan2
[ 307.319343] dmatest: Started 1 threads using dma1chan3
[ 307.324492] dmatest: Started 1 threads using dma1chan4
[ 308.730773] dmatest: dma1chan4-copy0: summary 50 tests, 0 failures 2390.28 iops 965436 KB/s (0)
Fixes:
6b41030fdc79 ("dmaengine: dmatest: Restore default for channel")
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200701101225.8607-1-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Sun, 5 Jul 2020 11:56:20 +0000 (14:56 +0300)]
dmaengine: dw: Initialize channel before each transfer
[ Upstream commit
99ba8b9b0d9780e9937eb1d488d120e9e5c2533d ]
In some cases DMA can be used only with a consumer which does runtime power
management and on the platforms, that have DMA auto power gating logic
(see comments in the drivers/acpi/acpi_lpss.c), may result in DMA losing
its context. Simple mitigation of this issue is to initialize channel
each time the consumer initiates a transfer.
Fixes:
cfdf5b6cc598 ("dw_dmac: add support for Lynxpoint DMA controllers")
Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206403
Link: https://lore.kernel.org/r/20200705115620.51929-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sun, 17 May 2020 09:59:53 +0000 (11:59 +0200)]
iio: adc: ad7780: Fix a resource handling path in 'ad7780_probe()'
[ Upstream commit
b0536f9826a5ed3328d527b4fc1686867a9f3041 ]
If 'ad7780_init_gpios()' fails, we must not release some resources that
have not been allocated yet. Return directly instead.
Fixes:
5bb30e7daf00 ("staging: iio: ad7780: move regulator to after GPIO init")
Fixes:
9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Renato Lui Geh <renatogeh@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Thu, 2 Jul 2020 20:57:14 +0000 (13:57 -0700)]
bus: ti-sysc: Do not disable on suspend for no-idle
[ Upstream commit
a55de412228cc5a2b4bf8d2a09849898102633e2 ]
If we have "ti,no-idle" specified for a module we must not disable
the the module on suspend to keep things backwards compatible.
Fixes:
386cb76681ca ("bus: ti-sysc: Handle missed no-idle property in addition to no-idle-on-init")
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Thu, 2 Jul 2020 17:41:02 +0000 (10:41 -0700)]
bus: ti-sysc: Fix sleeping function called from invalid context for RTC quirk
[ Upstream commit
afe6f1eeb08f85e57f0a02b71efb5a0839606aac ]
With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with RTC probe:
BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:1736
...
(sysc_quirk_rtc) from [<
c060d01c>] (sysc_write_sysconfig+0x1c/0x60)
(sysc_write_sysconfig) from [<
c060d9f4>] (sysc_enable_module+0x11c/0x274)
(sysc_enable_module) from [<
c060f37c>] (sysc_probe+0xe9c/0x1380)
(sysc_probe) from [<
c06e9384>] (platform_drv_probe+0x48/0x98)
Fixes:
e8639e1c986a ("bus: ti-sysc: Handle module unlock quirk needed for some RTC")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Thu, 2 Jul 2020 17:44:20 +0000 (10:44 -0700)]
bus: ti-sysc: Fix wakeirq sleeping function called from invalid context
[ Upstream commit
9f9113925018d500a95df539014d9ff11ac2c02d ]
With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with
wakeirqs and serial console idled:
BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:242
...
(sysc_wait_softreset) from [<
c0606894>] (sysc_enable_module+0x48/0x274)
(sysc_enable_module) from [<
c0606c5c>] (sysc_runtime_resume+0x19c/0x1d8)
(sysc_runtime_resume) from [<
c0606cf0>] (sysc_child_runtime_resume+0x58/0x84)
(sysc_child_runtime_resume) from [<
c06eb7bc>] (__rpm_callback+0x30/0x12c)
(__rpm_callback) from [<
c06eb8d8>] (rpm_callback+0x20/0x80)
(rpm_callback) from [<
c06eb434>] (rpm_resume+0x638/0x7fc)
(rpm_resume) from [<
c06eb658>] (__pm_runtime_resume+0x60/0x9c)
(__pm_runtime_resume) from [<
c06edc08>] (handle_threaded_wake_irq+0x24/0x60)
(handle_threaded_wake_irq) from [<
c01befec>] (irq_thread_fn+0x1c/0x78)
(irq_thread_fn) from [<
c01bf30c>] (irq_thread+0x140/0x26c)
We have __pm_runtime_resume() call the sysc_runtime_resume() with spinlock
held and interrupts disabled.
Fixes:
d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dave Jiang [Thu, 25 Jun 2020 19:16:54 +0000 (12:16 -0700)]
dmaengine: idxd: fix misc interrupt handler thread unmasking
[ Upstream commit
e3122822a74033ba8d6d9af855078f9ab741e33f ]
Fix unmasking of misc interrupt handler when completing normal. It exits
early and skips the unmasking with the current implementation. Fix to
unmask interrupt when exiting normally.
Fixes:
bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators")
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/159311256528.855.11527922406329728512.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dave Jiang [Thu, 25 Jun 2020 19:17:42 +0000 (12:17 -0700)]
dmaengine: idxd: cleanup workqueue config after disabling
[ Upstream commit
da32b28c95a79e399e18c03f8178f41aec9c66e4 ]
After disabling a device, we should clean up the internal state for
the wqs and zero out the configuration registers. Without doing so can cause
issues when the user reprogram the wqs.
Fixes:
c52ca478233c ("dmaengine: idxd: add configuration component of driver")
Reported-by: Yixin Zhang <yixin.zhang@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Yixin Zhang <yixin.zhang@intel.com>
Link: https://lore.kernel.org/r/159311264246.1198.11955791213681679428.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Neil Armstrong [Thu, 18 Jun 2020 13:27:37 +0000 (15:27 +0200)]
arm64: dts: meson-gxl-s805x: reduce initial Mali450 core frequency
[ Upstream commit
b2037dafcf082cd24b88ae9283af628235df36e1 ]
When starting at 744MHz, the Mali 450 core crashes on S805X based boards:
lima
d00c0000.gpu: IRQ ppmmu3 not found
lima
d00c0000.gpu: IRQ ppmmu4 not found
lima
d00c0000.gpu: IRQ ppmmu5 not found
lima
d00c0000.gpu: IRQ ppmmu6 not found
lima
d00c0000.gpu: IRQ ppmmu7 not found
Internal error: synchronous external abort:
96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.2+ #492
Hardware name: Libre Computer AML-S805X-AC (DT)
pstate:
40000005 (nZcv daif -PAN -UAO)
pc : lima_gp_init+0x28/0x188
...
Call trace:
lima_gp_init+0x28/0x188
lima_device_init+0x334/0x534
lima_pdev_probe+0xa4/0xe4
...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Reverting to a safer 666Mhz frequency on the S805X that doesn't use the
GP0 PLL makes it more stable.
Fixes:
fd47716479f5 ("ARM64: dts: add S805X based P241 board")
Fixes:
0449b8e371ac ("arm64: dts: meson: add libretech aml-s805x-ac board")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20200618132737.14243-1-narmstrong@baylibre.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Wed, 17 Jun 2020 12:53:46 +0000 (14:53 +0200)]
arm64: dts: meson: add missing gxl rng clock
[ Upstream commit
95ca6f06dd4827ff63be5154120c7a8511cd9a41 ]
The peripheral clock of the RNG is missing for gxl while it is present
for gxbb.
Fixes:
1b3f6d148692 ("ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20200617125346.1163527-1-jbrunet@baylibre.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Thu, 25 Jun 2020 12:44:28 +0000 (13:44 +0100)]
phy: sun4i-usb: fix dereference of pointer phy0 before it is null checked
[ Upstream commit
38b1927e5bf9bcad4a2e33189ef1c5569f9599ba ]
Currently pointer phy0 is being dereferenced via the assignment of
phy on the call to phy_get_drvdata before phy0 is null checked, this
can lead to a null pointer dereference. Fix this by performing the
null check on phy0 before the call to phy_get_drvdata. Also replace
the phy0 == NULL check with the more usual !phy0 idiom.
Addresses-Coverity: ("Dereference before null check")
Fixes:
e6f32efb1b12 ("phy: sun4i-usb: Make sure to disable PHY0 passby for peripheral mode")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200625124428.83564-1-colin.king@canonical.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Mon, 25 May 2020 13:08:57 +0000 (21:08 +0800)]
phy: rockchip: Fix return value of inno_dsidphy_probe()
[ Upstream commit
fdc355a03df537bc8d8909b86d1688fe07c7032b ]
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes:
b7535a3bc0ba ("phy/rockchip: Add support for Innosilicon MIPI/LVDS/TTL PHY")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/1590412138-13903-1-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yoshihiro Shimoda [Thu, 18 Jun 2020 12:07:33 +0000 (21:07 +0900)]
dmaengine: sh: usb-dmac: set tx_result parameters
[ Upstream commit
466257d9968ac79575831250b039dc07566c7b13 ]
A client driver (renesas_usbhs) assumed that
dmaengine_tx_status() could return the residue even if
the transfer was completed. However, this was not correct
usage [1] and this caused to break getting the residue after
the commit
24461d9792c2 ("dmaengine: virt-dma: Fix access after
free in vchan_complete()") actually. So, this is possible to get
wrong received size if the usb controller gets a short packet.
For example, g_zero driver causes "bad OUT byte" errors.
To use the tx_result from the renesas_usbhs driver when
the transfer is completed, set the tx_result parameters.
Notes that the renesas_usbhs driver needs to update for it.
[1]
https://lore.kernel.org/dmaengine/
20200616165550.GP2324254@vkoul-mobl/
Reported-by: Hien Dang <hien.dang.eb@renesas.com>
Fixes:
24461d9792c2 ("dmaengine: virt-dma: Fix access after free in vchan_complete()")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1592482053-19433-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Ujfalusi [Thu, 18 Jun 2020 11:40:04 +0000 (14:40 +0300)]
dmaengine: ti: k3-udma: Fix delayed_work usage for tx drain workaround
[ Upstream commit
d964d5ff68dba21b53368656adec3fb5f50426bb ]
INIT_DELAYED_WORK_ONSTACK() must be used with on-stack delayed work, which
is not the case here.
Use normal delayed_work for the channels instead.
Fixes:
25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA")
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200618114004.6268-1-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nikhil Rao [Mon, 22 Jun 2020 20:38:34 +0000 (13:38 -0700)]
dmaengine: idxd: fix cdev locking for open and release
[ Upstream commit
66983bc18fad17d10766650b3685045f6f092d73 ]
add the wq lock in cdev open and release call. This fixes
race conditions observed in the open and close routines.
Fixes:
42d279f9137a ("dmaengine: idxd: add char driver to expose submission portal to userland")
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/159285824892.64944.2905413694915141834.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Wed, 17 Jun 2020 16:35:36 +0000 (11:35 -0500)]
soundwire: intel: fix memory leak with devm_kasprintf
[ Upstream commit
bf6d6e68d2028a2d82f4c106f50ec75cc1e6ef89 ]
The dais are allocated with devm_kcalloc() but their name isn't
resourced managed and never freed. Fix by also using devm_ for the dai
names as well.
Fixes:
c46302ec554c5 ('soundwire: intel: Add audio DAI ops')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20200617163536.17401-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Ujfalusi [Wed, 27 May 2020 06:53:57 +0000 (09:53 +0300)]
dmaengine: ti: k3-udma: Use correct node to read "ti,udma-atype"
[ Upstream commit
9f2f3ce3daed229eecf647acac44defbdee1f7c0 ]
The "ti,udma-atype" property is expected in the UDMA node and not in the
parent navss node.
Fixes:
0ebcf1a274c5 ("dmaengine: ti: k3-udma: Implement support for atype (for virtualization)")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200527065357.30791-1-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Syed Nayyar Waris [Mon, 16 Mar 2020 12:50:46 +0000 (18:20 +0530)]
counter: 104-quad-8: Add lock guards - filter clock prescaler
[ Upstream commit
d5ed76adb926a90fada98f518abc1ab6ef07d28f ]
Add lock protection from race conditions to the 104-quad-8 counter
driver for filter clock prescaler code changes. Mutex calls used for
protection.
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Fixes:
de65d0556343 ("counter: 104-quad-8: Support Filter Clock Prescaler")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Syed Nayyar Waris [Mon, 16 Mar 2020 12:50:06 +0000 (18:20 +0530)]
counter: 104-quad-8: Add lock guards - differential encoder
[ Upstream commit
708d98932893cea609386cefdfd190f757f5a61c ]
Add lock protection from race conditions to 104-quad-8 counter driver
for differential encoder status code changes. Mutex lock calls used for
protection.
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Fixes:
954ab5cc5f3e ("counter: 104-quad-8: Support Differential Encoder Cable Status")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Cameron [Sun, 17 May 2020 17:29:57 +0000 (18:29 +0100)]
iio:health:
afe4404 Fix timestamp alignment and prevent data leak.
[ Upstream commit
f88ecccac4be348bbcc6d056bdbc622a8955c04d ]
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 40 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
Fixes:
87aec56e27ef ("iio: health: Add driver for the TI
AFE4404 heart monitor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephan Gerhold [Sat, 25 Apr 2020 20:06:31 +0000 (13:06 -0700)]
Input: mms114 - add extra compatible for mms345l
[ Upstream commit
7842087b0196d674ed877d768de8f2a34d7fdc53 ]
MMS345L is another first generation touch screen from Melfas,
which uses mostly the same registers as MMS152.
However, there is some garbage printed during initialization.
Apparently MMS345L does not have the MMS152_COMPAT_GROUP register
that is read+printed during initialization.
TSP FW Rev: bootloader 0x6 / core 0x26 / config 0x26, Compat group: \x06
On earlier kernel versions the compat group was actually printed as
an ASCII control character, seems like it gets escaped now.
But we probably shouldn't print something from a random register.
Add a separate "melfas,mms345l" compatible that avoids reading
from the MMS152_COMPAT_GROUP register. This might also help in case
there is some other device-specific quirk in the future.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://lore.kernel.org/r/20200423102431.2715-1-stephan@gerhold.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Begunkov [Wed, 15 Jul 2020 19:20:45 +0000 (22:20 +0300)]
io_uring: fix recvmsg memory leak with buffer selection
commit
681fda8d27a66f7e65ff7f2d200d7635e64a8d05 upstream.
io_recvmsg() doesn't free memory allocated for struct io_buffer. This can
causes a leak when used with automatic buffer selection.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Mon, 22 Jun 2020 11:05:41 +0000 (13:05 +0200)]
spi: spi-fsl-dspi: Fix lockup if device is shutdown during SPI transfer
[ Upstream commit
3c525b69e8c1a9a6944e976603c7a1a713e728f9 ]
During shutdown, the driver should unregister the SPI controller
and stop the hardware. Otherwise the dspi_transfer_one_message() could
wait on completion infinitely.
Additionally, calling spi_unregister_controller() first in device
shutdown reverse-matches the probe function, where SPI controller is
registered at the end.
Fixes:
dc234825997e ("spi: spi-fsl-dspi: Adding shutdown hook")
Reported-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200622110543.5035-2-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 28 Apr 2020 10:20:13 +0000 (11:20 +0100)]
scsi: qla2xxx: make 1-bit bit-fields unsigned int
[ Upstream commit
78b874b7cbf09fbfadfa5f18a347ebef7bbb49fe ]
The bitfields mpi_fw_dump_reading and mpi_fw_dumped are currently signed
which is not recommended as the representation is an implementation defined
behaviour. Fix this by making the bit-fields unsigned ints.
Link: https://lore.kernel.org/r/20200428102013.1040598-1-colin.king@canonical.com
Fixes:
cbb01c2f2f63 ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling")
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sascha Hauer [Wed, 24 Jun 2020 07:00:45 +0000 (09:00 +0200)]
net: ethernet: mvneta: Add back interface mode validation
[ Upstream commit
41c2b6b4f0f807803bb49f65835d136941a70f85 ]
When writing the serdes configuration register was moved to
mvneta_config_interface() the whole code block was removed from
mvneta_port_power_up() in the assumption that its only purpose was to
write the serdes configuration register. As mentioned by Russell King
its purpose was also to check for valid interface modes early so that
later in the driver we do not have to care for unexpected interface
modes.
Add back the test to let the driver bail out early on unhandled
interface modes.
Fixes:
b4748553f53f ("net: ethernet: mvneta: Fix Serdes configuration for SoCs without comphy")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sascha Hauer [Wed, 24 Jun 2020 07:00:44 +0000 (09:00 +0200)]
net: ethernet: mvneta: Do not error out in non serdes modes
[ Upstream commit
d3d239dcb8aae6d7b10642d292b404e57604f7ea ]
In mvneta_config_interface() the RGMII modes are catched by the default
case which is an error return. The RGMII modes are valid modes for the
driver, so instead of returning an error add a break statement to return
successfully.
This avoids this warning for non comphy SoCs which use RGMII, like
SolidRun Clearfog:
WARNING: CPU: 0 PID: 268 at drivers/net/ethernet/marvell/mvneta.c:3512 mvneta_start_dev+0x220/0x23c
Fixes:
b4748553f53f ("net: ethernet: mvneta: Fix Serdes configuration for SoCs without comphy")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 10 Jul 2020 11:36:10 +0000 (14:36 +0300)]
xen/xenbus: Fix a double free in xenbus_map_ring_pv()
[ Upstream commit
ba8c423488974f02b538e9dc1730f0334f9b85aa ]
When there is an error the caller frees "info->node" so the free here
will result in a double free. We should just delete first kfree().
Fixes:
3848e4e0a32a ("xen/xenbus: avoid large structs and arrays on the stack")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200710113610.GA92345@mwanda
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Thu, 9 Jul 2020 05:13:40 +0000 (22:13 -0700)]
arm64: Add missing sentinel to erratum_1463225
[ Upstream commit
09c717c92b52df54918e12cbfe6a4658233fda69 ]
When the erratum_1463225 array was introduced a sentinel at the end was
missing thus causing a KASAN: global-out-of-bounds in
is_affected_midr_range_list on arm64 error.
Fixes:
a9e821b89daa ("arm64: Add KRYO4XX gold CPU cores to erratum list
1463225 and
1418040")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Link: https://lore.kernel.org/linux-arm-kernel/CA+G9fYs3EavpU89-rTQfqQ9GgxAMgMAk7jiiVrfP0yxj5s+Q6g@mail.gmail.com/
Link: https://lore.kernel.org/r/20200709051345.14544-1-f.fainelli@gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Cameron [Sun, 17 May 2020 17:29:56 +0000 (18:29 +0100)]
iio:health:
afe4403 Fix timestamp alignment and prevent data leak.
commit
3f9c6d38797e9903937b007a341dad0c251765d6 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 32 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
Fixes:
eec96d1e2d31 ("iio: health: Add driver for the TI
AFE4403 heart monitor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 7 Jun 2020 15:53:57 +0000 (16:53 +0100)]
iio:pressure:ms5611 Fix buffer element alignment
commit
8db4afe163bbdd93dca6fcefbb831ef12ecc6b4d upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
Here there is no data leak possibility so use an explicit structure
on the stack to ensure alignment and nice readable fashion.
The forced alignment of ts isn't strictly necessary in this driver
as the padding will be correct anyway (there isn't any). However
it is probably less fragile to have it there and it acts as
documentation of the requirement.
Fixes:
713bbb4efb9dc ("iio: pressure: ms5611: Add triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 7 Jun 2020 15:53:53 +0000 (16:53 +0100)]
iio:humidity:hts221 Fix alignment and data leak issues
commit
5c49056ad9f3c786f7716da2dd47e4488fc6bd25 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak
apart from previous readings.
Explicit alignment of ts needed to ensure consistent padding
on all architectures (particularly x86_32 with it's 4 byte alignment
of s64)
Fixes:
e4a70e3e7d84 ("iio: humidity: add support to hts221 rh/temp combo device")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Navid Emamdoost [Fri, 5 Jun 2020 02:44:44 +0000 (21:44 -0500)]
iio: pressure: zpa2326: handle pm_runtime_get_sync failure
commit
d88de040e1df38414fc1e4380be9d0e997ab4d58 upstream.
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Fixes:
03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuhong Yuan [Thu, 28 May 2020 06:41:21 +0000 (14:41 +0800)]
iio: mma8452: Add missed iio_device_unregister() call in mma8452_probe()
commit
d7369ae1f4d7cffa7574d15e1f787dcca184c49d upstream.
The function iio_device_register() was called in mma8452_probe().
But the function iio_device_unregister() was not called after
a call of the function mma8452_set_freefall_mode() failed.
Thus add the missed function call for one error case.
Fixes:
1a965d405fc6 ("drivers:iio:accel:mma8452: added cleanup provision in case of failure.")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Ranostay [Tue, 9 Jun 2020 03:01:16 +0000 (06:01 +0300)]
iio: core: add missing IIO_MOD_H2/ETHANOL string identifiers
commit
25f02d3242ab4d16d0cee2dec0d89cedb3747fa9 upstream.
Add missing strings to iio_modifier_names[] for proper modification
of channels.
Fixes:
b170f7d48443d (iio: Add modifiers for ethanol and H2 gases)
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dinghao Liu [Tue, 26 May 2020 10:47:17 +0000 (18:47 +0800)]
iio: magnetometer: ak8974: Fix runtime PM imbalance on error
commit
0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream.
When devm_regmap_init_i2c() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep the
counter balanced. For error paths after ak8974_set_power(),
ak8974_detect() and ak8974_reset(), things are the same.
However, When iio_triggered_buffer_setup() returns an error
code, there will be two PM usgae counter decrements.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Fixes:
7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 7 Jun 2020 15:53:52 +0000 (16:53 +0100)]
iio:humidity:hdc100x Fix alignment and data leak issues
commit
ea5e7a7bb6205d24371373cd80325db1bc15eded upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak apart
from previous readings.
Fixes:
16bf793f86b2 ("iio: humidity: hdc100x: add triggered buffer support for HDC100X")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Alison Schofield <amsfield22@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 7 Jun 2020 15:53:49 +0000 (16:53 +0100)]
iio:magnetometer:ak8974: Fix alignment and data leak issues
commit
838e00b13bfd4cac8b24df25bfc58e2eb99bcc70 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak appart from
previous readings.
Fixes:
7c94a8b2ee8cf ("iio: magn: add a driver for AK8974")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Thu, 9 Jul 2020 12:59:53 +0000 (15:59 +0300)]
arm64/alternatives: don't patch up internal branches
[ Upstream commit
5679b28142193a62f6af93249c0477be9f0c669b ]
Commit
f7b93d42945c ("arm64/alternatives: use subsections for replacement
sequences") moved the alternatives replacement sequences into subsections,
in order to keep the as close as possible to the code that they replace.
Unfortunately, this broke the logic in branch_insn_requires_update,
which assumed that any branch into kernel executable code was a branch
that required updating, which is no longer the case now that the code
sequences that are patched in are in the same section as the patch site
itself.
So the only way to discriminate branches that require updating and ones
that don't is to check whether the branch targets the replacement sequence
itself, and so we can drop the call to kernel_text_address() entirely.
Fixes:
f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
Reported-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20200709125953.30918-1-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Thu, 2 Jul 2020 10:15:27 +0000 (13:15 +0300)]
i2c: eg20t: Load module automatically if ID matches
[ Upstream commit
5f90786b31fb7d1e199a8999d46c4e3aea672e11 ]
The driver can't be loaded automatically because it misses
module alias to be provided. Add corresponding MODULE_DEVICE_TABLE()
call to the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sai Prakash Ranjan [Tue, 30 Jun 2020 18:00:55 +0000 (23:30 +0530)]
arm64: Add KRYO4XX silver CPU cores to erratum list
1530923 and
1024718
[ Upstream commit
9b23d95c539ebc5d6d6b5d6f20d2d7922384e76e ]
KRYO4XX silver/LITTLE CPU cores with revision r1p0 are affected by
erratum
1530923 and
1024718, so add them to the respective list.
The variant and revision bits are implementation defined and are
different from the their Cortex CPU counterparts on which they are
based on, i.e., r1p0 is equivalent to rdpe.
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Link: https://lore.kernel.org/r/7013e8a3f857ca7e82863cc9e34a614293d7f80c.1593539394.git.saiprakash.ranjan@codeaurora.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sai Prakash Ranjan [Tue, 30 Jun 2020 18:00:54 +0000 (23:30 +0530)]
arm64: Add KRYO4XX gold CPU cores to erratum list
1463225 and
1418040
[ Upstream commit
a9e821b89daa55cc940c546b124101939d3f0451 ]
KRYO4XX gold/big CPU core revisions r0p0 to r3p1 are affected by
erratum
1463225 and
1418040, so add them to the respective list.
The variant and revision bits are implementation defined and are
different from the their Cortex CPU counterparts on which they are
based on, i.e., (r0p0 to r3p1) is equivalent to (rcpe to rfpf).
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Link: https://lore.kernel.org/r/83780e80c6377c12ca51b5d53186b61241685e49.1593539394.git.saiprakash.ranjan@codeaurora.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sai Prakash Ranjan [Tue, 30 Jun 2020 18:00:53 +0000 (23:30 +0530)]
arm64: Add MIDR value for KRYO4XX gold CPU cores
[ Upstream commit
dce4f2807f6920bb907eb4cd4f95e7f42d918bc6 ]
Add MIDR value for KRYO4XX gold/big CPU cores which are
used in Qualcomm Technologies, Inc. SoCs. This will be
used to identify and apply erratum which are applicable
for these CPU cores.
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Link: https://lore.kernel.org/r/9093fb82e22441076280ca1b729242ffde80c432.1593539394.git.saiprakash.ranjan@codeaurora.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Peterson [Thu, 25 Jun 2020 19:42:17 +0000 (14:42 -0500)]
gfs2: The freeze glock should never be frozen
[ Upstream commit
c860f8ffbea8924de05a281b937128773d30a77c ]
Before this patch, some gfs2 code locked the freeze glock with LM_FLAG_NOEXP
(Do not freeze) flag, and some did not. We never want to freeze the freeze
glock, so this patch makes it consistently use LM_FLAG_NOEXP always.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Peterson [Thu, 25 Jun 2020 18:30:52 +0000 (13:30 -0500)]
gfs2: When freezing gfs2, use GL_EXACT and not GL_NOCACHE
[ Upstream commit
623ba664b74a20f22a2ef7ebd71e171d2d7c626f ]
Before this patch, the freeze code in gfs2 specified GL_NOCACHE in
several places. That's wrong because we always want to know the state
of whether the file system is frozen.
There was also a problem with freeze/thaw transitioning the glock from
frozen (EX) to thawed (SH) because gfs2 will normally grant glocks in EX
to processes that request it in SH mode, unless GL_EXACT is specified.
Therefore, the freeze/thaw code, which tried to reacquire the glock in
SH mode would get the glock in EX mode, and miss the transition from EX
to SH. That made it think the thaw had completed normally, but since the
glock was still cached in EX, other nodes could not freeze again.
This patch removes the GL_NOCACHE flag to allow the freeze glock to be
cached. It also adds the GL_EXACT flag so the glock is fully transitioned
from EX to SH, thereby allowing future freeze operations.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Peterson [Thu, 25 Jun 2020 18:30:18 +0000 (13:30 -0500)]
gfs2: read-only mounts should grab the sd_freeze_gl glock
[ Upstream commit
b780cc615ba4795a7ef0e93b19424828a5ad456a ]
Before this patch, only read-write mounts would grab the freeze
glock in read-only mode, as part of gfs2_make_fs_rw. So the freeze
glock was never initialized. That meant requests to freeze, which
request the glock in EX, were granted without any state transition.
That meant you could mount a gfs2 file system, which is currently
frozen on a different cluster node, in read-only mode.
This patch makes read-only mounts lock the freeze glock in SH mode,
which will block for file systems that are frozen on another node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>