Jan Kiszka [Mon, 21 Jun 2021 18:08:28 +0000 (20:08 +0200)]
soc: ti: pruss: fix referenced node in error message
[ Upstream commit
8aa35e0bb5eaa42bac415ad0847985daa7b4890c ]
So far, "(null)" is reported for the node that is missing clocks.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/d6e24953-ea89-fd1c-6e16-7a0142118054@siemens.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alex Deucher [Wed, 10 Nov 2021 15:23:25 +0000 (10:23 -0500)]
drm/amdgpu/display: set vblank_disable_immediate for DC
[ Upstream commit
92020e81ddbeac351ea4a19bcf01743f32b9c800 ]
Disable vblanks immediately to save power. I think this was
missed when we merged DC support.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Li [Mon, 15 Nov 2021 08:10:19 +0000 (16:10 +0800)]
drm/amd/display: check top_pipe_to_program pointer
[ Upstream commit
a689e8d1f80012f90384ebac9dcfac4201f9f77e ]
Clang static analysis reports this error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
Dereference of null pointer [clang-analyzer-core.NullDereference]
if
(top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) {
^
top_pipe_to_program being NULL is caught as an error
But then it is used to report the error.
So add a check before using it.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Bulwahn [Thu, 28 Oct 2021 14:19:33 +0000 (16:19 +0200)]
ARM: imx: rename DEBUG_IMX21_IMX27_UART to DEBUG_IMX27_UART
[ Upstream commit
b0100bce4ff82ec1ccd3c1f3d339fd2df6a81784 ]
Since commit
4b563a066611 ("ARM: imx: Remove imx21 support"), the config
DEBUG_IMX21_IMX27_UART is really only debug support for IMX27.
So, rename this option to DEBUG_IMX27_UART and adjust dependencies in
Kconfig and rename the definitions to IMX27 as further clean-up.
This issue was discovered with ./scripts/checkkconfigsymbols.py, which
reported that DEBUG_IMX21_IMX27_UART depends on the non-existing config
SOC_IMX21.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Vasut [Sat, 16 Oct 2021 21:05:47 +0000 (23:05 +0200)]
soc: imx: gpcv2: Synchronously suspend MIX domains
[ Upstream commit
f756f435f7dd823f2d4bd593ce1bf3168def1308 ]
In case the following power domain sequence happens, iMX8M Mini always hangs:
gpumix:on -> gpu:on -> gpu:off -> gpu:on
This is likely due to another quirk of the GPC block. This situation can be
prevented by always synchronously powering off both the domain and MIX domain.
Make it so. This turns the aforementioned sequence into:
gpumix:on -> gpu:on -> gpu:off -> gpumix:off -> gpumix:on -> gpu:on
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Konrad Dybcio [Sun, 14 Nov 2021 01:27:45 +0000 (02:27 +0100)]
arm64: dts: qcom: sm8350: Shorten camera-thermal-bottom name
[ Upstream commit
f52dd33943ca5f84ae76890f352f6d9e12512c3f ]
Thermal zone names should not be longer than 20 names, which is indicated by
a message at boot. Change "camera-thermal-bottom" to "cam-thermal-bottom" to
fix it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211114012755.112226-6-konrad.dybcio@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinh Nguyen [Tue, 12 Oct 2021 19:07:06 +0000 (14:07 -0500)]
EDAC/synopsys: Use the quirk for version instead of ddr version
[ Upstream commit
bd1d6da17c296bd005bfa656952710d256e77dd3 ]
Version 2.40a supports DDR_ECC_INTR_SUPPORT for a quirk, so use that
quirk to determine a call to setup_address_map().
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lkml.kernel.org/r/20211012190709.1504152-1-dinguyen@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Li [Thu, 18 Nov 2021 09:48:03 +0000 (17:48 +0800)]
ethernet: renesas: Use div64_ul instead of do_div
[ Upstream commit
d9f31aeaa1e5aefa68130878af3c3513d41c1e2d ]
do_div() does a 64-by-32 division. Here the divisor is an
unsigned long which on some platforms is 64 bit wide. So use
div64_ul instead of do_div to avoid a possible truncation.
Eliminate the following coccicheck warning:
./drivers/net/ethernet/renesas/ravb_main.c:2492:1-7: WARNING:
do_div() does a 64-by-32 division, please consider using div64_ul
instead.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/1637228883-100100-1-git-send-email-yang.lee@linux.alibaba.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Wed, 17 Nov 2021 19:41:13 +0000 (11:41 -0800)]
libbpf: Accommodate DWARF/compiler bug with duplicated structs
[ Upstream commit
efdd3eb8015e7447095f02a26eaabd164cd18004 ]
According to [0], compilers sometimes might produce duplicate DWARF
definitions for exactly the same struct/union within the same
compilation unit (CU). We've had similar issues with identical arrays
and handled them with a similar workaround in
6b6e6b1d09aa ("libbpf:
Accomodate DWARF/compiler bug with duplicated identical arrays"). Do the
same for struct/union by ensuring that two structs/unions are exactly
the same, down to the integer values of field referenced type IDs.
Solving this more generically (allowing referenced types to be
equivalent, but using different type IDs, all within a single CU)
requires a huge complexity increase to handle many-to-many mappings
between canonidal and candidate type graphs. Before we invest in that,
let's see if this approach handles all the instances of this issue in
practice. Thankfully it's pretty rare, it seems.
[0] https://lore.kernel.org/bpf/YXr2NFlJTAhHdZqq@krava/
Reported-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211117194114.347675-1-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zheyu Ma [Tue, 11 May 2021 09:00:03 +0000 (10:00 +0100)]
media: b2c2: Add missing check in flexcop_pci_isr:
[ Upstream commit
b13203032e679674c7c518f52a7ec0801ca3a829 ]
A out-of-bounds bug can be triggered by an interrupt, the reason for
this bug is the lack of checking of register values.
In flexcop_pci_isr, the driver reads value from a register and uses it as
a dma address. Finally, this address will be passed to the count parameter
of find_next_packet. If this value is larger than the size of dma, the
index of buffer will be out-of-bounds.
Fix this by adding a check after reading the value of the register.
The following KASAN report reveals it:
BUG: KASAN: slab-out-of-bounds in find_next_packet
drivers/media/dvb-core/dvb_demux.c:528 [inline]
BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter
drivers/media/dvb-core/dvb_demux.c:572 [inline]
BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420
drivers/media/dvb-core/dvb_demux.c:603
Read of size 1 at addr
ffff8880608c00a0 by task swapper/2/0
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xec/0x156 lib/dump_stack.c:118
print_address_description+0x78/0x290 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x25b/0x380 mm/kasan/report.c:412
__asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430
find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline]
_dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline]
dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603
flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167
flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212
__handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
</IRQ>
RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31
e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3
90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RSP: 0018:
ffff88806b71fcc8 EFLAGS:
00000246 ORIG_RAX:
ffffffffffffffde
RAX:
0000000000000000 RBX:
ffffffff8bde44c8 RCX:
ffffffff88a11285
RDX:
0000000000000000 RSI:
0000000000000004 RDI:
ffffffff8c2f6200
RBP:
ffff88806b71fcc8 R08:
fffffbfff185ec40 R09:
fffffbfff185ec40
R10:
0000000000000001 R11:
fffffbfff185ec40 R12:
0000000000000002
R13:
ffffffff8be9d6e0 R14:
0000000000000000 R15:
0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
Allocated by task 1:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2741 [inline]
slab_alloc mm/slub.c:2749 [inline]
kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754
kmem_cache_zalloc include/linux/slab.h:699 [inline]
__kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633
kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693
__kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992
sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306
create_files fs/sysfs/group.c:63 [inline]
internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147
sysfs_create_group fs/sysfs/group.c:173 [inline]
sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200
driver_add_groups+0x3e/0x50 drivers/base/driver.c:129
bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684
driver_register+0x1cd/0x410 drivers/base/driver.c:170
__pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411
cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c:
1017
do_one_initcall+0xe0/0x610 init/main.c:884
do_initcall_level init/main.c:952 [inline]
do_initcalls init/main.c:960 [inline]
do_basic_setup init/main.c:978 [inline]
kernel_init_freeable+0x4d0/0x592 init/main.c:1145
kernel_init+0x18/0x190 init/main.c:1062
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at
ffff8880608c0000
which belongs to the cache kernfs_node_cache of size 160
The buggy address is located 0 bytes to the right of
160-byte region [
ffff8880608c0000,
ffff8880608c00a0)
The buggy address belongs to the page:
page:
ffffea0001823000 count:1 mapcount:0 mapping:
ffff88806bed1e00
index:0x0 compound_mapcount: 0
flags: 0x100000000008100(slab|head)
raw:
0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00
raw:
0000000000000000 0000000000240024 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
^
ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================
Link: https://lore.kernel.org/linux-media/1620723603-30912-1-git-send-email-zheyuma97@gmail.com
Reported-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Thu, 18 Nov 2021 07:29:53 +0000 (08:29 +0100)]
HID: apple: Do not reset quirks when the Fn key is not found
[ Upstream commit
a5fe7864d8ada170f19cc47d176bf8260ffb4263 ]
When a keyboard without a function key is detected, instead of removing
all quirks, remove only the APPLE_HAS_FN quirk.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Thu, 18 Nov 2021 16:52:08 +0000 (17:52 +0100)]
HID: magicmouse: Report battery level over USB
[ Upstream commit
0b91b4e4dae63cd43871fc2012370b86ee588f91 ]
When connected over USB, the Apple Magic Mouse 2 and the Apple Magic
Trackpad 2 register multiple interfaces, one of them is used to report
the battery level.
However, unlike when connected over Bluetooth, the battery level is not
reported automatically and it is required to fetch it manually.
Fix the battery report descriptor and add a timer to fetch the battery
level.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sat, 6 Nov 2021 13:02:27 +0000 (14:02 +0100)]
drm: panel-orientation-quirks: Add quirk for the Lenovo Yoga Book X91F/L
[ Upstream commit
bc30c3b0c8a1904d83d5f0d60fb8650a334b207b ]
The Lenovo Yoga Book X91F/L uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Cc: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Ser <contact@emersion.fr>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211106130227.11927-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brian Chen [Wed, 10 Nov 2021 21:33:12 +0000 (21:33 +0000)]
psi: Fix PSI_MEM_FULL state when tasks are in memstall and doing reclaim
[ Upstream commit
cb0e52b7748737b2cf6481fdd9b920ce7e1ebbdf ]
We've noticed cases where tasks in a cgroup are stalled on memory but
there is little memory FULL pressure since tasks stay on the runqueue
in reclaim.
A simple example involves a single threaded program that keeps leaking
and touching large amounts of memory. It runs in a cgroup with swap
enabled, memory.high set at 10M and cpu.max ratio set at 5%. Though
there is significant CPU pressure and memory SOME, there is barely any
memory FULL since the task enters reclaim and stays on the runqueue.
However, this memory-bound task is effectively stalled on memory and
we expect memory FULL to match memory SOME in this scenario.
The code is confused about memstall && running, thinking there is a
stalled task and a productive task when there's only one task: a
reclaimer that's counted as both. To fix this, we redefine the
condition for PSI_MEM_FULL to check that all running tasks are in an
active memstall instead of checking that there are no running tasks.
case PSI_MEM_FULL:
- return unlikely(tasks[NR_MEMSTALL] && !tasks[NR_RUNNING]);
+ return unlikely(tasks[NR_MEMSTALL] &&
+ tasks[NR_RUNNING] == tasks[NR_MEMSTALL_RUNNING]);
This will capture reclaimers. It will also capture tasks that called
psi_memstall_enter() and are about to sleep, but this should be
negligible noise.
Signed-off-by: Brian Chen <brianchen118@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20211110213312.310243-1-brianchen118@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavankumar Kondeti [Fri, 12 Nov 2021 10:24:40 +0000 (15:54 +0530)]
usb: gadget: f_fs: Use stream_open() for endpoint files
[ Upstream commit
c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7 ]
Function fs endpoint file operations are synchronized via an interruptible
mutex wait. However we see threads that do ep file operations concurrently
are getting blocked for the mutex lock in __fdget_pos(). This is an
uninterruptible wait and we see hung task warnings and kernel panic
if hung_task_panic systcl is enabled if host does not send/receive
the data for long time.
The reason for threads getting blocked in __fdget_pos() is due to
the file position protection introduced by the commit
9c225f2655e3
("vfs: atomic f_pos accesses as per POSIX"). Since function fs
endpoint files does not have the notion of the file position, switch
to the stream mode. This will bypass the file position mutex and
threads will be blocked in interruptible state for the function fs
mutex.
It should not affects user space as we are only changing the task state
changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting
for the USB transfers to be finished. However there is a slight change to
the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also
getting blocked inside fdget_pos(). Now they reach to function fs and error
code is returned. The non blocking behavior is actually honoured now.
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Link: https://lore.kernel.org/r/1636712682-1226-1-git-send-email-quic_pkondeti@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Haimin Zhang [Sat, 13 Nov 2021 16:53:20 +0000 (11:53 -0500)]
USB: ehci_brcm_hub_control: Improve port index sanitizing
[ Upstream commit
9933698f6119886c110750e67c10ac66f12b730f ]
Due to (wIndex & 0xff) - 1 can get an integer greater than 15, this
can cause array index to be out of bounds since the size of array
port_status is 15. This change prevents a possible out-of-bounds
pointer computation by forcing the use of a valid port number.
Reported-by: TCS Robot <tcs_robot@tencent.com>
Signed-off-by: Haimin Zhang <tcs.kernel@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20211113165320.GA59686@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amjad Ouled-Ameur [Fri, 12 Nov 2021 16:28:26 +0000 (17:28 +0100)]
usb: dwc3: meson-g12a: fix shared reset control use
[ Upstream commit
4ce3b45704d5ef46fb4b28083c8aba6716fabf3b ]
reset_control_(de)assert() calls are called on a shared reset line when
reset_control_reset has been used. This is not allowed by the reset
framework.
Use reset_control_rearm() call in suspend() and remove() as a way to state
that the resource is no longer used, hence the shared reset line
may be triggered again by other devices. Use reset_control_rearm() also in
case probe fails after reset() has been called.
reset_control_rearm() keeps use of triggered_count sane in the reset
framework, use of reset_control_reset() on shared reset line should be
balanced with reset_control_rearm().
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Reported-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20211112162827.128319-3-aouledameur@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Baochen Qiang [Tue, 26 Oct 2021 01:16:05 +0000 (09:16 +0800)]
ath11k: Fix crash caused by uninitialized TX ring
[ Upstream commit
273703ebdb01b6c5f1aaf4b98fb57b177609055c ]
Commit
31582373a4a8 ("ath11k: Change number of TCL rings to one for
QCA6390") avoids initializing the other entries of dp->tx_ring cause
the corresponding TX rings on QCA6390/WCN6855 are not used, but leaves
those ring masks in ath11k_hw_ring_mask_qca6390.tx unchanged. Normally
this is OK because we will only get interrupts from the first TX ring
on these chips and thus only the first entry of dp->tx_ring is involved.
In case of one MSI vector, all DP rings share the same IRQ. For each
interrupt, all rings have to be checked, which means the other entries
of dp->tx_ring are involved. However since they are not initialized,
system crashes.
Fix this issue by simply removing those ring masks.
crash stack:
[ 102.907438] BUG: kernel NULL pointer dereference, address:
0000000000000028
[ 102.907447] #PF: supervisor read access in kernel mode
[ 102.907451] #PF: error_code(0x0000) - not-present page
[ 102.907453] PGD
1081f0067 P4D
1081f0067 PUD
1081f1067 PMD 0
[ 102.907460] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 102.907465] CPU: 0 PID: 3511 Comm: apt-check Kdump: loaded Tainted: G E 5.15.0-rc4-wt-ath+ #20
[ 102.907470] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS RCD1005E 10/08/2020
[ 102.907472] RIP: 0010:ath11k_dp_tx_completion_handler+0x201/0x830 [ath11k]
[ 102.907497] Code: 3c 24 4e 8d ac 37 10 04 00 00 4a 8d bc 37 68 04 00 00 48 89 3c 24 48 63 c8 89 83 84 18 00 00 48 c1 e1 05 48 03 8b 78 18 00 00 <8b> 51 08 89 d6 83 e6 07 89 74 24 24 83 fe 03 74 04 85 f6 75 63 41
[ 102.907501] RSP: 0000:
ffff9b7340003e08 EFLAGS:
00010202
[ 102.907505] RAX:
0000000000000001 RBX:
ffff8e21530c0100 RCX:
0000000000000020
[ 102.907508] RDX:
0000000000000000 RSI:
00000000fffffe00 RDI:
ffff8e21530c1938
[ 102.907511] RBP:
ffff8e21530c0000 R08:
0000000000000001 R09:
0000000000000000
[ 102.907513] R10:
ffff8e2145534c10 R11:
0000000000000001 R12:
ffff8e21530c2938
[ 102.907515] R13:
ffff8e21530c18e0 R14:
0000000000000100 R15:
ffff8e21530c2978
[ 102.907518] FS:
00007f5d4297e740(0000) GS:
ffff8e243d600000(0000) knlGS:
0000000000000000
[ 102.907521] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 102.907524] CR2:
0000000000000028 CR3:
00000001034ea000 CR4:
0000000000350ef0
[ 102.907527] Call Trace:
[ 102.907531] <IRQ>
[ 102.907537] ath11k_dp_service_srng+0x5c/0x2f0 [ath11k]
[ 102.907556] ath11k_pci_ext_grp_napi_poll+0x21/0x70 [ath11k_pci]
[ 102.907562] __napi_poll+0x2c/0x160
[ 102.907570] net_rx_action+0x251/0x310
[ 102.907576] __do_softirq+0x107/0x2fc
[ 102.907585] irq_exit_rcu+0x74/0x90
[ 102.907593] common_interrupt+0x83/0xa0
[ 102.907600] </IRQ>
[ 102.907601] asm_common_interrupt+0x1e/0x40
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211026011605.58615-1-quic_bqiang@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauro Carvalho Chehab [Thu, 11 Nov 2021 23:04:09 +0000 (23:04 +0000)]
media: atomisp: handle errors at sh_css_create_isp_params()
[ Upstream commit
58043dbf6d1ae9deab4f5aa1e039c70112017682 ]
The succ var tracks memory allocation erros on this function.
Fix it, in order to stop this W=1 Werror in clang:
drivers/staging/media/atomisp/pci/sh_css_params.c:2430:7: error: variable 'succ' set but not used [-Werror,-Wunused-but-set-variable]
bool succ = true;
^
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Lüssing [Sun, 31 Oct 2021 21:30:12 +0000 (22:30 +0100)]
batman-adv: allow netlink usage in unprivileged containers
[ Upstream commit
9057d6c23e7388ee9d037fccc9a7bc8557ce277b ]
Currently, creating a batman-adv interface in an unprivileged LXD
container and attaching secondary interfaces to it with "ip" or "batctl"
works fine. However all batctl debug and configuration commands
fail:
root@container:~# batctl originators
Error received: Operation not permitted
root@container:~# batctl orig_interval
1000
root@container:~# batctl orig_interval 2000
root@container:~# batctl orig_interval
1000
To fix this change the generic netlink permissions from GENL_ADMIN_PERM
to GENL_UNS_ADMIN_PERM. This way a batman-adv interface is fully
maintainable as root from within a user namespace, from an unprivileged
container.
All except one batman-adv netlink setting are per interface and do not
leak information or change settings from the host system and are
therefore save to retrieve or modify as root from within an unprivileged
container.
"batctl routing_algo" / BATADV_CMD_GET_ROUTING_ALGOS is the only
exception: It provides the batman-adv kernel module wide default routing
algorithm. However it is read-only from netlink and an unprivileged
container is still not allowed to modify
/sys/module/batman_adv/parameters/routing_algo. Instead it is advised to
use the newly introduced "batctl if create routing_algo RA_NAME" /
IFLA_BATADV_ALGO_NAME to set the routing algorithm on interface
creation, which already works fine in an unprivileged container.
Cc: Tycho Andersen <tycho@tycho.pizza>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wan Jiabing [Mon, 18 Oct 2021 01:45:03 +0000 (21:45 -0400)]
ARM: shmobile: rcar-gen2: Add missing of_node_put()
[ Upstream commit
85744f2d938c5f3cfc44cb6533c157469634da93 ]
Fix following coccicheck warning:
./arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c:156:1-33: Function
for_each_matching_node_and_match should have of_node_put() before break
and goto.
Early exits from for_each_matching_node_and_match() should decrement the
node reference counter.
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Link: https://lore.kernel.org/r/20211018014503.7598-1-wanjiabing@vivo.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauro Carvalho Chehab [Wed, 10 Nov 2021 12:59:11 +0000 (12:59 +0000)]
media: atomisp: check before deference asd variable
[ Upstream commit
71665d816214124d6bc4eb80314ac8f84ecacd78 ]
The asd->isp was referenced before checking if asd is not
NULL.
This fixes this warning:
../drivers/staging/media/atomisp/pci/atomisp_cmd.c:5548 atomisp_set_fmt_to_snr() warn: variable dereferenced before check 'asd' (see line 5540)
While here, avoid getting the pipe pointer twice.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 7 Nov 2021 17:15:48 +0000 (17:15 +0000)]
media: atomisp-ov2680: Fix ov2680_set_fmt() clobbering the exposure
[ Upstream commit
4492289c31364d28c2680b43b18883385a5d216c ]
Now that we restore the default or last user set exposure setting on
power_up() there is no need for the registers written by ov2680_set_fmt()
to write to the exposure register.
Not doing so fixes the exposure always being reset to the value from
the res->regs array after a set_fmt().
Link: https://lore.kernel.org/linux-media/20211107171549.267583-11-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauro Carvalho Chehab [Fri, 29 Oct 2021 07:09:39 +0000 (08:09 +0100)]
media: atomisp: set per-device's default mode
[ Upstream commit
2c45e343c581091835c9047ed5298518aa133163 ]
The atomisp driver originally used the s_parm command to
initialize the run_mode type to the driver. So, before start
setting up the streaming, s_parm should be called.
So, even having 5 "normal" video devices, one meant to be used
for each type, the run_mode was actually selected when
s_parm is called.
Without setting the run mode, applications that don't call
VIDIOC_SET_PARM with a custom atomisp parameters won't work, as
the pipeline won't be set:
atomisp-isp2 0000:00:03.0: can't create streams
atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22
However, commit
8a7c5594c020 ("media: v4l2-ioctl: clear fields in s_parm")
broke support for it, with a good reason, as drivers shoudn't be
extending the API for their own purposes.
So, as an step to allow generic apps to use this driver, put
the device's run_mode in preview after open.
After this patch, using v4l2grab starts to work on preview
mode (/dev/video2):
$ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u
$ feh out000.pnm
So, let's just setup the default run_mode that each video devnode
should assume, setting it at open() time.
Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauro Carvalho Chehab [Thu, 4 Nov 2021 11:45:27 +0000 (11:45 +0000)]
media: atomisp: fix try_fmt logic
[ Upstream commit
c9e9094c4e42124af909b2f5f6ded0498e0854ac ]
The internal try_fmt logic is not meant to provide everything
that the V4L2 API should provide. Also, it doesn't decrement
the pads that are used only internally by the driver, but aren't
part of the device's output.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Skeggs [Wed, 24 Feb 2021 09:29:52 +0000 (19:29 +1000)]
drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR
[ Upstream commit
1d2271d2fb85e54bfc9630a6c30ac0feb9ffb983 ]
There have been reports of the WFI timing out on some boards, and a
patch was proposed to just remove it. This stuff is rather fragile,
and I believe the WFI might be needed with our FW prior to GM200.
However, we probably should not be touching PMU during init on GPUs
where we depend on NVIDIA FW, outside of limited circumstances, so
this should be a somewhat safer change that achieves the desired
result.
Reported-by: Diego Viola <diego.viola@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
Signed-off-by: Sasha Levin <sashal@kernel.org>
Neil Armstrong [Fri, 29 Oct 2021 13:59:47 +0000 (15:59 +0200)]
drm/bridge: dw-hdmi: handle ELD when DRM_BRIDGE_ATTACH_NO_CONNECTOR
[ Upstream commit
3f2532d65a571ca02258b547b5b68ab2e9406fdb ]
The current ELD handling takes the internal connector ELD buffer and
shares it to the I2S and AHB sub-driver.
But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created
elsewhere (or not), and an eventual connector is known only
if the bridge chain up to a connector is enabled.
The current dw-hdmi code gets the current connector from
atomic_enable() so use the already stored connector pointer and
replace the buffer pointer with a callback returning the current
connector ELD buffer.
Since a connector is not always available, either pass an empty
ELD to the alsa HDMI driver or don't call snd_pcm_hw_constraint_eld()
in AHB driver.
Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed typo in commit log]
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211029135947.3022875-1-narmstrong@baylibre.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zekun Shen [Thu, 28 Oct 2021 22:37:49 +0000 (18:37 -0400)]
ar5523: Fix null-ptr-deref with unexpected WDCMSG_TARGET_START reply
[ Upstream commit
ae80b6033834342601e99f74f6a62ff5092b1cee ]
Unexpected WDCMSG_TARGET_START replay can lead to null-ptr-deref
when ar->tx_cmd->odata is NULL. The patch adds a null check to
prevent such case.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
ar5523_cmd+0x46a/0x581 [ar5523]
ar5523_probe.cold+0x1b7/0x18da [ar5523]
? ar5523_cmd_rx_cb+0x7a0/0x7a0 [ar5523]
? __pm_runtime_set_status+0x54a/0x8f0
? _raw_spin_trylock_bh+0x120/0x120
? pm_runtime_barrier+0x220/0x220
? __pm_runtime_resume+0xb1/0xf0
usb_probe_interface+0x25b/0x710
really_probe+0x209/0x5d0
driver_probe_device+0xc6/0x1b0
device_driver_attach+0xe2/0x120
I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.
After fixing the code (fourth byte in usb packet) to WDCMSG_TARGET_START,
I got the null-ptr-deref bug. I believe the bug is triggerable whenever
cmd->odata is NULL. After patching, I tested with the same input and no
longer see the KASAN report.
This was NOT tested on a real device.
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YXsmPQ3awHFLuAj2@10-18-43-117.dynapool.wireless.nyu.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sun, 7 Nov 2021 16:55:21 +0000 (08:55 -0800)]
selftests/bpf: Fix bpf_object leak in skb_ctx selftest
[ Upstream commit
8c7a95520184b6677ca6075e12df9c208d57d088 ]
skb_ctx selftest didn't close bpf_object implicitly allocated by
bpf_prog_test_load() helper. Fix the problem by explicitly calling
bpf_object__close() at the end of the test.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com>
Link: https://lore.kernel.org/bpf/20211107165521.9240-10-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sun, 7 Nov 2021 16:55:20 +0000 (08:55 -0800)]
selftests/bpf: Destroy XDP link correctly
[ Upstream commit
f91231eeeed752119f49eb6620cae44ec745a007 ]
bpf_link__detach() was confused with bpf_link__destroy() and leaves
leaked FD in the process. Fix the problem.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com>
Link: https://lore.kernel.org/bpf/20211107165521.9240-9-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sun, 7 Nov 2021 16:55:15 +0000 (08:55 -0800)]
selftests/bpf: Fix memory leaks in btf_type_c_dump() helper
[ Upstream commit
8ba285874913da21ca39a46376e9cc5ce0f45f94 ]
Free up memory and resources used by temporary allocated memstream and
btf_dump instance.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Hengqi Chen <hengqi.chen@gmail.com>
Link: https://lore.kernel.org/bpf/20211107165521.9240-4-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qiang Yu [Sun, 31 Oct 2021 04:16:04 +0000 (12:16 +0800)]
drm/lima: fix warning when CONFIG_DEBUG_SG=y & CONFIG_DMA_API_DEBUG=y
[ Upstream commit
89636a06fa2ee7826a19c39c19a9bc99ab9340a9 ]
Otherwise get following warning:
DMA-API: lima 1c40000.gpu: mapping sg segment longer than device claims to support [len=4149248] [max=65536]
See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5496
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211031041604.187216-1-yuq825@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Aring [Tue, 2 Nov 2021 19:17:24 +0000 (15:17 -0400)]
fs: dlm: filter user dlm messages for kernel locks
[ Upstream commit
6c2e3bf68f3e5e5a647aa52be246d5f552d7496d ]
This patch fixes the following crash by receiving a invalid message:
[ 160.672220] ==================================================================
[ 160.676206] BUG: KASAN: user-memory-access in dlm_user_add_ast+0xc3/0x370
[ 160.679659] Read of size 8 at addr
00000000deadbeef by task kworker/u32:13/319
[ 160.681447]
[ 160.681824] CPU: 10 PID: 319 Comm: kworker/u32:13 Not tainted 5.14.0-rc2+ #399
[ 160.683472] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.14.0-1.module+el8.6.0+12648+
6ede71a5 04/01/2014
[ 160.685574] Workqueue: dlm_recv process_recv_sockets
[ 160.686721] Call Trace:
[ 160.687310] dump_stack_lvl+0x56/0x6f
[ 160.688169] ? dlm_user_add_ast+0xc3/0x370
[ 160.689116] kasan_report.cold.14+0x116/0x11b
[ 160.690138] ? dlm_user_add_ast+0xc3/0x370
[ 160.690832] dlm_user_add_ast+0xc3/0x370
[ 160.691502] _receive_unlock_reply+0x103/0x170
[ 160.692241] _receive_message+0x11df/0x1ec0
[ 160.692926] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 160.693700] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 160.694427] ? lock_acquire+0x175/0x400
[ 160.695058] ? do_purge.isra.51+0x200/0x200
[ 160.695744] ? lock_acquired+0x360/0x5d0
[ 160.696400] ? lock_contended+0x6a0/0x6a0
[ 160.697055] ? lock_release+0x21d/0x5e0
[ 160.697686] ? lock_is_held_type+0xe0/0x110
[ 160.698352] ? lock_is_held_type+0xe0/0x110
[ 160.699026] ? ___might_sleep+0x1cc/0x1e0
[ 160.699698] ? dlm_wait_requestqueue+0x94/0x140
[ 160.700451] ? dlm_process_requestqueue+0x240/0x240
[ 160.701249] ? down_write_killable+0x2b0/0x2b0
[ 160.701988] ? do_raw_spin_unlock+0xa2/0x130
[ 160.702690] dlm_receive_buffer+0x1a5/0x210
[ 160.703385] dlm_process_incoming_buffer+0x726/0x9f0
[ 160.704210] receive_from_sock+0x1c0/0x3b0
[ 160.704886] ? dlm_tcp_shutdown+0x30/0x30
[ 160.705561] ? lock_acquire+0x175/0x400
[ 160.706197] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 160.706941] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 160.707681] process_recv_sockets+0x32/0x40
[ 160.708366] process_one_work+0x55e/0xad0
[ 160.709045] ? pwq_dec_nr_in_flight+0x110/0x110
[ 160.709820] worker_thread+0x65/0x5e0
[ 160.710423] ? process_one_work+0xad0/0xad0
[ 160.711087] kthread+0x1ed/0x220
[ 160.711628] ? set_kthread_struct+0x80/0x80
[ 160.712314] ret_from_fork+0x22/0x30
The issue is that we received a DLM message for a user lock but the
destination lock is a kernel lock. Note that the address which is trying
to derefence is
00000000deadbeef, which is in a kernel lock
lkb->lkb_astparam, this field should never be derefenced by the DLM
kernel stack. In case of a user lock lkb->lkb_astparam is lkb->lkb_ua
(memory is shared by a union field). The struct lkb_ua will be handled
by the DLM kernel stack but on a kernel lock it will contain invalid
data and ends in most likely crashing the kernel.
It can be reproduced with two cluster nodes.
node 2:
dlm_tool join test
echo "862 fooobaar 1 2 1" > /sys/kernel/debug/dlm/test_locks
echo "862 3 1" > /sys/kernel/debug/dlm/test_waiters
node 1:
dlm_tool join test
python:
foo = DLM(h_cmd=3, o_nextcmd=1, h_nodeid=1, h_lockspace=0x77222027, \
m_type=7, m_flags=0x1, m_remid=0x862, m_result=0xFFFEFFFE)
newFile = open("/sys/kernel/debug/dlm/comms/2/rawmsg", "wb")
newFile.write(bytes(foo))
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Archie Pusaka [Thu, 28 Oct 2021 11:17:25 +0000 (19:17 +0800)]
Bluetooth: Fix removing adv when processing cmd complete
[ Upstream commit
2128939fe2e771645dd88e1938c27fdf96bd1cd0 ]
If we remove one instance of adv using Set Extended Adv Enable, there
is a possibility of issue occurs when processing the Command Complete
event. Especially, the adv_info might not be found since we already
remove it in hci_req_clear_adv_instance() -> hci_remove_adv_instance().
If that's the case, we will mistakenly proceed to remove all adv
instances instead of just one single instance.
This patch fixes the issue by checking the content of the HCI command
instead of checking whether the adv_info is found.
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brian Norris [Fri, 24 Sep 2021 00:33:55 +0000 (17:33 -0700)]
drm/panel: Delete panel on mipi_dsi_attach() failure
[ Upstream commit
9bf7123bb07f98dc76acb5daa91248e6f95713cb ]
Many DSI panel drivers fail to clean up their panel references on
mipi_dsi_attach() failure, so we're leaving a dangling drm_panel
reference to freed memory. Clean that up on failure.
Noticed by inspection, after seeing similar problems on other drivers.
Therefore, I'm not marking Fixes/stable.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210923173336.3.If9e74fa9b1d6eaa9e0e5b95b2b957b992740251c@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Wed, 13 Oct 2021 08:55:01 +0000 (16:55 +0800)]
Bluetooth: Fix memory leak of hci device
[ Upstream commit
75d9b8559ac36e059238ee4f8e33cd86086586ba ]
Fault injection test reported memory leak of hci device as follows:
unreferenced object 0xffff88800b858000 (size 8192):
comm "kworker/0:2", pid 167, jiffies
4294955747 (age 557.148s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N..
backtrace:
[<
0000000070eb1059>] kmem_cache_alloc_trace mm/slub.c:3208
[<
00000000015eb521>] hci_alloc_dev_priv include/linux/slab.h:591
[<
00000000dcfc1e21>] bpa10x_probe include/net/bluetooth/hci_core.h:1240
[<
000000005d3028c7>] usb_probe_interface drivers/usb/core/driver.c:397
[<
00000000cbac9243>] really_probe drivers/base/dd.c:517
[<
0000000024cab3f0>] __driver_probe_device drivers/base/dd.c:751
[<
00000000202135cb>] driver_probe_device drivers/base/dd.c:782
[<
000000000761f2bc>] __device_attach_driver drivers/base/dd.c:899
[<
00000000f7d63134>] bus_for_each_drv drivers/base/bus.c:427
[<
00000000c9551f0b>] __device_attach drivers/base/dd.c:971
[<
000000007f79bd16>] bus_probe_device drivers/base/bus.c:487
[<
000000007bb8b95a>] device_add drivers/base/core.c:3364
[<
000000009564d9ea>] usb_set_configuration drivers/usb/core/message.c:2171
[<
00000000e4657087>] usb_generic_driver_probe drivers/usb/core/generic.c:239
[<
0000000071ede518>] usb_probe_device drivers/usb/core/driver.c:294
[<
00000000cbac9243>] really_probe drivers/base/dd.c:517
hci_alloc_dev() do not init the device's flag. And hci_free_dev()
using put_device() to free the memory allocated for this device,
but it calls just put_device(dev) only in case of HCI_UNREGISTER
flag is set, So any error handing before hci_register_dev() success
will cause memory leak.
To avoid this behaviour we can using kfree() to release dev before
hci_register_dev() success.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Wed, 13 Oct 2021 08:55:46 +0000 (16:55 +0800)]
Bluetooth: Fix debugfs entry leak in hci_register_dev()
[ Upstream commit
5a4bb6a8e981d3d0d492aa38412ee80b21033177 ]
Fault injection test report debugfs entry leak as follows:
debugfs: Directory 'hci0' with parent 'bluetooth' already present!
When register_pm_notifier() failed in hci_register_dev(), the debugfs
create by debugfs_create_dir() do not removed in the error handing path.
Add the remove debugfs code to fix it.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merlijn Wajer [Sun, 12 Dec 2021 22:40:07 +0000 (23:40 +0100)]
leds: lp55xx: initialise output direction from dts
[ Upstream commit
9e87a8da747bf72365abb79e6f64fcca955b4f56 ]
Commit
a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to
output") attempts to fix this, but the fix did not work since at least
for the Nokia N900 the value needs to be set to HIGH, per the device
tree. So rather than hardcoding the value to a potentially invalid value
for some devices, let's set direction in lp55xx_init_device.
Fixes:
a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output")
Fixes:
92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Fixes:
ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors")
Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sicelo A. Mhlongo [Sun, 12 Dec 2021 22:40:06 +0000 (23:40 +0100)]
ARM: dts: omap3-n900: Fix lp5523 for multi color
[ Upstream commit
e9af026a3b24f59d7af4609f73e0ef60a4d6d516 ]
Since the LED multicolor framework support was added in commit
92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx")
LEDs on this platform stopped working.
Fixes:
92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Fixes:
ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors")
Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
jason-jh.lin [Thu, 23 Dec 2021 14:51:55 +0000 (22:51 +0800)]
mailbox: fix gce_num of mt8192 driver data
[ Upstream commit
35ca43710f792ce183312fdc7e4b2bb0b721a173 ]
Because mt8192 only have 1 gce, the gce_num should be 1.
Fixes:
85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195")
Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Cercueil [Fri, 7 Jan 2022 18:57:22 +0000 (18:57 +0000)]
MIPS: compressed: Fix build with ZSTD compression
[ Upstream commit
c5c7440fe7f74645940d5c9e2c49cd7efb706a4f ]
Fix the following build issues:
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal':
decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `BIT_initDStream':
decompress.c:(.text.BIT_initDStream+0x7c): undefined reference to `__clzdi2'
mips64el-linux-ld: decompress.c:(.text.BIT_initDStream+0x158): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_buildFSETable_body_default.constprop.0':
decompress.c:(.text.ZSTD_buildFSETable_body_default.constprop.0+0x2a8): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_readNCount_body_default':
decompress.c:(.text.FSE_readNCount_body_default+0x130): undefined reference to `__ctzdi2'
mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x1a4): undefined reference to `__ctzdi2'
mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x2e4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `HUF_readStats_body_default':
decompress.c:(.text.HUF_readStats_body_default+0x184): undefined reference to `__clzdi2'
mips64el-linux-ld: decompress.c:(.text.HUF_readStats_body_default+0x1b4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_DCtx_getParameter':
decompress.c:(.text.ZSTD_DCtx_getParameter+0x60): undefined reference to `__clzdi2'
Fixes:
a510b616131f ("MIPS: Add support for ZSTD-compressed kernels")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Cercueil [Fri, 19 Nov 2021 17:50:52 +0000 (17:50 +0000)]
MIPS: boot/compressed/: add __ashldi3 to target for ZSTD compression
[ Upstream commit
fbf3bce458214bb971d3d571515b3b129eac290b ]
Just like before with __bswapdi2(), for MIPS pre-boot when
CONFIG_KERNEL_ZSTD=y the decompressor function will use __ashldi3(), so
the object file should be added to the target object file.
Fixes these build errors:
mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal':
decompress.c:(.text.FSE_buildDTable_internal+0x48): undefined reference to `__ashldi3'
mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_decompress_wksp_body_default':
decompress.c:(.text.FSE_decompress_wksp_body_default+0xa8): undefined reference to `__ashldi3'
mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_getFrameHeader_advanced':
decompress.c:(.text.ZSTD_getFrameHeader_advanced+0x134): undefined reference to `__ashldi3'
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Boyd [Fri, 7 Jan 2022 19:42:32 +0000 (11:42 -0800)]
of/fdt: Don't worry about non-memory region overlap for no-map
[ Upstream commit
da17d6905d29ddcdc04b2fdc37ed8cf1e8437cc8 ]
In commit
8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove
already reserved regions") we returned -EBUSY when trying to mark
regions as no-map when they intersect with reserved memory. The goal was
to find bad no-map reserved memory DT nodes that would unmap the kernel
text/data sections.
The problem is the reserved memory check will still trigger if the DT
has a /memreserve/ that completely subsumes the no-map memory carveouts
in the reserved memory node _and_ that region is also not part of the
memory reg property. For example in sc7180.dtsi we have the following
reserved-memory and memory node:
memory@
80000000 {
/* We expect the bootloader to fill in the size */
reg = <0 0x80000000 0 0>;
};
smem_mem: memory@
80900000 {
reg = <0x0 0x80900000 0x0 0x200000>;
no-map;
};
and the memreserve filled in by the bootloader is
/memreserve/ 0x80800000 0x400000;
while the /memory node is transformed into
memory@
80000000 {
/* The bootloader fills in the size, and adds another region */
reg = <0 0x80000000 0 0x00800000>,
<0 0x80c00000 0 0x7f200000>;
};
The smem region is doubly reserved via /memreserve/ and by not being
part of the /memory reg property. This leads to the following warning
printed at boot.
OF: fdt: Reserved memory: failed to reserve memory for node 'memory@
80900000': base 0x0000000080900000, size 2 MiB
Otherwise nothing really goes wrong because the smem region is not going
to be mapped by the kernel's direct linear mapping given that it isn't
part of the memory node. Therefore, let's only consider this to be a
problem if we're trying to mark a region as no-map and it is actually
memory that we're intending to keep out of the kernel's direct mapping
but it's already been reserved.
Acked-by: Mike Rapoport <rppt@kernel.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Nicolas Boichat <drinkcat@chromium.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Fixes:
8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220107194233.2793146-1-swboyd@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Baruch Siach [Thu, 30 Dec 2021 16:31:52 +0000 (18:31 +0200)]
of: base: Fix phandle argument length mismatch error message
[ Upstream commit
94a4950a4acff39b5847cc1fee4f65e160813493 ]
The cell_count field of of_phandle_iterator is the number of cells we
expect in the phandle arguments list when cells_name is missing. The
error message should show the number of cells we actually see.
Fixes:
af3be70a3211 ("of: Improve of_phandle_iterator_next() error message")
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/96519ac55be90a63fa44afe01480c30d08535465.1640881913.git.baruch@tkos.co.il
Signed-off-by: Sasha Levin <sashal@kernel.org>
Conor Dooley [Thu, 23 Dec 2021 15:42:44 +0000 (15:42 +0000)]
clk: bm1880: remove kfrees on static allocations
[ Upstream commit
c861c1be3897845313a0df47804b1db37c7052e1 ]
bm1880_clk_unregister_pll & bm1880_clk_unregister_div both try to
free statically allocated variables, so remove those kfrees.
For example, if we take L703 kfree(div_hw):
- div_hw is a bm1880_div_hw_clock pointer
- in bm1880_clk_register_plls this is pointed to an element of arg1:
struct bm1880_div_hw_clock *clks
- in the probe, where bm1880_clk_register_plls is called arg1 is
bm1880_div_clks, defined on L371:
static struct bm1880_div_hw_clock bm1880_div_clks[]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Fixes:
1ab4601da55b ("clk: Add common clock driver for BM1880 SoC")
Link: https://lore.kernel.org/r/20211223154244.1024062-1-conor.dooley@microchip.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shengjiu Wang [Wed, 5 Jan 2022 11:08:03 +0000 (19:08 +0800)]
ASoC: fsl_asrc: refine the check of available clock divider
[ Upstream commit
320386343451ab6a3577e0ee200dac56a6182944 ]
According to RM, the clock divider range is from 1 to 8, clock
prescaling ratio may be any power of 2 from 1 to 128.
So the supported divider is not all the value between
1 and 1024, just limited value in that range.
Create table for the supported divder and add function to
check the clock divider is available by comparing with
the table.
Fixes:
d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio mode")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1641380883-20709-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shengjiu Wang [Tue, 4 Jan 2022 10:40:35 +0000 (18:40 +0800)]
ASoC: imx-card: improve the sound quality for low rate
[ Upstream commit
3969341813eb56d2dfc39bb64229359a6ae3c195 ]
According to RM, on auto mode:
For codec AK4458 and AK4497, the lowest ratio of MLCK/FS is 256
if sample rate is 8kHz-48kHz,
For codec AK5558, the lowest ratio of MLCK/FS is 512 if sample
rate is 8kHz-48kHz.
With these setting the sound quality for 8kHz-48kHz can be improved.
Fixes:
aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1641292835-19085-4-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shengjiu Wang [Tue, 4 Jan 2022 10:40:34 +0000 (18:40 +0800)]
ASoC: imx-card: Fix mclk calculation issue for akcodec
[ Upstream commit
f331ae5fa59fbfb748317b290648fc3f1a50d932 ]
Transfer the refined slots and slot_width to akcodec_get_mclk_rate()
for mclk calculation, otherwise the mclk frequency does not match
with the slots and slot_width for S16_LE format, because the default
slot_width is 32.
Fixes:
aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1641292835-19085-3-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shengjiu Wang [Tue, 4 Jan 2022 10:40:33 +0000 (18:40 +0800)]
ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
[ Upstream commit
3349b3d0c63b8b6fcca58156d72407f0b2e101ac ]
The SAI on i.MX8MQ don't support one2one ratio for mclk:bclk, so
the mclk frequency exceeds the supported range of codec for
the case that sample rate is larger than 705kHZ and format is
S32_LE. Update the supported width for such case.
Fixes:
aa736700f42f ("ASoC: imx-card: Add imx-card machine driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1641292835-19085-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Taniya Das [Mon, 20 Dec 2021 16:43:56 +0000 (22:13 +0530)]
clk: qcom: gcc-sc7280: Mark gcc_cfg_noc_lpass_clk always enabled
[ Upstream commit
9c337073d9d81a145434b22f42dc3128ecd17730 ]
The gcc cfg noc lpass clock is required to be always enabled for the
LPASS core and audio drivers to be functional.
Fixes:
a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280")
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Link: https://lore.kernel.org/r/1640018638-19436-4-git-send-email-tdas@codeaurora.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kamal Heib [Mon, 20 Dec 2021 15:25:30 +0000 (17:25 +0200)]
RDMA/cxgb4: Set queue pair state when being queried
[ Upstream commit
e375b9c92985e409c4bb95dd43d34915ea7f5e28 ]
The API for ib_query_qp requires the driver to set cur_qp_state on return,
add the missing set.
Fixes:
67bbc05512d8 ("RDMA/cxgb4: Add query_qp support")
Link: https://lore.kernel.org/r/20211220152530.60399-1-kamalheib1@gmail.com
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian A. Ehrhardt [Fri, 31 Dec 2021 13:44:32 +0000 (14:44 +0100)]
ALSA: hda/cs8409: Fix Jack detection after resume
[ Upstream commit
57f234248ff925d88caedf4019ec84e6ecb83909 ]
The suspend code unconditionally sets ->hp_jack_in and ->mic_jack_in
to zero but without reporting this status change to the HDA core.
To compensate for this, always assume a status change on the
first unsol event after boot or resume.
Fixes:
424e531b47f8 ("ALSA: hda/cs8409: Ensure Type Detection is only run on startup when necessary")
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Link: https://lore.kernel.org/r/20211231134432.atwmuzeceqiklcoa@cae.in-ulm.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian A. Ehrhardt [Fri, 31 Dec 2021 13:12:21 +0000 (14:12 +0100)]
ALSA: hda/cs8409: Increase delay during jack detection
[ Upstream commit
8cd07657177006b67cc1610e4466cc75ad781c05 ]
Commit
c8b4f0865e82 reduced delays related to cs42l42 jack
detection. However, the change was too aggressive. As a result
internal speakers on DELL Inspirion 3501 are not detected.
Increase the delay in cs42l42_run_jack_detect() a bit.
Fixes:
c8b4f0865e82 ("ALSA: hda/cs8409: Remove unnecessary delays")
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Link: https://lore.kernel.org/r/20211231131221.itwotyfk5qomn7n6@cae.in-ulm.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alyssa Ross [Tue, 4 Jan 2022 13:22:16 +0000 (13:22 +0000)]
ASoC: fsl_mqs: fix MODULE_ALIAS
[ Upstream commit
9f3d45318dd9e739ed62e4218839a7a824d3cced ]
modprobe can't handle spaces in aliases.
Fixes:
9e28f6532c61 ("ASoC: fsl_mqs: Add MQS component driver")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Link: https://lore.kernel.org/r/20220104132218.1690103-1-hi@alyssa.is
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ammar Faizi [Sun, 26 Dec 2021 13:54:02 +0000 (20:54 +0700)]
powerpc/xive: Add missing null check after calling kmalloc
[ Upstream commit
18dbfcdedc802f9500b2c29794f22a31d27639c0 ]
Commit
930914b7d528fc ("powerpc/xive: Add a debugfs file to dump
internal XIVE state") forgot to add a null check.
Add it.
Fixes:
930914b7d528fc6b0249bffc00564100bcf6ef75 ("powerpc/xive: Add a debugfs file to dump internal XIVE state")
Signed-off-by: Ammar Faizi <ammarfaizi2@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211226135314.251221-1-ammar.faizi@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Wed, 29 Dec 2021 00:05:53 +0000 (16:05 -0800)]
mips: bcm63xx: add support for clk_set_parent()
[ Upstream commit
6f03055d508ff4feb8db02ba3df9303a1db8d381 ]
The MIPS BMC63XX subarch does not provide/support clk_set_parent().
This causes build errors in a few drivers, so add a simple implementation
of that function so that callers of it will build without errors.
Fixes these build errors:
ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined!
ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined!
Fixes:
e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs." )
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Wed, 29 Dec 2021 00:03:45 +0000 (16:03 -0800)]
mips: lantiq: add support for clk_set_parent()
[ Upstream commit
76f66dfd60dc5d2f9dec22d99091fea1035c5d03 ]
Provide a simple implementation of clk_set_parent() in the lantiq
subarch so that callers of it will build without errors.
Fixes these build errors:
ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined!
ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined!
Fixes:
171bb2f19ed6 ("MIPS: Lantiq: Add initial support for Lantiq SoCs")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
--to=linux-mips@vger.kernel.org --cc="John Crispin <john@phrozen.org>" --cc="Jonathan Cameron <jic23@kernel.org>" --cc="Russell King <linux@armlinux.org.uk>" --cc="Andy Shevchenko <andy.shevchenko@gmail.com>" --cc=alsa-devel@alsa-project.org --to="Thomas Bogendoerfer <tsbogend@alpha.franken.de>"
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sameer Pujar [Thu, 23 Dec 2021 11:53:51 +0000 (17:23 +0530)]
arm64: tegra: Remove non existent Tegra194 reset
[ Upstream commit
146b3a77af8091cabbd1decc51d67799e69682d2 ]
Tegra194 does not really have "hda2codec_2x" related reset. Hence drop
this entry to reflect actual HW.
Fixes:
4878cc0c9fab ("arm64: tegra: Add HDA controller on Tegra194")
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1640260431-11613-4-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trevor Wu [Thu, 30 Dec 2021 08:47:30 +0000 (16:47 +0800)]
ASoC: mediatek: mt8195: correct pcmif BE dai control flow
[ Upstream commit
2355028c0c54c03afb66c589347f1dc9f6fe2e38 ]
Originally, the conditions for preventing reentry are not correct.
dai->component->active is not the state specifically for pcmif dai, so it
is not a correct condition to indicate the status of pcmif dai.
On the other hand, snd_soc_dai_stream_actvie() in prepare ops for both
playback and capture possibly return true at the first entry when these
two streams are opened at the same time.
In the patch, I refer to the implementation in mt8192-dai-pcm.c.
Clock and enabling bit for PCMIF are managed by DAPM, and the condition
for prepare ops is replaced by the status of dai widget.
Fixes:
1f95c019115c ("ASoC: mediatek: mt8195: support pcm in platform driver")
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20211230084731.31372-2-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Tue, 28 Dec 2021 12:55:22 +0000 (12:55 +0000)]
misc: lattice-ecp3-config: Fix task hung when firmware load failed
[ Upstream commit
fcee5ce50bdb21116711e38635e3865594af907e ]
When firmware load failed, kernel report task hung as follows:
INFO: task xrun:5191 blocked for more than 147 seconds.
Tainted: G W 5.16.0-rc5-next-
20211220+ #11
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:xrun state:D stack: 0 pid: 5191 ppid: 270 flags:0x00000004
Call Trace:
__schedule+0xc12/0x4b50 kernel/sched/core.c:4986
schedule+0xd7/0x260 kernel/sched/core.c:6369 (discriminator 1)
schedule_timeout+0x7aa/0xa80 kernel/time/timer.c:1857
wait_for_completion+0x181/0x290 kernel/sched/completion.c:85
lattice_ecp3_remove+0x32/0x40 drivers/misc/lattice-ecp3-config.c:221
spi_remove+0x72/0xb0 drivers/spi/spi.c:409
lattice_ecp3_remove() wait for signals from firmware loading, but when
load failed, firmware_load() does not send this signal. This cause
device remove hung. Fix it by sending signal even if load failed.
Fixes:
781551df57c7 ("misc: Add Lattice ECP3 FPGA configuration via SPI")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20211228125522.3122284-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Tue, 28 Dec 2021 03:40:26 +0000 (11:40 +0800)]
ASoC: samsung: idma: Check of ioremap return value
[ Upstream commit
3ecb46755eb85456b459a1a9f952c52986bce8ec ]
Because of the potential failure of the ioremap(), the buf->area could
be NULL.
Therefore, we need to check it and return -ENOMEM in order to transfer
the error.
Fixes:
f09aecd50f39 ("ASoC: SAMSUNG: Add I2S0 internal dma driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211228034026.1659385-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Swapnil Jakhade [Thu, 23 Dec 2021 06:01:33 +0000 (07:01 +0100)]
phy: cadence: Sierra: Fix to get correct parent for mux clocks
[ Upstream commit
da08aab940092a050a4fb2857ed9479d2b0e03c4 ]
Fix get_parent() callback to return the correct index of the parent for
PLL_CMNLC1 clock. Add a separate table of register values corresponding
to the parent index for PLL_CMNLC1. Update set_parent() callback
accordingly.
Fixes:
28081b72859f ("phy: cadence: Sierra: Model PLL_CMNLC and PLL_CMNLC1 as clocks (mux clocks)")
Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20211223060137.9252-12-sjakhade@cadence.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Ellerman [Tue, 21 Dec 2021 13:51:00 +0000 (00:51 +1100)]
powerpc/64s: Use EMIT_WARN_ENTRY for SRR debug warnings
[ Upstream commit
fd1eaaaaa6864b5fb8f99880fcefb49760b8fe4e ]
When CONFIG_PPC_RFI_SRR_DEBUG=y we check the SRR values before returning
from interrupts. This is done in asm using EMIT_BUG_ENTRY, and passing
BUGFLAG_WARNING.
However that fails to create an exception table entry for the warning,
and so do_program_check() fails the exception table search and proceeds
to call _exception(), resulting in an oops like:
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 2 PID: 1204 Comm: sigreturn_unali Tainted: P 5.16.0-rc2-00194-g91ca3d4f77c5 #12
NIP:
c00000000000c5b0 LR:
0000000000000000 CTR:
0000000000000000
...
NIP [
c00000000000c5b0] system_call_common+0x150/0x268
LR [
0000000000000000] 0x0
Call Trace:
[
c00000000db73e10] [
c00000000000c558] system_call_common+0xf8/0x268 (unreliable)
...
Instruction dump:
7cc803a6 888d0931 2c240000 4082001c 38800000 988d0931 e8810170 e8a10178
7c9a03a6 7cbb03a6 7d7a02a6 e9810170 <
7f0b6088>
7d7b02a6 e9810178 7f0b6088
We should instead use EMIT_WARN_ENTRY, which creates an exception table
entry for the warning, allowing the warning to be correctly recognised,
and the code to resume after printing the warning.
Note however that because this warning is buried deep in the interrupt
return path, we are not able to recover from it (due to MSR_RI being
clear), so we still end up in die() with an unrecoverable exception.
Fixes:
59dc5bfca0cb ("powerpc/64s: avoid reloading (H)SRR registers if they are still valid")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211221135101.2085547-2-mpe@ellerman.id.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Ellerman [Tue, 21 Dec 2021 13:50:59 +0000 (00:50 +1100)]
powerpc/64s: Mask NIP before checking against SRR0
[ Upstream commit
314f6c23dd8d417281eb9e8a516dd98036f2e7b3 ]
When CONFIG_PPC_RFI_SRR_DEBUG=y we check that NIP and SRR0 match when
returning from interrupts. This can trigger falsely if NIP has either of
its two low bits set via sigreturn or ptrace, while SRR0 has its low two
bits masked in hardware.
As a quick fix make sure to mask the low bits before doing the check.
Fixes:
59dc5bfca0cb ("powerpc/64s: avoid reloading (H)SRR registers if they are still valid")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Link: https://lore.kernel.org/r/20211221135101.2085547-1-mpe@ellerman.id.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Wed, 22 Dec 2021 01:51:57 +0000 (09:51 +0800)]
ASoC: mediatek: Check for error clk pointer
[ Upstream commit
9de2b9286a6dd16966959b3cb34fc2ddfd39213e ]
Yes, you are right and now the return code depending on the
init_clks().
Fixes:
6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20211222015157.1025853-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ryuta NAKANISHI [Wed, 22 Dec 2021 05:19:29 +0000 (14:19 +0900)]
phy: uniphier-usb3ss: fix unintended writing zeros to PHY register
[ Upstream commit
898c7a9ec81620125f2463714a0f4dea18ad6e54 ]
Similar to commit
4a90bbb478db ("phy: uniphier-pcie: Fix updating phy
parameters"), in function uniphier_u3ssphy_set_param(), unintentionally
write zeros to other fields when writing PHY registers.
Fixes:
5ab43d0f8697 ("phy: socionext: add USB3 PHY driver for UniPhier SoC")
Signed-off-by: Ryuta NAKANISHI <nakanishi.ryuta@socionext.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1640150369-4134-1-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alan Stern [Mon, 20 Dec 2021 11:21:26 +0000 (19:21 +0800)]
scsi: block: pm: Always set request queue runtime active in blk_post_runtime_resume()
[ Upstream commit
6e1fcab00a23f7fe9f4fe9704905a790efa1eeab ]
John Garry reported a deadlock that occurs when trying to access a
runtime-suspended SATA device. For obscure reasons, the rescan procedure
causes the link to be hard-reset, which disconnects the device.
The rescan tries to carry out a runtime resume when accessing the device.
scsi_rescan_device() holds the SCSI device lock and won't release it until
it can put commands onto the device's block queue. This can't happen until
the queue is successfully runtime-resumed or the device is unregistered.
But the runtime resume fails because the device is disconnected, and
__scsi_remove_device() can't do the unregistration because it can't get the
device lock.
The best way to resolve this deadlock appears to be to allow the block
queue to start running again even after an unsuccessful runtime resume.
The idea is that the driver or the SCSI error handler will need to be able
to use the queue to resolve the runtime resume failure.
This patch removes the err argument to blk_post_runtime_resume() and makes
the routine act as though the resume was successful always. This fixes the
deadlock.
Link: https://lore.kernel.org/r/1639999298-244569-4-git-send-email-chenxiang66@hisilicon.com
Fixes:
e27829dc92e5 ("scsi: serialize ->rescan against ->remove")
Reported-and-tested-by: John Garry <john.garry@huawei.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pingfan Liu [Wed, 15 Dec 2021 02:13:48 +0000 (10:13 +0800)]
efi: apply memblock cap after memblock_add()
[ Upstream commit
b398123bff3bcbc1facb0f29bf6e7b9f1bc55931 ]
On arm64, during kdump kernel saves vmcore, it runs into the following bug:
...
[ 15.148919] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmem_cache_node' (offset 0, size 4096)!
[ 15.159707] ------------[ cut here ]------------
[ 15.164311] kernel BUG at mm/usercopy.c:99!
[ 15.168482] Internal error: Oops - BUG: 0 [#1] SMP
[ 15.173261] Modules linked in: xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm nvme nvme_core xgene_hwmon i2c_designware_platform i2c_designware_core dm_mirror dm_region_hash dm_log dm_mod overlay squashfs zstd_decompress loop
[ 15.206186] CPU: 0 PID: 542 Comm: cp Not tainted 5.16.0-rc4 #1
[ 15.212006] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F12 (SCP: 1.5.
20210426) 05/13/2021
[ 15.221125] pstate:
60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 15.228073] pc : usercopy_abort+0x9c/0xa0
[ 15.232074] lr : usercopy_abort+0x9c/0xa0
[ 15.236070] sp :
ffff8000121abba0
[ 15.239371] x29:
ffff8000121abbb0 x28:
0000000000003000 x27:
0000000000000000
[ 15.246494] x26:
0000000080000400 x25:
0000ffff885c7000 x24:
0000000000000000
[ 15.253617] x23:
000007ff80400000 x22:
ffff07ff80401000 x21:
0000000000000001
[ 15.260739] x20:
0000000000001000 x19:
ffff07ff80400000 x18:
ffffffffffffffff
[ 15.267861] x17:
656a626f2042554c x16:
53206d6f72662064 x15:
6574636574656420
[ 15.274983] x14:
74706d6574746120 x13:
2129363930342065 x12:
7a6973202c302074
[ 15.282105] x11:
ffffc8b041d1b148 x10:
00000000ffff8000 x9 :
ffffc8b04012812c
[ 15.289228] x8 :
00000000ffff7fff x7 :
ffffc8b041d1b148 x6 :
0000000000000000
[ 15.296349] x5 :
0000000000000000 x4 :
0000000000007fff x3 :
0000000000000000
[ 15.303471] x2 :
0000000000000000 x1 :
ffff07ff8c064800 x0 :
000000000000006b
[ 15.310593] Call trace:
[ 15.313027] usercopy_abort+0x9c/0xa0
[ 15.316677] __check_heap_object+0xd4/0xf0
[ 15.320762] __check_object_size.part.0+0x160/0x1e0
[ 15.325628] __check_object_size+0x2c/0x40
[ 15.329711] copy_oldmem_page+0x7c/0x140
[ 15.333623] read_from_oldmem.part.0+0xfc/0x1c0
[ 15.338142] __read_vmcore.constprop.0+0x23c/0x350
[ 15.342920] read_vmcore+0x28/0x34
[ 15.346309] proc_reg_read+0xb4/0xf0
[ 15.349871] vfs_read+0xb8/0x1f0
[ 15.353088] ksys_read+0x74/0x100
[ 15.356390] __arm64_sys_read+0x28/0x34
...
This bug introduced by commit
b261dba2fdb2 ("arm64: kdump: Remove custom
linux,usable-memory-range handling"), which moves
memblock_cap_memory_range() to fdt, but it breaches the rules that
memblock_cap_memory_range() should come after memblock_add() etc as said
in commit
e888fa7bb882 ("memblock: Check memory add/cap ordering").
As a consequence, the virtual address set up by copy_oldmem_page() does
not bail out from the test of virt_addr_valid() in check_heap_object(),
and finally hits the BUG_ON().
Since memblock allocator has no idea about when the memblock is fully
populated, while efi_init() is aware, so tackling this issue by calling the
interface early_init_dt_check_for_usable_mem_range() exposed by of/fdt.
Fixes:
b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling")
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: linux-arm-kernel@lists.infradead.org
To: devicetree@vger.kernel.org
To: linux-efi@vger.kernel.org
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211215021348.8766-1-kernelfans@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Tue, 14 Dec 2021 04:01:56 +0000 (12:01 +0800)]
of: fdt: Aggregate the processing of "linux,usable-memory-range"
[ Upstream commit
8347b41748c3019157312fbe7f8a6792ae396eb7 ]
Currently, we parse the "linux,usable-memory-range" property in
early_init_dt_scan_chosen(), to obtain the specified memory range of the
crash kernel. We then reserve the required memory after
early_init_dt_scan_memory() has identified all available physical memory.
Because the two pieces of code are separated far, the readability and
maintainability are reduced. So bring them together.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
(change the prototype of early_init_dt_check_for_usable_mem_range(), in
order to use it outside)
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: John Donnelly <john.p.donnelly@oracle.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
To: devicetree@vger.kernel.org
To: linux-efi@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trevor Wu [Thu, 16 Dec 2021 02:24:24 +0000 (10:24 +0800)]
ASoC: mediatek: mt8195: correct default value
[ Upstream commit
30e693ee82d20361f2caacca3b68c79e1a7cb16c ]
mt8195_cg_patch is used to reset the default value of audio cg, so the
register value could be consistent with CCF reference count.
Nevertheless, AUDIO_TOP_CON1[1:0] is used to control an internal mux,
and it's expected to keep the default value 0.
This patch corrects the default value in case an unexpected behavior
happens in the future.
Fixes:
6746cc8582599 ("ASoC: mediatek: mt8195: add platform driver")
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20211216022424.28470-1-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiongfeng Wang [Fri, 17 Dec 2021 15:30:55 +0000 (15:30 +0000)]
iommu/iova: Fix race between FQ timeout and teardown
[ Upstream commit
d7061627d701c90e1cac1e1e60c45292f64f3470 ]
It turns out to be possible for hotplugging out a device to reach the
stage of tearing down the device's group and default domain before the
domain's flush queue has drained naturally. At this point, it is then
possible for the timeout to expire just before the del_timer() call
in free_iova_flush_queue(), such that we then proceed to free the FQ
resources while fq_flush_timeout() is still accessing them on another
CPU. Crashes due to this have been observed in the wild while removing
NVMe devices.
Close the race window by using del_timer_sync() to safely wait for any
active timeout handler to finish before we start to free things. We
already avoid any locking in free_iova_flush_queue() since the FQ is
supposed to be inactive anyway, so the potential deadlock scenario does
not apply.
Fixes:
9a005a800ae8 ("iommu/iova: Add flush timer")
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[ rm: rewrite commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/0a365e5b07f14b7344677ad6a9a734966a8422ce.1639753638.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cezary Rojewski [Thu, 16 Dec 2021 11:57:39 +0000 (12:57 +0100)]
ASoC: Intel: catpt: Test dmaengine_submit() result before moving on
[ Upstream commit
2a9a72e290d4a4741e673f86b9fba9bfb319786d ]
After calling dmaengine_submit(), the submitted transfer descriptor
belongs to the DMA engine. Pointer to that descriptor may no longer be
valid after the call and should be tested before awaiting transfer
completion.
Reported-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Dave Jiang <dave.jiang@intel.com>
Fixes:
4fac9b31d0b9 ("ASoC: Intel: Add catpt base members")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20211216115743.2130622-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Levitsky [Tue, 23 Nov 2021 16:10:38 +0000 (18:10 +0200)]
iommu/amd: Remove useless irq affinity notifier
[ Upstream commit
575f5cfb13c84f324f9898383fa4a5694e53c9ef ]
iommu->intcapxt_notify field is no longer used
after a switch to a separate domain was done
Fixes:
d1adcfbb520c ("iommu/amd: Fix IOMMU interrupt generation in X2APIC mode")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20211123161038.48009-6-mlevitsk@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Levitsky [Tue, 23 Nov 2021 16:10:37 +0000 (18:10 +0200)]
iommu/amd: X2apic mode: mask/unmask interrupts on suspend/resume
[ Upstream commit
1980105e3cfc2215c75b4f6b172661d675c467d1 ]
Use IRQCHIP_MASK_ON_SUSPEND to make the core irq code to
mask the iommu interrupt on suspend and unmask it on the resume.
Since now the unmask function updates the INTX settings,
that will restore them on resume from s3/s4.
Since IRQCHIP_MASK_ON_SUSPEND is only effective for interrupts
which are not wakeup sources, remove IRQCHIP_SKIP_SET_WAKE flag
and instead implement a dummy .irq_set_wake which doesn't allow
the interrupt to become a wakeup source.
Fixes:
66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20211123161038.48009-5-mlevitsk@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Levitsky [Tue, 23 Nov 2021 16:10:36 +0000 (18:10 +0200)]
iommu/amd: X2apic mode: setup the INTX registers on mask/unmask
[ Upstream commit
4691f79d62a637958f7b5f55c232a65399500b7a ]
This is more logically correct and will also allow us to
to use mask/unmask logic to restore INTX setttings after
the resume from s3/s4.
Fixes:
66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20211123161038.48009-4-mlevitsk@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Levitsky [Tue, 23 Nov 2021 16:10:35 +0000 (18:10 +0200)]
iommu/amd: X2apic mode: re-enable after resume
[ Upstream commit
01b297a48a26bcb96769505ac948db4603b72bd1 ]
Otherwise it is guaranteed to not work after the resume...
Fixes:
66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20211123161038.48009-3-mlevitsk@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Levitsky [Tue, 23 Nov 2021 16:10:34 +0000 (18:10 +0200)]
iommu/amd: Restore GA log/tail pointer on host resume
[ Upstream commit
a8d4a37d1bb93608501d0d0545f902061152669a ]
This will give IOMMU GA log a chance to work after resume
from s3/s4.
Fixes:
8bda0cfbdc1a6 ("iommu/amd: Detect and initialize guest vAPIC log")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20211123161038.48009-2-mlevitsk@redhat.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 22 Nov 2021 22:21:58 +0000 (23:21 +0100)]
dmaengine: pxa/mmp: stop referencing config->slave_id
[ Upstream commit
134c37fa250a87a7e77c80a7c59ae16c462e46e0 ]
The last driver referencing the slave_id on Marvell PXA and MMP platforms
was the SPI driver, but this stopped doing so a long time ago, so the
TODO from the earlier patch can no be removed.
Fixes:
b729bf34535e ("spi/pxa2xx: Don't use slave_id of dma_slave_config")
Fixes:
13b3006b8ebd ("dma: mmp_pdma: add filter function")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20211122222203.4103644-7-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Bulwahn [Mon, 13 Dec 2021 11:16:42 +0000 (12:16 +0100)]
mips: fix Kconfig reference to PHYS_ADDR_T_64BIT
[ Upstream commit
a670c82d9ca4f1e7385d9d6f26ff41a50fbdd944 ]
Commit
d4a451d5fc84 ("arch: remove the ARCH_PHYS_ADDR_T_64BIT config
symbol") removes config ARCH_PHYS_ADDR_T_64BIT with all instances of that
config refactored appropriately. Since then, it is recommended to use the
config PHYS_ADDR_T_64BIT instead.
Commit
171543e75272 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
introduces the expression "!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))"
for config CPU_SUPPORTS_HUGEPAGES, which unintentionally refers to the
non-existing symbol ARCH_PHYS_ADDR_T_64BIT instead of the intended
PHYS_ADDR_T_64BIT.
Fix this Kconfig reference to the intended PHYS_ADDR_T_64BIT.
This issue was identified with the script ./scripts/checkkconfigsymbols.py.
I then reported it on the mailing list and Paul confirmed the mistake in
the linked email thread.
Link: https://lore.kernel.org/lkml/H8IU3R.H5QVNRA077PT@crapouillou.net/
Suggested-by: Paul Cercueil <paul@crapouillou.net>
Fixes:
171543e75272 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Bulwahn [Mon, 13 Dec 2021 11:16:35 +0000 (12:16 +0100)]
mips: add SYS_HAS_CPU_MIPS64_R5 config for MIPS Release 5 support
[ Upstream commit
fd4eb90b164442cb1e9909f7845e12a0835ac699 ]
Commit
ab7c01fdc3cf ("mips: Add MIPS Release 5 support") adds the two
configs CPU_MIPS32_R5 and CPU_MIPS64_R5, which depend on the corresponding
SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R5, respectively.
The config SYS_HAS_CPU_MIPS32_R5 was already introduced with commit
c5b367835cfc ("MIPS: Add support for XPA."); the config
SYS_HAS_CPU_MIPS64_R5, however, was never introduced.
Hence, ./scripts/checkkconfigsymbols.py warns:
SYS_HAS_CPU_MIPS64_R5
Referencing files: arch/mips/Kconfig, arch/mips/include/asm/cpu-type.h
Add the definition for config SYS_HAS_CPU_MIPS64_R5 under the assumption
that SYS_HAS_CPU_MIPS64_R5 follows the same pattern as the existing
SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R6.
Fixes:
ab7c01fdc3cf ("mips: Add MIPS Release 5 support")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dillon Min [Tue, 26 Oct 2021 07:11:21 +0000 (15:11 +0800)]
clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after system enter shell
[ Upstream commit
6fc058a72f3b7b07fc4de6d66ad1f68951b00f6e ]
stm32's clk driver register two ltdc gate clk to clk core by
clk_hw_register_gate() and clk_hw_register_composite()
first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
both of them point to the same offset of stm32's RCC register. after
kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]'
is no one to use. but, actually 'stm32f429_aux_clk[]' is in use.
stm32f469/746/769 have the same issue, fix it.
Fixes:
daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
Link: https://lore.kernel.org/linux-arm-kernel/1590564453-24499-7-git-send-email-dillon.minfei@gmail.com/
Link: https://lore.kernel.org/lkml/CAPTRvHkf0cK_4ZidM17rPo99gWDmxgqFt4CDUjqFFwkOeQeFDg@mail.gmail.com/
Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/1635232282-3992-10-git-send-email-dillon.minfei@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frank Rowand [Sun, 12 Dec 2021 22:18:52 +0000 (16:18 -0600)]
of: unittest: 64 bit dma address test requires arch support
[ Upstream commit
9fd4cf5d3571b27d746b8ead494a3f051485b679 ]
If an architecture does not support 64 bit dma addresses then testing
for an expected dma address >= 0x100000000 will fail.
Fixes:
e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211212221852.233295-1-frowand.list@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jim Quinlan [Fri, 10 Dec 2021 18:46:35 +0000 (13:46 -0500)]
of: unittest: fix warning on PowerPC frame size warning
[ Upstream commit
a8d61a9112ad0c9216ab45d050991e07bc4f3408 ]
The struct device variable "dev_bogus" was triggering this warning
on a PowerPC build:
drivers/of/unittest.c: In function 'of_unittest_dma_ranges_one.constprop':
[...] >> The frame size of 1424 bytes is larger than 1024 bytes
[-Wframe-larger-than=]
This variable is now dynamically allocated.
Fixes:
e0d072782c734 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211210184636.7273-2-jim2101024@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Wed, 15 Dec 2021 03:15:50 +0000 (11:15 +0800)]
ASoC: rt5663: Handle device_property_read_u32_array error codes
[ Upstream commit
2167c0b205960607fb136b4bb3c556a62be1569a ]
The return value of device_property_read_u32_array() is not always 0.
To catch the exception in case that devm_kzalloc failed and the
rt5663->imp_table was NULL, which caused the failure of
device_property_read_u32_array.
Fixes:
450f0f6a8fb4 ("ASoC: rt5663: Add the manual offset field to compensate the DC offset")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20211215031550.70702-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Avihai Horon [Thu, 9 Dec 2021 13:16:07 +0000 (15:16 +0200)]
RDMA/cma: Let cma_resolve_ib_dev() continue search even after empty entry
[ Upstream commit
20679094a0161c94faf77e373fa3f7428a8e14bd ]
Currently, when cma_resolve_ib_dev() searches for a matching GID it will
stop searching after encountering the first empty GID table entry. This
behavior is wrong since neither IB nor RoCE spec enforce tightly packed
GID tables.
For example, when the matching valid GID entry exists at index N, and if a
GID entry is empty at index N-1, cma_resolve_ib_dev() will fail to find
the matching valid entry.
Fix it by making cma_resolve_ib_dev() continue searching even after
encountering missing entries.
Fixes:
f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()")
Link: https://lore.kernel.org/r/b7346307e3bb396c43d67d924348c6c496493991.1639055490.git.leonro@nvidia.com
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Mark Zhang <markzhang@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>
Avihai Horon [Thu, 9 Dec 2021 13:16:06 +0000 (15:16 +0200)]
RDMA/core: Let ib_find_gid() continue search even after empty entry
[ Upstream commit
483d805191a23191f8294bbf9b4e94836f5d92e4 ]
Currently, ib_find_gid() will stop searching after encountering the first
empty GID table entry. This behavior is wrong since neither IB nor RoCE
spec enforce tightly packed GID tables.
For example, when a valid GID entry exists at index N, and if a GID entry
is empty at index N-1, ib_find_gid() will fail to find the valid entry.
Fix it by making ib_find_gid() continue searching even after encountering
missing entries.
Fixes:
5eb620c81ce3 ("IB/core: Add helpers for uncached GID and P_Key searches")
Link: https://lore.kernel.org/r/e55d331b96cecfc2cf19803d16e7109ea966882d.1639055490.git.leonro@nvidia.com
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Mark Zhang <markzhang@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>
Rob Clark [Mon, 8 Nov 2021 17:17:23 +0000 (09:17 -0800)]
iommu/arm-smmu-qcom: Fix TTBR0 read
[ Upstream commit
c31112fbd4077a51a14ff338038c82e9571dc821 ]
It is a 64b register, lets not lose the upper bits.
Fixes:
ab5df7b953d8 ("iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211108171724.470973-1-robdclark@gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Wed, 8 Dec 2021 17:36:52 +0000 (17:36 +0000)]
powerpc/powermac: Add additional missing lockdep_register_key()
[ Upstream commit
b149d5d45ac9171ed699a256f026c8ebef901112 ]
Commit
df1f679d19ed ("powerpc/powermac: Add missing
lockdep_register_key()") fixed a problem that was causing a WARNING.
There are two other places in the same file with the same problem
originating from commit
9e607f72748d ("i2c_powermac: shut up lockdep
warning").
Add missing lockdep_register_key()
Fixes:
9e607f72748d ("i2c_powermac: shut up lockdep warning")
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Depends-on:
df1f679d19ed ("powerpc/powermac: Add missing lockdep_register_key()")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200055
Link: https://lore.kernel.org/r/2c7e421874e21b2fb87813d768cf662f630c2ad4.1638984999.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Gleixner [Mon, 6 Dec 2021 22:27:26 +0000 (23:27 +0100)]
PCI/MSI: Fix pci_irq_vector()/pci_irq_get_affinity()
[ Upstream commit
29bbc35e29d9b6347780dcacde2deb4b39344167 ]
pci_irq_vector() and pci_irq_get_affinity() use the list position to find the
MSI-X descriptor at a given index. That's correct for the normal case where
the entry number is the same as the list position.
But it's wrong for cases where MSI-X was allocated with an entries array
describing sparse entry numbers into the hardware message descriptor
table. That's inconsistent at best.
Make it always check the entry number because that's what the zero base
index really means. This change won't break existing users which use a
sparse entries array for allocation because these users retrieve the Linux
interrupt number from the entries array after allocation and none of them
uses pci_irq_vector() or pci_irq_get_affinity().
Fixes:
aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20211206210223.929792157@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kamal Heib [Mon, 6 Dec 2021 20:13:14 +0000 (22:13 +0200)]
RDMA/qedr: Fix reporting max_{send/recv}_wr attrs
[ Upstream commit
b1a4da64bfc189510e08df1ccb1c589e667dc7a3 ]
Fix the wrongly reported max_send_wr and max_recv_wr attributes for user
QP by making sure to save their valuse on QP creation, so when query QP is
called the attributes will be reported correctly.
Fixes:
cecbcddf6461 ("qedr: Add support for QP verbs")
Link: https://lore.kernel.org/r/20211206201314.124947-1-kamalheib1@gmail.com
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Fri, 3 Dec 2021 23:19:39 +0000 (15:19 -0800)]
scsi: ufs: Fix race conditions related to driver data
[ Upstream commit
21ad0e49085deb22c094f91f9da57319a97188e4 ]
The driver data pointer must be set before any callbacks are registered
that use that pointer. Hence move the initialization of that pointer from
after the ufshcd_init() call to inside ufshcd_init().
Link: https://lore.kernel.org/r/20211203231950.193369-7-bvanassche@acm.org
Fixes:
3b1d05807a9a ("[SCSI] ufs: Segregate PCI Specific Code")
Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
Tested-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Fri, 3 Dec 2021 23:19:34 +0000 (15:19 -0800)]
scsi: core: Fix scsi_device_max_queue_depth()
[ Upstream commit
4bc3bffc1a885eb5cb259e4a25146a4c7b1034e3 ]
The comment above scsi_device_max_queue_depth() and also the description of
commit
ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <=
max(shost->can_queue, 1024)") contradict the implementation of the function
scsi_device_max_queue_depth(). Additionally, the maximum queue depth of a
SCSI LUN never exceeds host->can_queue. Fix scsi_device_max_queue_depth()
by changing max_t() into min_t().
Link: https://lore.kernel.org/r/20211203231950.193369-2-bvanassche@acm.org
Fixes:
ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)")
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com>
Tested-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hector Martin [Sat, 20 Nov 2021 03:13:43 +0000 (12:13 +0900)]
iommu/io-pgtable-arm: Fix table descriptor paddr formatting
[ Upstream commit
9abe2ac834851a7d0b0756e295cf7a292c45ca53 ]
Table descriptors were being installed without properly formatting the
address using paddr_to_iopte, which does not match up with the
iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
format, as it does not handle the high bits properly.
This was found on Apple T6000 DARTs, which require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.
Fixes:
6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address")
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20211120031343.88034-1-marcan@marcan.st
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Baolu [Mon, 8 Nov 2021 06:13:49 +0000 (14:13 +0800)]
iommu: Extend mutex lock scope in iommu_probe_device()
[ Upstream commit
556f99ac886635e8da15528995f06d1d7028cfca ]
Extend the scope of holding group->mutex so that it can cover the default
domain check/attachment and direct mappings of reserved regions.
Cc: Ashish Mhetre <amhetre@nvidia.com>
Fixes:
211ff31b3d33b ("iommu: Fix race condition during default domain allocation")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20211108061349.1985579-1-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stafford Horne [Fri, 3 Dec 2021 22:10:18 +0000 (07:10 +0900)]
openrisc: Add clone3 ABI wrapper
[ Upstream commit
433fe39f674d58bc7a3e8254a5d2ffc290b7e04e ]
Like fork and clone the clone3 syscall needs a wrapper to save callee
saved registers, which is required by the OpenRISC ABI. This came up
after auditing code following a discussion with Rob Landley and Arnd
Bergmann [0].
Tested with the clone3 kselftests and there were no issues.
[0] https://lore.kernel.org/all/
41206fc7-f8ce-98aa-3718-
ba3e1431e320@landley.net/T/#m9c0cdb2703813b9df4da04cf6b30de1f1aa89944
Fixes:
07e83dfbe16c ("openrisc: Enable the clone3 syscall")
Cc: Rob Landley <rob@landley.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Todd Kjos [Tue, 30 Nov 2021 18:51:50 +0000 (10:51 -0800)]
binder: avoid potential data leakage when copying txn
[ Upstream commit
6d98eb95b450a75adb4516a1d33652dc78d2b20c ]
Transactions are copied from the sender to the target
first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA
are then fixed up. This means there is a short period where
the sender's version of these objects are visible to the
target prior to the fixups.
Instead of copying all of the data first, copy data only
after any needed fixups have been applied.
Fixes:
457b9a6f09f0 ("Staging: android: add binder driver")
Reviewed-by: Martijn Coenen <maco@android.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-3-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Todd Kjos [Tue, 30 Nov 2021 18:51:49 +0000 (10:51 -0800)]
binder: fix handling of error during copy
[ Upstream commit
fe6b1869243f23a485a106c214bcfdc7aa0ed593 ]
If a memory copy function fails to copy the whole buffer,
a positive integar with the remaining bytes is returned.
In binder_translate_fd_array() this can result in an fd being
skipped due to the failed copy, but the loop continues
processing fds since the early return condition expects a
negative integer on error.
Fix by returning "ret > 0 ? -EINVAL : ret" to handle this case.
Fixes:
bb4a2e48d510 ("binder: return errors from buffer copy functions")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-2-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 3 Dec 2021 08:42:06 +0000 (00:42 -0800)]
char/mwave: Adjust io port register size
[ Upstream commit
f5912cc19acd7c24b2dbf65a6340bf194244f085 ]
Using MKWORD() on a byte-sized variable results in OOB read. Expand the
size of the reserved area so both MKWORD and MKBYTE continue to work
without overflow. Silences this warning on a -Warray-bounds build:
drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds]
346 | #define MKWORD(var) (*((unsigned short *)(&var)))
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp'
356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index)
| ^~~~~
drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD'
373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl));
| ^~~~~~
drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl'
358 | DSP_ISA_SLAVE_CONTROL rSlaveControl;
| ^~~~~~~~~~~~~
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20211203084206.3104326-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Thu, 25 Nov 2021 21:27:27 +0000 (23:27 +0200)]
misc: at25: Make driver OF independent again
[ Upstream commit
5b557298d7d09cce04e0565a535fbca63661724a ]
The commit
f60e7074902a ("misc: at25: Make use of device property API")
made a good job by enabling the driver for non-OF platforms, but the
recent commit
604288bc6196 ("nvmem: eeprom: at25: fix type compiler warnings")
brought that back.
Restore greatness of the driver once again.
Fixes:
eab61fb1cc2e ("nvmem: eeprom: at25: fram discovery simplification")
Fixes:
fd307a4ad332 ("nvmem: prepare basics for FRAM support")
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125212729.86585-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Thu, 2 Dec 2021 08:38:33 +0000 (09:38 +0100)]
ALSA: usb-audio: Drop superfluous '0' in Presonus Studio 1810c's ID
[ Upstream commit
1e583aef12aa74afd37c1418255cc4b74e023236 ]
The vendor ID of Presonus Studio 1810c had a superfluous '0' in its
USB ID. Drop it.
Fixes:
8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c")
Link: https://lore.kernel.org/r/20211202083833.17784-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / platform / kernel / linux-rpi.git / log