From: Charles Keepax <ckeepax@opensource.cirrus.com>
[ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ]
Currently, the SPI core doesn't set the struct device fwnode pointer
when it creates a new SPI device. This means when the device is
registered the fwnode is NULL and the check in device_add which sets
the fwnode->dev pointer is skipped. This wasn't previously an issue,
however these two patches:
commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
fw_devlink=on by default")
commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the
primary device")
Added some code to the GPIO core which relies on using that
fwnode->dev pointer to determine if a driver is bound to the fwnode
and if not bind a stub GPIO driver. This means the GPIO providers
behind SPI will get both the expected driver and this stub driver
causing the stub driver to fail if it attempts to request any pin
configuration. For example on my system:
madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3
madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22
madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl
gpio_stub_drv gpiochip3: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip3 failed with error -22
The firmware node on the device created by the GPIO framework is set
through the of_node pointer hence things generally actually work,
however that fwnode->dev is never set, as the check was skipped at
device_add time. This fix appears to match how the I2C subsystem
handles the same situation.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/spi/spi.c | 1 +
1 file changed, 1 insertion(+)
@@ -1849,6 +1849,7 @@ of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc)/* Store a pointer to the node in the device structure */of_node_get(nc);spi->dev.of_node=nc;+spi->dev.fwnode=of_fwnode_handle(nc);/* Register the new device */rc=spi_add_device(spi);
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit fdc34e82c0f968ac4c157bd3d8c299ebc24c9c63 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
While here, check if the PM runtime error was caught at
s5p_cec_adap_enable().
Reviewed-by: Jonathan Cameron <redacted>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-cec/s5p_cec.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit c44eac5b72e23c31eefc0e10a71d9650036b8341 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
The bdisp_start_streaming() doesn't take it into account, which
would unbalance PM usage counter at bdisp_stop_streaming().
The logic at bdisp_probe() is correct, but the best is to use
the same call along the driver.
So, replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
Reviewed-by: Jonathan Cameron <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
@@ -499,7 +499,7 @@ static int bdisp_start_streaming(struct vb2_queue *q, unsigned int count){structbdisp_ctx*ctx=q->drv_priv;structvb2_v4l2_buffer*buf;-intret=pm_runtime_get_sync(ctx->bdisp_dev->dev);+intret=pm_runtime_resume_and_get(ctx->bdisp_dev->dev);if(ret<0){dev_err(ctx->bdisp_dev->dev,"failed to set runtime PM\n");
@@ -1364,10 +1364,10 @@ static int bdisp_probe(struct platform_device *pdev)/* Power management */pm_runtime_enable(dev);-ret=pm_runtime_get_sync(dev);+ret=pm_runtime_resume_and_get(dev);if(ret<0){dev_err(dev,"failed to set PM\n");-gotoerr_pm;+gotoerr_remove;}/* Filters */
@@ -1395,6 +1395,7 @@ static int bdisp_probe(struct platform_device *pdev)bdisp_hw_free_filters(bdisp->dev);err_pm:pm_runtime_put(dev);+err_remove:bdisp_debugfs_remove(bdisp);err_v4l2:v4l2_device_unregister(&bdisp->v4l2_dev);
From: Pavel Skripkin <redacted>
[ Upstream commit be8656e62e9e791837b606a027802b504a945c97 ]
syzbot reported leak in cpia2 usb driver. The problem was
in invalid error handling.
v4l2_device_register() is called in cpia2_init_camera_struct(), but
all error cases after cpia2_init_camera_struct() did not call the
v4l2_device_unregister()
Reported-by: syzbot+d1e69c888f0d3866ead4@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/cpia2/cpia2.h | 1 +
drivers/media/usb/cpia2/cpia2_core.c | 12 ++++++++++++
drivers/media/usb/cpia2/cpia2_usb.c | 13 +++++++------
3 files changed, 20 insertions(+), 6 deletions(-)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 56c1f0876293888f686e31278d183d4af2cac3c3 ]
The right thing to do is to add a new object to the building
system when a certain config option is selected, and *not*
override them.
So, fix obj-$(config) logic at sti makefiles, using "+=",
instead of ":=".
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sti/bdisp/Makefile | 2 +-
drivers/media/platform/sti/delta/Makefile | 2 +-
drivers/media/platform/sti/hva/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
From: Bixuan Cui <redacted>
[ Upstream commit 06676aa1f455c74e3ad1624cea3acb9ed2ef71ae ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Bixuan Cui <redacted>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/nx/nx-842-pseries.c | 1 +
1 file changed, 1 insertion(+)
From: Lv Yunlong <redacted>
[ Upstream commit 7dd0c9e547b6924e18712b6b51aa3cba1896ee2c ]
A use after free bug caused by the dangling pointer
filp->privitate_data in v4l2_fh_release.
See https://lore.kernel.org/patchwork/patch/1419058/.
My patch sets the dangling pointer to NULL to provide
robust.
Signed-off-by: Lv Yunlong <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/v4l2-core/v4l2-fh.c | 1 +
1 file changed, 1 insertion(+)
From: Igor Matheus Andrade Torrente <redacted>
[ Upstream commit ac5688637144644f06ed1f3c6d4dd8bb7db96020 ]
The em28xx struct kref isn't being decreased after an error in the
em28xx_ir_init, leading to a possible memory leak.
A kref_put and em28xx_shutdown_buttons is added to the error handler code.
Signed-off-by: Igor Matheus Andrade Torrente <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/em28xx/em28xx-input.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -720,7 +720,8 @@ static int em28xx_ir_init(struct em28xx *dev)dev->board.has_ir_i2c=0;dev_warn(&dev->intf->dev,"No i2c IR remote control device found.\n");-return-ENODEV;+err=-ENODEV;+gotoref_put;}}
@@ -735,7 +736,7 @@ static int em28xx_ir_init(struct em28xx *dev)ir=kzalloc(sizeof(*ir),GFP_KERNEL);if(!ir)-return-ENOMEM;+gotoref_put;rc=rc_allocate_device(RC_DRIVER_SCANCODE);if(!rc)gotoerror;
@@ -839,6 +840,9 @@ static int em28xx_ir_init(struct em28xx *dev)dev->ir=NULL;rc_free_device(rc);kfree(ir);+ref_put:+em28xx_shutdown_buttons(dev);+kref_put(&dev->ref,em28xx_free_device);returnerr;}
From: Anirudh Rayabharam <redacted>
[ Upstream commit f8194e5e63fdcb349e8da9eef9e574d5b1d687cb ]
syzbot has reported the following warning in pvr2_i2c_done:
sysfs group 'power' not found for kobject '1-0043'
When the device is disconnected (pvr_hdw_disconnect), the i2c adapter is
not unregistered along with the USB and v4l2 teardown. As part of the USB
device disconnect, the sysfs files of the subdevices are also deleted.
So, by the time pvr_i2c_core_done is called by pvr_context_destroy, the
sysfs files have been deleted.
To fix this, unregister the i2c adapter too in pvr_hdw_disconnect. Make
the device deregistration code shared by calling pvr_hdw_disconnect from
pvr2_hdw_destroy.
Reported-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
Tested-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Anirudh Rayabharam <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Dongliang Mu <redacted>
[ Upstream commit 9ad1efee086e0e913914fa2b2173efb830bad68c ]
When the driver fails to talk with the hardware with dvb_usb_generic_rw,
it will return an error to dvb_usb_adapter_frontend_init. However, the
driver forgets to free the resource (e.g., struct cinergyt2_fe_state),
which leads to a memory leak.
Fix this by freeing struct cinergyt2_fe_state when dvb_usb_generic_rw
fails in cinergyt2_frontend_attach.
backtrace:
[<0000000056e17b1a>] kmalloc include/linux/slab.h:552 [inline]
[<0000000056e17b1a>] kzalloc include/linux/slab.h:682 [inline]
[<0000000056e17b1a>] cinergyt2_fe_attach+0x21/0x80 drivers/media/usb/dvb-usb/cinergyT2-fe.c:271
[<00000000ae0b1711>] cinergyt2_frontend_attach+0x21/0x70 drivers/media/usb/dvb-usb/cinergyT2-core.c:74
[<00000000d0254861>] dvb_usb_adapter_frontend_init+0x11b/0x1b0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
[<0000000002e08ac6>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:84 [inline]
[<0000000002e08ac6>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline]
[<0000000002e08ac6>] dvb_usb_device_init.cold+0x4d0/0x6ae drivers/media/usb/dvb-usb/dvb-usb-init.c:287
Reported-by: syzbot+e1de8986786b3722050e@syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <redacted>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/usb/dvb-usb/cinergyT2-core.c | 2 ++
1 file changed, 2 insertions(+)
@@ -78,6 +78,8 @@ static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)ret=dvb_usb_generic_rw(d,st->data,1,st->data,3,0);if(ret<0){+if(adap->fe_adap[0].fe)+adap->fe_adap[0].fe->ops.release(adap->fe_adap[0].fe);deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep state info\n");}mutex_unlock(&d->data_mutex);
From: Tong Zhang <redacted>
[ Upstream commit 42933c8aa14be1caa9eda41f65cde8a3a95d3e39 ]
This patch fixes the following issues:
1. memstick_free_host() will free the host, so the use of ms_dev(host) after
it will be a problem. To fix this, move memstick_free_host() after when we
are done with ms_dev(host).
2. In rtsx_usb_ms_drv_remove(), pm need to be disabled before we remove
and free host otherwise memstick_check will be called and UAF will
happen.
[ 11.351173] BUG: KASAN: use-after-free in rtsx_usb_ms_drv_remove+0x94/0x140 [rtsx_usb_ms]
[ 11.357077] rtsx_usb_ms_drv_remove+0x94/0x140 [rtsx_usb_ms]
[ 11.357376] platform_remove+0x2a/0x50
[ 11.367531] Freed by task 298:
[ 11.368537] kfree+0xa4/0x2a0
[ 11.368711] device_release+0x51/0xe0
[ 11.368905] kobject_put+0xa2/0x120
[ 11.369090] rtsx_usb_ms_drv_remove+0x8c/0x140 [rtsx_usb_ms]
[ 11.369386] platform_remove+0x2a/0x50
[ 12.038408] BUG: KASAN: use-after-free in __mutex_lock.isra.0+0x3ec/0x7c0
[ 12.045432] mutex_lock+0xc9/0xd0
[ 12.046080] memstick_check+0x6a/0x578 [memstick]
[ 12.046509] process_one_work+0x46d/0x750
[ 12.052107] Freed by task 297:
[ 12.053115] kfree+0xa4/0x2a0
[ 12.053272] device_release+0x51/0xe0
[ 12.053463] kobject_put+0xa2/0x120
[ 12.053647] rtsx_usb_ms_drv_remove+0xc4/0x140 [rtsx_usb_ms]
[ 12.053939] platform_remove+0x2a/0x50
Signed-off-by: Tong Zhang <redacted>
Co-developed-by: Ulf Hansson <redacted>
Link: https://lore.kernel.org/r/20210511163944.1233295-1-ztong0001@gmail.com
Signed-off-by: Ulf Hansson <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/memstick/host/rtsx_usb_ms.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
@@ -799,9 +799,9 @@ static int rtsx_usb_ms_drv_probe(struct platform_device *pdev)return0;err_out:-memstick_free_host(msh);pm_runtime_disable(ms_dev(host));pm_runtime_put_noidle(ms_dev(host));+memstick_free_host(msh);returnerr;}
@@ -828,9 +828,6 @@ static int rtsx_usb_ms_drv_remove(struct platform_device *pdev)}mutex_unlock(&host->host_mutex);-memstick_remove_host(msh);-memstick_free_host(msh);-/* Balance possible unbalanced usage count*e.g.unconditionalmoduleremoval*/
@@ -838,10 +835,11 @@ static int rtsx_usb_ms_drv_remove(struct platform_device *pdev)pm_runtime_put(ms_dev(host));pm_runtime_disable(ms_dev(host));-platform_set_drvdata(pdev,NULL);-+memstick_remove_host(msh);dev_dbg(ms_dev(host),": Realtek USB Memstick controller has been removed\n");+memstick_free_host(msh);+platform_set_drvdata(pdev,NULL);return0;}
From: Ard Biesheuvel <ardb@kernel.org>
[ Upstream commit 22ca9f4aaf431a9413dcc115dd590123307f274f ]
crypto_shash_alg_has_setkey() is implemented by testing whether the
.setkey() member of a struct shash_alg points to the default version,
called shash_no_setkey(). As crypto_shash_alg_has_setkey() is a static
inline, this requires shash_no_setkey() to be exported to modules.
Unfortunately, when building with CFI, function pointers are routed
via CFI stubs which are private to each module (or to the kernel proper)
and so this function pointer comparison may fail spuriously.
Let's fix this by turning crypto_shash_alg_has_setkey() into an out of
line function.
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <redacted>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
crypto/shash.c | 18 +++++++++++++++---
include/crypto/internal/hash.h | 8 +-------
2 files changed, 16 insertions(+), 10 deletions(-)
From: Krzysztof Kozlowski <redacted>
[ Upstream commit 961470820021e6f9d74db4837bd6831a1a30341b ]
The sdhci_sprd_writew() was defined by never used in sdhci_ops:
drivers/mmc/host/sdhci-sprd.c:134:20: warning: unused function 'sdhci_sprd_writew'
Reported-by: kernel test robot <redacted>
Signed-off-by: Krzysztof Kozlowski <redacted>
Link: https://lore.kernel.org/r/20210601095403.236007-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Ulf Hansson <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/mmc/host/sdhci-sprd.c | 1 +
1 file changed, 1 insertion(+)
From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
[ Upstream commit 77bbbc0cf84834ed130838f7ac1988567f4d0288 ]
The POWER9 vCPU TLB management code assumes all threads in a core share
a TLB, and that TLBIEL execued by one thread will invalidate TLBs for
all threads. This is not the case for SMT8 capable POWER9 and POWER10
(big core) processors, where the TLB is split between groups of threads.
This results in TLB multi-hits, random data corruption, etc.
Fix this by introducing cpu_first_tlb_thread_sibling etc., to determine
which siblings share TLBs, and use that in the guest TLB flushing code.
[npiggin@gmail.com: add changelog and comment]
Signed-off-by: Paul Mackerras <redacted>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Fabiano Rosas <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210602040441.3984352-1-npiggin@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cputhreads.h | 30 +++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv.c | 13 ++++++------
arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
4 files changed, 39 insertions(+), 8 deletions(-)
@@ -99,6 +99,36 @@ static inline int cpu_last_thread_sibling(int cpu)returncpu|(threads_per_core-1);}+/*+*tlb_thread_siblingsaresiblingswhichshareaTLB.Thisisnot+*architected,isnotsomethingahypervisorcouldemulateandafuture+*CPUmaychangebehaviourevenincompatmode,sothisshouldonlybe+*usedonPowerNV,andonlywithcare.+*/+staticinlineintcpu_first_tlb_thread_sibling(intcpu)+{+if(cpu_has_feature(CPU_FTR_ARCH_300)&&(threads_per_core==8))+returncpu&~0x6;/* Big Core */+else+returncpu_first_thread_sibling(cpu);+}++staticinlineintcpu_last_tlb_thread_sibling(intcpu)+{+if(cpu_has_feature(CPU_FTR_ARCH_300)&&(threads_per_core==8))+returncpu|0x6;/* Big Core */+else+returncpu_last_thread_sibling(cpu);+}++staticinlineintcpu_tlb_thread_sibling_step(void)+{+if(cpu_has_feature(CPU_FTR_ARCH_300)&&(threads_per_core==8))+return2;/* Big Core */+else+return1;+}+staticinlineu32get_tensr(void){#ifdef CONFIG_BOOKE
From: Christophe Leroy <redacted>
[ Upstream commit b05fbcc36be1f8597a1febef4892053a0b2f3f60 ]
With a config having PAGE_SIZE set to 256K, BTRFS build fails
with the following message
include/linux/compiler_types.h:326:38: error: call to
'__compiletime_assert_791' declared with attribute error:
BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0
BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with
256K pages at the time being.
There are two platforms that can select 256K pages:
- hexagon
- powerpc
Disable BTRFS when 256K page size is selected. Supporting this would
require changes to the subpage mode that's currently being developed.
Given that 256K is many times larger than page sizes commonly used and
for what the algorithms and structures have been tuned, it's out of
scope and disabling build is a reasonable option.
Reported-by: kernel test robot <redacted>
Signed-off-by: Christophe Leroy <redacted>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/Kconfig | 2 ++
1 file changed, 2 insertions(+)
From: Boqun Feng <redacted>
[ Upstream commit 69c7a5fb2482636f525f016c8333fdb9111ecb9d ]
We use the same code to print backwards lock dependency path as the
forwards lock dependency path, and this could result into incorrect
printing because for a backwards lock_list ->trace is not the call trace
where the lock of ->class is acquired.
Fix this by introducing a separate function on printing the backwards
dependency path. Also add a few comments about the printing while we are
at it.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Boqun Feng <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210618170110.3699115-2-boqun.feng@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/locking/lockdep.c | 108 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 106 insertions(+), 2 deletions(-)
@@ -1969,6 +2018,61 @@ print_shortest_lock_dependencies(struct lock_list *leaf,}while(entry&&(depth>=0));}+/*+*printktheshortestlockdependenciesfrom@leafto@root.+*+*Wehavealockdependencypath(fromabackwardssearch)asfollow:+*+*@leaf@root+*||+*VV+*->parent->parent+*|lock_list|--------->|lock_list|...|lock_list|--------->|lock_list|+*|L2<-L1||L3<-L2|...|Ln<-Ln-1||<-Ln|+*+*,sowhenweiteratefrom@leafto@root,weactuallyprintthelock+*dependencypathL1->L2->..->Lninthenon-reverseorder.+*+*Anotherthingtonoticehereisthat->classofL2<-L1isL1,whilethe+*->traceofL2<-L1isthecalltraceofL2,infactwedon'thavethecall+*traceofL1inthedependencypath,whichisalright,becausemostofthe+*timewecanfigureoutwhereL1isheldfromthecalltraceofL2.+*/+staticvoid__used+print_shortest_lock_dependencies_backwards(structlock_list*leaf,+structlock_list*root)+{+structlock_list*entry=leaf;+conststructlock_trace*trace=NULL;+intdepth;++/*compute depth from generated tree by BFS*/+depth=get_lock_depth(leaf);++do{+print_lock_class_header(entry->class,depth);+if(trace){+printk("%*s ... acquired at:\n",depth,"");+print_lock_trace(trace,2);+printk("\n");+}++/*+*Recordthepointertothetraceforthenextlock_list+*entry,seethecommentsforthefunction.+*/+trace=entry->trace;++if(depth==0&&(entry!=root)){+printk("lockdep:%s bad path found in chain graph\n",__func__);+break;+}++entry=get_lock_parent(entry);+depth--;+}while(entry&&(depth>=0));+}+staticvoidprint_irq_lock_scenario(structlock_list*safe_entry,structlock_list*unsafe_entry,
@@ -2086,7 +2190,7 @@ print_bad_irq_dependency(struct task_struct *curr,prev_root->trace=save_trace();if(!prev_root->trace)return;-print_shortest_lock_dependencies(backwards_entry,prev_root);+print_shortest_lock_dependencies_backwards(backwards_entry,prev_root);pr_warn("\nthe dependencies between the lock to be acquired");pr_warn(" and %s-irq-unsafe lock:\n",irqclass);
From: Heiko Carstens <hca@linux.ibm.com>
[ Upstream commit 4fa3b91bdee1b08348c82660668ca0ca34e271ad ]
Using register asm statements has been proven to be very error prone,
especially when using code instrumentation where gcc may add function
calls, which clobbers register contents in an unexpected way.
Therefore get rid of register asm statements in kvm code, even though
there is currently nothing wrong with them. This way we know for sure
that this bug class won't be introduced here.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Christian Borntraeger <redacted>
Reviewed-by: Thomas Huth <redacted>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Link: https://lore.kernel.org/r/20210621140356.1210771-1-hca@linux.ibm.com
[borntraeger@de.ibm.com: checkpatch strict fix]
Signed-off-by: Christian Borntraeger <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/s390/kvm/kvm-s390.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
From: Axel Lin <redacted>
[ Upstream commit a336dc8f683e5be794186b5643cd34cb28dd2c53 ]
Use DIV_ROUND_UP to prevent truncation by integer division issue.
This ensures we return enough delay time.
Also fix returning negative value when new_sel < old_sel.
Signed-off-by: Axel Lin <redacted>
Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/da9052-regulator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 6e8b1526db164c9d4b9dacfb9bc48e365d7c4860 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
While here, check if the PM runtime error was caught at open time.
Reviewed-by: Jonathan Cameron <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sh_vou.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
@@ -1133,7 +1133,11 @@ static int sh_vou_open(struct file *file)if(v4l2_fh_is_singular_file(file)&&vou_dev->status==SH_VOU_INITIALISING){/* First open */-pm_runtime_get_sync(vou_dev->v4l2_dev.dev);+err=pm_runtime_resume_and_get(vou_dev->v4l2_dev.dev);+if(err<0){+v4l2_fh_release(file);+gotodone_open;+}err=sh_vou_hw_init(vou_dev);if(err<0){pm_runtime_put(vou_dev->v4l2_dev.dev);
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 908711f542c17fe61e5d653da1beb8e5ab5c7b50 ]
Currently, the driver just assumes that PM runtime logic
succeded resuming the device.
That may not be the case, as pm_runtime_get_sync()
can fail (but keeping the usage count incremented).
Replace the code to use pm_runtime_resume_and_get(),
and letting it return the error code.
This way, if mtk_vcodec_dec_pw_on() fails, the logic
under fops_vcodec_open() will do the right thing and
return an error, instead of just assuming that the
device is ready to be used.
Reviewed-by: Jonathan Cameron <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 +++-
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 8 +++++---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
From: Tian Tao <tiantao6@hisilicon.com>
[ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ]
word_len should be checked in the omap1_spi100k_setup_transfer
function to see if it exceeds 32.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/spi/spi-omap-100k.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jay Fang <f.fangjian@huawei.com>
[ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ]
pch_spi_set_tx() frees data->pkt_tx_buff on failure of kzalloc() for
data->pkt_rx_buff, but its caller, pch_spi_process_messages(), will
free data->pkt_tx_buff again. Set data->pkt_tx_buff to NULL after
kfree() to avoid double free.
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/spi/spi-topcliff-pch.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 59087b66ea6730c130c57d23bd9fd139b78c1ba5 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
As a bonus, as pm_runtime_get_sync() always return 0 on
success, the logic can be simplified.
Reviewed-by: Jonathan Cameron <redacted>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/exynos-gsc/gsc-m2m.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
@@ -134,7 +134,7 @@ static int exynos_trng_probe(struct platform_device *pdev)returnPTR_ERR(trng->mem);pm_runtime_enable(&pdev->dev);-ret=pm_runtime_get_sync(&pdev->dev);+ret=pm_runtime_resume_and_get(&pdev->dev);if(ret<0){dev_err(&pdev->dev,"Could not get runtime PM.\n");gotoerr_pm_get;
@@ -167,7 +167,7 @@ static int exynos_trng_probe(struct platform_device *pdev)clk_disable_unprepare(trng->clk);err_clock:-pm_runtime_put_sync(&pdev->dev);+pm_runtime_put_noidle(&pdev->dev);err_pm_get:pm_runtime_disable(&pdev->dev);
From: Zou Wei <redacted>
[ Upstream commit d019f38a1af3c6015cde6a47951a3ec43beeed80 ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Zou Wei <redacted>
Link: https://lore.kernel.org/r/1620705198-104566-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/uniphier-regulator.c | 1 +
1 file changed, 1 insertion(+)
From: Hans Verkuil <redacted>
[ Upstream commit 3d37ef41bed0854805ab9af22c422267510e1344 ]
The cobalt_s_bit_sysctrl reads the old register value over PCI,
then changes a bit and sets writes the new value to the register.
This is used among other things for setting the HPD output pin.
But if the HPD is changed for multiple inputs at the same time,
then this causes a race condition where a stale value is read.
Serialize this function with a mutex.
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/pci/cobalt/cobalt-driver.c | 1 +
drivers/media/pci/cobalt/cobalt-driver.h | 7 ++++++-
2 files changed, 7 insertions(+), 1 deletion(-)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 10343de268d10cf07b092b8b525e12ad558ead77 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
As a plus, pm_runtime_resume_and_get() doesn't return
positive numbers, so the return code validation can
be removed.
Reviewed-by: Jonathan Cameron <redacted>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
From: Jack Xu <redacted>
[ Upstream commit 9afe77cf25d9670e61b489fd52cc6f75fd7f6803 ]
Remove the unused macro ICP_DH895XCC_PESRAM_BAR_SIZE in the firmware
loader.
This is to fix the following warning when compiling the driver using the
clang compiler with CC=clang W=2:
drivers/crypto/qat/qat_common/qat_uclo.c:345:9: warning: macro is not used [-Wunused-macros]
Signed-off-by: Jack Xu <redacted>
Co-developed-by: Zhehui Xiang <redacted>
Signed-off-by: Zhehui Xiang <redacted>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/qat/qat_common/qat_uclo.c | 1 -
1 file changed, 1 deletion(-)
From: Steve Longerbeam <slongerbeam@gmail.com>
[ Upstream commit e198be37e52551bb863d07d2edc535d0932a3c4f ]
Some BT.656 sensors (e.g. ADV718x) transmit frames with unstable BT.656
sync codes after initial power on. This confuses the imx CSI,resulting
in vertical and/or horizontal sync issues. Skip the first 20 frames
to avoid the unstable sync codes.
[fabio: fixed checkpatch warning and increased the frame skipping to 20]
Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/staging/media/imx/imx-media-csi.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
@@ -764,6 +765,17 @@ static int csi_start(struct csi_priv *priv)if(ret)returnret;+/* Skip first few frames from a BT.656 source */+if(priv->upstream_ep.bus_type==V4L2_MBUS_BT656){+u32delay_usec,bad_frames=20;++delay_usec=DIV_ROUND_UP_ULL((u64)USEC_PER_SEC*+input_fi->numerator*bad_frames,+input_fi->denominator);++usleep_range(delay_usec,delay_usec+1000);+}+if(priv->dest==IPU_CSI_DEST_IDMAC){ret=csi_idmac_start(priv);if(ret)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit 5368b1ee2939961a16e74972b69088433fc52195 ]
As reported by smatch:
drivers/media/common/siano/smsdvb-main.c:1231 smsdvb_hotplug() warn: '&client->entry' not removed from list
If an error occur at the end of the registration logic, it won't
drop the device from the list.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/common/siano/smsdvb-main.c | 4 ++++
1 file changed, 4 insertions(+)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit abc0226df64dc137b48b911c1fe4319aec5891bb ]
The risk of especulation is actually almost-non-existing here,
as there are very few users of TCP/IP using the DVB stack,
as, this is mainly used with DVB-S/S2 cards, and only by people
that receives TCP/IP from satellite connections, which limits
a lot the number of users of such feature(*).
(*) In thesis, DVB-C cards could also benefit from it, but I'm
yet to see a hardware that supports it.
Yet, fixing it is trivial.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/dvb-core/dvb_net.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
From: Josef Bacik <josef@toxicpanda.com>
[ Upstream commit bb385bedded3ccbd794559600de4a09448810f4a ]
If we get an error while looking up the inode item we'll simply bail
without cleaning up the delayed node. This results in this style of
warning happening on commit:
WARNING: CPU: 0 PID: 76403 at fs/btrfs/delayed-inode.c:1365 btrfs_assert_delayed_root_empty+0x5b/0x90
CPU: 0 PID: 76403 Comm: fsstress Tainted: G W 5.13.0-rc1+ #373
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
RIP: 0010:btrfs_assert_delayed_root_empty+0x5b/0x90
RSP: 0018:ffffb8bb815a7e50 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff95d6d07e1888 RCX: ffff95d6c0fa3000
RDX: 0000000000000002 RSI: 000000000029e91c RDI: ffff95d6c0fc8060
RBP: ffff95d6c0fc8060 R08: 00008d6d701a2c1d R09: 0000000000000000
R10: ffff95d6d1760ea0 R11: 0000000000000001 R12: ffff95d6c15a4d00
R13: ffff95d6c0fa3000 R14: 0000000000000000 R15: ffffb8bb815a7e90
FS: 00007f490e8dbb80(0000) GS:ffff95d73bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6e75555cb0 CR3: 00000001101ce001 CR4: 0000000000370ef0
Call Trace:
btrfs_commit_transaction+0x43c/0xb00
? finish_wait+0x80/0x80
? vfs_fsync_range+0x90/0x90
iterate_supers+0x8c/0x100
ksys_sync+0x50/0x90
__do_sys_sync+0xa/0x10
do_syscall_64+0x3d/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Because the iref isn't dropped and this leaves an elevated node->count,
so any release just re-queues it onto the delayed inodes list. Fix this
by going to the out label to handle the proper cleanup of the delayed
node.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/delayed-inode.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 897f6339893b741a5d68ae8e2475df65946041c2 ]
The MAX31790 has two sets of registers for pwm duty cycles, one to request
a duty cycle and one to read the actual current duty cycle. Both do not
have to be the same.
When reporting the pwm duty cycle to the user, the actual pwm duty cycle
from pwm duty cycle registers needs to be reported. When setting it, the
pwm target duty cycle needs to be written. Since we don't know the actual
pwm duty cycle after a target pwm duty cycle has been written, set the
valid flag to false to indicate that actual pwm duty cycle should be read
from the chip instead of using cached values.
Cc: Jan Kundrát <redacted>
Cc: Václav Kubernát <redacted>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <redacted>
Reviewed-by: Jan Kundrát <redacted>
Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/hwmon/max31790.rst | 3 ++-
drivers/hwmon/max31790.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
From: Qu Wenruo <redacted>
[ Upstream commit 0528476b6ac7832f31e2ed740a57ae31316b124e ]
[BUG]
With current subpage RW support, the following script can hang the fs
with 64K page size.
# mkfs.btrfs -f -s 4k $dev
# mount $dev -o nospace_cache $mnt
# fsstress -w -n 50 -p 1 -s 1607749395 -d $mnt
The kernel will do an infinite loop in btrfs_punch_hole_lock_range().
[CAUSE]
In btrfs_punch_hole_lock_range() we:
- Truncate page cache range
- Lock extent io tree
- Wait any ordered extents in the range.
We exit the loop until we meet all the following conditions:
- No ordered extent in the lock range
- No page is in the lock range
The latter condition has a pitfall, it only works for sector size ==
PAGE_SIZE case.
While can't handle the following subpage case:
0 32K 64K 96K 128K
| |///////||//////| ||
lockstart=32K
lockend=96K - 1
In this case, although the range crosses 2 pages,
truncate_pagecache_range() will invalidate no page at all, but only zero
the [32K, 96K) range of the two pages.
Thus filemap_range_has_page(32K, 96K-1) will always return true, thus we
will never meet the loop exit condition.
[FIX]
Fix the problem by doing page alignment for the lock range.
Function filemap_range_has_page() has already handled lend < lstart
case, we only need to round up @lockstart, and round_down @lockend for
truncate_pagecache_range().
This modification should not change any thing for sector size ==
PAGE_SIZE case, as in that case our range is already page aligned.
Tested-by: Ritesh Harjani <redacted> # [ppc64]
Tested-by: Anand Jain <redacted> # [aarch64]
Signed-off-by: Qu Wenruo <redacted>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/file.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
From: Shuah Khan <skhan@linuxfoundation.org>
[ Upstream commit 50e7a31d30e8221632675abed3be306382324ca2 ]
Smatch static checker warns that "mdev" can be null:
sound/usb/media.c:287 snd_media_device_create()
warn: 'mdev' can also be NULL
If CONFIG_MEDIA_CONTROLLER is disabled, this file should not be included
in the build.
The below conditions in the sound/usb/Makefile are in place to ensure that
media.c isn't included in the build.
sound/usb/Makefile:
snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o
select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER &&
(MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO)
The following config check in include/media/media-dev-allocator.h is
in place to enable the API only when CONFIG_MEDIA_CONTROLLER and
CONFIG_USB are enabled.
#if defined(CONFIG_MEDIA_CONTROLLER) && defined(CONFIG_USB)
This check doesn't work as intended when CONFIG_USB=m. When CONFIG_USB=m,
CONFIG_USB_MODULE is defined and CONFIG_USB is not. The above config check
doesn't catch that CONFIG_USB is defined as a module and disables the API.
This results in sound/usb enabling Media Controller specific ALSA driver
code, while Media disables the Media Controller API.
Fix the problem requires two changes:
1. Change the check to use IS_ENABLED to detect when CONFIG_USB is enabled
as a module or static. Since CONFIG_MEDIA_CONTROLLER is a bool, leave
the check unchanged to be consistent with drivers/media/Makefile.
2. Change the drivers/media/mc/Makefile to include mc-dev-allocator.o
in mc-objs when CONFIG_USB is enabled.
Link: https://lore.kernel.org/alsa-devel/YLeAvT+R22FQ%2FEyw@mwanda/
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/mc/Makefile | 2 +-
include/media/media-dev-allocator.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
From: Hsin-Hsiung Wang <redacted>
[ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ]
The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf.
Signed-off-by: Hsin-Hsiung Wang <redacted>
Reviewed-by: Axel Lin <redacted>
Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/regulator/mt6358-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Evgeny Novikov <redacted>
[ Upstream commit b7fdd208687ba59ebfb09b2199596471c63b69e3 ]
When ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread() it tries to
access fields of ctx that is NULL at that point. The patch gets rid of
these accesses.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <redacted>
Signed-off-by: Hans Verkuil <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/sti/hva/hva-hw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 148c847c9e5a54b99850617bf9c143af9a344f92 ]
pwmX_enable supports three possible values:
0: Fan control disabled. Duty cycle is fixed to 0%
1: Fan control enabled, pwm mode. Duty cycle is determined by
values written into Target Duty Cycle registers.
2: Fan control enabled, rpm mode
Duty cycle is adjusted such that fan speed matches
the values in Target Count registers
The current code does not do this; instead, it mixes pwm control
configuration with fan speed monitoring configuration. Worse, it
reports that pwm control would be disabled (pwmX_enable==0) when
it is in fact enabled in pwm mode. Part of the problem may be that
the chip sets the "TACH input enable" bit on its own whenever the
mode bit is set to RPM mode, but that doesn't mean that "TACH input
enable" accurately reflects the pwm mode.
Fix it up and only handle pwm control with the pwmX_enable attributes.
In the documentation, clarify that disabling pwm control (pwmX_enable=0)
sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN
is set together with RPM_MODE.
While at it, only update the configuration register if the configuration
has changed, and only update the cached configuration if updating the
chip configuration was successful.
Cc: Jan Kundrát <redacted>
Cc: Václav Kubernát <redacted>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <redacted>
Reviewed-by: Jan Kundrát <redacted>
Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/hwmon/max31790.rst | 2 +-
drivers/hwmon/max31790.c | 41 ++++++++++++++++++++------------
2 files changed, 27 insertions(+), 16 deletions(-)
From: Boqun Feng <redacted>
[ Upstream commit 7b1f8c6179769af6ffa055e1169610b51d71edd5 ]
In the step #3 of check_irq_usage(), we seach backwards to find a lock
whose usage conflicts the usage of @target_entry1 on safe/unsafe.
However, we should only keep the irq-unsafe usage of @target_entry1 into
consideration, because it could be a case where a lock is hardirq-unsafe
but soft-safe, and in check_irq_usage() we find it because its
hardirq-unsafe could result into a hardirq-safe-unsafe deadlock, but
currently since we don't filter out the other usage bits, so we may find
a lock dependency path softirq-unsafe -> softirq-safe, which in fact
doesn't cause a deadlock. And this may cause misleading lockdep splats.
Fix this by only keeping LOCKF_ENABLED_IRQ_ALL bits when we try the
backwards search.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Boqun Feng <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210618170110.3699115-4-boqun.feng@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/locking/lockdep.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
From: Odin Ugedal <redacted>
[ Upstream commit 08f7c2f4d0e9f4283f5796b8168044c034a1bfcb ]
When using something other than 8 spaces per tab, this ascii art
makes not sense, and the reader might end up wondering what this
advanced equation "is".
Signed-off-by: Odin Ugedal <redacted>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210518125202.78658-4-odin@uged.al
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/sched/fair.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Nick Desaulniers <ndesaulniers@google.com>
[ Upstream commit 27f2a4db76e8d8a8b601fc1c6a7a17f88bd907ab ]
GDB produces the following warning when debugging kernels built with
CONFIG_RELR:
BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'
when loading a kernel built with CONFIG_RELR into GDB. It can also
prevent debugging symbols using such relocations.
Peter sugguests:
[That flag] means that lld will use dynamic tags and section type
numbers in the OS-specific range rather than the generic range. The
kernel itself doesn't care about these numbers; it determines the
location of the RELR section using symbols defined by a linker script.
Link: https://github.com/ClangBuiltLinux/linux/issues/1057
Suggested-by: Peter Collingbourne <redacted>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 2 +-
scripts/tools-support-relr.sh | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
@@ -937,7 +937,7 @@ LDFLAGS_vmlinux += $(call ld-option, -X,)endififeq ($(CONFIG_RELR),y)-LDFLAGS_vmlinux+=--pack-dyn-relocs=relr+LDFLAGS_vmlinux+=--pack-dyn-relocs=relr--use-android-relr-tagsendif# make the checker run with the right architecture
@@ -7,7 +7,8 @@ trap "rm -f $tmp_file.o $tmp_file $tmp_file.bin" EXIT cat<<"END"|$CC-c-xc--o$tmp_file.o>/dev/null2>&1 void*p=&p; END-$LD$tmp_file.o-shared-Bsymbolic--pack-dyn-relocs=relr-o$tmp_file+$LD$tmp_file.o-shared-Bsymbolic--pack-dyn-relocs=relr\+--use-android-relr-tags-o$tmp_file# Despite printing an error message, GNU nm still exits with exit code 0 if it# sees a relr section. So we need to check that nothing is printed to stderr.
From: Jack Xu <redacted>
[ Upstream commit 96b57229209490c8bca4335b01a426a96173dc56 ]
Check the return code of the function qat_hal_rd_rel_reg() and return it
to the caller.
This is to fix the following warning when compiling the driver with
clang scan-build:
drivers/crypto/qat/qat_common/qat_hal.c:1436:2: warning: 6th function call argument is an uninitialized value
Signed-off-by: Jack Xu <redacted>
Co-developed-by: Zhehui Xiang <redacted>
Signed-off-by: Zhehui Xiang <redacted>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/qat/qat_common/qat_hal.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
@@ -1256,7 +1256,11 @@ static int qat_hal_put_rel_wr_xfer(struct icp_qat_fw_loader_handle *handle,pr_err("QAT: bad xfrAddr=0x%x\n",xfr_addr);return-EINVAL;}-qat_hal_rd_rel_reg(handle,ae,ctx,ICP_GPB_REL,gprnum,&gprval);+status=qat_hal_rd_rel_reg(handle,ae,ctx,ICP_GPB_REL,gprnum,&gprval);+if(status){+pr_err("QAT: failed to read register");+returnstatus;+}gpr_addr=qat_hal_get_reg_addr(ICP_GPB_REL,gprnum);data16low=0xffff&data;data16hi=0xffff&(data>>0x10);
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
[ Upstream commit d07bb9702cf5f5ccf3fb661e6cab54bbc33cd23f ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
as it doesn't make any sense to return 0 if the PM runtime failed
to resume.
Reviewed-by: Jonathan Cameron <redacted>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Qu Wenruo <redacted>
[ Upstream commit 87b4d86baae219a9a79f6b0a1434b2a42fd40d09 ]
Currently we use page Private2 bit to indicate that we have ordered
extent for the page range.
But the lifespan of it is not consistent, during regular writeback path,
there are two locations to clear the same PagePrivate2:
T ----- Page marked Dirty
|
+ ----- Page marked Private2, through btrfs_run_dealloc_range()
|
+ ----- Page cleared Private2, through btrfs_writepage_cow_fixup()
| in __extent_writepage_io()
| ^^^ Private2 cleared for the first time
|
+ ----- Page marked Writeback, through btrfs_set_range_writeback()
| in __extent_writepage_io().
|
+ ----- Page cleared Private2, through
| btrfs_writepage_endio_finish_ordered()
| ^^^ Private2 cleared for the second time.
|
+ ----- Page cleared Writeback, through
btrfs_writepage_endio_finish_ordered()
Currently PagePrivate2 is mostly to prevent ordered extent accounting
being executed for both endio and invalidatepage.
Thus only the one who cleared page Private2 is responsible for ordered
extent accounting.
But the fact is, in btrfs_writepage_endio_finish_ordered(), page
Private2 is cleared and ordered extent accounting is executed
unconditionally.
The race prevention only happens through btrfs_invalidatepage(), where
we wait for the page writeback first, before checking the Private2 bit.
This means, Private2 is also protected by Writeback bit, and there is no
need for btrfs_writepage_cow_fixup() to clear Priavte2.
This patch will change btrfs_writepage_cow_fixup() to just check
PagePrivate2, not to clear it.
The clearing will happen in either btrfs_invalidatepage() or
btrfs_writepage_endio_finish_ordered().
This makes the Private2 bit easier to understand, just meaning the page
has unfinished ordered extent attached to it.
And this patch is a hard requirement for the incoming refactoring for
how we finished ordered IO for endio context, as the coming patch will
check Private2 to determine if we need to do the ordered extent
accounting. Thus this patch is definitely needed or we will hang due to
unfinished ordered extent.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <redacted>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -2406,7 +2406,7 @@ int btrfs_writepage_cow_fixup(struct page *page, u64 start, u64 end)structbtrfs_writepage_fixup*fixup;/* this page is properly in the ordered list */-if(TestClearPagePrivate2(page))+if(PagePrivate2(page))return0;/*
From: Josef Bacik <josef@toxicpanda.com>
[ Upstream commit 04587ad9bef6ce9d510325b4ba9852b6129eebdb ]
If we fail to update the delayed inode we need to abort the transaction,
because we could leave an inode with the improper counts or some other
such corruption behind.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/btrfs/delayed-inode.c | 8 ++++++++
1 file changed, 8 insertions(+)