Parav Pandit [Wed, 13 Jan 2021 12:17:01 +0000 (14:17 +0200)]
IB/mlx5: Add mutex destroy call to cap_mask_mutex mutex
[ Upstream commit
ab40530a2e0a7aca9a5187824c4fb072f3916e85 ]
mutex_destroy() call for device's cap_mask_mutex mutex is missing, let's
add it to annotate destruction.
Fixes:
e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Link: https://lore.kernel.org/r/20210113121703.559778-4-leon@kernel.org
Signed-off-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yishai Hadas [Wed, 30 Dec 2020 13:01:19 +0000 (15:01 +0200)]
RDMA/mlx5: Use the correct obj_id upon DEVX TIR creation
[ Upstream commit
8798e4ad0abe0ba1221928a46561981c510be0c6 ]
Use the correct obj_id upon DEVX TIR creation by strictly taking the tirn
24 bits and not the general obj_id which is 32 bits.
Fixes:
7efce3691d33 ("IB/mlx5: Add obj create and destroy functionality")
Link: https://lore.kernel.org/r/20201230130121.180350-2-leon@kernel.org
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guido Günther [Mon, 18 Jan 2021 16:31:10 +0000 (17:31 +0100)]
spi: imx: Don't print error on -EPROBEDEFER
[ Upstream commit
8346633f2c87713a1852d802305e03555e9a9fce ]
This avoids
[ 0.962538] spi_imx
30820000.spi: bitbang start failed with -517
durig driver probe.
Fixes:
8197f489f4c4 ("spi: imx: Fix failure path leak on GPIO request error correctly")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/0f51ab42e7c7a3452f2f8652794d81584303ea0d.1610987414.git.agx@sigxcpu.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Rix [Mon, 18 Jan 2021 21:19:55 +0000 (13:19 -0800)]
clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined
[ Upstream commit
7da390694afbaed8e0f05717a541dfaf1077ba51 ]
When DEBUG is defined this error occurs
drivers/clocksource/mxs_timer.c:138:1: error:
expected ‘;’ before ‘}’ token
The preceding statement needs a semicolon.
Replace pr_info() with pr_debug() and remove the unneeded ifdef.
Fixes:
eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' interface")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210118211955.763609-1-trix@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Sun, 3 Jan 2021 13:59:24 +0000 (14:59 +0100)]
clocksource/drivers/ixp4xx: Select TIMER_OF when needed
[ Upstream commit
7a3b8758bd6e45f7b671723b5c9fa2b69d0787ae ]
Compile-testing the ixp4xx timer with CONFIG_OF enabled but
CONFIG_TIMER_OF disabled leads to a harmless warning:
arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ixp4xx.o' being placed in section `__timer_of_table'
Move the select statement from the platform code into the driver
so it always gets enabled in configurations that rely on it.
Fixes:
40df14cc5cc0 ("clocksource/drivers/ixp4xx: Add OF initialization support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210103135955.3808976-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Sat, 16 Jan 2021 21:13:10 +0000 (13:13 -0800)]
power: supply: fix sbs-charger build, needs REGMAP_I2C
[ Upstream commit
a4bdea2004b28f47ab48ea99172eda8628f6fb44 ]
CHARGER_SBS should select REGMAP_I2C since it uses API(s) that are
provided by that Kconfig symbol.
Fixes these errors:
../drivers/power/supply/sbs-charger.c:149:21: error: variable ‘sbs_regmap’ has initializer but incomplete type
static const struct regmap_config sbs_regmap = {
../drivers/power/supply/sbs-charger.c:150:3: error: ‘const struct regmap_config’ has no member named ‘reg_bits’
.reg_bits = 8,
../drivers/power/supply/sbs-charger.c:155:23: error: ‘REGMAP_ENDIAN_LITTLE’ undeclared here (not in a function)
.val_format_endian = REGMAP_ENDIAN_LITTLE, /* since based on SMBus */
../drivers/power/supply/sbs-charger.c: In function ‘sbs_probe’:
../drivers/power/supply/sbs-charger.c:183:17: error: implicit declaration of function ‘devm_regmap_init_i2c’; did you mean ‘devm_request_irq’? [-Werror=implicit-function-declaration]
chip->regmap = devm_regmap_init_i2c(client, &sbs_regmap);
../drivers/power/supply/sbs-charger.c: At top level:
../drivers/power/supply/sbs-charger.c:149:35: error: storage size of ‘sbs_regmap’ isn’t known
static const struct regmap_config sbs_regmap = {
Fixes:
feb583e37f8a ("power: supply: add sbs-charger driver")
Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dave Jiang [Fri, 15 Jan 2021 21:53:07 +0000 (14:53 -0700)]
dmaengine: idxd: set DMA channel to be private
[ Upstream commit
c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ]
Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are
expected to be used by a single client and not shared. While doing NTB
testing this mistake was discovered, which prevented ntb_transport from
requesting DSA wqs as DMA channels via dma_request_channel().
Reported-by: Srinijia Kambham <srinija.kambham@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Srinijia Kambham <srinija.kambham@intel.com>
Fixes:
8f47d1a5e545 ("dmaengine: idxd: connect idxd to dmaengine subsystem")
Link: https://lore.kernel.org/r/161074758743.2184057.3388557138816350980.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bartosz Golaszewski [Thu, 14 Jan 2021 10:22:17 +0000 (11:22 +0100)]
rtc: s5m: select REGMAP_I2C
[ Upstream commit
1f0cbda3b452b520c5f3794f8f0e410e8bc7386a ]
The rtc-s5m uses the I2C regmap but doesn't select it in Kconfig so
depending on the configuration the build may fail. Fix it.
Fixes:
959df7778bbd ("rtc: Enable compile testing for Maxim and Samsung drivers")
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210114102219.23682-2-brgl@bgdev.pl
Signed-off-by: Sasha Levin <sashal@kernel.org>
Claudiu Beznea [Wed, 16 Dec 2020 12:57:31 +0000 (14:57 +0200)]
power: reset: at91-sama5d2_shdwc: fix wkupdbc mask
[ Upstream commit
95aa21a3f1183260db1b0395e03df5bebc5ed641 ]
According to datasheet WKUPDBC mask is b/w bits 26..24.
Fixes:
f80cb48843987 ("power: reset: at91-shdwc: add new shutdown controller driver")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:19:14 +0000 (15:19 +0100)]
RDMA/rtrs-srv: Init wr_cnt as 1
[ Upstream commit
6f5d1b3016d650f351e65c645a5eee5394547dd0 ]
Fix up wr_avail accounting. if wr_cnt is 0, then we do SIGNAL for first
wr, in completion we add queue_depth back, which is not right in the
sense of tracking for available wr.
So fix it by init wr_cnt to 1.
Fixes:
9cb837480424 ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20201217141915.56989-19-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guoqing Jiang [Thu, 17 Dec 2020 14:19:10 +0000 (15:19 +0100)]
RDMA/rtrs-clt: Refactor the failure cases in alloc_clt
[ Upstream commit
eab098246625e91c1cbd6e8f75b09e4c9c28a9fc ]
Make all failure cases go to the common path to avoid duplicate code.
And some issued existed before.
1. clt need to be freed to avoid memory leak.
2. return ERR_PTR(-ENOMEM) if kobject_create_and_add fails, because
rtrs_clt_open checks the return value of by call "IS_ERR(clt)".
Fixes:
6a98d71daea1 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20201217141915.56989-15-jinpu.wang@cloud.ionos.com
Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:19:09 +0000 (15:19 +0100)]
RDMA/rtrs-srv: Fix missing wr_cqe
[ Upstream commit
8537f2de6519945890a2b0f3739b23f32b5c0a89 ]
We had a few places wr_cqe is not set, which could lead to NULL pointer
deref or GPF in error case.
Fixes:
9cb837480424 ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20201217141915.56989-14-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guoqing Jiang [Thu, 17 Dec 2020 14:19:03 +0000 (15:19 +0100)]
RDMA/rtrs: Call kobject_put in the failure path
[ Upstream commit
424774c9f3fa100ef7d9cfb9ee211e2ba1cd5119 ]
Per the comment of kobject_init_and_add, we need to free the memory
by call kobject_put.
Fixes:
215378b838df ("RDMA/rtrs: client: sysfs interface functions")
Fixes:
91b11610af8d ("RDMA/rtrs: server: sysfs interface functions")
Link: https://lore.kernel.org/r/20201217141915.56989-8-jinpu.wang@cloud.ionos.com
Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Reviewed-by: Gioh Kim <gi-oh.kim@cloud.ionos.com>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:19:01 +0000 (15:19 +0100)]
RDMA/rtrs-clt: Set mininum limit when create QP
[ Upstream commit
f47e4e3e71724f625958b0059f6c8ac5d44d27ef ]
Currently rtrs when create_qp use a coarse numbers (bigger in general),
which leads to hardware create more resources which only waste memory
with no benefits.
- SERVICE con,
For max_send_wr/max_recv_wr, it's 2 times SERVICE_CON_QUEUE_DEPTH + 2
- IO con
For max_send_wr/max_recv_wr, it's sess->queue_depth * 3 + 1
Fixes:
6a98d71daea1 ("RDMA/rtrs: client: main functionality")
Link: https://lore.kernel.org/r/20201217141915.56989-6-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:19:00 +0000 (15:19 +0100)]
RDMA/rtrs-srv: Use sysfs_remove_file_self for disconnect
[ Upstream commit
f991fdac813f1598a9bb17b602ce04812ba9148c ]
Remove self first to avoid deadlock, we don't want to
use close_work to remove sess sysfs.
Fixes:
91b11610af8d ("RDMA/rtrs: server: sysfs interface functions")
Link: https://lore.kernel.org/r/20201217141915.56989-5-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Tested-by: Lutz Pogrell <lutz.pogrell@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:18:59 +0000 (15:18 +0100)]
RDMA/rtrs-srv: Release lock before call into close_sess
[ Upstream commit
99f0c3807973359bba8f37d9198eea59fe38c32a ]
In this error case, we don't need hold mutex to call close_sess.
Fixes:
9cb837480424 ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20201217141915.56989-4-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Tested-by: Lutz Pogrell <lutz.pogrell@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Thu, 17 Dec 2020 14:18:57 +0000 (15:18 +0100)]
RDMA/rtrs: Extend ibtrs_cq_qp_create
[ Upstream commit
7490fd1fe836ba3c7eda7a4b1cfd9e44389ffda5 ]
rtrs does not have same limit for both max_send_wr and max_recv_wr,
To allow client and server set different values, export in a separate
parameter for rtrs_cq_qp_create.
Also fix the type accordingly, u32 should be used instead of u16.
Fixes:
c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and server modules")
Link: https://lore.kernel.org/r/20201217141915.56989-2-jinpu.wang@cloud.ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicolas Boichat [Fri, 15 Jan 2021 11:45:44 +0000 (11:45 +0000)]
of/fdt: Make sure no-map does not remove already reserved regions
[ Upstream commit
8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ]
If the device tree is incorrectly configured, and attempts to
define a "no-map" reserved memory that overlaps with the kernel
data/code, the kernel would crash quickly after boot, with no
obvious clue about the nature of the issue.
For example, this would happen if we have the kernel mapped at
these addresses (from /proc/iomem):
40000000-
41ffffff : System RAM
40080000-
40dfffff : Kernel code
40e00000-
411fffff : reserved
41200000-
413e0fff : Kernel data
And we declare a no-map shared-dma-pool region at a fixed address
within that range:
mem_reserved: mem_region {
compatible = "shared-dma-pool";
reg = <0 0x40000000 0 0x01A00000>;
no-map;
};
To fix this, when removing memory regions at early boot (which is
what "no-map" regions do), we need to make sure that the memory
is not already reserved. If we do, __reserved_mem_reserve_reg
will throw an error:
[ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
for node 'mem_region': base 0x0000000040000000, size 26 MiB
and the code that will try to use the region should also fail,
later on.
We do not do anything for non-"no-map" regions, as memblock
explicitly allows reserved regions to overlap, and the commit
that this fixes removed the check for that precise reason.
[ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ]
Fixes:
094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
KarimAllah Ahmed [Fri, 15 Jan 2021 11:45:43 +0000 (11:45 +0000)]
fdt: Properly handle "no-map" field in the memory region
[ Upstream commit
86588296acbfb1591e92ba60221e95677ecadb43 ]
Mark the memory region with NOMAP flag instead of completely removing it
from the memory blocks. That makes the FDT handling consistent with the EFI
memory map handling.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Fri, 15 Jan 2021 13:15:24 +0000 (13:15 +0000)]
power: supply: cpcap-charger: Fix power_supply_put on null battery pointer
[ Upstream commit
39196cfe10dd2b46ee28b44abbc0db4f4cb7822f ]
Currently if the pointer battery is null there is a null pointer
dereference on the call to power_supply_put. Fix this by only
performing the put if battery is not null.
Addresses-Coverity: ("Dereference after null check")
Fixes:
4bff91bb3231 ("power: supply: cpcap-charger: Fix missing power_supply_put()")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Sun, 10 Jan 2021 19:53:50 +0000 (21:53 +0200)]
power: supply: cpcap-battery: Fix missing power_supply_put()
[ Upstream commit
97456a24acb41b74ab6910f40fb8f09b206fd3b5 ]
Fix missing power_supply_put().
Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Carl Philipp Klemm <philipp@uvos.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Fixes:
8b0134cc14b9 ("power: supply: cpcap-battery: Fix handling of lowered charger voltage")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Sun, 10 Jan 2021 19:53:49 +0000 (21:53 +0200)]
power: supply: cpcap-charger: Fix missing power_supply_put()
[ Upstream commit
4bff91bb3231882b530af794c92ac3a5fe199481 ]
Fix missing power_supply_put().
Cc: Arthur Demchenkov <spinal.by@gmail.com>
Cc: Carl Philipp Klemm <philipp@uvos.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Fixes:
5688ea049233 ("power: supply: cpcap-charger: Allow changing constant charge voltage")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yoshihiro Shimoda [Tue, 12 Jan 2021 09:00:56 +0000 (18:00 +0900)]
mfd: bd9571mwv: Use devm_mfd_add_devices()
[ Upstream commit
c58ad0f2b052b5675d6394e03713ee41e721b44c ]
To remove mfd devices when unload this driver, should use
devm_mfd_add_devices() instead.
Fixes:
d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ferry Toth [Tue, 12 Jan 2021 22:37:49 +0000 (23:37 +0100)]
dmaengine: hsu: disable spurious interrupt
[ Upstream commit
035b73b2b3b2e074a56489a7bf84b6a8012c0e0d ]
On Intel Tangier B0 and Anniedale the interrupt line, disregarding
to have different numbers, is shared between HSU DMA and UART IPs.
Thus on such SoCs we are expecting that IRQ handler is called in
UART driver only. hsu_pci_irq was handling the spurious interrupt
from HSU DMA by returning immediately. This wastes CPU time and
since HSU DMA and HSU UART interrupt occur simultaneously they race
to be handled causing delay to the HSU UART interrupt handling.
Fix this by disabling the interrupt entirely.
Fixes:
4831e0d9054c ("serial: 8250_mid: handle interrupt correctly in DMA case")
Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210112223749.97036-1-ftoth@exalondelft.nl
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 12 Dec 2020 16:25:35 +0000 (17:25 +0100)]
dmaengine: owl-dma: Fix a resource leak in the remove function
[ Upstream commit
1f0a16f04113f9f0ab0c8e6d3abe661edab549e6 ]
A 'dma_pool_destroy()' call is missing in the remove function.
Add it.
This call is already made in the error handling path of the probe function.
Fixes:
47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201212162535.95727-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 12 Dec 2020 16:06:14 +0000 (17:06 +0100)]
dmaengine: fsldma: Fix a resource leak in an error handling path of the probe function
[ Upstream commit
b202d4e82531a62a33a6b14d321dd2aad491578e ]
In case of error, the previous 'fsl_dma_chan_probe()' calls must be undone
by some 'fsl_dma_chan_remove()', as already done in the remove function.
It was added in the remove function in commit
77cd62e8082b ("fsldma: allow
Freescale Elo DMA driver to be compiled as a module")
Fixes:
d3f620b2c4fe ("fsldma: simplify IRQ probing and handling")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201212160614.92576-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 12 Dec 2020 16:05:16 +0000 (17:05 +0100)]
dmaengine: fsldma: Fix a resource leak in the remove function
[ Upstream commit
cbc0ad004c03ad7971726a5db3ec84dba3dcb857 ]
A 'irq_dispose_mapping()' call is missing in the remove function.
Add it.
This is needed to undo the 'irq_of_parse_and_map() call from the probe
function and already part of the error handling path of the probe function.
It was added in the probe function only in commit
d3f620b2c4fe ("fsldma:
simplify IRQ probing and handling")
Fixes:
77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201212160516.92515-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bernard Metzler [Fri, 8 Jan 2021 12:58:45 +0000 (13:58 +0100)]
RDMA/siw: Fix handling of zero-sized Read and Receive Queues.
[ Upstream commit
661f385961f06f36da24cf408d461f988d0c39ad ]
During connection setup, the application may choose to zero-size inbound
and outbound READ queues, as well as the Receive queue. This patch fixes
handling of zero-sized queues, but not prevents it.
Kamal Heib says in an initial error report:
When running the blktests over siw the following shift-out-of-bounds is
reported, this is happening because the passed IRD or ORD from the ulp
could be zero which will lead to unexpected behavior when calling
roundup_pow_of_two(), fix that by blocking zero values of ORD or IRD.
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 20 PID: 3957 Comm: kworker/u64:13 Tainted: G S 5.10.0-rc6 #2
Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
Call Trace:
dump_stack+0x99/0xcb
ubsan_epilogue+0x5/0x40
__ubsan_handle_shift_out_of_bounds.cold.11+0xb4/0xf3
? down_write+0x183/0x3d0
siw_qp_modify.cold.8+0x2d/0x32 [siw]
? __local_bh_enable_ip+0xa5/0xf0
siw_accept+0x906/0x1b60 [siw]
? xa_load+0x147/0x1f0
? siw_connect+0x17a0/0x17a0 [siw]
? lock_downgrade+0x700/0x700
? siw_get_base_qp+0x1c2/0x340 [siw]
? _raw_spin_unlock_irqrestore+0x39/0x40
iw_cm_accept+0x1f4/0x430 [iw_cm]
rdma_accept+0x3fa/0xb10 [rdma_cm]
? check_flush_dependency+0x410/0x410
? cma_rep_recv+0x570/0x570 [rdma_cm]
nvmet_rdma_queue_connect+0x1a62/0x2680 [nvmet_rdma]
? nvmet_rdma_alloc_cmds+0xce0/0xce0 [nvmet_rdma]
? lock_release+0x56e/0xcc0
? lock_downgrade+0x700/0x700
? lock_downgrade+0x700/0x700
? __xa_alloc_cyclic+0xef/0x350
? __xa_alloc+0x2d0/0x2d0
? rdma_restrack_add+0xbe/0x2c0 [ib_core]
? __ww_mutex_die+0x190/0x190
cma_cm_event_handler+0xf2/0x500 [rdma_cm]
iw_conn_req_handler+0x910/0xcb0 [rdma_cm]
? _raw_spin_unlock_irqrestore+0x39/0x40
? trace_hardirqs_on+0x1c/0x150
? cma_ib_handler+0x8a0/0x8a0 [rdma_cm]
? __kasan_kmalloc.constprop.7+0xc1/0xd0
cm_work_handler+0x121c/0x17a0 [iw_cm]
? iw_cm_reject+0x190/0x190 [iw_cm]
? trace_hardirqs_on+0x1c/0x150
process_one_work+0x8fb/0x16c0
? pwq_dec_nr_in_flight+0x320/0x320
worker_thread+0x87/0xb40
? __kthread_parkme+0xd1/0x1a0
? process_one_work+0x16c0/0x16c0
kthread+0x35f/0x430
? kthread_mod_delayed_work+0x180/0x180
ret_from_fork+0x22/0x30
Fixes:
a531975279f3 ("rdma/siw: main include file")
Fixes:
f29dd55b0236 ("rdma/siw: queue pair methods")
Fixes:
8b6a361b8c48 ("rdma/siw: receive path")
Fixes:
b9be6f18cf9e ("rdma/siw: transmit path")
Fixes:
303ae1cdfdf7 ("rdma/siw: application interface")
Link: https://lore.kernel.org/r/20210108125845.1803-1-bmt@zurich.ibm.com
Reported-by: Kamal Heib <kamalheib1@gmail.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Thu, 17 Dec 2020 01:12:21 +0000 (17:12 -0800)]
HID: core: detect and skip invalid inputs to snto32()
[ Upstream commit
a0312af1f94d13800e63a7d0a66e563582e39aec ]
Prevent invalid (0, 0) inputs to hid-core's snto32() function.
Maybe it is just the dummy device here that is causing this, but
there are hundreds of calls to snto32(0, 0). Having n (bits count)
of 0 is causing the current UBSAN trap with a shift value of
0xffffffff (-1, or n - 1 in this function).
Either of the value to shift being 0 or the bits count being 0 can be
handled by just returning 0 to the caller, avoiding the following
complex shift + OR operations:
return value & (1 << (n - 1)) ? value | (~0U << n) : value;
Fixes:
dde5845a529f ("[PATCH] Generic HID layer - code split")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: syzbot+1e911ad71dd4ea72e04a@syzkaller.appspotmail.com
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Mon, 19 Oct 2020 12:06:10 +0000 (14:06 +0200)]
clk: renesas: r8a779a0: Fix parent of CBFUSA clock
[ Upstream commit
80d3e07ec509c5098d44e4f1416cc9f133fd436f ]
According to Figure 8.1.1 ("Block Diagram of CPG (R-Car V3U-AD)") in the
R-Car V3U Series User's Manual Rev. 0.5, the parent of the CBFUSA clock
is EXTAL.
Fixes:
17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20201019120614.22149-3-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Mon, 19 Oct 2020 12:06:09 +0000 (14:06 +0200)]
clk: renesas: r8a779a0: Remove non-existent S2 clock
[ Upstream commit
5b30be15ca262d9cb2c36b173bb488e8d1952ea0 ]
The S2 internal core clock does not exist on R-Car V3U. Remove it.
Fixes:
17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20201019120614.22149-2-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andre Przywara [Wed, 6 Jan 2021 14:32:46 +0000 (14:32 +0000)]
clk: sunxi-ng: h6: Fix CEC clock
[ Upstream commit
756650820abd4770c4200763505b634a3c04e05e ]
The CEC clock on the H6 SoC is a bit special, since it uses a fixed
pre-dividier for one source clock (the PLL), but conveys the other clock
(32K OSC) directly.
We are using a fixed predivider array for that, but fail to use the right
flag to actually activate that.
Fixes:
524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
Reported-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210106143246.11255-1-andre.przywara@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pratyush Yadav [Tue, 22 Dec 2020 18:44:20 +0000 (00:14 +0530)]
spi: cadence-quadspi: Abort read if dummy cycles required are too many
[ Upstream commit
ceeda328edeeeeac7579e9dbf0610785a3b83d39 ]
The controller can only support up to 31 dummy cycles. If the command
requires more it falls back to using 31. This command is likely to fail
because the correct number of cycles are not waited upon. Rather than
silently issuing an incorrect command, fail loudly so the caller can get
a chance to find out the command can't be supported by the controller.
Fixes:
140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rayagonda Kokatanur [Mon, 2 Nov 2020 03:54:32 +0000 (09:24 +0530)]
i2c: iproc: handle master read request
[ Upstream commit
e21d79778768e4e187b2892d662c6aaa01e1d399 ]
Handle single or multi byte master read request with or without
repeated start.
Fixes:
c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rayagonda Kokatanur [Mon, 2 Nov 2020 03:54:30 +0000 (09:24 +0530)]
i2c: iproc: update slave isr mask (ISR_MASK_SLAVE)
[ Upstream commit
603e77af7b0704bdb057de0368f1f2b04fc9552c ]
Update slave isr mask (ISR_MASK_SLAVE) to include remaining
two slave interrupts.
Fixes:
c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rayagonda Kokatanur [Mon, 2 Nov 2020 03:54:29 +0000 (09:24 +0530)]
i2c: iproc: handle only slave interrupts which are enabled
[ Upstream commit
545f4011e156554d704d6278245d54543f6680d1 ]
Handle only slave interrupts which are enabled.
The IS_OFFSET register contains the interrupt status bits which will be
set regardless of the enabling of the corresponding interrupt condition.
One must therefore look at both IS_OFFSET and IE_OFFSET to determine
whether an interrupt condition is set and enabled.
Fixes:
c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Kara [Tue, 22 Dec 2020 11:09:53 +0000 (12:09 +0100)]
quota: Fix memory leak when handling corrupted quota file
[ Upstream commit
a4db1072e1a3bd7a8d9c356e1902b13ac5deb8ef ]
When checking corrupted quota file we can bail out and leak allocated
info structure. Properly free info structure on error return.
Reported-by: syzbot+77779c9b52ab78154b08@syzkaller.appspotmail.com
Fixes:
11c514a99bb9 ("quota: Sanity-check quota file headers on load")
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Baryshkov [Thu, 31 Dec 2020 12:23:48 +0000 (15:23 +0300)]
arm64: dts: qcom: qrb5165-rb5: fix pm8009 regulators
[ Upstream commit
c3da02421230639bf6ee5462b70b58f5b7f3b7c6 ]
Fix pm8009 compatibility string to reference pm8009 revision specific to
sm8250 platform. Also add S2 regulator to be used for qca639x.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes:
b1d2674e6121 ("arm64: dts: qcom: Add basic devicetree support for QRB5165 RB5")
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201231122348.637917-5-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Baryshkov [Thu, 31 Dec 2020 12:23:47 +0000 (15:23 +0300)]
regulator: qcom-rpmh-regulator: add pm8009-1 chip revision
[ Upstream commit
951384cabc5dfb09251d440dbc26058eba86f97e ]
PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes:
06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20201231122348.637917-4-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Po-Hsu Lin [Mon, 28 Dec 2020 04:34:59 +0000 (12:34 +0800)]
selftests/powerpc: Make the test check in eeh-basic.sh posix compliant
[ Upstream commit
3db380570af7052620ace20c29e244938610ca71 ]
The == operand is a bash extension, thus this will fail on Ubuntu
with:
./eeh-basic.sh: 89: test: 2: unexpected operator
As the /bin/sh on Ubuntu is pointed to DASH.
Use -eq to fix this posix compatibility issue.
Fixes:
996f9e0f93f162 ("selftests/powerpc: Fix eeh-basic.sh exit codes")
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201228043459.14281-1-po-hsu.lin@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sat, 26 Dec 2020 12:15:56 +0000 (13:15 +0100)]
clk: meson: clk-pll: propagate the error from meson_clk_pll_set_rate()
[ Upstream commit
ccdc1f0836f8e37b558a424f1e491f929b2e7ede ]
Popagate the error code from meson_clk_pll_set_rate() when the PLL does
not lock with the new settings.
Fixes:
722825dcd54b2e ("clk: meson: migrate plls clocks to clk_regmap")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201226121556.975418-4-martin.blumenstingl@googlemail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sat, 26 Dec 2020 12:15:55 +0000 (13:15 +0100)]
clk: meson: clk-pll: make "ret" a signed integer
[ Upstream commit
9e717285f0bd591d716fa0e7418f2cdaf756dd25 ]
The error codes returned by meson_clk_get_pll_settings() are all
negative. Make "ret" a signed integer in meson_clk_pll_set_rate() to
make it match with the clk_ops.set_rate API as well as the data type
returned by meson_clk_get_pll_settings().
Fixes:
8eed1db1adec6a ("clk: meson: pll: update driver for the g12a")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201226121556.975418-3-martin.blumenstingl@googlemail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sat, 26 Dec 2020 12:15:54 +0000 (13:15 +0100)]
clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL
[ Upstream commit
2f290b7c67adf6459a17a4c978102af35cd62e4a ]
The "rate" parameter in meson_clk_pll_set_rate() contains the new rate.
Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try
to switch from the new rate to the same rate again.
Fixes:
7a29a869434e8b ("clk: meson: Add support for Meson clock controller")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201226121556.975418-2-martin.blumenstingl@googlemail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Wed, 30 Dec 2020 10:19:11 +0000 (12:19 +0200)]
power: supply: cpcap: Add missing IRQF_ONESHOT to fix regression
[ Upstream commit
e62333e26be649bfc3c167b9f2bbca38b92332c5 ]
Commit
25d76fed7ffe ("phy: cpcap-usb: Use IRQF_ONESHOT") started causing
errors loading phy-cpcap-usb driver:
cpcap_battery cpcap_battery.0: failed to register power supply
genirq: Flags mismatch irq 211.
00002080 (se0conn) vs.
00000080 (se0conn)
cpcap-usb-phy cpcap-usb-phy.0: could not get irq se0conn: -16
Let's fix this by adding the missing IRQF_ONESHOT to also cpcap-battery
and cpcap-charger drivers.
Fixes:
25d76fed7ffe ("phy: cpcap-usb: Use IRQF_ONESHOT")
Reported-by: Merlijn Wajer <merlijn@wizzup.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Qilong [Mon, 23 Nov 2020 10:18:27 +0000 (18:18 +0800)]
HSI: Fix PM usage counter unbalance in ssi_hw_init
[ Upstream commit
aa57e77b3d28f0df07149d88c47bc0f3aa77330b ]
pm_runtime_get_sync will increment pm usage counter
even it failed. Forgetting to putting operation will
result in reference leak here. We fix it by replacing
it with pm_runtime_resume_and_get to keep usage counter
balanced.
Fixes:
b209e047bc743 ("HSI: Introduce OMAP SSI driver")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric W. Biederman [Thu, 17 Dec 2020 15:42:00 +0000 (09:42 -0600)]
capabilities: Don't allow writing ambiguous v3 file capabilities
[ Upstream commit
95ebabde382c371572297915b104e55403674e73 ]
The v3 file capabilities have a uid field that records the filesystem
uid of the root user of the user namespace the file capabilities are
valid in.
When someone is silly enough to have the same underlying uid as the
root uid of multiple nested containers a v3 filesystem capability can
be ambiguous.
In the spirit of don't do that then, forbid writing a v3 filesystem
capability if it is ambiguous.
Fixes:
8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
Reviewed-by: Andrew G. Morgan <morgan@kernel.org>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nirmoy Das [Wed, 10 Feb 2021 17:11:04 +0000 (18:11 +0100)]
drm/amdgpu/display: remove hdcp_srm sysfs on device removal
[ Upstream commit
e96b1b2974989c6a25507b527843ede7594efc85 ]
Fixes:
9037246bb2da5 ("drm/amd/display: Add sysfs interface for set/get srm")
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Sat, 23 Jan 2021 20:10:25 +0000 (21:10 +0100)]
smp: Process pending softirqs in flush_smp_call_function_from_idle()
[ Upstream commit
66040b2d5d41f85cb1a752a75260595344c5ec3b ]
send_call_function_single_ipi() may wake an idle CPU without sending an
IPI. The woken up CPU will process the SMP-functions in
flush_smp_call_function_from_idle(). Any raised softirq from within the
SMP-function call will not be processed.
Should the CPU have no tasks assigned, then it will go back to idle with
pending softirqs and the NOHZ will rightfully complain.
Process pending softirqs on return from flush_smp_call_function_queue().
Fixes:
b2a02fc43a1f4 ("smp: Optimize send_call_function_single_ipi()")
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210123201027.3262800-2-bigeasy@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Mon, 8 Feb 2021 14:56:05 +0000 (15:56 +0100)]
irqchip/imx: IMX_INTMUX should not default to y, unconditionally
[ Upstream commit
a890caeb2ba40ca183969230e204ab144f258357 ]
Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, restrict the automatic enabling of IMX_INTMUX to ARCH_MXC,
and ask the user in case of compile-testing.
Fixes:
66968d7dfc3f5451 ("irqchip: Add COMPILE_TEST support for IMX_INTMUX")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210208145605.422943-1-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang ShaoBo [Sun, 15 Nov 2020 08:23:43 +0000 (16:23 +0800)]
ubifs: Fix error return code in alloc_wbufs()
[ Upstream commit
42119dbe571eb419dae99b81dd20fa42f47464e1 ]
Fix to return PTR_ERR() error code from the error handling case instead
fo 0 in function alloc_wbufs(), as done elsewhere in this function.
Fixes:
6a98bc4614de ("ubifs: Add authentication nodes to journal")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Thu, 14 Jan 2021 21:30:11 +0000 (22:30 +0100)]
ubifs: replay: Fix high stack usage, again
[ Upstream commit
410b6de702ef84fea6e7abcb6620ef8bfc112fae ]
An earlier commit moved out some functions to not be inlined by gcc, but
after some other rework to remove one of those, clang started inlining
the other one and ran into the same problem as gcc did before:
fs/ubifs/replay.c:1174:5: error: stack frame size of 1152 bytes in function 'ubifs_replay_journal' [-Werror,-Wframe-larger-than=]
Mark the function as noinline_for_stack to ensure it doesn't happen
again.
Fixes:
f80df3851246 ("ubifs: use crypto_shash_tfm_digest()")
Fixes:
eb66eff6636d ("ubifs: replay: Fix high stack usage")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinghao Liu [Tue, 5 Jan 2021 06:03:40 +0000 (14:03 +0800)]
ubifs: Fix memleak in ubifs_init_authentication
[ Upstream commit
11b8ab3836454a2600e396f34731e491b661f9d5 ]
When crypto_shash_digestsize() fails, c->hmac_tfm
has not been freed before returning, which leads
to memleak.
Fixes:
49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Rix [Wed, 30 Dec 2020 14:56:04 +0000 (06:56 -0800)]
jffs2: fix use after free in jffs2_sum_write_data()
[ Upstream commit
19646447ad3a680d2ab08c097585b7d96a66126b ]
clang static analysis reports this problem
fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
c->summary->sum_list_head = temp->u.next;
^~~~~~~~~~~~
In jffs2_sum_write_data(), in a loop summary data is handles a node at
a time. When it has written out the node it is removed the summary list,
and the node is deleted. In the corner case when a
JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to
jffs2_sum_disable_collecting(). jffs2_sum_disable_collecting() deletes
the whole list which conflicts with the loop's deleting the list by parts.
To preserve the old behavior of stopping the write midway, bail out of
the loop after disabling summary collection.
Fixes:
6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.")
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Thu, 11 Feb 2021 13:01:08 +0000 (13:01 +0000)]
fs/jfs: fix potential integer overflow on shift of a int
[ Upstream commit
4208c398aae4c2290864ba15c3dab7111f32bec1 ]
The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
arithmetic and then assigned to a signed 64 bit integer. In the case where
l2nb is 32 or more this can lead to an overflow. Avoid this by shifting
the value 1LL instead.
Addresses-Coverity: ("Uninitentional integer overflow")
Fixes:
b40c2e665cd5 ("fs/jfs: TRIM support for JFS Filesystem")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sameer Pujar [Wed, 10 Feb 2021 06:43:39 +0000 (12:13 +0530)]
ASoC: simple-card-utils: Fix device module clock
[ Upstream commit
1e30f642cf2939bbdac82ea0dd3071232670b5ab ]
If "clocks = <&xxx>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by populating "simple_dai->clk" field when clocks property
is specified from device node as well. Also tidy up by re-organising
conditional statements of parsing logic.
Fixes:
bb6fc620c2ed ("ASoC: simple-card-utils: add asoc_simple_card_parse_clk()")
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1612939421-19900-2-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lakshmi Ramasubramanian [Thu, 4 Feb 2021 17:49:51 +0000 (09:49 -0800)]
ima: Free IMA measurement buffer after kexec syscall
[ Upstream commit
f31e3386a4e92ba6eda7328cb508462956c94c64 ]
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. This buffer is not freed before
completing the kexec system call resulting in memory leak.
Add ima_buffer field in "struct kimage" to store the virtual address
of the buffer allocated for the IMA measurement list.
Free the memory allocated for the IMA measurement list in
kimage_file_post_load_cleanup() function.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Fixes:
7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lakshmi Ramasubramanian [Thu, 4 Feb 2021 17:49:50 +0000 (09:49 -0800)]
ima: Free IMA measurement buffer on error
[ Upstream commit
6d14c6517885fa68524238787420511b87d671df ]
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. In error code paths this memory
is not freed resulting in memory leak.
Free the memory allocated for the IMA measurement list in
the error code paths in ima_add_kexec_buffer() function.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Fixes:
7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Mon, 8 Feb 2021 23:18:53 +0000 (17:18 -0600)]
ASoC: SOF: sof-pci-dev: add missing Up-Extreme quirk
[ Upstream commit
bd8036eb15263a720b8f846861c180b27d050a09 ]
The UpExtreme board supports the community key and was missed in
previous contributions. Add it to make sure the open firmware is
picked by default without needing a symlink on the target.
Fixes:
46207ca24545 ('ASoC: SOF: pci: change the default firmware path when the community key is used')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210208231853.58761-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chaitanya Kulkarni [Wed, 10 Feb 2021 05:47:52 +0000 (21:47 -0800)]
nvmet: set status to 0 in case for invalid nsid
[ Upstream commit
40244ad36bcfb796a6bb9e95bdcbf8ddf3134509 ]
For unallocated namespace in nvmet_execute_identify_ns() don't set the
status to NVME_SC_INVALID_NS, set it to zero.
Fixes:
bffcd507780e ("nvmet: set right status on error in id-ns handler")
Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chaitanya Kulkarni [Thu, 14 Jan 2021 01:33:54 +0000 (17:33 -0800)]
nvmet: remove extra variable in identify ns
[ Upstream commit
3c7b224f1956ed232b24ed2eb2c54e4476c6acb2 ]
We remove the extra local variable struct nvmet_ns in
nvmet_execute_identify_ns() since req already has ns member that can be
reused, this also eliminates the explicit call to nvmet_put_namespace()
which is already present in the request completion path.
Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Keith Busch [Fri, 5 Feb 2021 19:50:02 +0000 (11:50 -0800)]
nvme-multipath: set nr_zones for zoned namespaces
[ Upstream commit
73a1a2298f3e9df24cea7a9aab412ba9470f6159 ]
The bio based drivers only require the request_queue's nr_zones is set,
so set this field in the head if the namespace path is zoned.
Fixes:
240e6ee272c07 ("nvme: support for zoned namespaces")
Reported-by: Minwoo Im <minwoo.im.dev@gmail.com>
Cc: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sagi Grimberg [Fri, 5 Feb 2021 19:47:25 +0000 (11:47 -0800)]
nvmet-tcp: fix potential race of tcp socket closing accept_work
[ Upstream commit
0fbcfb089a3f2f2a731d01f0aec8f7697a849c28 ]
When we accept a TCP connection and allocate an nvmet-tcp queue we should
make sure not to fully establish it or reference it as the connection may
be already closing, which triggers queue release work, which does not
fence against queue establishment.
In order to address such a race, we make sure to check the sk_state and
contain the queue reference to be done underneath the sk_callback_lock
such that the queue release work correctly fences against it.
Fixes:
872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Reported-by: Elad Grupi <elad.grupi@dell.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sagi Grimberg [Wed, 3 Feb 2021 23:00:01 +0000 (15:00 -0800)]
nvmet-tcp: fix receive data digest calculation for multiple h2cdata PDUs
[ Upstream commit
fda871c0ba5d2eed2cd1c881573168129da70058 ]
When a host sends multiple h2cdata PDUs for a single command, we
should verify the data digest calculation per PDU and not
per command.
Fixes:
872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Reported-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
Tested-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hao Xu [Fri, 5 Feb 2021 08:34:21 +0000 (16:34 +0800)]
io_uring: fix possible deadlock in io_uring_poll
[ Upstream commit
ed670c3f90a67d9e16ab6d8893be6f072d79cd4c ]
Abaci reported follow issue:
[ 30.615891] ======================================================
[ 30.616648] WARNING: possible circular locking dependency detected
[ 30.617423] 5.11.0-rc3-next-
20210115 #1 Not tainted
[ 30.618035] ------------------------------------------------------
[ 30.618914] a.out/1128 is trying to acquire lock:
[ 30.619520]
ffff88810b063868 (&ep->mtx){+.+.}-{3:3}, at: __ep_eventpoll_poll+0x9f/0x220
[ 30.620505]
[ 30.620505] but task is already holding lock:
[ 30.621218]
ffff88810e952be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0
[ 30.622349]
[ 30.622349] which lock already depends on the new lock.
[ 30.622349]
[ 30.623289]
[ 30.623289] the existing dependency chain (in reverse order) is:
[ 30.624243]
[ 30.624243] -> #1 (&ctx->uring_lock){+.+.}-{3:3}:
[ 30.625263] lock_acquire+0x2c7/0x390
[ 30.625868] __mutex_lock+0xae/0x9f0
[ 30.626451] io_cqring_overflow_flush.part.95+0x6d/0x70
[ 30.627278] io_uring_poll+0xcb/0xd0
[ 30.627890] ep_item_poll.isra.14+0x4e/0x90
[ 30.628531] do_epoll_ctl+0xb7e/0x1120
[ 30.629122] __x64_sys_epoll_ctl+0x70/0xb0
[ 30.629770] do_syscall_64+0x2d/0x40
[ 30.630332] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.631187]
[ 30.631187] -> #0 (&ep->mtx){+.+.}-{3:3}:
[ 30.631985] check_prevs_add+0x226/0xb00
[ 30.632584] __lock_acquire+0x1237/0x13a0
[ 30.633207] lock_acquire+0x2c7/0x390
[ 30.633740] __mutex_lock+0xae/0x9f0
[ 30.634258] __ep_eventpoll_poll+0x9f/0x220
[ 30.634879] __io_arm_poll_handler+0xbf/0x220
[ 30.635462] io_issue_sqe+0xa6b/0x13e0
[ 30.635982] __io_queue_sqe+0x10b/0x550
[ 30.636648] io_queue_sqe+0x235/0x470
[ 30.637281] io_submit_sqes+0xcce/0xf10
[ 30.637839] __x64_sys_io_uring_enter+0x3fb/0x5b0
[ 30.638465] do_syscall_64+0x2d/0x40
[ 30.638999] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.639643]
[ 30.639643] other info that might help us debug this:
[ 30.639643]
[ 30.640618] Possible unsafe locking scenario:
[ 30.640618]
[ 30.641402] CPU0 CPU1
[ 30.641938] ---- ----
[ 30.642664] lock(&ctx->uring_lock);
[ 30.643425] lock(&ep->mtx);
[ 30.644498] lock(&ctx->uring_lock);
[ 30.645668] lock(&ep->mtx);
[ 30.646321]
[ 30.646321] *** DEADLOCK ***
[ 30.646321]
[ 30.647642] 1 lock held by a.out/1128:
[ 30.648424] #0:
ffff88810e952be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0
[ 30.649954]
[ 30.649954] stack backtrace:
[ 30.650592] CPU: 1 PID: 1128 Comm: a.out Not tainted 5.11.0-rc3-next-
20210115 #1
[ 30.651554] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 30.652290] Call Trace:
[ 30.652688] dump_stack+0xac/0xe3
[ 30.653164] check_noncircular+0x11e/0x130
[ 30.653747] ? check_prevs_add+0x226/0xb00
[ 30.654303] check_prevs_add+0x226/0xb00
[ 30.654845] ? add_lock_to_list.constprop.49+0xac/0x1d0
[ 30.655564] __lock_acquire+0x1237/0x13a0
[ 30.656262] lock_acquire+0x2c7/0x390
[ 30.656788] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.657379] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.658014] __mutex_lock+0xae/0x9f0
[ 30.658524] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.659112] ? mark_held_locks+0x5a/0x80
[ 30.659648] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.660229] ? _raw_spin_unlock_irqrestore+0x2d/0x40
[ 30.660885] ? trace_hardirqs_on+0x46/0x110
[ 30.661471] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.662102] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.662696] __ep_eventpoll_poll+0x9f/0x220
[ 30.663273] ? __ep_eventpoll_poll+0x220/0x220
[ 30.663875] __io_arm_poll_handler+0xbf/0x220
[ 30.664463] io_issue_sqe+0xa6b/0x13e0
[ 30.664984] ? __lock_acquire+0x782/0x13a0
[ 30.665544] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.666170] ? __io_queue_sqe+0x10b/0x550
[ 30.666725] __io_queue_sqe+0x10b/0x550
[ 30.667252] ? __fget_files+0x131/0x260
[ 30.667791] ? io_req_prep+0xd8/0x1090
[ 30.668316] ? io_queue_sqe+0x235/0x470
[ 30.668868] io_queue_sqe+0x235/0x470
[ 30.669398] io_submit_sqes+0xcce/0xf10
[ 30.669931] ? xa_load+0xe4/0x1c0
[ 30.670425] __x64_sys_io_uring_enter+0x3fb/0x5b0
[ 30.671051] ? lockdep_hardirqs_on_prepare+0xde/0x180
[ 30.671719] ? syscall_enter_from_user_mode+0x2b/0x80
[ 30.672380] do_syscall_64+0x2d/0x40
[ 30.672901] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.673503] RIP: 0033:0x7fd89c813239
[ 30.673962] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 ec 2c 00 f7 d8 64 89 01 48
[ 30.675920] RSP: 002b:
00007ffc65a7c628 EFLAGS:
00000217 ORIG_RAX:
00000000000001aa
[ 30.676791] RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007fd89c813239
[ 30.677594] RDX:
0000000000000000 RSI:
0000000000000014 RDI:
0000000000000003
[ 30.678678] RBP:
00007ffc65a7c720 R08:
0000000000000000 R09:
0000000003000000
[ 30.679492] R10:
0000000000000000 R11:
0000000000000217 R12:
0000000000400ff0
[ 30.680282] R13:
00007ffc65a7c840 R14:
0000000000000000 R15:
0000000000000000
This might happen if we do epoll_wait on a uring fd while reading/writing
the former epoll fd in a sqe in the former uring instance.
So let's don't flush cqring overflow list, just do a simple check.
Reported-by: Abaci <abaci@linux.alibaba.com>
Fixes:
6c503150ae33 ("io_uring: patch up IOPOLL overflow_flush sync")
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniele Alessandrelli [Wed, 3 Feb 2021 11:28:37 +0000 (11:28 +0000)]
crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()
[ Upstream commit
a53ab94eb6850c3657392e2d2ce9b38c387a2633 ]
The length ('len' parameter) passed to crypto_ecdh_decode_key() is never
checked against the length encoded in the passed buffer ('buf'
parameter). This could lead to an out-of-bounds access when the passed
length is less than the encoded length.
Add a check to prevent that.
Fixes:
3c4b23901a0c7 ("crypto: ecdh - Add ECDH software support")
Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Henrik Weinstock [Mon, 1 Feb 2021 15:14:59 +0000 (16:14 +0100)]
hwrng: timeriomem - Fix cooldown period calculation
[ Upstream commit
e145f5565dc48ccaf4cb50b7cfc48777bed8c100 ]
Ensure cooldown period tolerance of 1% is actually accounted for.
Fixes:
ca3bff70ab32 ("hwrng: timeriomem - Improve performance...")
Signed-off-by: Jan Henrik Weinstock <jan.weinstock@rwth-aachen.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Imre Deak [Mon, 1 Feb 2021 12:01:43 +0000 (14:01 +0200)]
drm/dp_mst: Don't cache EDIDs for physical ports
[ Upstream commit
4b8878eefa0a3b65e2e016db49014ea66fb9fd45 ]
Caching EDIDs for physical ports prevents updating the EDID if a port
gets reconnected via a Connection Status Notification message, fix this.
Fixes:
db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210201120145.350258-2-imre.deak@intel.com
(cherry picked from commit
468091531c2e5c49f55d8c6f1d036ce997d24e13)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qinglang Miao [Fri, 27 Nov 2020 09:44:38 +0000 (17:44 +0800)]
drm/lima: fix reference leak in lima_pm_busy
[ Upstream commit
de4248b744e8394f239c0dd0af34088399d27d94 ]
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new function.
[0] commit
dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
Fixes:
50de2e9ebbc0 ("drm/lima: enable runtime pm")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201127094438.121003-1-miaoqinglang@huawei.com
(cherry picked from commit
de499781c97d96703af8a32d2b5e37fdb5b51568)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Mon, 11 Jan 2021 14:23:01 +0000 (15:23 +0100)]
drm/vc4: hdmi: Update the CEC clock divider on HSM rate change
[ Upstream commit
47fa9a80270e20a0c4ddaffca1f144d22cc59620 ]
As part of the enable sequence we might change the HSM clock rate if the
pixel rate is different than the one we were already dealing with.
On the BCM2835 however, the CEC clock derives from the HSM clock so any
rate change will need to be reflected in the CEC clock divider to output
40kHz.
Fixes:
cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-8-maxime@cerno.tech
(cherry picked from commit
a9dd0b9a5c3e11c79e6ff9c7fdf07c471732dcb6)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Mon, 11 Jan 2021 14:23:00 +0000 (15:23 +0100)]
drm/vc4: hdmi: Compute the CEC clock divider from the clock rate
[ Upstream commit
163a3ef681e5e9d5df558e855d86ccd4708d6200 ]
The CEC clock divider needs to output a frequency of 40kHz from the HSM
rate on the BCM2835. The driver used to have a fixed frequency for it,
but that changed for the BCM2711 and we now need to compute it
dynamically to maintain the proper rate.
Fixes:
cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-7-maxime@cerno.tech
(cherry picked from commit
f1ceb9d10043683b89e5e5e5848fb4e855295762)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dom Cobley [Mon, 11 Jan 2021 14:22:59 +0000 (15:22 +0100)]
drm/vc4: hdmi: Restore cec physical address on reconnect
[ Upstream commit
4d8602b8ec16f5721a4d1339c610a81f95df1856 ]
Currently we call cec_phys_addr_invalidate on a hotplug deassert.
That may be due to a TV power cycling, or an AVR being switched
on (and switching edid).
This makes CEC unusable since our controller wouldn't have a physical
address anymore.
Set it back up again on the hotplug assert.
Fixes:
15b4511a4af6 ("drm/vc4: add HDMI CEC support")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-6-maxime@cerno.tech
(cherry picked from commit
b06eecb5158e5f3eb47b9d05aea8c259985cc5f7)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dom Cobley [Mon, 11 Jan 2021 14:22:58 +0000 (15:22 +0100)]
drm/vc4: hdmi: Fix up CEC registers
[ Upstream commit
5a32bfd563e8b5766e57475c2c81c769e5a13f5d ]
The commit
311e305fdb4e ("drm/vc4: hdmi: Implement a register layout
abstraction") forgot one CEC register, and made a copy and paste mistake
for another one. Fix those mistakes.
Fixes:
311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-5-maxime@cerno.tech
(cherry picked from commit
303085bc11bb7aebeeaaf09213f99fd7aa539a34)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dom Cobley [Mon, 11 Jan 2021 14:22:57 +0000 (15:22 +0100)]
drm/vc4: hdmi: Fix register offset with longer CEC messages
[ Upstream commit
4a59ed546c0511f01a4bf6b886fe34b6cce2513f ]
The code prior to
311e305fdb4e ("drm/vc4: hdmi: Implement a register
layout abstraction") was relying on the fact that the register offset
was incremented by 4 for each readl call. That worked since the register
width is 4 bytes.
However, since that commit the HDMI_READ macro is now taking an enum,
and the offset doesn't increment by 4 but 1 now. Divide the index by 4
to fix this.
Fixes:
311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-4-maxime@cerno.tech
(cherry picked from commit
e9c9481f373eb7344f9e973eb28fc6e9d0f46485)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dom Cobley [Mon, 11 Jan 2021 14:22:56 +0000 (15:22 +0100)]
drm/vc4: hdmi: Move hdmi reset to bind
[ Upstream commit
902dc5c19a8fecd3113dd41cc601b34557bdede9 ]
The hdmi reset got moved to a later point in the commit
9045e91a476b
("drm/vc4: hdmi: Add reset callback").
However, the reset now occurs after vc4_hdmi_cec_init and so tramples
the setup of registers like HDMI_CEC_CNTRL_1
This only affects pi0-3 as on pi4 the cec registers are in a separate
block
Fixes:
9045e91a476b ("drm/vc4: hdmi: Add reset callback")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-3-maxime@cerno.tech
(cherry picked from commit
7155334f15f360f5c98391c5c7e12af4c13395c4)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Harald Freudenberger [Thu, 21 Jan 2021 15:03:08 +0000 (16:03 +0100)]
s390/zcrypt: return EIO when msg retry limit reached
[ Upstream commit
d39fae45c97c67b1b4da04773f2bb5a2f29088c4 ]
When a msg is retried because the lower ap layer returns -EAGAIN
there is a retry limit (currently 10). When this limit is reached
the last return code from the lower layer is returned, causing
the userspace to get -1 on the ioctl with errno EAGAIN.
This EAGAIN is misleading here. After 10 retry attempts the
userspace should receive a clear failure indication like EINVAL
or EIO or ENODEV. However, the reason why these retries all
fail is unclear. On an invalid message EINVAL would be returned
by the lower layer, and if devices go away or are not available
an ENODEV is seen. So this patch now reworks the retry loops
to return EIO to userspace when the retry limit is reached.
Fixes:
91ffc519c199 ("s390/zcrypt: introduce msg tracking in zcrypt functions")
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Christopherson [Fri, 5 Feb 2021 01:24:58 +0000 (17:24 -0800)]
KVM: x86: Restore all 64 bits of DR6 and DR7 during RSM on x86-64
[ Upstream commit
2644312052d54e2e7543c7d186899a36ed22f0bf ]
Restore the full 64-bit values of DR6 and DR7 when emulating RSM on
x86-64, as defined by both Intel's SDM and AMD's APM.
Note, bits 63:32 of DR6 and DR7 are reserved, so this is a glorified nop
unless the SMM handler is poking into SMRAM, which it most definitely
shouldn't be doing since both Intel and AMD list the DR6 and DR7 fields
as read-only.
Fixes:
660a5d517aaa ("KVM: x86: save/load state on SMM switch")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <
20210205012458.3872687-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qu Wenruo [Wed, 27 Jan 2021 06:38:48 +0000 (14:38 +0800)]
btrfs: fix double accounting of ordered extent for subpage case in btrfs_invalidapge
[ Upstream commit
951c80f83d61bd4b21794c8aba829c3c1a45c2d0 ]
Commit
dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could
span across a page") make btrfs_invalidapage() to search all ordered
extents.
The offending code looks like this:
again:
start = page_start;
ordered = btrfs_lookup_ordered_range(inode, start, page_end - start + 1);
if (ordred) {
end = min(page_end,
ordered->file_offset + ordered->num_bytes - 1);
/* Do the cleanup */
start = end + 1;
if (start < page_end)
goto again;
}
The behavior is indeed necessary for the incoming subpage support, but
when it iterates through all the ordered extents, it also resets the
search range @start.
This means, for the following cases, we can double account the ordered
extents, causing its bytes_left underflow:
Page offset
0 16K 32K
|<--- OE 1 --->|<--- OE 2 ---->|
As the first iteration will find ordered extent (OE) 1, which doesn't
cover the full page, thus after cleanup code, we need to retry again.
But again label will reset start to page_start, and we got OE 1 again,
which causes double accounting on OE 1, and cause OE 1's byte_left to
underflow.
This problem can only happen for subpage case, as for regular sectorsize
== PAGE_SIZE case, we will always find a OE ends at or after page end,
thus no way to trigger the problem.
Move the again label after start = page_start. There will be more
comprehensive rework to convert the open coded loop to a proper while
loop for subpage support.
Fixes:
dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could span across a page")
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhihao Cheng [Fri, 20 Nov 2020 01:08:04 +0000 (09:08 +0800)]
btrfs: clarify error returns values in __load_free_space_cache
[ Upstream commit
3cc64e7ebfb0d7faaba2438334c43466955a96e8 ]
Return value in __load_free_space_cache is not properly set after
(unlikely) memory allocation failures and 0 is returned instead.
This is not a problem for the caller load_free_space_cache because only
value 1 is considered as 'cache loaded' but for clarity it's better
to set the errors accordingly.
Fixes:
a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hui Wang [Mon, 8 Feb 2021 10:38:57 +0000 (18:38 +0800)]
ASoC: SOF: debug: Fix a potential issue on string buffer termination
[ Upstream commit
9037c3bde65d339017ef41d81cb58069ffc321d4 ]
The function simple_write_to_buffer() doesn't add string termination
at the end of buf, we need to handle it on our own. This change refers
to the function tokenize_input() in debug.c and the function
sof_dfsentry_trace_filter_write() in trace.c.
Fixes:
091c12e1f50c ("ASoC: SOF: debug: add new debugfs entries for IPC flood test")
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210208103857.75705-1-hui.wang@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sathyanarayana Nujella [Fri, 5 Feb 2021 17:14:28 +0000 (09:14 -0800)]
ASoC: rt5682: Fix panic in rt5682_jack_detect_handler happening during system shutdown
[ Upstream commit
45a2702ce10993eda7a5b12690294782d565519c ]
During Coldboot stress tests, system encountered the following panic.
Panic logs depicts rt5682_i2c_shutdown() happened first and then later
jack detect handler workqueue function triggered.
This situation causes panic as rt5682_i2c_shutdown() resets codec.
Fix this panic by cancelling all jack detection delayed work.
Panic log:
[ 20.936124] sof_pci_shutdown
[ 20.940248] snd_sof_device_shutdown
[ 20.945023] snd_sof_shutdown
[ 21.126849] rt5682_i2c_shutdown
[ 21.286053] rt5682_jack_detect_handler
[ 21.291235] BUG: kernel NULL pointer dereference, address:
000000000000037c
[ 21.299302] #PF: supervisor read access in kernel mode
[ 21.305254] #PF: error_code(0x0000) - not-present page
[ 21.311218] PGD 0 P4D 0
[ 21.314155] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 21.319206] CPU: 2 PID: 123 Comm: kworker/2:3 Tainted: G U 5.4.68 #10
[ 21.333687] ACPI: Preparing to enter system sleep state S5
[ 21.337669] Workqueue: events_power_efficient rt5682_jack_detect_handler [snd_soc_rt5682]
[ 21.337671] RIP: 0010:rt5682_jack_detect_handler+0x6c/0x279 [snd_soc_rt5682]
Fixes:
a50067d4f3c1d ('ASoC: rt5682: split i2c driver into separate module')
Signed-off-by: Jairaj Arava <jairaj.arava@intel.com>
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
Reviewed-by: Shuming Fan <shumingf@realtek.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210205171428.2344210-1-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jun Nie [Mon, 1 Feb 2021 13:29:41 +0000 (21:29 +0800)]
ASoC: qcom: lpass: Fix i2s ctl register bit map
[ Upstream commit
5e3277ab3baff6db96ae44adf6f85d6f0f6502cc ]
Fix bitwidth mapping in i2s ctl register per APQ8016 document.
Fixes:
b5022a36d28f ("ASoC: qcom: lpass: Use regmap_field for i2sctl and dmactl registers")
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Link: https://lore.kernel.org/r/20210201132941.460360-1-jun.nie@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Mon, 1 Feb 2021 10:55:38 +0000 (11:55 +0100)]
locking/lockdep: Avoid unmatched unlock
[ Upstream commit
7f82e631d236cafd28518b998c6d4d8dc2ef68f6 ]
Commit
f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI"
inversions") overlooked that print_usage_bug() releases the graph_lock
and called it without the graph lock held.
Fixes:
f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Link: https://lkml.kernel.org/r/YBfkuyIfB1+VRxXP@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Thu, 4 Feb 2021 20:32:59 +0000 (14:32 -0600)]
ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A3E
[ Upstream commit
5ab3ff4d66960be766a544886667e7c002f17fd6 ]
We missed adding the TGL_HDMI quirk which is very much needed to
expose the 4 display pipelines and will be required on TGL topologies.
Fixes:
e787f5b5b1406 ('ASoC: Intel: add support for new SoundWire hardware layout on TGL')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210204203312.27112-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Thu, 4 Feb 2021 20:33:00 +0000 (14:33 -0600)]
ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A5E
[ Upstream commit
f12bbc50f3b14c9b8ed902c6d1da980dd5addcce ]
We missed adding the TGL_HDMI quirk which is very much needed to
expose the 4 display pipelines and will be required on TGL topologies.
Fixes:
9ad9bc59dde10 ('ASoC: Intel: sof_sdw: set proper flags for Dell TGL-H SKU 0A5E')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210204203312.27112-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Parri (Microsoft) [Wed, 9 Dec 2020 07:08:25 +0000 (08:08 +0100)]
Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind()
[ Upstream commit
e3fa4b747f085d2cda09bba0533b86fa76038635 ]
When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could
invoke put_device(), that will eventually release the device and free
the channel object (cf. vmbus_device_release()). However, a pointer
to the object is dereferenced again later to load the primary_channel.
The use-after-free can be avoided by noticing that this load/check is
redundant if device_obj is non-NULL: primary_channel must be NULL if
device_obj is non-NULL, cf. vmbus_add_channel_work().
Fixes:
54a66265d6754b ("Drivers: hv: vmbus: Fix rescind handling")
Reported-by: Juan Vazquez <juvazq@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yongqiang Niu [Mon, 11 Jan 2021 07:43:44 +0000 (15:43 +0800)]
drm/mediatek: Check if fb is null
[ Upstream commit
b1d685b6467ac0d98fc63989f71b4ca9186be5d4 ]
It's possible that state->base.fb is null. Add a check before access its
format.
Fixes:
b6b1bb980ec4 ("drm/mediatek: Turn off Alpha bit when plane format has no alpha")
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Christopherson [Thu, 4 Feb 2021 00:01:07 +0000 (16:01 -0800)]
KVM: nSVM: Don't strip host's C-bit from guest's CR3 when reading PDPTRs
[ Upstream commit
2732be90235347a3be4babdc9f88a1ea93970b0b ]
Don't clear the SME C-bit when reading a guest PDPTR, as the GPA (CR3) is
in the guest domain.
Barring a bizarre paravirtual use case, this is likely a benign bug. SME
is not emulated by KVM, loading SEV guest PDPTRs is doomed as KVM can't
use the correct key to read guest memory, and setting guest MAXPHYADDR
higher than the host, i.e. overlapping the C-bit, would cause faults in
the guest.
Note, for SEV guests, stripping the C-bit is technically aligned with CPU
behavior, but for KVM it's the greater of two evils. Because KVM doesn't
have access to the guest's encryption key, ignoring the C-bit would at
best result in KVM reading garbage. By keeping the C-bit, KVM will
fail its read (unless userspace creates a memslot with the C-bit set).
The guest will still undoubtedly die, as KVM will use '0' for the PDPTR
value, but that's preferable to interpreting encrypted data as a PDPTR.
Fixes:
d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <
20210204000117.3303214-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Srinivasa Rao Mandadapu [Tue, 2 Feb 2021 06:27:27 +0000 (11:57 +0530)]
ASoC: qcom: Fix typo error in HDMI regmap config callbacks
[ Upstream commit
e681b1a6d706b4e54c3847bb822531b4660234f3 ]
Had a typo in lpass platform driver that resulted in crash
during suspend/resume with an HDMI dongle connected.
The regmap read/write/volatile regesters validation callbacks in lpass-cpu
were using MI2S rdma_channels count instead of hdmi_rdma_channels.
This typo error causing to read registers from the regmap beyond the length
of the mapping created by ioremap().
This fix avoids the need for reducing number hdmi_rdma_channels,
which is done in
commit
7dfe20ee92f6 ("ASoC: qcom: Fix number of HDMI RDMA channels on sc7180").
So reverting the same.
Fixes:
7cb37b7bd0d3c ("ASoC: qcom: Add support for lpass hdmi driver")
Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20210202062727.22469-1-srivasam@codeaurora.org
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dehe Gu [Tue, 2 Feb 2021 09:39:22 +0000 (17:39 +0800)]
f2fs: fix a wrong condition in __submit_bio
[ Upstream commit
39f71b7e40e21805d6b15fc7750bdd9cab6a5010 ]
We should use !F2FS_IO_ALIGNED() to check and submit_io directly.
Fixes:
8223ecc456d0 ("f2fs: fix to add missing F2FS_IO_ALIGNED() condition")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Dehe Gu <gudehe@huawei.com>
Signed-off-by: Ge Qiu <qiuge@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Tue, 2 Feb 2021 05:56:36 +0000 (08:56 +0300)]
drm/amdgpu: Prevent shift wrapping in amdgpu_read_mask()
[ Upstream commit
c915ef890d5dc79f483e1ca3b3a5b5f1a170690c ]
If the user passes a "level" value which is higher than 31 then that
leads to shift wrapping. The undefined behavior will lead to a
syzkaller stack dump.
Fixes:
5632708f4452 ("drm/amd/powerplay: add dpm force multiple levels on cz/tonga/fiji/polaris (v2)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yi Chen [Thu, 28 Jan 2021 09:02:56 +0000 (17:02 +0800)]
f2fs: fix to avoid inconsistent quota data
[ Upstream commit
25fb04dbce6a0e165d28fd1fa8a1d7018c637fe8 ]
Occasionally, quota data may be corrupted detected by fsck:
Info: checkpoint state = 45 : crc compacted_summary unmount
[QUOTA WARNING] Usage inconsistent for ID 0:actual (
1543036928, 762) != expected (
1543032832, 762)
[ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found.
[QUOTA WARNING] Usage inconsistent for ID 0:actual (
1352478720, 344) != expected (
1352474624, 344)
[ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found.
[FSCK] Unreachable nat entries [Ok..] [0x0]
[FSCK] SIT valid block bitmap checking [Ok..]
[FSCK] Hard link checking for regular file [Ok..] [0x0]
[FSCK] valid_block_count matching with CP [Ok..] [0xdf299]
[FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x2b01]
[FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x2b01]
[FSCK] valid_inode_count matched with CP [Ok..] [0x2665]
[FSCK] free segment_count matched with CP [Ok..] [0xcb04]
[FSCK] next block offset is free [Ok..]
[FSCK] fixing SIT types
[FSCK] other corrupted bugs [Fail]
The root cause is:
If we open file w/ readonly flag, disk quota info won't be initialized
for this file, however, following mmap() will force to convert inline
inode via f2fs_convert_inline_inode(), which may increase block usage
for this inode w/o updating quota data, it causes inconsistent disk quota
info.
The issue will happen in following stack:
open(file, O_RDONLY)
mmap(file)
- f2fs_convert_inline_inode
- f2fs_convert_inline_page
- f2fs_reserve_block
- f2fs_reserve_new_block
- f2fs_reserve_new_blocks
- f2fs_i_blocks_write
- dquot_claim_block
inode->i_blocks increase, but the dqb_curspace keep the size for the dquots
is NULL.
To fix this issue, let's call dquot_initialize() anyway in both
f2fs_truncate() and f2fs_convert_inline_inode() functions to avoid potential
inconsistent quota data issue.
Fixes:
0abd675e97e6 ("f2fs: support plain user/group quota")
Signed-off-by: Daiyue Zhang <zhangdaiyue1@huawei.com>
Signed-off-by: Dehe Gu <gudehe@huawei.com>
Signed-off-by: Junchao Jiang <jiangjunchao1@huawei.com>
Signed-off-by: Ge Qiu <qiuge@huawei.com>
Signed-off-by: Yi Chen <chenyi77@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Manivannan Sadhasivam [Mon, 4 Jan 2021 04:11:37 +0000 (09:41 +0530)]
mtd: parsers: afs: Fix freeing the part name memory in failure
[ Upstream commit
7b844cf445f0a7daa68be0ce71eb2c88d68b0c5d ]
In the case of failure while parsing the partitions, the iterator should
be pre decremented by one before starting to free the memory allocated
by kstrdup(). Because in the failure case, kstrdup() will not succeed
and thus no memory will be allocated for the current iteration.
Fixes:
1fca1f6abb38 ("mtd: afs: simplify partition parsing")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210104041137.113075-5-manivannan.sadhasivam@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Srinivas Kandagatla [Mon, 1 Feb 2021 16:14:29 +0000 (16:14 +0000)]
ASoC: codecs: add missing max_register in regmap config
[ Upstream commit
e8820dbddbcad7e91daacf7d42a49d1d04a4e489 ]
For some reason setting max_register was missed from regmap_config.
Without this cat /sys/kernel/debug/regmap/sdw:0:217:2010:0:1/range
actually throws below Warning.
WARNING: CPU: 7 PID: 540 at drivers/base/regmap/regmap-debugfs.c:160
regmap_debugfs_get_dump_start.part.10+0x1e0/0x220
...
Call trace:
regmap_debugfs_get_dump_start.part.10+0x1e0/0x220
regmap_reg_ranges_read_file+0xc0/0x2e0
full_proxy_read+0x64/0x98
vfs_read+0xa8/0x1e0
ksys_read+0x6c/0x100
__arm64_sys_read+0x1c/0x28
el0_svc_common.constprop.3+0x6c/0x190
do_el0_svc+0x24/0x90
el0_svc+0x14/0x20
el0_sync_handler+0x90/0xb8
el0_sync+0x158/0x180
...
Fixes:
a0aab9e1404a ("ASoC: codecs: add wsa881x amplifier support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210201161429.28060-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Reichel [Sat, 23 Jan 2021 17:29:45 +0000 (18:29 +0100)]
ASoC: cpcap: fix microphone timeslot mask
[ Upstream commit
de5bfae2fd962a9da99f56382305ec7966a604b9 ]
The correct mask is 0x1f8 (Bit 3-8), but due to missing BIT() 0xf (Bit
0-3) was set instead. This means setting of CPCAP_BIT_MIC1_RX_TIMESLOT0
(Bit 3) still worked (part of both masks). On the other hand the code
does not properly clear the other MIC timeslot bits. I think this
is not a problem, since they are probably initialized to 0 and not
touched by the driver anywhere else. But the mask also contains some
wrong bits, that will be cleared. Bit 0 (CPCAP_BIT_SMB_CDC) should be
safe, since the driver enforces it to be 0 anyways.
Bit 1-2 are CPCAP_BIT_FS_INV and CPCAP_BIT_CLK_INV. This means enabling
audio recording forces the codec into SND_SOC_DAIFMT_NB_NF mode, which
is obviously bad.
The bug probably remained undetected, because there are not many use
cases for routing microphone to the CPU on platforms using cpcap and
user base is small. I do remember having some issues with bad sound
quality when testing voice recording back when I wrote the driver.
It probably was this bug.
Fixes:
f6cdf2d3445d ("ASoC: cpcap: new codec")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210123172945.3958622-1-sre@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Fri, 29 Jan 2021 18:28:45 +0000 (10:28 -0800)]
ata: ahci_brcm: Add back regulators management
[ Upstream commit
10340f8d7b6dd54e616339c8ccb2f397133ebea0 ]
While reworking the resources management and departing from using
ahci_platform_enable_resources() which did not allow a proper step
separation like we need, we unfortunately lost the ability to control
AHCI regulators. This broke some Broadcom STB systems that do expect
regulators to be turned on to link up with attached hard drives.
Fixes:
c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Will Deacon [Wed, 27 Jan 2021 23:53:42 +0000 (23:53 +0000)]
mm: proc: Invalidate TLB after clearing soft-dirty page state
[ Upstream commit
912efa17e5121693dfbadae29768f4144a3f9e62 ]
Since commit
0758cd830494 ("asm-generic/tlb: avoid potential double
flush"), TLB invalidation is elided in tlb_finish_mmu() if no entries
were batched via the tlb_remove_*() functions. Consequently, the
page-table modifications performed by clear_refs_write() in response to
a write to /proc/<pid>/clear_refs do not perform TLB invalidation.
Although this is fine when simply aging the ptes, in the case of
clearing the "soft-dirty" state we can end up with entries where
pte_write() is false, yet a writable mapping remains in the TLB.
Fix this by avoiding the mmu_gather API altogether: managing both the
'tlb_flush_pending' flag on the 'mm_struct' and explicit TLB
invalidation for the sort-dirty path, much like mprotect() does already.
Fixes:
0758cd830494 ("asm-generic/tlb: avoid potential double flush”)
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Yu Zhao <yuzhao@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lkml.kernel.org/r/20210127235347.1402-2-will@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frantisek Hrbata [Fri, 28 Aug 2020 09:28:46 +0000 (11:28 +0200)]
drm/nouveau: bail out of nouveau_channel_new if channel init fails
[ Upstream commit
eaba3b28401f50e22d64351caa8afe8d29509f27 ]
Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
ioctl. This was reported by trinity[1] fuzzer.
[ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17
[ 71.081730] BUG: kernel NULL pointer dereference, address:
00000000000000a0
[ 71.088928] #PF: supervisor read access in kernel mode
[ 71.094059] #PF: error_code(0x0000) - not-present page
[ 71.099189] PGD
119590067 P4D
119590067 PUD
1054f5067 PMD 0
[ 71.104842] Oops: 0000 [#1] SMP NOPTI
[ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
[ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
[ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau]
[ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
[ 71.147074] RSP: 0018:
ffffb4a1809cfd38 EFLAGS:
00010246
[ 71.152526] RAX:
0000000000000000 RBX:
ffff98cedbaa1d20 RCX:
00000000000003bf
[ 71.159651] RDX:
00000000000003be RSI:
0000000000000000 RDI:
0000000000030160
[ 71.166774] RBP:
ffff98cee776de00 R08:
ffffdc0144198a08 R09:
ffff98ceeefd4000
[ 71.173901] R10:
ffff98cee7e81780 R11:
0000000000000001 R12:
ffffb4a1809cfe08
[ 71.181214] R13:
ffff98cee776d000 R14:
ffff98cec519e000 R15:
ffff98cee776def0
[ 71.188339] FS:
00007fd926250500(0000) GS:
ffff98ceeac80000(0000) knlGS:
0000000000000000
[ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 71.202155] CR2:
00000000000000a0 CR3:
0000000106622000 CR4:
00000000000406e0
[ 71.209297] Call Trace:
[ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm]
[ 71.222421] drm_ioctl+0x211/0x3c0 [drm]
[ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau]
[ 71.237285] ksys_ioctl+0x86/0xc0
[ 71.240595] __x64_sys_ioctl+0x16/0x20
[ 71.244340] do_syscall_64+0x4c/0x90
[ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 71.253162] RIP: 0033:0x7fd925d4b88b
[ 71.256731] Code: Bad RIP value.
[ 71.259955] RSP: 002b:
00007ffc743592d8 EFLAGS:
00000206 ORIG_RAX:
0000000000000010
[ 71.267514] RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007fd925d4b88b
[ 71.274637] RDX:
0000000000601080 RSI:
00000000c0586442 RDI:
0000000000000003
[ 71.281986] RBP:
00007ffc74359340 R08:
00007fd926016ce0 R09:
00007fd926016ce0
[ 71.289111] R10:
0000000000000003 R11:
0000000000000206 R12:
0000000000400620
[ 71.296235] R13:
00007ffc74359420 R14:
0000000000000000 R15:
0000000000000000
[ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod
[ 71.365269] CR2:
00000000000000a0
simplified reproducer
---------------------------------8<----------------------------------------
/*
* gcc -o crashme crashme.c
* ./crashme /dev/dri/renderD128
*/
struct drm_nouveau_channel_alloc {
uint32_t fb_ctxdma_handle;
uint32_t tt_ctxdma_handle;
int channel;
uint32_t pushbuf_domains;
/* Notifier memory */
uint32_t notifier_handle;
/* DRM-enforced subchannel assignments */
struct {
uint32_t handle;
uint32_t grclass;
} subchan[8];
uint32_t nr_subchan;
};
static struct drm_nouveau_channel_alloc channel;
int main(int argc, char *argv[]) {
int fd;
int rv;
if (argc != 2)
die("usage: %s <dev>", 0, argv[0]);
if ((fd = open(argv[1], O_RDONLY)) == -1)
die("open %s", errno, argv[1]);
if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 &&
errno == EACCES)
die("ioctl %s", errno, argv[1]);
close(fd);
printf("PASS\n");
return 0;
}
---------------------------------8<----------------------------------------
[1] https://github.com/kernelslacker/trinity
Fixes:
eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory")
Signed-off-by: Frantisek Hrbata <frantisek@hrbata.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Wed, 20 Jan 2021 18:57:25 +0000 (18:57 +0000)]
crypto: talitos - Fix ctr(aes) on SEC1
[ Upstream commit
43a942d27eaaf33bca560121cbe42f3637e92880 ]
While ctr(aes) requires the use of a special descriptor on SEC2 (see
commit
70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")), that
special descriptor doesn't work on SEC1, see commit
e738c5f15562
("powerpc/8xx: Add DT node for using the SEC engine of the MPC885").
However, the common nonsnoop descriptor works properly on SEC1 for
ctr(aes).
Add a second template for ctr(aes) that will be registered
only on SEC1.
Fixes:
70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Wed, 20 Jan 2021 18:57:24 +0000 (18:57 +0000)]
crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error)
[ Upstream commit
416b846757bcea20006a9197e67ba3a8b5b2a680 ]
Talitos Security Engine AESU considers any input
data size that is not a multiple of 16 bytes to be an error.
This is not a problem in general, except for Counter mode
that is a stream cipher and can have an input of any size.
Test Manager for ctr(aes) fails on 4th test vector which has
a length of 499 while all previous vectors which have a 16 bytes
multiple length succeed.
As suggested by Freescale, round up the input data length to the
nearest 16 bytes.
Fixes:
5e75ae1b3cef ("crypto: talitos - add new crypto modes")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 28 Jan 2021 09:36:52 +0000 (12:36 +0300)]
mtd: parser: imagetag: fix error codes in bcm963xx_parse_imagetag_partitions()
[ Upstream commit
12ba8f8ce29fdd277f3100052eddc1afd2f5ea3f ]
If the kstrtouint() calls fail, then this should return a negative
error code but it currently returns success.
Fixes:
dd84cb022b31 ("mtd: bcm63xxpart: move imagetag parsing to its own parser")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/YBKFtNaFHGYBj+u4@mwanda
Signed-off-by: Sasha Levin <sashal@kernel.org>