Get rid of the remaining node.js warnings by updating the actions.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Also create generic overrides in camera-mux-N-port, that can be extended
to configure vsync modes for cameras supporting this.

Example usages (to be combined with camera_auto_detect=0):
dtoverlay=imx477,cam0,sync-source
dtoverlay=imx477,sync-sink
dtoverlay=camera-mux-2port,cam1-imx477,cam1-sync-sink
dtoverlay=camera-mux-4port,cam3-imx477,cam3-sync-sink

Signed-off-by: Erik Botö <erik.boto@gmail.com>

Allow trigger-mode to be overridden using device tree so that it can be
set per camera. Previously the mode could only be changed using a module
parameter, which would then affect all cameras.

Signed-off-by: Erik Botö <erik.boto@gmail.com>

As we have never released a (standard) DACplusADC board with onboard
clocks, we can simply use a fixed setup avoiding incompatibilities
with Pi5 during driver init. Setting 'hifiberry-dacplusadc,slave' in
the overlays disables the failing clock probing mechanism.

Removes 'slave' parameter description from README which is still
supported but not needed.

Signed-off-by: j-schambacher <joerg@hifiberry.com>

Same issue as #5919.
'width' needs to be set independent of clocking mode.

Signed-off-by: j-schambacher <joerg@hifiberry.com>

Adds all available Hifberry cards' UUIDs to the hat_map file.

Signed-off-by: j-schambacher <joerg@hifiberry.com>

As the easy switching of the I2S module bewteen clock producer/consumer
on the PI5 is not possible, two specific DT-overlays are introduced.
The DAC+PRO boards with onboard clocks use the -PRO overlay, the boards
without oscillators the -STD version.
The "hifiberry-dacplus,slave" parameter in the -STD overlay disables
the automatic clock detection inside the hifiberry-dacplus driver.

The former hifiberry-dacplus overlay is kept for compatibility but
will be deprecated.

Signed-off-by: j-schambacher <joerg@hifiberry.com>

Signed-off-by: Eng33 <eng33@waveshare.net>

Signed-off-by: Eng33 <eng33@waveshare.net>

Signed-off-by: Eng33 <eng33@waveshare.net>

Signed-off-by: Eng33 <eng33@waveshare.net>

The code was reducing the number of components by one when we were not
blending with alpha. But that only makes sense if the components include
alpha.

For YUV, we were reducing the number of components for Y from one to zero
which resulted in no lbm space being allocated.

Fixes: https://github.com/raspberrypi/linux/issues/5912



Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Co-authored-by: Dom Cobley <popcornmix@gmail.com>

Allowing an unprivileged user to dump processor registers leaves the
door open to the leaking of sensitive data. Disable it.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Dedicated overlay claiming all 4 data lanes of the designware
I2S0 module to drive 4x PCM5102. THe devices share BCLK and
LRCLK, therefore all outputs will always run at the same
samplerate and format.

Compatible only with PI5!

Signed-off-by: j-schambacher <joerg@hifiberry.com>

Defines the settings for the 8 channel version of the standard
DAC by overwriting the number of channels in the DAI defs.
It can run in 8ch mode only on PI5 using the 4 lane data output
of the designware I2S0 module.

Signed-off-by: j-schambacher <joerg@hifiberry.com>

Fixes https://github.com/raspberrypi/Pi-Codec/issues/9

The label 'i2c' is no longer created by the firmware - i2c_arm or
i2c1 should be used instead. Replace the last occurrence of &i2c with
&i2c1.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Currently, the V3D driver uses PAGE_SHIFT over the assumption that
PAGE_SHIFT = 12, as the PAGE_SIZE = 4KB. But, the RPi 5 is using
PAGE_SIZE = 16KB, so the MMU PAGE_SHIFT is different than the system's
PAGE_SHIFT.

Enable V3D to be used in system's with any PAGE_SIZE by making sure that
everything MMU-related uses the MMU page shift.

Signed-off-by: Maíra Canal <mcanal@igalia.com>

This implementation of MMU support for larger pages doesn't address the
real problem: we are using the system's PAGE_SHIFT (which depends on the
PAGE_SIZE) to allocate the VA.

This implementation is especially problematic when dealing with a high
memory usage, e.g. vkoverhead and RBDOOM-3-BFG, as it can lead to a
kernel crash:

[   72.794493] Unable to handle kernel paging request at virtual address ffffc00009b58000
[   72.802451] Mem abort info:
[   72.805251]   ESR = 0x0000000096000047
[   72.809011]   EC = 0x25: DABT (current EL), IL = 32 bits
[   72.814340]   SET = 0, FnV = 0
[   72.817399]   EA = 0, S1PTW = 0
[   72.820544]   FSC = 0x07: level 3 translation fault
[   72.825438] Data abort info:
[   72.828320]   ISV = 0, ISS = 0x00000047
[   72.832165]   CM = 0, WnR = 1
[   72.835137] swapper pgtable: 16k pages, 47-bit VAs, pgdp=000000000123c000
[   72.841950] [ffffc00009b58000] pgd=100000010018c003, p4d=100000010018c003, pud=100000010018c003, pmd=1000000100190003, pte=0000000000000000
[   72.854530] Internal error: Oops: 0000000096000047 [#1] PREEMPT SMP
[   72.860819] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc brcmfmac brcmutil hci_uart cfg80211 btbcm bluetooth aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha2_ce rpivid_hevc(C) pisp_be joydev ecdh_generic sha256_arm64 ecc v4l2_mem2mem sha1_ce videobuf2_dma_contig videobuf2_memops rfkill videobuf2_v4l2 libaes videobuf2_common raspberrypi_hwmon videodev mc pwm_fan rp1_adc raspberrypi_gpiomem nvmem_rmem uio_pdrv_genirq uio i2c_dev fuse dm_mod ip_tables x_tables ipv6 hid_logitech_hidpp hid_logitech_dj vc4 snd_soc_hdmi_codec drm_display_helper cec drm_dma_helper spidev drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops snd_soc_core snd_compress spi_bcm2835 snd_pcm_dmaengine v3d gpu_sched drm_shmem_helper i2c_brcmstb drm snd_pcm snd_timer snd gpio_keys drm_panel_orientation_quirks backlight
[   72.938384] CPU: 1 PID: 1918 Comm: vkoverhead Tainted: G         C         6.1.0-rpi8-rpi-2712 #1  Debian 1:6.1.73-1+rpt1
[   72.949386] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[   72.955236] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   72.962222] pc : v3d_mmu_insert_ptes+0xc0/0x154 [v3d]
[   72.967298] lr : v3d_mmu_insert_ptes+0x6c/0x154 [v3d]
[   72.972369] sp : ffffc0000a07bbb0
[   72.975688] x29: ffffc0000a07bbb0 x28: ffffc0000a07bd48 x27: 0000000000000010
[   72.982849] x26: ffffc0000a07bd48 x25: ffff800101d9ca00 x24: 0000000000000042
[   72.990009] x23: ffff800101d9ca00 x22: ffff800100d42000 x21: 0000000000100004
[   72.997169] x20: ffff8001ca4cc000 x19: 0000000000ffffff x18: 0000000000000100
[   73.004330] x17: 0000000000000000 x16: ffffd0000c6434b0 x15: ffffd0000d16c008
[   73.011491] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[   73.018652] x11: 0000000000000001 x10: 0000000000000000 x9 : ffffcfffde8dc260
[   73.025813] x8 : ffff800100d42700 x7 : 0000000000003fff x6 : ffff8001ca3a1520
[   73.032973] x5 : 0000000000100000 x4 : ffffc00009758000 x3 : 0000000000100000
[   73.040134] x2 : 00000000301ca4cf x1 : 0000000000100001 x0 : 00000000301ca4d0
[   73.047295] Call trace:
[   73.049741]  v3d_mmu_insert_ptes+0xc0/0x154 [v3d]
[   73.054463]  v3d_bo_create_finish+0xd0/0xf0 [v3d]
[   73.059185]  v3d_create_bo_ioctl+0x50/0x150 [v3d]
[   73.063906]  drm_ioctl_kernel+0xd0/0x180 [drm]
[   73.068412]  drm_ioctl+0x214/0x430 [drm]
[   73.072383]  __arm64_sys_ioctl+0xb4/0xfc
[   73.076318]  invoke_syscall+0x50/0x120
[   73.080077]  el0_svc_common.constprop.0+0x4c/0xf4
[   73.084794]  do_el0_svc+0x34/0xd0
[   73.088114]  el0_svc+0x2c/0x84
[   73.091173]  el0t_64_sync_handler+0xf4/0x120
[   73.095454]  el0t_64_sync+0x18c/0x190
[   73.099124] Code: 2a0103e3 11000421 4b050020 0b020000 (b8237880)
[   73.105237] ---[ end trace 0000000000000000 ]---

Signed-off-by: Maíra Canal <mcanal@igalia.com>

Adding 2 new overlays for use with
Interlude Audio's Digital and Analog hats
adding descriptions for both in README
adding changes to Makefile to include both DT's

Implementing driver support for
Interlude audio's WM8805 based digital hat
by leveraging existing drivers

Since [1], the fbdev deferred IO framework is careful to cancel
pending updates on close to prevent dirty pages being accessed after
they may have been reused. However, this is not necessary in the case
that the pagelist is empty, and drivers that don't make use of the
pagelist may have wanted updates cancelled for no good reason.

Avoid penalising fbdev drivers that don't make use of the pagelist by
making the cancelling of deferred IO on close conditional on there
being a non-empty pagelist.

See: https://github.com/raspberrypi/linux/issues/5398



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

[1] 3efc61d9 ("fbdev: Fix invalid page access after closing deferred I/O devices")

There are multiple causes of interrupts, errors being one, and only the
receipt of data warrants continued polling.

See: https://github.com/raspberrypi/linux/issues/2676



Signed-off-by: Phil Elwell <phil@raspberrypi.com>

This reverts commit 631ee829.

This reverts commit 1dc23c47.

Link: https://lore.kernel.org/r/20240203035317.354186483@linuxfoundation.org


Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20240203174756.358721205@linuxfoundation.org


Tested-by: SeongJae Park <sj@kernel.org>
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: kernelci.org bot <bot@kernelci.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 16da3990 ]

Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()'

Fixes the below:
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r'
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r'
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r'
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r'

Fixes: fac4ebd7

 ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'")
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b53cc614 upstream.

The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is,
in 15 levels.

Fix the dB values for the PA volume control as experiments using wsa8835
show that the first 16 levels all map to the same lowest gain while the
last three map to the highest gain.

These values specifically need to be correct for the sound server to
provide proper volume control.

Note that level 0 (-3 dB) does not mute the PA so the mute flag should
also not be set.

Fixes: cdb09e62

 ("ASoC: codecs: wsa883x: add control, dapm widgets and map")
Cc: stable@vger.kernel.org      # 6.0
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.org


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46188db0 upstream.

The LPASS WSA macro codec driver is updating the digital gain settings
behind the back of user space on DAPM events if companding has been
enabled.

As compander control is exported to user space, this can result in the
digital gain setting being incremented (or decremented) every time the
sound server is started and the codec suspended depending on what the
UCM configuration looks like.

Soon enough playback will become distorted (or too quiet).

This is specifically a problem on the Lenovo ThinkPad X13s as this
bypasses the limit for the digital gain setting that has been set by the
machine driver.

Fix this by simply dropping the compander gain offset hack. If someone
cares about modelling the impact of the compander setting this can
possibly be done by exporting it as a volume control later.

Note that the volume registers still need to be written after enabling
clocks in order for any prior updates to take effect.

Fixes: 2c4066e5

 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route")
Cc: stable@vger.kernel.org      # 5.11
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486058f4 upstream.

As suggested by Paolo in link[1], if the memory allocation fails, the mm
layer will emit a lot warning comprising the backtrace, so remove the
print.

[1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/



Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

From: Bailey Forrest <bcf@google.com>

Call skb_shinfo() after gve_prep_tso() on DQO TX path.
gve_prep_tso() calls skb_cow_head(), which may reallocate
shinfo causing a use after free.

This bug was unintentionally fixed by 'a6fb8d5a
("gve: Tx path for DQO-QPL")' while adding DQO-QPL format
support in 6.6. That patch is not appropriate for stable releases.

Fixes: a57e5de4

 ("gve: DQO: Add TX path")
Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
Signed-off-by: Bailey Forrest <bcf@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Jeroen de Borst <jeroendb@google.com>
Reviewed-by: Kevin DeCabooter <decabooter@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5056c596 upstream.

Machines which have more than 8 nodes fail to boot SMP after commit
a2ccf463 ("LoongArch/smp: Call rcutree_report_cpu_starting()
earlier"). Because such machines use tlb-based per-cpu base address
rather than dmw-based per-cpu base address, resulting per-cpu variables
can only be accessed after tlb_init(). But rcutree_report_cpu_starting()
is now called before tlb_init() and accesses per-cpu variables indeed.

Since the original patch want to avoid the lockdep warning caused by
page allocation in tlb_init(), we can move rcutree_report_cpu_starting()
to tlb_init() where after tlb exception configuration but before page
allocation.

Fixes: a2ccf463

 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier")
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ab502bc

 upstream.

Some devices power the DSI PHY/PLL through a power rail that we model
as a GENPD. Enable runtime PM to make it suspendable.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/543352/
Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org


Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 85d16c03.

duplicated a change made in 6.1.69
20907717



Cc: stable@vger.kernel.org # 6.1
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6564fce upstream.

Alexander Potapenko writes in [1]: "For every memory access in the code
instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata
for the memory being accessed.  For virtual memory the metadata pointers
are stored in the corresponding `struct page`, therefore we need to call
virt_to_page() to get them.

According to the comment in arch/x86/include/asm/page.h,
virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is
true, so KMSAN needs to call virt_addr_valid() as well.

To avoid recursion, kmsan_get_metadata() must not call instrumented code,
therefore ./arch/x86/include/asm/kmsan.h forks parts of
arch/x86/mm/physaddr.c to check whether a virtual address is valid or not.

But the introduction of rcu_read_lock() to pfn_valid() added instrumented
RCU API calls to virt_to_page_or_null(), which is called by
kmsan_get_metadata(), so there is an infinite recursion now.  I do not
think it is correct to stop that recursion by doing
kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that
would prevent instrumented functions called from within the runtime from
tracking the shadow values, which might introduce false positives."

Fix the issue by switching pfn_valid() to the _sched() variant of
rcu_read_lock/unlock(), which does not require calling into RCU.  Given
the critical section in pfn_valid() is very small, this is a reasonable
trade-off (with preemptible RCU).

KMSAN further needs to be careful to suppress calls into the scheduler,
which would be another source of recursion.  This can be done by wrapping
the call to pfn_valid() into preempt_disable/enable_no_resched().  The
downside is that this sacrifices breaking scheduling guarantees; however,
a kernel compiled with KMSAN has already given up any performance
guarantees due to being heavily instrumented.

Note, KMSAN code already disables tracing via Makefile, and since mmzone.h
is included, it is not necessary to use the notrace variant, which is
generally preferred in all other cases.

Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1]
Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com
Fixes: 5ec8e8ea

 ("mm/sparsemem: fix race in accessing memory_section->usage")
Signed-off-by: Marco Elver <elver@google.com>
Reported-by: Alexander Potapenko <glider@google.com>
Reported-by:  <syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com>
Reviewed-by: Alexander Potapenko <glider@google.com>
Tested-by: Alexander Potapenko <glider@google.com>
Cc: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b1a09e4 upstream.

The init_irq_stacks() has been changed to use the correct node:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf



The init_irq_scs() has the same issue with init_irq_stacks():
	cpu_to_node() is not initialized yet, it does not work.

This patch uses early_cpu_to_node() to set the init_irq_scs()
with the correct node.

Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com


Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 8cc063ae ]

The purpose of the test_LAG_cleanup() function is to check that some
hardware addresses are removed from underlying devices after they have been
unenslaved. The test function simply checks that those addresses are not
present at the end. However, if the addresses were never added to begin
with due to some error in device setup, the test function currently passes.
This is a false positive since in that situation the test did not actually
exercise the intended functionality.

Add a check that the expected addresses are indeed present after device
setup. This makes the test function more robust.

I noticed this problem when running the team/dev_addr_lists.sh test on a
system without support for dummy and ipv6:

tools/testing/selftests/drivers/net/team# ./dev_addr_lists.sh
Error: Unknown device type.
Error: Unknown device type.
This program is not intended to be run as root.
RTNETLINK answers: Operation not supported
TEST: team cleanup mode lacp                                        [ OK ]

Fixes: bbb774d9

 ("net: Add tests for bonding and team address list management")
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Link: https://lore.kernel.org/r/20240131140848.360618-3-bpoirier@nvidia.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 7b6fb305 ]

Similar to commit dd2d40ac ("selftests: bonding: Add more missing
config options"), add more networking-specific config options which are
needed for team device tests.

For testing, I used the minimal config generated by virtme-ng and I added
the options in the config file. Afterwards, the team device test passed.

Fixes: bbb774d9

 ("net: Add tests for bonding and team address list management")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Link: https://lore.kernel.org/r/20240131140848.360618-2-bpoirier@nvidia.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>