Author: Takashi Iwai <tiwai@suse.de>
Date: Fri Jul 26 16:26:20 2024 +0200
ALSA: hda/conexant: Mute speakers at suspend / shutdown
[ Upstream commit 4f61c8fe35202702426cfc0003e15116a01ba885 ]
Use the new helper to mute speakers at suspend / shutdown for avoiding
click noises.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1228269
Link: https://patch.msgid.link/20240726142625.2460-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Fri Jul 26 16:26:19 2024 +0200
ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown
[ Upstream commit 6cd23b26b348fa52c88e1adf9c0e48d68e13f95e ]
Some devices indicate click noises at suspend or shutdown when the
speakers are unmuted. This patch adds a helper,
snd_hda_gen_shutup_speakers(), to work around it. The new function is
supposed to be called at suspend or shutdown by the codec driver, and
it mutes the speakers.
The mute status isn't cached, hence the original mute state will be
restored at resume again.
Link: https://patch.msgid.link/20240726142625.2460-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jul 31 15:05:26 2024 +0200
ALSA: seq: ump: Explicitly reset RPN with Null RPN
[ Upstream commit 98ea612dd1150adb61cd2a0e93875e1cc77e6b87 ]
RPN with 127:127 is treated as a Null RPN, just to reset the
parameters, and it's not translated to MIDI2. Although the current
code can work as is in most cases, better to implement the RPN reset
explicitly for Null message.
Link: https://patch.msgid.link/20240731130528.12600-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jul 31 15:05:25 2024 +0200
ALSA: seq: ump: Transmit RPN/NRPN message at each MSB/LSB data reception
[ Upstream commit a4ff92ff0bdd731eca9f0b50b1cbb5aba89be4b2 ]
Just like the core UMP conversion helper, we need to deal with the
partially-filled RPN/NRPN data in the sequencer UMP converter as
well.
Link: https://patch.msgid.link/20240731130528.12600-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jul 31 15:05:24 2024 +0200
ALSA: seq: ump: Use the common RPN/bank conversion context
[ Upstream commit a683030606fa5ff8b722a5e28839d19288011ede ]
The UMP core conversion helper API already defines the context needed
to record the bank and RPN/NRPN values, and we can simply re-use the
same struct instead of re-defining the same content as a different
name.
Link: https://patch.msgid.link/20240731130528.12600-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jul 31 15:05:23 2024 +0200
ALSA: ump: Explicitly reset RPN with Null RPN
[ Upstream commit 50a6dd19dca9446475f023eaa652016bfe5b1cbe ]
RPN with 127:127 is treated as a Null RPN, just to reset the
parameters, and it's not translated to MIDI2. Although the current
code can work as is in most cases, better to implement the RPN reset
explicitly for Null message.
Link: https://patch.msgid.link/20240731130528.12600-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Jul 31 15:05:22 2024 +0200
ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception
[ Upstream commit e6ce8a28c768dbbad3f818db286cd0f4c7a921a8 ]
The UMP 1.1 spec says that an RPN/NRPN should be sent when one of the
following occurs:
* a CC 38 is received
* a subsequent CC 6 is received
* a CC 98, 99, 100, and 101 is received, indicating the last RPN/NRPN
message has ended and a new one has started
That said, we should send a partial data even if it's not fully
filled. Let's change the UMP conversion helper code to follow that
rule.
Link: https://patch.msgid.link/20240731130528.12600-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Leesoo Ahn <lsahn@ooseel.net>
Date: Wed May 8 01:12:29 2024 +0900
apparmor: fix possible NULL pointer dereference
[ Upstream commit 3dd384108d53834002be5630132ad5c3f32166ad ]
profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent->old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.
BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
<TASK>
? show_regs+0x6d/0x80
? __die+0x24/0x80
? page_fault_oops+0x99/0x1b0
? kernelmode_fixup_or_oops+0xb2/0x140
? __bad_area_nosemaphore+0x1a5/0x2c0
? find_vma+0x34/0x60
? bad_area_nosemaphore+0x16/0x30
? do_user_addr_fault+0x2a2/0x6b0
? exc_page_fault+0x83/0x1b0
? asm_exc_page_fault+0x27/0x30
? aafs_create.constprop.0+0x7f/0x130
? aafs_create.constprop.0+0x51/0x130
__aafs_profile_mkdir+0x3d6/0x480
aa_replace_profiles+0x83f/0x1270
policy_update+0xe3/0x180
profile_load+0xbc/0x150
? rw_verify_area+0x47/0x140
vfs_write+0x100/0x480
? __x64_sys_openat+0x55/0xa0
? syscall_exit_to_user_mode+0x86/0x260
ksys_write+0x73/0x100
__x64_sys_write+0x19/0x30
x64_sys_call+0x7e/0x25c0
do_syscall_64+0x7f/0x180
entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
</TASK>
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johan Hovold <johan+linaro@kernel.org>
Date: Mon Jul 22 11:42:47 2024 +0200
arm64: dts: qcom: x1e80100-crd: fix missing PCIe4 gpios
[ Upstream commit 42b33ad188466292eaac9825544b8be8deddb3cb ]
Add the missing PCIe4 perst, wake and clkreq GPIOs and pin config.
Fixes: d7e03cce0400 ("arm64: dts: qcom: x1e80100-crd: Enable more support")
Cc: stable@vger.kernel.org # 6.9
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240722094249.26471-7-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johan Hovold <johan+linaro@kernel.org>
Date: Mon Jul 22 11:42:45 2024 +0200
arm64: dts: qcom: x1e80100-crd: fix up PCIe6a pinctrl node
[ Upstream commit 6e3902c499544291ac4fd1a1bb69f2e9037a0e86 ]
The PCIe6a pinctrl node appears to have been copied from the sc8280xp
CRD dts, which has the NVMe on pcie2a and uses some funny indentation.
Fix up the node name to match the x1e80100 use and label and use only
tabs for indentation.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240722094249.26471-5-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stable-dep-of: 42b33ad18846 ("arm64: dts: qcom: x1e80100-crd: fix missing PCIe4 gpios")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johan Hovold <johan+linaro@kernel.org>
Date: Mon Jul 22 11:54:51 2024 +0200
arm64: dts: qcom: x1e80100-qcp: fix missing PCIe4 gpios
[ Upstream commit 2ac90e4d2b6d6823ca10642ef39595ff1181c3fa ]
Add the missing PCIe4 perst, wake and clkreq GPIOs and pin config.
Fixes: f9a9c11471da ("arm64: dts: qcom: x1e80100-qcp: Enable more support")
Cc: stable@vger.kernel.org # 6.9
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240722095459.27437-5-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johan Hovold <johan+linaro@kernel.org>
Date: Mon Jul 22 11:54:49 2024 +0200
arm64: dts: qcom: x1e80100-qcp: fix up PCIe6a pinctrl node
[ Upstream commit 0aab6eaac72ac140dfc5e0a38bf3178497762e43 ]
The PCIe6a pinctrl node appears to have been copied from the sc8280xp
CRD dts, which has the NVMe on pcie2a and uses some funny indentation.
Fix up the node name to match the x1e80100 use and label and use only
tabs for indentation.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240722095459.27437-3-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stable-dep-of: 2ac90e4d2b6d ("arm64: dts: qcom: x1e80100-qcp: fix missing PCIe4 gpios")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Abel Vesa <abel.vesa@linaro.org>
Date: Thu May 30 18:43:41 2024 +0300
arm64: dts: qcom: x1e80100: Describe the PCIe 6a resources
[ Upstream commit eb57cbe730d10ec8c6505492a9f3252b160e0f1e ]
On both the CRD and QCP, on PCIe 6a sits the NVMe. Add the 3.3V
gpio-controlled regulator and the clkreq, perst and wake gpios as
resources for the PCIe 6a.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240530-x1e80100-dts-pcie6a-v1-3-ee17a9939ba5@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stable-dep-of: 42b33ad18846 ("arm64: dts: qcom: x1e80100-crd: fix missing PCIe4 gpios")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Bruno Ancona <brunoanconasala@gmail.com>
Date: Sun Jul 28 22:50:32 2024 -0600
ASoC: amd: yc: Support mic on HP 14-em0002la
[ Upstream commit c118478665f467e57d06b2354de65974b246b82b ]
Add support for the internal microphone for HP 14-em0002la laptop using
a quirk entry.
Signed-off-by: Bruno Ancona <brunoanconasala@gmail.com>
Link: https://patch.msgid.link/20240729045032.223230-1-brunoanconasala@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Krzysztof Stępniak <kfs.szk@gmail.com>
Date: Wed Aug 7 02:12:19 2024 +0200
ASoC: amd: yc: Support mic on Lenovo Thinkpad E14 Gen 6
[ Upstream commit 23a58b782f864951485d7a0018549729e007cb43 ]
Lenovo Thinkpad E14 Gen 6 (model type 21M3)
needs a quirk entry for internal mic to work.
Signed-off-by: Krzysztof Stępniak <kfs.szk@gmail.com>
Link: https://patch.msgid.link/20240807001219.1147-1-kfs.szk@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Zhang Yi <zhangyi@everest-semi.com>
Date: Wed Aug 7 10:53:55 2024 +0800
ASoC: codecs: ES8326: button detect issue
[ Upstream commit 4684a2df9c5b3fc914377127faf2515aa9049093 ]
We find that we need to set snd_jack_types to 0. If not,
there will be a probability of button detection errors
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
Link: https://patch.msgid.link/20240807025356.24904-2-zhangyi@everest-semi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Jun 13 10:48:16 2024 +0200
block: remove the blk_flush_integrity call in blk_integrity_unregister
[ Upstream commit e8bc14d116aeac8f0f133ec8d249acf4e0658da7 ]
Now that there are no indirect calls for PI processing there is no
way to dereference a NULL pointer here. Additionally drivers now always
freeze the queue (or in case of stacking drivers use their internal
equivalent) around changing the integrity profile.
This is effectively a revert of commit 3df49967f6f1 ("block: flush the
integrity workqueue in blk_integrity_unregister").
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20240613084839.1044015-7-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Qu Wenruo <wqu@suse.com>
Date: Fri Mar 8 13:40:30 2024 +1030
btrfs: factor out stripe length calculation into a helper
[ Upstream commit 33eb1e5db351e2c0e652d878b66b8a6d4d013135 ]
Currently there are two locations which need to calculate the real
length of a stripe (which can be at the end of a chunk, and the chunk
size may not always be 64K aligned).
Factor them into a helper as we're going to have a third user soon.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Boris Burkov <boris@bur.io>
Date: Fri Jul 19 16:49:08 2024 -0700
btrfs: fix qgroup reserve leaks in cow_file_range
[ Upstream commit 30479f31d44d47ed00ae0c7453d9b253537005b2 ]
In the buffered write path, the dirty page owns the qgroup reserve until
it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created
must free that reservation, or else the space is leaked. The fstest
generic/475 exercises various IO error paths, and is able to trigger
errors in cow_file_range where we fail to get to allocating the ordered
extent. Note that because we *do* clear delalloc, we are likely to
remove the inode from the delalloc list, so the inodes/pages to not have
invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure
BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure
BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672
------------[ cut here ]------------
WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]
Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq
CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]
RSP: 0018:ffffb4465283be00 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8
RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0
Call Trace:
<TASK>
? close_ctree+0x222/0x4d0 [btrfs]
? __warn.cold+0x8e/0xea
? close_ctree+0x222/0x4d0 [btrfs]
? report_bug+0xff/0x140
? handle_bug+0x3b/0x70
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? close_ctree+0x222/0x4d0 [btrfs]
generic_shutdown_super+0x70/0x160
kill_anon_super+0x11/0x40
btrfs_kill_super+0x11/0x20 [btrfs]
deactivate_locked_super+0x2e/0xa0
cleanup_mnt+0xb5/0x150
task_work_run+0x57/0x80
syscall_exit_to_user_mode+0x121/0x130
do_syscall_64+0xab/0x1a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f916847a887
---[ end trace 0000000000000000 ]---
BTRFS error (device dm-8 state EA): qgroup reserved space leaked
Cases 2 and 3 in the out_reserve path both pertain to this type of leak
and must free the reserved qgroup data. Because it is already an error
path, I opted not to handle the possible errors in
btrfs_free_qgroup_data.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Qu Wenruo <wqu@suse.com>
Date: Fri Mar 8 13:40:31 2024 +1030
btrfs: scrub: update last_physical after scrubbing one stripe
[ Upstream commit 63447b7dd40c6a9ae8d3bb70c11f4c46731823e3 ]
Currently sctx->stat.last_physical only got updated in the following
cases:
- When the last stripe of a non-RAID56 chunk is scrubbed
This implies a pitfall, if the last stripe is at the chunk boundary,
and we finished the scrub of the whole chunk, we won't update
last_physical at all until the next chunk.
- When a P/Q stripe of a RAID56 chunk is scrubbed
This leads the following two problems:
- sctx->stat.last_physical is not updated for a almost full chunk
This is especially bad, affecting scrub resume, as the resume would
start from last_physical, causing unnecessary re-scrub.
- "btrfs scrub status" will not report any progress for a long time
Fix the problem by properly updating @last_physical after each stripe is
scrubbed.
And since we're here, for the sake of consistency, use spin lock to
protect the update of @last_physical, just like all the remaining
call sites touching sctx->stat.
Reported-by: Michel Palleau <michel.palleau@gmail.com>
Link: https://lore.kernel.org/linux-btrfs/CAMFk-+igFTv2E8svg=cQ6o3e6CrR5QwgQ3Ok9EyRaEvvthpqCQ@mail.gmail.com/
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Qu Wenruo <wqu@suse.com>
Date: Mon Jul 15 16:07:07 2024 +0930
btrfs: tree-checker: validate dref root and objectid
[ Upstream commit f333a3c7e8323499aa65038e77fe8f3199d4e283 ]
[CORRUPTION]
There is a bug report that btrfs flips RO due to a corruption in the
extent tree, the involved dumps looks like this:
item 188 key (402811572224 168 4096) itemoff 14598 itemsize 79
extent refs 3 gen 3678544 flags 1
ref#0: extent data backref root 13835058055282163977 objectid 281473384125923 offset 81432576 count 1
ref#1: shared data backref parent 1947073626112 count 1
ref#2: shared data backref parent 1156030103552 count 1
BTRFS critical (device vdc1: state EA): unable to find ref byte nr 402811572224 parent 0 root 265 owner 28703026 offset 81432576 slot 189
BTRFS error (device vdc1: state EA): failed to run delayed ref for logical 402811572224 num_bytes 4096 type 178 action 2 ref_mod 1: -2
[CAUSE]
The corrupted entry is ref#0 of item 188.
The root number 13835058055282163977 is beyond the upper limit for root
items (the current limit is 1 << 48), and the objectid also looks
suspicious.
Only the offset and count is correct.
[ENHANCEMENT]
Although it's still unknown why we have such many bytes corrupted
randomly, we can still enhance the tree-checker for data backrefs by:
- Validate the root value
For now there should only be 3 types of roots can have data backref:
* subvolume trees
* data reloc trees
* root tree
Only for v1 space cache
- validate the objectid value
The objectid should be a valid inode number.
Hopefully we can catch such problem in the future with the new checkers.
Reported-by: Kai Krakow <hurikhan77@gmail.com>
Link: https://lore.kernel.org/linux-btrfs/CAMthOuPjg5RDT-G_LXeBBUUtzt3cq=JywF+D1_h+JYxe=WKp-Q@mail.gmail.com/#t
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jagadeesh Kona <quic_jkona@quicinc.com>
Date: Mon May 20 12:07:32 2024 +0530
cpufreq: scmi: Avoid overflow of target_freq in fast switch
[ Upstream commit 074cffb5020ddcaa5fafcc55655e5da6ebe8c831 ]
Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
can lead to overflow if the multiplied result is greater than
UINT_MAX, since type of target_freq is unsigned int. Avoid this
overflow by assigning target_freq to unsigned long variable for
converting it to HZ.
Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Stefan Berger <stefanb@linux.ibm.com>
Date: Thu Jun 13 17:38:20 2024 -0400
crypto: ecc - Fix off-by-one missing to clear most significant digit
[ Upstream commit 1dcf865d3bf5bff45e93cb2410911b3428dacb78 ]
Fix an off-by-one error where the most significant digit was not
initialized leading to signature verification failures by the testmgr.
Example: If a curve requires ndigits (=9) and diff (=2) indicates that
2 digits need to be set to zero then start with digit 'ndigits - diff' (=7)
and clear 'diff' digits starting from there, so 7 and 8.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Closes: https://lore.kernel.org/linux-crypto/619bc2de-b18a-4939-a652-9ca886bf6349@linux.ibm.com/T/#m045d8812409ce233c17fcdb8b88b6629c671f9f4
Fixes: 2fd2a82ccbfc ("crypto: ecdsa - Use ecc_digits_from_bytes to create hash digits array")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Maxime Méré <maxime.mere@foss.st.com>
Date: Tue May 28 16:05:48 2024 +0200
crypto: stm32/cryp - call finalize with bh disabled
[ Upstream commit 56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce ]
The finalize operation in interrupt mode produce a produces a spinlock
recursion warning. The reason is the fact that BH must be disabled
during this process.
Signed-off-by: Maxime Méré <maxime.mere@foss.st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Rik van Riel <riel@surriel.com>
Date: Tue Aug 6 11:56:45 2024 -0400
dma-debug: avoid deadlock between dma debug vs printk and netconsole
[ Upstream commit bd44ca3de49cc1badcff7a96010fa2c64f04868c ]
Currently the dma debugging code can end up indirectly calling printk
under the radix_lock. This happens when a radix tree node allocation
fails.
This is a problem because the printk code, when used together with
netconsole, can end up inside the dma debugging code while trying to
transmit a message over netcons.
This creates the possibility of either a circular deadlock on the same
CPU, with that CPU trying to grab the radix_lock twice, or an ABBA
deadlock between different CPUs, where one CPU grabs the console lock
first and then waits for the radix_lock, while the other CPU is holding
the radix_lock and is waiting for the console lock.
The trace captured by lockdep is of the ABBA variant.
-> #2 (&dma_entry_hash[i].lock){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x5a/0x90
debug_dma_map_page+0x79/0x180
dma_map_page_attrs+0x1d2/0x2f0
bnxt_start_xmit+0x8c6/0x1540
netpoll_start_xmit+0x13f/0x180
netpoll_send_skb+0x20d/0x320
netpoll_send_udp+0x453/0x4a0
write_ext_msg+0x1b9/0x460
console_flush_all+0x2ff/0x5a0
console_unlock+0x55/0x180
vprintk_emit+0x2e3/0x3c0
devkmsg_emit+0x5a/0x80
devkmsg_write+0xfd/0x180
do_iter_readv_writev+0x164/0x1b0
vfs_writev+0xf9/0x2b0
do_writev+0x6d/0x110
do_syscall_64+0x80/0x150
entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #0 (console_owner){-.-.}-{0:0}:
__lock_acquire+0x15d1/0x31a0
lock_acquire+0xe8/0x290
console_flush_all+0x2ea/0x5a0
console_unlock+0x55/0x180
vprintk_emit+0x2e3/0x3c0
_printk+0x59/0x80
warn_alloc+0x122/0x1b0
__alloc_pages_slowpath+0x1101/0x1120
__alloc_pages+0x1eb/0x2c0
alloc_slab_page+0x5f/0x150
new_slab+0x2dc/0x4e0
___slab_alloc+0xdcb/0x1390
kmem_cache_alloc+0x23d/0x360
radix_tree_node_alloc+0x3c/0xf0
radix_tree_insert+0xf5/0x230
add_dma_entry+0xe9/0x360
dma_map_page_attrs+0x1d2/0x2f0
__bnxt_alloc_rx_frag+0x147/0x180
bnxt_alloc_rx_data+0x79/0x160
bnxt_rx_skb+0x29/0xc0
bnxt_rx_pkt+0xe22/0x1570
__bnxt_poll_work+0x101/0x390
bnxt_poll+0x7e/0x320
__napi_poll+0x29/0x160
net_rx_action+0x1e0/0x3e0
handle_softirqs+0x190/0x510
run_ksoftirqd+0x4e/0x90
smpboot_thread_fn+0x1a8/0x270
kthread+0x102/0x120
ret_from_fork+0x2f/0x40
ret_from_fork_asm+0x11/0x20
This bug is more likely than it seems, because when one CPU has run out
of memory, chances are the other has too.
The good news is, this bug is hidden behind the CONFIG_DMA_API_DEBUG, so
not many users are likely to trigger it.
Signed-off-by: Rik van Riel <riel@surriel.com>
Reported-by: Konstantin Ovsepian <ovs@meta.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Olivier Dautricourt <olivierdautricourt@gmail.com>
Date: Sat Jun 8 23:31:48 2024 +0200
dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor
[ Upstream commit 54e4ada1a4206f878e345ae01cf37347d803d1b1 ]
Remove list_del call in msgdma_chan_desc_cleanup, this should be the role
of msgdma_free_descriptor. In consequence replace list_add_tail with
list_move_tail in msgdma_free_descriptor.
This fixes the path:
msgdma_free_chan_resources -> msgdma_free_descriptors ->
msgdma_free_desc_list -> msgdma_free_descriptor
which does not correctly free the descriptors as first nodes were not
removed from the list.
Signed-off-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
Tested-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
Link: https://lore.kernel.org/r/20240608213216.25087-3-olivierdautricourt@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Olivier Dautricourt <olivierdautricourt@gmail.com>
Date: Sat Jun 8 23:31:46 2024 +0200
dmaengine: altera-msgdma: use irq variant of spin_lock/unlock while invoking callbacks
[ Upstream commit 261d3a85d959841821ca0d69f9d7b0d4087661c4 ]
As we first take the lock with spin_lock_irqsave in msgdma_tasklet, Lockdep
might complain about this. Inspired by commit 9558cf4ad07e
("dmaengine: zynqmp_dma: fix lockdep warning in tasklet")
Signed-off-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
Tested-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
Suggested-by: Eric Schwarz <eas@sw-optimization.com>
Link: https://lore.kernel.org/r/20240608213216.25087-1-olivierdautricourt@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Julien Stephan <jstephan@baylibre.com>
Date: Thu May 30 11:22:46 2024 +0200
driver: iio: add missing checks on iio_info's callback access
[ Upstream commit c4ec8dedca961db056ec85cb7ca8c9f7e2e92252 ]
Some callbacks from iio_info structure are accessed without any check, so
if a driver doesn't implement them trying to access the corresponding
sysfs entries produce a kernel oops such as:
[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
[...]
[ 2203.783416] Call trace:
[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48
[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120
[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0
[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4
[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54
[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000
[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
[ 2203.830363] Code: bad PC value
[ 2203.832695] ---[ end trace 0000000000000000 ]---
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Link: https://lore.kernel.org/r/20240530-iio-core-fix-segfault-v3-1-8b7cd2a03773@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Asad Kamal <asad.kamal@amd.com>
Date: Fri Apr 26 02:26:55 2024 +0800
drm/amd/amdgpu: Check tbo resource pointer
[ Upstream commit 6cd2b872643bb29bba01a8ac739138db7bd79007 ]
Validate tbo resource pointer, skip if NULL
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Wed Apr 24 10:09:31 2024 -0400
drm/amd/display: Add array index check for hdcp ddc access
[ Upstream commit 4e70c0f5251c25885c31ee84a31f99a01f7cf50e ]
[Why]
Coverity reports OVERRUN warning. Do not check if array
index valid.
[How]
Check msg_id valid and valid array index.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Mon Apr 22 16:22:44 2024 -0400
drm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range
[ Upstream commit 5524fa301ba649f8cf00848f91468e0ba7e4f24c ]
[Why & How]
ASSERT if return NULL from kcalloc.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Apr 26 11:13:47 2024 -0400
drm/amd/display: Add otg_master NULL check within resource_log_pipe_topology_update
[ Upstream commit 871cd9d881fa791d3f82885000713de07041c0ae ]
[Why]
Coverity reports NULL_RETURN warning.
[How]
Add otg_master NULL check.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: winstang <winstang@amd.com>
Date: Mon May 27 08:51:19 2024 -0400
drm/amd/display: added NULL check at start of dc_validate_stream
[ Upstream commit 26c56049cc4f1705b498df013949427692a4b0d5 ]
[Why]
prevent invalid memory access
[How]
check if dc and stream are NULL
Co-authored-by: winstang <winstang@amd.com>
Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: winstang <winstang@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alvin Lee <alvin.lee2@amd.com>
Date: Tue Apr 16 14:42:18 2024 -0400
drm/amd/display: Assign linear_pitch_alignment even for VM
[ Upstream commit 984debc133efa05e62f5aa1a7a1dd8ca0ef041f4 ]
[Description]
Assign linear_pitch_alignment so we don't cause a divide by 0
error in VM environments
Reviewed-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Fri May 31 11:51:26 2024 -0600
drm/amd/display: Avoid overflow from uint32_t to uint8_t
[ Upstream commit d6b54900c564e35989cf6813e4071504fa0a90e0 ]
[WHAT & HOW]
dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned
0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.
This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Mon Jun 3 08:24:13 2024 -0600
drm/amd/display: Check BIOS images before it is used
[ Upstream commit 8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c ]
BIOS images may fail to load and null checks are added before they are
used.
This fixes 6 NULL_RETURNS issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Tue Apr 16 16:40:00 2024 -0600
drm/amd/display: Check gpio_id before used as array index
[ Upstream commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 ]
[WHY & HOW]
GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
should be checked in advance.
This fixes 5 OVERRUN issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Thu Apr 18 18:22:43 2024 -0600
drm/amd/display: Check index for aux_rd_interval before using
[ Upstream commit 9ba2ea6337b4f159aecb177555a6a81da92d302e ]
aux_rd_interval has size of 7 and should be checked.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Tue Apr 16 16:30:17 2024 -0600
drm/amd/display: Check link_index before accessing dc->links[]
[ Upstream commit 8aa2864044b9d13e95fe224f32e808afbf79ecdf ]
[WHY & HOW]
dc->links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Tue Apr 16 16:47:42 2024 -0600
drm/amd/display: Check msg_id before processing transcation
[ Upstream commit fa71face755e27dc44bc296416ebdf2c67163316 ]
[WHY & HOW]
HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid
array index, and it needs checking before used.
This fixes 4 OVERRUN issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Tue Apr 16 16:22:35 2024 -0600
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
[ Upstream commit b38a4815f79b87efb196cd5121579fc51e29a7fb ]
[WHY & HOW]
num_valid_sets needs to be checked to avoid a negative index when
accessing reader_wm_sets[num_valid_sets - 1].
This fixes an OVERRUN issue reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Wayne Lin <wayne.lin@amd.com>
Date: Mon May 27 15:33:48 2024 +0800
drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
[ Upstream commit ad28d7c3d989fc5689581664653879d664da76f0 ]
[Why & How]
It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller
number to create array dmub_callback & dmub_thread_offload has potential to access
item out of array bound. Fix it.
Reviewed-by: Jerry Zuo <jerry.zuo@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: Wayne Lin <wayne.lin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed May 29 12:12:09 2024 -0400
drm/amd/display: Disable DMCUB timeout for DCN35
[ Upstream commit 7c70e60fbf4bff1123f0e8d5cb1ae71df6164d7f ]
[Why]
DMCUB can intermittently take longer than expected to process commands.
Old ASIC policy was to continue while logging a diagnostic error - which
works fine for ASIC without IPS, but with IPS this could lead to a race
condition where we attempt to access DCN state while it's inaccessible,
leading to a system hang when the NIU port is not disabled or register
accesses that timeout and the display configuration in an undefined
state.
[How]
We need to investigate why these accesses take longer than expected, but
for now we should disable the timeout on DCN35 to avoid this race
condition. Since the waits happen only at lower interrupt levels the
risk of taking too long at higher IRQ and causing a system watchdog
timeout are minimal.
Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Sep 27 15:06:41 2023 -0400
drm/amd/display: Don't use fsleep for PSR exit waits on dmub replay
[ Upstream commit b5236da757adc75d7e52c69bdc233d29249a0d0c ]
[Why]
These functions can be called from high IRQ levels and the OS will hang
if it tries to use a usleep_highres or a msleep.
[How]
Replace the flseep with a udelay for dmub_replay_enable.
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Tue Apr 16 16:44:17 2024 -0600
drm/amd/display: Ensure array index tg_inst won't be -1
[ Upstream commit 687fe329f18ab0ab0496b20ed2cb003d4879d931 ]
[WHY & HOW]
tg_inst will be a negative if timing_generator_count equals 0, which
should be checked before used.
This fixes 2 OVERRUN issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Wed Apr 24 17:08:04 2024 -0600
drm/amd/display: Ensure index calculation will not overflow
[ Upstream commit 8e2734bf444767fed787305ccdcb36a2be5301a2 ]
[WHY & HOW]
Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will
never overflow and exceess array size.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Apr 26 11:58:11 2024 -0400
drm/amd/display: Fix Coverity INTEGER_OVERFLOW within dal_gpio_service_create
[ Upstream commit c6077aa66fa230d12f37fef01161ef080d13b726 ]
[Why]
For subtraction, coverity reports integer overflow
warning message when variable type is uint32_t.
[How]
Change variable type to int32_t.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Apr 26 12:13:59 2024 -0400
drm/amd/display: Fix Coverity INTEGER_OVERFLOW within decide_fallback_link_setting_max_bw_policy
[ Upstream commit 83c0c8361347cf43937348e8ca0a487679c003ae ]
[Why]
For addtion (uint8_t) variable + constant 1,
coverity generates message below:
Truncation due to cast operation on "cur_idx + 1" from
32 to 8 bits.
Then Coverity assume result is 32 bits value be saved into
8 bits variable. When result is used as index to access
array, Coverity suspects index invalid.
[How]
Change varaible type to uint32_t.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Apr 26 10:46:41 2024 -0400
drm/amd/display: Fix Coverity INTERGER_OVERFLOW within construct_integrated_info
[ Upstream commit 176abbcc71952e23009a6ed194fd203b99646884 ]
[Why]
For substrcation, coverity reports integer overflow
warning message when variable type is uint32_t.
[How]
Change varaible type to int32_t.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Fri Apr 19 20:23:36 2024 -0600
drm/amd/display: Fix incorrect size calculation for loop
[ Upstream commit 3941a3aa4b653b69876d894d08f3fff1cc965267 ]
[WHY]
fe_clk_en has size of 5 but sizeof(fe_clk_en) has byte size 20 which is
lager than the array size.
[HOW]
Divide byte size 20 by its element size.
This fixes 2 OVERRUN issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Thu Apr 25 09:24:44 2024 -0400
drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box
[ Upstream commit 188fd1616ec43033cedbe343b6579e9921e2d898 ]
[Why]
Coverity reports OVERRUN warning. soc.num_states could
be 40. But array range of bw_params->clk_table.entries is 8.
[How]
Assert if soc.num_states greater than 8.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Nicholas Susanto <nicholas.susanto@amd.com>
Date: Tue May 7 14:01:39 2024 -0400
drm/amd/display: Fix pipe addition logic in calc_blocks_to_ungate DCN35
[ Upstream commit 3aec7a5af4d6248b7462b7d1eb597f06d35f5ee0 ]
[Why]
Missing check for when there is new pipe configuration but both cur_pipe
and new_pipe are both populated causing update_state of DSC for that
instance not being updated correctly.
This causes some display mode changes to cause underflow since DSCCLK
is still gated when the display requires DSC.
[How]
Added another condition in the new pipe addition branch that checks if
there is a new pipe configuration and if it is not the same as cur_pipe.
cur_pipe does not necessarily have to be NULL to go in this branch.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Roman Li <roman.li@amd.com>
Signed-off-by: Nicholas Susanto <nicholas.susanto@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Tue Apr 30 14:24:17 2024 -0400
drm/amd/display: Fix writeback job lock evasion within dm_crtc_high_irq
[ Upstream commit 922c2877827dcc474f3079e464773ab31ac13b79 ]
[Why]
Coverity report LOCK_EVASION warning. Access
acrtc->wb_pending without lock wb_conn->job_lock.
[How]
Lock wb_conn->job_lock before accessing
acrtc->wb_pending.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Date: Thu Apr 18 17:39:39 2024 -0600
drm/amd/display: Handle the case which quad_part is equal 0
[ Upstream commit 02fb803db110dbdac9f0d446180f0f7b545e15ff ]
Add code to handle case when quad_part is 0 in gpu_addr_to_uma().
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Wed Apr 24 20:18:30 2024 -0400
drm/amd/display: Release clck_src memory if clk_src_construct fails
[ Upstream commit 674704a5dabe4a434645fdd11e35437f4e06dfc4 ]
[Why]
Coverity reports RESOURCE_LEAK for some implemenations
of clock_source_create. Do not release memory of clk_src
if contructor fails.
[How]
Free clk_src if contructor fails.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Wed Apr 24 20:32:53 2024 -0400
drm/amd/display: Release state memory if amdgpu_dm_create_color_properties fail
[ Upstream commit 52cbcf980509e6190740dd1e2a1a437e8fb8101b ]
[Why]
Coverity reports RESOURCE_LEAK warning. State memory
is not released if dm_create_color_properties fail.
[How]
Call kfree(state) before return.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Tue May 28 15:25:30 2024 -0400
drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection
[ Upstream commit 466423c6dd8af23ebb3a69d43434d01aed0db356 ]
[Why]
These registers should not be read from driver and triggering the
security violation when DMCUB work times out and diagnostics are
collected blocks Z8 entry.
[How]
Remove the register read from DCN35.
Reviewed-by: Duncan Ma <duncan.ma@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Apr 26 16:39:37 2024 -0400
drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration
[ Upstream commit a54f7e866cc73a4cb71b8b24bb568ba35c8969df ]
[Why]
Coverity reports Memory - illegal accesses.
[How]
Skip inactive planes.
Reviewed-by: Alex Hung <alex.hung@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Mon Jun 3 10:47:37 2024 -0600
drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
[ Upstream commit c4d31653c03b90e51515b1380115d1aedad925dd ]
Callers can pass null in filter (i.e. from returned from the function
wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
not the case.
This fixes 4 NULL_RETURNS issues reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Alex Hung <alex.hung@amd.com>
Date: Fri Apr 26 10:33:47 2024 -0600
drm/amd/display: Spinlock before reading event
[ Upstream commit ae13c8a5cff92015b9a3eb7cee65ebc75859487f ]
[WHY & HOW]
A read of acrtc_attach->base.state->event was not locked so moving it
inside the spinlock.
This fixes a LOCK_EVASION issue reported by Coverity.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Wed Apr 24 16:15:15 2024 -0400
drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links
[ Upstream commit cf8b16857db702ceb8d52f9219a4613363e2b1cf ]
[Why]
Coverity report OVERRUN warning. There are
only max_links elements within dc->links. link
count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.
[How]
Make sure link count less than max_links.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Wed Apr 24 16:00:19 2024 -0400
drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6
[ Upstream commit 84723eb6068c50610c5c0893980d230d7afa2105 ]
[Why]
Coverity reports OVERRUN warning. Should abort amdgpu_dm
initialize.
[How]
Return failure to amdgpu_dm_init.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Wenjing Liu <wenjing.liu@amd.com>
Date: Wed May 29 12:20:41 2024 -0400
drm/amd/display: use preferred link settings for dp signal only
[ Upstream commit abf34ca465f5cd182b07701d3f3d369c0fc04723 ]
[why]
We set preferred link settings for virtual signal. However we don't support
virtual signal for UHBR link rate. If preferred is set to UHBR link rate, we
will allow virtual signal with UHBR link rate which causes system crashes.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Mon May 13 16:01:23 2024 +0800
drm/amd/pm: check negtive return for table entries
[ Upstream commit f76059fe14395b37ba8d997eb0381b1b9e80a939 ]
Function hwmgr->hwmgr_func->get_num_of_pp_table_entries(hwmgr) returns a negative number
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Suggested-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Wed May 8 17:13:28 2024 +0800
drm/amd/pm: check specific index for aldebaran
[ Upstream commit 0ce8ef2639c112ae203c985b758389e378630aac ]
Check for specific indexes that may be invalid values.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Wed May 8 17:50:21 2024 +0800
drm/amd/pm: check specific index for smu13
[ Upstream commit a3ac9d1c9751f00026c2d98b802ec8a98626c3ed ]
Check for specific indexes that may be invalid values.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Suggested-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Tue Apr 30 10:23:48 2024 +0800
drm/amd/pm: Fix negative array index read
[ Upstream commit c8c19ebf7c0b202a6a2d37a52ca112432723db5f ]
Avoid using the negative values
for clk_idex as an index into an array pptable->DpmDescriptor.
V2: fix clk_index return check (Tim Huang)
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Tue Apr 30 10:29:08 2024 +0800
drm/amd/pm: fix the Out-of-bounds read warning
[ Upstream commit 12c6967428a099bbba9dfd247bb4322a984fcc0b ]
using index i - 1U may beyond element index
for mc_data[] when i = 0.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Sun Apr 28 15:36:26 2024 +0800
drm/amd/pm: fix uninitialized variable warning
[ Upstream commit 7c836905520703dbc8b938993b6d4d718bc739f3 ]
Check the return of function smum_send_msg_to_smc
as it may fail to initialize the variable.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Fri Apr 26 12:52:45 2024 +0800
drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr
[ Upstream commit 86df36b934640866eb249a4488abb148b985a0d9 ]
Clear warnings that using uninitialized value level when fails
to get the value from SMU.
Signed-off-by: Tim Huang <Tim.Huang@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>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Mon Apr 29 11:17:54 2024 +0800
drm/amd/pm: fix uninitialized variable warning for smu_v13
[ Upstream commit 6e46b89f40e39e2054f2e179e8e8c3132e7a9d57 ]
Clear warning that using uninitialized variable when the dpm is
not enabled and reuse the code for SMU13 to get the boot frequency.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Sun Apr 28 15:42:03 2024 +0800
drm/amd/pm: fix uninitialized variable warnings for vangogh_ppt
[ Upstream commit b2871de6961d24d421839fbfa4aa3008ec9170d5 ]
1. Fix a issue that using uninitialized mask to get the ultimate frequency.
2. Check return of smu_cmn_send_smc_msg_with_param to avoid using
uninitialized variable residency.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Sun Apr 28 12:41:42 2024 +0800
drm/amd/pm: fix uninitialized variable warnings for vega10_hwmgr
[ Upstream commit 5fa7d540d95d97ddc021a74583f6b3da4df9c93a ]
Clear warnings that using uninitialized variable when fails
to get the valid value from SMU.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Mon Apr 29 15:26:25 2024 +0800
drm/amd/pm: fix warning using uninitialized value of max_vid_step
[ Upstream commit 17e3bea65cdc453695b2fe4ff26d25d17f5339e9 ]
Check the return of pp_atomfwctrl_get_Voltage_table_v4
as it may fail to initialize max_vid_step
V2: change the check condition (Tim Huang)
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Fri May 10 10:05:21 2024 +0800
drm/amdgpu/pm: Check input value for CUSTOM profile mode setting on legacy SOCs
[ Upstream commit df0a9bd92fbbd3fcafcb2bce6463c9228a3e6868 ]
Check the input value for CUSTOM profile mode setting on legacy
SOCs. Otherwise we may use uninitalized value of input[]
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Wed May 8 16:39:29 2024 +0800
drm/amdgpu/pm: Check input value for power profile setting on smu11, smu13 and smu14
[ Upstream commit adb9de4dd207fb1264ea70b9eacab9f70ee4707a ]
Check the input value for CUSTOM profile mode setting on smu 11,
smu13 and smu14. Otherwise we use uninitialized value of input[]
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Fri Apr 26 14:38:04 2024 +0800
drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc
[ Upstream commit 579f0c21baec9e7506b6bb3f60f0a9b6d07693b4 ]
Check the return value of smum_send_msg_to_smc, otherwise
we might use an uninitialized variable "now"
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Sun Apr 28 14:41:38 2024 +0800
drm/amdgpu/pm: Fix uninitialized variable agc_btc_response
[ Upstream commit df4409d8a04dd39d7f2aa0c5f528a56b99eaaa13 ]
Assign an default value to agc_btc_response in failed case
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Fri Apr 26 17:46:08 2024 +0800
drm/amdgpu/pm: Fix uninitialized variable warning for smu10
[ Upstream commit 336c8f558d596699d3d9814a45600139b2f23f27 ]
Check return value of smum_send_msg_to_smc to fix
uninitialized variable varning
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: David (Ming Qiang) Wu <David.Wu3@amd.com>
Date: Thu May 9 13:40:10 2024 -0400
drm/amdgpu/vcn: remove irq disabling in vcn 5 suspend
[ Upstream commit 10fe1a79cd1bff3048e13120e93c02f8ecd05e9d ]
We do not directly enable/disable VCN IRQ in vcn 5.0.0.
And we do not handle the IRQ state as well. So the calls to
disable IRQ and set state are removed. This effectively gets
rid of the warining of
"WARN_ON(!amdgpu_irq_enabled(adev, src, type))"
in amdgpu_irq_put().
Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Yunxiang Li <Yunxiang.Li@amd.com>
Date: Fri May 24 17:11:30 2024 -0400
drm/amdgpu: add lock in amdgpu_gart_invalidate_tlb
[ Upstream commit 18f2525d31401e5142db95ff3a6ec0f4147be818 ]
We need to take the reset domain lock before flush hdp. We can't put the
lock inside amdgpu_device_flush_hdp itself because it is used during
reset where we already take the write side lock.
Signed-off-by: Yunxiang Li <Yunxiang.Li@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>
Author: Yunxiang Li <Yunxiang.Li@amd.com>
Date: Mon Jun 3 12:29:30 2024 -0400
drm/amdgpu: add lock in kfd_process_dequeue_from_device
[ Upstream commit d225960c2330e102370815367b877baaf8bb8b5d ]
We need to take the reset domain lock before talking to MES. While in
this case we can take the lock inside the mes helper. We can't do so for
most other mes helpers since they are used during reset. So for
consistency sake we add the lock here.
Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Yunxiang Li <Yunxiang.Li@amd.com>
Date: Fri May 24 16:14:55 2024 -0400
drm/amdgpu: add skip_hw_access checks for sriov
[ Upstream commit b3948ad1ac582f560e1f3aeaecf384619921c48d ]
Accessing registers via host is missing the check for skip_hw_access and
the lockdep check that comes with it.
Signed-off-by: Yunxiang Li <Yunxiang.Li@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>
Author: Zhigang Luo <Zhigang.Luo@amd.com>
Date: Tue Apr 16 16:35:14 2024 -0400
drm/amdgpu: avoid reading vf2pf info size from FB
[ Upstream commit 3bcc0ee14768d886cedff65da72d83d375a31a56 ]
VF can't access FB when host is doing mode1 reset. Using sizeof to get
vf2pf info size, instead of reading it from vf2pf header stored in FB.
Signed-off-by: Zhigang Luo <Zhigang.Luo@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Yang Wang <kevinyang.wang@amd.com>
Date: Tue May 14 07:48:19 2024 +0800
drm/amdgpu: fix compiler 'side-effect' check issue for RAS_EVENT_LOG()
[ Upstream commit b712d7c20133b67f13aa134e7534369f19e1214f ]
create a new helper function to avoid compiler 'side-effect'
check about RAS_EVENT_LOG() macro.
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Wed May 8 14:51:35 2024 +0800
drm/amdgpu: fix dereference after null check
[ Upstream commit b1f7810b05d1950350ac2e06992982974343e441 ]
check the pointer hive before use.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Mon May 6 16:30:01 2024 +0800
drm/amdgpu: fix mc_data out-of-bounds read warning
[ Upstream commit 51dfc0a4d609fe700750a62f41447f01b8c9ea50 ]
Clear warning that read mc_data[i-1] may out-of-bounds.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Tue May 7 09:29:33 2024 +0800
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
[ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ]
Check the fb_channel_number range to avoid the array out-of-bounds
read error
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Thu Apr 25 14:00:17 2024 +0800
drm/amdgpu: Fix out-of-bounds write warning
[ Upstream commit be1684930f5262a622d40ce7a6f1423530d87f89 ]
Check the ring type value to fix the out-of-bounds
write warning
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Thu Apr 25 13:15:27 2024 +0800
drm/amdgpu: fix overflowed array index read warning
[ Upstream commit ebbc2ada5c636a6a63d8316a3408753768f5aa9f ]
Clear overflowed array index read warning by cast operation.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@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>
Author: Bob Zhou <bob.zhou@amd.com>
Date: Fri Jun 7 16:33:35 2024 +0800
drm/amdgpu: fix overflowed constant warning in mmhub_set_clockgating()
[ Upstream commit be6a69b21a3517122ba6cf7ab8f62f4803637dbe ]
To fix potential overflowed constant warning, modify the variables to u32
for getting the return value of RREG32_SOC15().
Signed-off-by: Bob Zhou <bob.zhou@amd.com>
Acked-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>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Wed Apr 24 15:44:56 2024 +0800
drm/amdgpu: Fix the uninitialized variable warning
[ Upstream commit 7e39d7ec35883a168343ea02f40e260e176c6c63 ]
Check the user input and phy_id value range to fix
"Using uninitialized value phy_id"
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Wed May 8 16:20:49 2024 +0800
drm/amdgpu: fix the waring dereferencing hive
[ Upstream commit 1940708ccf5aff76de4e0b399f99267c93a89193 ]
Check the amdgpu_hive_info *hive that maybe is NULL.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Thu May 9 13:17:47 2024 +0800
drm/amdgpu: fix the warning bad bit shift operation for aca_error_type type
[ Upstream commit e6ae021adb79e5f4c4bc4362dd651d7b8b646340 ]
Filter invalid aca error types before performing a shift operation.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Fri May 10 17:32:53 2024 +0800
drm/amdgpu: Fix the warning division or modulo by zero
[ Upstream commit 1a00f2ac82d6bc6689388c7edcd2a4bd82664f3c ]
Checks the partition mode and returns an error for an invalid mode.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Mon May 6 16:21:00 2024 +0800
drm/amdgpu: fix ucode out-of-bounds read warning
[ Upstream commit 8944acd0f9db33e17f387fdc75d33bb473d7936f ]
Clear warning that read ucode[] may out-of-bounds.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Fri Apr 26 08:43:30 2024 +0800
drm/amdgpu: fix uninitialized scalar variable warning
[ Upstream commit 0fa4c25db8b791f79bc0d5a0cd58aff9ad85186b ]
Clear warning that field bp is uninitialized when
calling amdgpu_virt_ras_add_bps.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Mon May 6 13:48:57 2024 +0800
drm/amdgpu: fix uninitialized variable warning for amdgpu_xgmi
[ Upstream commit 8f184f8e7a07fddc33ee4e6a38b717c770c3aedd ]
Clear warning that using uninitialized variable current_node.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tim Huang <Tim.Huang@amd.com>
Date: Mon May 6 13:57:03 2024 +0800
drm/amdgpu: fix uninitialized variable warning for jpeg_v4
[ Upstream commit 9e5da942594034ec377ba8c0caa9c15e1d26ba08 ]
Clear warning that using uninitialized variable r.
Signed-off-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Wed Apr 24 10:50:54 2024 +0800
drm/amdgpu: Fix uninitialized variable warning in amdgpu_afmt_acr
[ Upstream commit c0d6bd3cd209419cc46ac49562bef1db65d90e70 ]
Assign value to clock to fix the warning below:
"Using uninitialized value res. Field res.clock is uninitialized"
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ma Jun <Jun.Ma2@amd.com>
Date: Mon May 6 14:01:33 2024 +0800
drm/amdgpu: Fix uninitialized variable warning in amdgpu_info_ioctl
[ Upstream commit 0991e49d2b73bb4189f83a49eb41cdf16976bbf6 ]
Check the return value of amdgpu_xcp_get_inst_details, otherwise we
may use an uninitialized variable inst_mask
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Philip Yang <Philip.Yang@amd.com>
Date: Fri Apr 19 16:27:00 2024 -0400
drm/amdgpu: Handle sg size limit for contiguous allocation
[ Upstream commit b2dba064c9bdd18c7dd39066d25453af28451dbf ]
Define macro AMDGPU_MAX_SG_SEGMENT_SIZE 2GB, because struct scatterlist
length is unsigned int, and some users of it cast to a signed int, so
every segment of sg table is limited to size 2GB maximum.
For contiguous VRAM allocation, don't limit the max buddy block size in
order to get contiguous VRAM memory. To workaround the sg table segment
size limit, allocate multiple segments if contiguous size is bigger than
AMDGPU_MAX_SG_SEGMENT_SIZE.
Signed-off-by: Philip Yang <Philip.Yang@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>
Author: Victor Skvortsov <victor.skvortsov@amd.com>
Date: Sun May 19 10:39:43 2024 -0400
drm/amdgpu: Queue KFD reset workitem in VF FED
[ Upstream commit 5434bc03f52de2ec57d6ce684b1853928f508cbc ]
The guest recovery sequence is buggy in Fatal Error when both
FLR & KFD reset workitems are queued at the same time. In addition,
FLR guest recovery sequence is out of order when PF/VF communication
breaks due to a GPU fatal error
As a temporary work around, perform a KFD style reset (Initiate reset
request from the guest) inside the pf2vf thread on FED.
Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com>
Reviewed-by: Zhigang Luo <zhigang.luo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Yang Wang <kevinyang.wang@amd.com>
Date: Thu Jul 4 13:48:19 2024 +0800
drm/amdgpu: remove redundant semicolons in RAS_EVENT_LOG
commit 332210c13ac0595c34516caf9a61430b45e16d21 upstream.
remove redundant semicolons in RAS_EVENT_LOG to avoid
code format check warning.
Fixes: b712d7c20133 ("drm/amdgpu: fix compiler 'side-effect' check issue for RAS_EVENT_LOG()")
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Author: Tao Zhou <tao.zhou1@amd.com>
Date: Thu Jun 6 11:20:57 2024 +0800
drm/amdgpu: set RAS fed status for more cases
[ Upstream commit 09a3d8202df1e9fa1eb5f5f63524c8948275ff4c ]
Indicate fatal error for each RAS block and NBIO.
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Mon May 13 15:22:42 2024 +0800
drm/amdgpu: the warning dereferencing obj for nbio_v7_4
[ Upstream commit d190b459b2a4304307c3468ed97477b808381011 ]
if ras_manager obj null, don't print NBIO err data
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Suggested-by: Tim Huang <Tim.Huang@amd.com>
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tao Zhou <tao.zhou1@amd.com>
Date: Fri May 17 18:04:26 2024 +0800
drm/amdgpu: update type of buf size to u32 for eeprom functions
[ Upstream commit 2aadb520bfacec12527effce3566f8df55e5d08e ]
Avoid overflow issue.
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jesse Zhang <jesse.zhang@amd.com>
Date: Wed May 29 17:29:01 2024 +0800
drm/amdgu: fix Unintentional integer overflow for mall size
[ Upstream commit c09d2eff81a997c169e0cacacd6b60c5e3aa33f2 ]
Potentially overflowing expression mall_size_per_umc * adev->gmc.num_umc with type unsigned int (32 bits, unsigned)
is evaluated using 32-bit arithmetic,and then used in a context that expects an expression of type u64 (64 bits, unsigned).
Signed-off-by: Jesse Zhang <Jesse.Zhang@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>
Author: Lin.Cao <lincao12@amd.com>
Date: Wed Apr 24 11:27:16 2024 +0800
drm/amdkfd: Check debug trap enable before write dbg_ev_file
[ Upstream commit 547033b593063eb85bfdf9b25a5f1b8fd1911be2 ]
In interrupt context, write dbg_ev_file will be run by work queue. It
will cause write dbg_ev_file execution after debug_trap_disable, which
will cause NULL pointer access.
v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.
Signed-off-by: Lin.Cao <lincao12@amd.com>
Reviewed-by: Jonathan Kim <jonathan.kim@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Michael Chen <michael.chen@amd.com>
Date: Fri May 3 15:31:08 2024 -0400
drm/amdkfd: Reconcile the definition and use of oem_id in struct kfd_topology_device
[ Upstream commit 10f624ef239bd136cdcc5bbc626157a57b938a31 ]
Currently oem_id is defined as uint8_t[6] and casted to uint64_t*
in some use case. This would lead code scanner to complain about
access beyond. Re-define it in union to enforce 8-byte size and
alignment to avoid potential issue.
Signed-off-by: Michael Chen <michael.chen@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Tao Zhou <tao.zhou1@amd.com>
Date: Thu Jun 13 14:54:11 2024 +0800
drm/amdkfd: use mode1 reset for RAS poison consumption
[ Upstream commit 4280f60e8e7caa5160135223e486545893bc9013 ]
Per firmware's requirement, replace mode2 with mode1.
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Marek Vasut <marex@denx.de>
Date: Fri May 31 22:33:12 2024 +0200
drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
[ Upstream commit 162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f ]
Make sure the connector is fully initialized before signalling any
HPD events via drm_kms_helper_hotplug_event(), otherwise this may
lead to NULL pointer dereference.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240531203333.277476-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Sui Jingfeng <sui.jingfeng@linux.dev>
Date: Wed May 8 02:00:00 2024 +0800
drm/drm-bridge: Drop conditionals around of_node pointers
[ Upstream commit ad3323a6ccb7d43bbeeaa46d5311c43d5d361fc7 ]
Having conditional around the of_node pointer of the drm_bridge structure
is not necessary, since drm_bridge structure always has the of_node as its
member.
Let's drop the conditional to get a better looks, please also note that
this is following the already accepted commitments. see commit d8dfccde2709
("drm/bridge: Drop conditionals around of_node pointers") for reference.
Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240507180001.1358816-1-sui.jingfeng@linux.dev
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date: Wed Jul 3 22:17:37 2024 +0800
drm/fb-helper: Don't schedule_work() to flush frame buffer during panic()
[ Upstream commit 833cd3e9ad8360785b6c23c82dd3856df00732d9 ]
Sometimes the system [1] hangs on x86 I/O machine checks. However, the
expected behavior is to reboot the system, as the machine check handler
ultimately triggers a panic(), initiating a reboot in the last step.
The root cause is that sometimes the panic() is blocked when
drm_fb_helper_damage() invoking schedule_work() to flush the frame buffer.
This occurs during the process of flushing all messages to the frame
buffer driver as shown in the following call trace:
Machine check occurs [2]:
panic()
console_flush_on_panic()
console_flush_all()
console_emit_next_record()
con->write()
vt_console_print()
hide_cursor()
vc->vc_sw->con_cursor()
fbcon_cursor()
ops->cursor()
bit_cursor()
soft_cursor()
info->fbops->fb_imageblit()
drm_fbdev_generic_defio_imageblit()
drm_fb_helper_damage_area()
drm_fb_helper_damage()
schedule_work() // <--- blocked here
...
emergency_restart() // wasn't invoked, so no reboot.
During panic(), except the panic CPU, all the other CPUs are stopped.
In schedule_work(), the panic CPU requires the lock of worker_pool to
queue the work on that pool, while the lock may have been token by some
other stopped CPU. So schedule_work() is blocked.
Additionally, during a panic(), since there is no opportunity to execute
any scheduled work, it's safe to fix this issue by skipping schedule_work()
on 'oops_in_progress' in drm_fb_helper_damage().
[1] Enable the kernel option CONFIG_FRAMEBUFFER_CONSOLE,
CONFIG_DRM_FBDEV_EMULATION, and boot with the 'console=tty0'
kernel command line parameter.
[2] Set 'panic_timeout' to a non-zero value before calling panic().
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Yudong Wang <yudong.wang@intel.com>
Tested-by: Yudong Wang <yudong.wang@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240703141737.75378-1-qiuxu.zhuo@intel.com
Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Xiaogang Chen <xiaogang.chen@amd.com>
Date: Mon May 13 23:54:25 2024 -0500
drm/kfd: Correct pinned buffer handling at kfd restore and validate process
[ Upstream commit f326d7cc745683f53052b84382bd10567b45cd5d ]
This reverts commit 8a774fe912ff ("drm/amdgpu: avoid restore process run into dead loop")
since buffer got pinned is not related whether it needs mapping
And skip buffer validation at kfd driver if the buffer has been pinned.
Signed-off-by: Xiaogang Chen <Xiaogang.Chen@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Haoran Liu <liuhaoran14@163.com>
Date: Wed Nov 29 03:34:05 2023 -0800
drm/meson: plane: Add error handling
[ Upstream commit 3c28b239620e249b68beeca17f429e317fa6b8d4 ]
This patch adds robust error handling to the meson_plane_create
function in drivers/gpu/drm/meson/meson_plane.c. The function
previously lacked proper handling for potential failure scenarios
of the drm_universal_plane_init call.
Signed-off-by: Haoran Liu <liuhaoran14@163.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231129113405.33057-1-liuhaoran14@163.com
[narmstrong: fixe the commit subject]
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231129113405.33057-1-liuhaoran14@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Francois Dugast <francois.dugast@intel.com>
Date: Thu May 2 14:43:10 2024 +0200
drm/xe/gt: Fix assert in L3 bank mask generation
[ Upstream commit 8ad0e1810bf23f22cedb8a2664548b15646570c7 ]
What needs to be asserted is that the pattern fits in the number
of bits provided by the user in patternbits, otherwise it would
be truncated when replicated according to the mask, which is
likely not the intended use of this function.
The pattern argument is a bitmap so use find_last_bit() instead
of fls(). The bit position starts at index 0 so remove "or equal"
from the comparison. XE_MAX_L3_BANK_MASK_BITS would be the
returned value if the pattern is 0, which can be the case on some
platforms.
v2: Check the result does not overflow the array (Lucas De Marchi)
v3: Use __fls() for long and handle mask == 0 (Lucas De Marchi)
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240502124311.159695-1-francois.dugast@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Karthik Poosa <karthik.poosa@intel.com>
Date: Fri Apr 19 18:29:45 2024 +0530
drm/xe/hwmon: Remove unwanted write permission for currN_label
[ Upstream commit 515f08972355e160f896f612347121fbb685e740 ]
Change umode of currN_label from 0644 to 0444 as write permission
not needed for label.
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240419125945.4085629-1-karthik.poosa@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthew Brost <matthew.brost@intel.com>
Date: Tue Jun 11 07:40:50 2024 -0700
drm/xe: Add GuC state asserts to deregister_exec_queue
[ Upstream commit 716ce587a81e6165a4133ea32f63f3d69f80e1e7 ]
Will help catch bugs in GuC state machine.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240611144053.2805091-9-matthew.brost@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Date: Fri Jun 7 18:27:41 2024 +0530
drm/xe: Check valid domain is passed in xe_force_wake_ref
[ Upstream commit 35feb8dbbca627d118ccc1f2111841788c142703 ]
Assert domain is not XE_FORCEWAKE_ALL.
v2
- use domain != XE_FORCEWAKE_ALL (Michal)
v3
- Fix commit description.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240607125741.1407331-2-himal.prasad.ghimiray@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Fri May 3 15:03:31 2024 -0400
drm/xe: Demote CCS_MODE info to debug only
[ Upstream commit e9c190b9b8e7e07bc0ef0ba9b87321fa37b456c5 ]
This information is printed in any gt_reset, which actually
occurs in any runtime resume, what can be so verbose in
production build. Let's demote it to debug only.
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503190331.6690-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthew Brost <matthew.brost@intel.com>
Date: Mon Jun 3 11:18:24 2024 -0700
drm/xe: Don't overmap identity VRAM mapping
[ Upstream commit 6d3581edffea0b3a64b0d3094d3f09222e0024f7 ]
Overmapping the identity VRAM mapping is triggering hardware bugs on
certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM
chunk.
v2:
- Always use 2M pages for last chunk (Fei Yang)
- break loop when 2M pages are used
- Add assert for usable_size being 2M aligned
v3:
- Fix checkpatch
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Fei Yang <fei.yang@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Fei Yang <fei.yang@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603181824.1927675-1-matthew.brost@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Date: Fri Jun 7 18:27:40 2024 +0530
drm/xe: Ensure caller uses sole domain for xe_force_wake_assert_held
[ Upstream commit 3541e19d0d3b30ad099c0c26ba87561aedfbd652 ]
xe_force_wake_assert_held() is designed to confirm a particular
forcewake domain's wakefulness; it doesn't verify the wakefulness of
multiple domains. Make sure the caller doesn't input multiple
domains(XE_FORCEWAKE_ALL) as a parameter.
v2
- use domain != XE_FORCEWAKE_ALL (Michal)
v3
- Add kernel-doc
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240607125741.1407331-1-himal.prasad.ghimiray@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Date: Wed May 8 20:52:16 2024 +0530
drm/xe: Fix the warning conditions
[ Upstream commit 4c0be90e6874b8af30541c37689780fc7c8276c9 ]
The maximum timeout display uses in xe_pcode_request is 3 msec, add the
warning in cases the function is misused with higher timeouts.
Add a warning if pcode_try_request is not passed the timeout parameter
greater than 0.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240508152216.3263109-3-himal.prasad.ghimiray@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Nirmoy Das <nirmoy.das@intel.com>
Date: Mon Jun 3 10:17:23 2024 +0200
drm/xe: Use missing lock in relay_needs_worker
[ Upstream commit 8b01f970ee890574b3607c85781354a765c849bd ]
Add missing lock that is protecting relay->incoming_actions.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603081723.18775-1-nirmoy.das@intel.com
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Philip Mueller <philm@manjaro.org>
Date: Mon Jul 15 11:57:49 2024 +0700
drm: panel-orientation-quirks: Add quirk for OrangePi Neo
[ Upstream commit d60c429610a14560085d98fa6f4cdb43040ca8f0 ]
This adds a DMI orientation quirk for the OrangePi Neo Linux Gaming
Handheld.
Signed-off-by: Philip Mueller <philm@manjaro.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240715045818.1019979-1-philm@manjaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Chao Yu <chao@kernel.org>
Date: Tue May 21 14:23:18 2024 +0800
f2fs: fix to do sanity check on blocks for inline_data inode
[ Upstream commit c240c87bcd44a1a2375fc8ef8c645d1f1fe76466 ]
inode can be fuzzed, so it can has F2FS_INLINE_DATA flag and valid
i_blocks/i_nid value, this patch supports to do extra sanity check
to detect such corrupted state.
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Amir Goldstein <amir73il@gmail.com>
Date: Sun May 12 13:30:07 2024 +0200
fsnotify: clear PARENT_WATCHED flags lazily
[ Upstream commit 172e422ffea20a89bfdc672741c1aad6fbb5044e ]
In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode->i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.
Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.
When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Wed Jun 5 22:13:15 2024 +0200
gfs2: Revert "Add quota_change type"
[ Upstream commit ec4b5200c8af9ce021399d3192b3379c089396c3 ]
Commit 432928c93779 ("gfs2: Add quota_change type") makes the incorrect
assertion that function do_qc() should behave differently in the two
contexts it is used in, but that isn't actually true. In all cases,
do_qc() grabs a "reference" when it starts using a slot in the per-node
quota changes file, and it releases that "reference" when no more
residual changes remain. Revert that broken commit.
There are some remaining issues with function do_qc() which are
addressed in the next commit.
This reverts commit 432928c9377959684c748a9bc6553ed2d3c2ea4f.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date: Thu Jun 6 11:12:56 2024 -0500
hwmon: (k10temp) Check return value of amd_smn_read()
[ Upstream commit c2d79cc5455c891de6c93e1e0c73d806e299c54f ]
Check the return value of amd_smn_read() before saving a value. This
ensures invalid values aren't saved or used.
There are three cases here with slightly different behavior:
1) read_tempreg_nb_zen():
This is a function pointer which does not include a return code.
In this case, set the register value to 0 on failure. This
enforces Read-as-Zero behavior.
2) k10temp_read_temp():
This function does have return codes, so return the error code
from the failed register read. Continued operation is not
necessary, since there is no valid data from the register.
Furthermore, if the register value was set to 0, then the
following operation would underflow.
3) k10temp_get_ccd_support():
This function reads the same register from multiple CCD
instances in a loop. And a bitmask is formed if a specific bit
is set in each register instance. The loop should continue on a
failed register read, skipping the bit check.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20240606-fix-smn-bad-read-v4-3-ffde21931c3f@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Richard Maina <quic_rmaina@quicinc.com>
Date: Wed May 29 11:09:55 2024 -0700
hwspinlock: Introduce hwspin_lock_bust()
[ Upstream commit 7c327d56597d8de1680cf24e956b704270d3d84a ]
When a remoteproc crashes or goes down unexpectedly this can result in
a state where locks held by the remoteproc will remain locked possibly
resulting in deadlock. This new API hwspin_lock_bust() allows
hwspinlock implementers to define a bust operation for freeing previously
acquired hwspinlocks after verifying ownership of the acquired lock.
Signed-off-by: Richard Maina <quic_rmaina@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-1-c8b924ffa5a2@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Fri Aug 2 16:22:14 2024 +0100
i2c: Fix conditional for substituting empty ACPI functions
[ Upstream commit f17c06c6608ad4ecd2ccf321753fb511812d821b ]
Add IS_ENABLED(CONFIG_I2C) to the conditional around a bunch of ACPI
functions.
The conditional around these functions depended only on CONFIG_ACPI.
But the functions are implemented in I2C core, so are only present if
CONFIG_I2C is enabled.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Wed Aug 14 13:16:49 2024 +0100
i2c: Use IS_REACHABLE() for substituting empty ACPI functions
commit 71833e79a42178d8a50b5081c98c78ace9325628 upstream.
Replace IS_ENABLED() with IS_REACHABLE() to substitute empty stubs for:
i2c_acpi_get_i2c_resource()
i2c_acpi_client_count()
i2c_acpi_find_bus_speed()
i2c_acpi_new_device_by_fwnode()
i2c_adapter *i2c_acpi_find_adapter_by_handle()
i2c_acpi_waive_d0_probe()
commit f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI
functions") partially fixed this conditional to depend on CONFIG_I2C,
but used IS_ENABLED(), which is wrong since CONFIG_I2C is tristate.
CONFIG_ACPI is boolean but let's also change it to use IS_REACHABLE()
to future-proof it against becoming tristate.
Somehow despite testing various combinations of CONFIG_I2C and CONFIG_ACPI
we missed the combination CONFIG_I2C=m, CONFIG_ACPI=y.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI functions")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202408141333.gYnaitcV-lkp@intel.com/
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Author: Shannon Nelson <shannon.nelson@amd.com>
Date: Tue May 28 17:02:53 2024 -0700
ionic: fix potential irq name truncation
[ Upstream commit 3eb76e71b16e8ba5277bf97617aef51f5e64dbe4 ]
Address a warning about potential string truncation based on the
string buffer sizes. We can add some hints to the string format
specifier to set limits on the resulting possible string to
squelch the complaints.
Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://lore.kernel.org/r/20240529000259.25775-2-shannon.nelson@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun Sep 8 07:56:41 2024 +0200
Linux 6.10.9
Link: https://lore.kernel.org/r/20240905093732.239411633@linuxfoundation.org
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240905163542.314666063@linuxfoundation.org
Tested-by: Ronald Warsow <rwarsow@gmx.de>
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Mark Brown <broonie@kernel.org>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Peter Schneider <pschneider1968@googlemail.com>
Tested-by: Ron Economos <re@w6rz.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Author: Ricardo Ribalda <ribalda@chromium.org>
Date: Thu Apr 4 17:56:18 2024 +0000
media: uvcvideo: Enforce alignment of frame and interval
[ Upstream commit c8931ef55bd325052ec496f242aea7f6de47dc9c ]
Struct uvc_frame and interval (u32*) are packaged together on
streaming->formats on a single contiguous allocation.
Right now they are allocated right after uvc_format, without taking into
consideration their required alignment.
This is working fine because both structures have a field with a
pointer, but it will stop working when the sizeof() of any of those
structs is not a multiple of the sizeof(void*).
Enforce that alignment during the allocation.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20240404-uvc-align-v2-1-9e104b0ecfbd@chromium.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date: Tue May 28 14:00:51 2024 +0300
media: v4l2-cci: Always assign *val
[ Upstream commit 7417b1b1f36cc214dc458e717278a27a912d3b51 ]
Always assign *val to 0 in cci_read(). This has the benefit of not
requiring initialisation of the variables data is read to using
cci_read(). Once smatch is fixed, it could catch the use of uninitialised
reads.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: David Howells <dhowells@redhat.com>
Date: Wed Aug 28 22:02:45 2024 +0100
mm: Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range()
commit c26096ee0278c5e765009c5eee427bbafe6dc090 upstream.
Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range()
rather than truncate_inode_pages_range(). The latter clears the
invalidated bit of a partial pages rather than discarding it entirely.
This causes copy_file_range() to fail on cifs because the partial pages at
either end of the destination range aren't evicted and reread, but rather
just partly cleared.
This causes generic/075 and generic/112 xfstests to fail.
Fixes: 74e797d79cf1 ("mm: Provide a means of invalidation without using launder_folio")
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/20240828210249.1078637-5-dhowells@redhat.com
cc: Matthew Wilcox <willy@infradead.org>
cc: Miklos Szeredi <miklos@szeredi.hu>
cc: Trond Myklebust <trond.myklebust@hammerspace.com>
cc: Christoph Hellwig <hch@lst.de>
cc: Andrew Morton <akpm@linux-foundation.org>
cc: Alexander Viro <viro@zeniv.linux.org.uk>
cc: Christian Brauner <brauner@kernel.org>
cc: Jeff Layton <jlayton@kernel.org>
cc: linux-mm@kvack.org
cc: linux-fsdevel@vger.kernel.org
cc: netfs@lists.linux.dev
cc: v9fs@lists.linux.dev
cc: linux-afs@lists.infradead.org
cc: ceph-devel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-nfs@vger.kernel.org
cc: devel@lists.orangefs.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Author: Yevgeny Kliteynik <kliteyn@nvidia.com>
Date: Tue Jul 30 09:16:32 2024 +0300
net/mlx5: DR, Fix 'stack guard page was hit' error in dr_rule
[ Upstream commit 94a3ad6c081381fa9ee523781789802b4ed00faf ]
This patch reduces the size of hw_ste_arr_optimized array that is
allocated on stack from 640 bytes (5 match STEs + 5 action STES)
to 448 bytes (2 match STEs + 5 action STES).
This fixes the 'stack guard page was hit' issue, while still fitting
majority of the usecases (up to 2 match STEs).
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
Link: https://patch.msgid.link/20240730061638.1831002-4-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Dragos Tatulea <dtatulea@nvidia.com>
Date: Tue Jun 4 00:22:07 2024 +0300
net/mlx5e: SHAMPO, Fix incorrect page release
[ Upstream commit 70bd03b89f20b9bbe51a7f73c4950565a17a45f7 ]
Under the following conditions:
1) No skb created yet
2) header_size == 0 (no SHAMPO header)
3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the
last page fragment of a SHAMPO header page)
a new skb is formed with a page that is NOT a SHAMPO header page (it
is a regular data page). Further down in the same function
(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from
header_index is released. This is wrong and it leads to SHAMPO header
pages being released more than once.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://lore.kernel.org/r/20240603212219.1037656-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jason Xing <kernelxing@tencent.com>
Date: Fri May 31 23:46:34 2024 +0800
net: remove NULL-pointer net parameter in ip_metrics_convert
[ Upstream commit 61e2bbafb00e4b9a5de45e6448a7b6b818658576 ]
When I was doing some experiments, I found that when using the first
parameter, namely, struct net, in ip_metrics_convert() always triggers NULL
pointer crash. Then I digged into this part, realizing that we can remove
this one due to its uselessness.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Valentin Schneider <vschneid@redhat.com>
Date: Thu Jun 6 17:11:37 2024 +0200
net: tcp/dccp: prepare for tw_timer un-pinning
[ Upstream commit b334b924c9b709bc969644fb5c406f5c9d01dceb ]
The TCP timewait timer is proving to be problematic for setups where
scheduler CPU isolation is achieved at runtime via cpusets (as opposed to
statically via isolcpus=domains).
What happens there is a CPU goes through tcp_time_wait(), arming the
time_wait timer, then gets isolated. TCP_TIMEWAIT_LEN later, the timer
fires, causing interference for the now-isolated CPU. This is conceptually
similar to the issue described in commit e02b93124855 ("workqueue: Unbind
kworkers before sending them to exit()")
Move inet_twsk_schedule() to within inet_twsk_hashdance(), with the ehash
lock held. Expand the lock's critical section from inet_twsk_kill() to
inet_twsk_deschedule_put(), serializing the scheduling vs descheduling of
the timer. IOW, this prevents the following race:
tcp_time_wait()
inet_twsk_hashdance()
inet_twsk_deschedule_put()
del_timer_sync()
inet_twsk_schedule()
Thanks to Paolo Abeni for suggesting to leverage the ehash lock.
This also restores a comment from commit ec94c2696f0b ("tcp/dccp: avoid
one atomic operation for timewait hashdance") as inet_twsk_hashdance() had
a "Step 1" and "Step 3" comment, but the "Step 2" had gone missing.
inet_twsk_deschedule_put() now acquires the ehash spinlock to synchronize
with inet_twsk_hashdance_schedule().
To ease possible regression search, actual un-pin is done in next patch.
Link: https://lore.kernel.org/all/ZPhpfMjSiHVjQkTk@localhost.localdomain/
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Co-developed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: ZHANG Yuntian <yt@radxa.com>
Date: Sat Aug 3 15:46:51 2024 +0800
net: usb: qmi_wwan: add MeiG Smart SRM825L
[ Upstream commit 1ca645a2f74a4290527ae27130c8611391b07dbf ]
Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=2dee ProdID=4d22 Rev= 4.14
S: Manufacturer=MEIG
S: Product=LTE-A Module
S: SerialNumber=6f345e48
C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
Signed-off-by: ZHANG Yuntian <yt@radxa.com>
Link: https://patch.msgid.link/D1EB81385E405DFE+20240803074656.567061-1-yt@radxa.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date: Fri May 3 15:57:05 2024 +0300
PCI: al: Check IORESOURCE_BUS existence during probe
[ Upstream commit a9927c2cac6e9831361e43a14d91277818154e6a ]
If IORESOURCE_BUS is not provided in Device Tree it will be fabricated in
of_pci_parse_bus_range(), so NULL pointer dereference should not happen
here.
But that's hard to verify, so check for NULL anyway.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Link: https://lore.kernel.org/linux-pci/20240503125705.46055-1-amishin@t-argos.ru
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Léo DUBOIN <lduboin@freebox.fr>
Date: Thu Apr 25 15:58:02 2024 +0200
pinctrl: core: reset gpio_device in loop in pinctrl_pins_show()
[ Upstream commit 9dfbcf2fc566c0be2de1c7685f29effd25696b75 ]
We were not resetting the pointer to the associated gpio_device once
we are done displaying a pin's information.
This meant that once we reached the end of a gpio-range, if there
were pins right after it that did not belong to any known range,
they would be associated with the previous range's gpio device.
This resulted in those pins appearing as <4294966783:old_gdev> instead
of the expected <0:?> (due to gpio_num being -1).
Signed-off-by: Léo DUBOIN <lduboin@freebox.fr>
Link: https://lore.kernel.org/r/c40d0634abefa19e689ffd450e0f48a8d63c4fc4.1714049455.git.lduboin@freebox.fr
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date: Thu May 30 18:38:48 2024 +0100
pinctrl: renesas: rzg2l: Validate power registers for SD and ETH
[ Upstream commit a3a632ed87f0913779092c30bd0ea7dfd81601f3 ]
On RZ/V2H(P) SoC, the power registers for SD and ETH do not exist,
resulting in invalid register offsets. Ensure that the register offsets
are valid before any read/write operations are performed. If the power
registers are not available, both SD and ETH will be set to '0'.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S
Link: https://lore.kernel.org/r/20240530173857.164073-7-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ben Walsh <ben@jubnut.com>
Date: Wed Jun 5 07:33:48 2024 +0100
platform/chrome: cros_ec_lpc: MEC access can use an AML mutex
[ Upstream commit 60c7df66450e3a7821a8d68496c20c95de6a15c5 ]
Framework Laptops have ACPI code which accesses the MEC memory. It
uses an AML mutex to prevent concurrent access. But the cros_ec_lpc
driver was not aware of this mutex. The ACPI code and LPC driver both
attempted to talk to the EC at the same time, messing up communication
with the EC.
Allow the LPC driver MEC code to find and use the AML mutex.
Tested-by: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Ben Walsh <ben@jubnut.com>
Link: https://lore.kernel.org/r/20240605063351.14836-3-ben@jubnut.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Tue Jul 23 18:54:50 2024 +0530
platform/x86/amd/pmf: Add new ACPI ID AMDI0107
[ Upstream commit 942810c0e89277d738b7f1b6f379d0a5877999f6 ]
Add new ACPI ID AMDI0107 used by upcoming AMD platform to the PMF
supported list of devices.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20240723132451.3488326-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Luke D. Jones <luke@ljones.dev>
Date: Mon Jul 29 14:08:31 2024 +1200
platform/x86/amd: pmf: Add quirk for ROG Ally X
[ Upstream commit 4c83ee4bf32ea8e57ae2321906c067d69ad7c41b ]
The ASUS ROG Ally X has the same issue as the G14 where it advertises
SPS support but doesn't use it.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20240729020831.28117-1-luke@ljones.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Ken Sloat <ksloat@designlinxhs.com>
Date: Thu Dec 15 16:07:15 2022 +0000
pwm: xilinx: Fix u32 overflow issue in 32-bit width PWM mode.
[ Upstream commit 56f45266df67aa0f5b2a6881c8c4d16dbfff6b7d ]
This timer HW supports 8, 16 and 32-bit timer widths. This
driver currently uses a u32 to store the max possible value
of the timer. However, statements perform addition of 2 in
xilinx_pwm_apply() when calculating the period_cycles and
duty_cycles values. Since priv->max is a u32, this will
result in an overflow to 1 which will not only be incorrect
but fail on range comparison. This results in making it
impossible to set the PWM in this timer mode.
There are two obvious solutions to the current problem:
1. Cast each instance where overflow occurs to u64.
2. Change priv->max from a u32 to a u64.
Solution #1 requires more code modifications, and leaves
opportunity to introduce similar overflows if other math
statements are added in the future. These may also go
undetected if running in non 32-bit timer modes.
Solution #2 is the much smaller and cleaner approach and
thus the chosen method in this patch.
This was tested on a Zynq UltraScale+ with multiple
instances of the PWM IP.
Signed-off-by: Ken Sloat <ksloat@designlinxhs.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
Link: https://lore.kernel.org/r/SJ0P222MB0107490C5371B848EF04351CA1E19@SJ0P222MB0107.NAMP222.PROD.OUTLOOK.COM
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: John Allen <john.allen@amd.com>
Date: Thu Jun 6 20:33:11 2024 +0000
RAS/AMD/ATL: Validate address map when information is gathered
[ Upstream commit d5811a165caf63a69cd8ae11156b8587cc57d1d1 ]
Validate address maps at the time the information is gathered as the
address map will not change during translation.
Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Link: https://lore.kernel.org/r/20240606203313.51197-5-john.allen@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Frederic Weisbecker <frederic@kernel.org>
Date: Thu Apr 25 16:18:35 2024 +0200
rcu/nocb: Remove buggy bypass lock contention mitigation
[ Upstream commit e4f78057291608f6968a6789c5ebb3bde7d95504 ]
The bypass lock contention mitigation assumes there can be at most
2 contenders on the bypass lock, following this scheme:
1) One kthread takes the bypass lock
2) Another one spins on it and increment the contended counter
3) A third one (a bypass enqueuer) sees the contended counter on and
busy loops waiting on it to decrement.
However this assumption is wrong. There can be only one CPU to find the
lock contended because call_rcu() (the bypass enqueuer) is the only
bypass lock acquire site that may not already hold the NOCB lock
beforehand, all the other sites must first contend on the NOCB lock.
Therefore step 2) is impossible.
The other problem is that the mitigation assumes that contenders all
belong to the same rdp CPU, which is also impossible for a raw spinlock.
In theory the warning could trigger if the enqueuer holds the bypass
lock and another CPU flushes the bypass queue concurrently but this is
prevented from all flush users:
1) NOCB kthreads only flush if they successfully _tried_ to lock the
bypass lock. So no contention management here.
2) Flush on callbacks migration happen remotely when the CPU is offline.
No concurrency against bypass enqueue.
3) Flush on deoffloading happen either locally with IRQs disabled or
remotely when the CPU is not yet online. No concurrency against
bypass enqueue.
4) Flush on barrier entrain happen either locally with IRQs disabled or
remotely when the CPU is offline. No concurrency against
bypass enqueue.
For those reasons, the bypass lock contention mitigation isn't needed
and is even wrong. Remove it but keep the warning reporting a contended
bypass lock on a remote CPU, to keep unexpected contention awareness.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Michael Margolin <mrgolin@amazon.com>
Date: Mon May 13 06:46:30 2024 +0000
RDMA/efa: Properly handle unexpected AQ completions
[ Upstream commit 2d0e7ba468eae365f3c4bc9266679e1f8dd405f0 ]
Do not try to handle admin command completion if it has an unexpected
command id and print a relevant error message.
Reviewed-by: Firas Jahjah <firasj@amazon.com>
Reviewed-by: Yehuda Yitschak <yehuday@amazon.com>
Signed-off-by: Michael Margolin <mrgolin@amazon.com>
Link: https://lore.kernel.org/r/20240513064630.6247-1-mrgolin@amazon.com
Reviewed-by: Gal Pressman <gal.pressman@linux.dev>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Wed Jun 5 23:53:15 2024 +0300
regmap: spi: Fix potential off-by-one when calculating reserved size
[ Upstream commit d4ea1d504d2701ba04412f98dc00d45a104c52ab ]
If we ever meet a hardware that uses weird register bits and padding,
we may end up in off-by-one error since x/8 + y/8 might not be equal
to (x + y)/8 in some cases.
bits pad x/8+y/8 (x+y)/8
4..7 0..3 0 0 // x + y from 4 up to 7
4..7 4..7 0 1 // x + y from 8 up to 11
4..7 8..11 1 1 // x + y from 12 up to 15
8..15 0..7 1 1 // x + y from 8 up to 15
8..15 8..15 2 2 // x + y from 16 up to 23
Fix this by using (x+y)/8.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date: Mon May 20 13:27:24 2024 +0200
remoteproc: mediatek: Zero out only remaining bytes of IPI buffer
[ Upstream commit 9dbd9962cfe56d210be5232349851420b5f9c8f6 ]
In scp_ipi_handler(), instead of zeroing out the entire shared
buffer, which may be as large as 600 bytes, overwrite it with the
received data, then zero out only the remaining bytes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240520112724.139945-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Richard Maina <quic_rmaina@quicinc.com>
Date: Wed May 29 11:09:58 2024 -0700
remoteproc: qcom_q6v5_pas: Add hwspinlock bust on stop
[ Upstream commit 568b13b65078e2b557ccf47674a354cecd1db641 ]
When remoteproc goes down unexpectedly this results in a state where any
acquired hwspinlocks will remain locked possibly resulting in deadlock.
In order to ensure all locks are freed we include a call to
qcom_smem_bust_hwspin_lock_by_host() during remoteproc shutdown.
For qcom_q6v5_pas remoteprocs, each remoteproc has an assigned smem
host_id. Remoteproc can pass this id to smem to try and bust the lock on
remoteproc stop.
This edge case only occurs with q6v5_pas watchdog crashes. The error
fatal case has handling to clear the hwspinlock before the error fatal
interrupt is triggered.
Signed-off-by: Richard Maina <quic_rmaina@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-4-c8b924ffa5a2@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Joshua Aberback <joshua.aberback@amd.com>
Date: Wed Apr 10 16:25:41 2024 -0400
Revert "drm/amd/display: Fix incorrect pointer assignment"
[ Upstream commit 0c9c0674f81add3edb2bb992b3e89be8a44f03db ]
This reverts commit 0a571e8657c40047e6602466abfcb6514a391041.
[Why]
The change being reverted incorrectly assumes that a pointer type was
intended, however copying to a new structure is correct. As well, there
is no compiler error, it was instead an error in the testing framework
being used.
Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Joshua Aberback <joshua.aberback@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Peter Wang <peter.wang@mediatek.com>
Date: Fri Jul 12 17:45:06 2024 +0800
scsi: ufs: core: Bypass quick recovery if force reset is needed
[ Upstream commit 022587d8aec3da1d1698ddae9fb8cfe35f3ad49c ]
If force_reset is true, bypass quick recovery. This will shorten error
recovery time.
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Link: https://lore.kernel.org/r/20240712094506.11284-1-peter.wang@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-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>
Author: Kyoungrul Kim <k831.kim@samsung.com>
Date: Wed Jul 10 08:25:20 2024 +0900
scsi: ufs: core: Check LSDBS cap when !mcq
[ Upstream commit 0c60eb0cc320fffbb8b10329d276af14f6f5e6bf ]
If the user sets use_mcq_mode to 0, the host will try to activate the LSDB
mode unconditionally even when the LSDBS of device HCI cap is 1. This makes
commands time out and causes device probing to fail.
To prevent that problem, check the LSDBS cap when MCQ is not supported.
Signed-off-by: Kyoungrul Kim <k831.kim@samsung.com>
Link: https://lore.kernel.org/r/20240709232520epcms2p8ebdb5c4fccc30a6221390566589bf122@epcms2p8
Reviewed-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>
Author: Paolo Abeni <pabeni@redhat.com>
Date: Sat Jul 27 11:04:01 2024 +0200
selftests: mptcp: add explicit test case for remove/readd
[ Upstream commit b5e2fb832f48bc01d937a053e0550a1465a2f05d ]
Delete and re-create a signal endpoint and ensure that the PM
actually deletes and re-create the subflow.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stable-dep-of: 1c2326fcae4f ("selftests: mptcp: join: check re-adding init endp with != id")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date: Wed Aug 28 08:14:30 2024 +0200
selftests: mptcp: join: check re-adding init endp with != id
[ Upstream commit 1c2326fcae4f0c5de8ad0d734ced43a8e5f17dac ]
The initial subflow has a special local ID: 0. It is specific per
connection.
When a global endpoint is deleted and re-added later, it can have a
different ID, but the kernel should still use the ID 0 if it corresponds
to the initial address.
This test validates this behaviour: the endpoint linked to the initial
subflow is removed, and re-added with a different ID.
Note that removing the initial subflow will not decrement the 'subflows'
counters, which corresponds to the *additional* subflows. On the other
hand, when the same endpoint is re-added, it will increment this
counter, as it will be seen as an additional subflow this time.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date: Wed Aug 28 08:14:38 2024 +0200
selftests: mptcp: join: check re-re-adding ID 0 signal
[ Upstream commit f18fa2abf81099d822d842a107f8c9889c86043c ]
This test extends "delete re-add signal" to validate the previous
commit: when the 'signal' endpoint linked to the initial subflow (ID 0)
is re-added multiple times, it will re-send the ADD_ADDR with id 0. The
client should still be able to re-create this subflow, even if the
add_addr_accepted limit has been reached as this special address is not
considered as a new address.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date: Mon Aug 19 21:45:20 2024 +0200
selftests: mptcp: join: check re-using ID of unused ADD_ADDR
[ Upstream commit a13d5aad4dd9a309eecdc33cfd75045bd5f376a3 ]
This test extends "delete re-add signal" to validate the previous
commit. An extra address is announced by the server, but this address
cannot be used by the client. The result is that no subflow will be
established to this address.
Later, the server will delete this extra endpoint, and set a new one,
with a valid address, but re-using the same ID. Before the previous
commit, the server would not have been able to announce this new
address.
While at it, extra checks have been added to validate the expected
numbers of MPJ, ADD_ADDR and RM_ADDR.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-2-38035d40de5b@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: 1c2326fcae4f ("selftests: mptcp: join: check re-adding init endp with != id")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date: Mon Aug 19 21:45:24 2024 +0200
selftests: mptcp: join: test for flush/re-add endpoints
commit e06959e9eebdfea4654390f53b65cff57691872e upstream.
After having flushed endpoints that didn't cause the creation of new
subflows, it is important to check endpoints can be re-created, re-using
previously used IDs.
Before the previous commit, the client would not have been able to
re-create the subflow that was previously rejected.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Fixes: 06faa2271034 ("mptcp: remove multi addresses and subflows in PM")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-6-38035d40de5b@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date: Wed Aug 28 08:14:36 2024 +0200
selftests: mptcp: join: validate event numbers
[ Upstream commit 20ccc7c5f7a3aa48092441a4b182f9f40418392e ]
This test extends "delete and re-add" and "delete re-add signal" to
validate the previous commit: the number of MPTCP events are checked to
make sure there are no duplicated or unexpected ones.
A new helper has been introduced to easily check these events. The
missing events have been added to the lib.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Fixes: b911c97c7dc7 ("mptcp: add netlink event support")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Casey Schaufler <casey@schaufler-ca.com>
Date: Wed Jun 5 15:41:50 2024 -0700
smack: tcp: ipv4, fix incorrect labeling
[ Upstream commit 2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550 ]
Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
* Take two machines, let's call them C and S,
with active Smack in the default state
(no settings, no rules, no labeled hosts, only builtin labels)
* At S, add Smack rule 'foo bar w'
(labels 'foo' and 'bar' are instantiated at S at this moment)
* At S, at label 'bar', launch a program
that listens for incoming tcp/ipv4 connections
* From C, at label 'foo', connect to the listener at S.
(label 'foo' is instantiated at C at this moment)
Connection succeedes and works.
* Send some data in both directions.
* Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims.
Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Paulo Alcantara <pc@manguebit.com>
Date: Thu Aug 1 18:12:39 2024 -0300
smb: client: fix FSCTL_GET_REPARSE_POINT against NetApp
[ Upstream commit ddecea00f87f0c46e9c8339a7c89fb2ff891521a ]
NetApp server requires the file to be open with FILE_READ_EA access in
order to support FSCTL_GET_REPARSE_POINT, otherwise it will return
STATUS_INVALID_DEVICE_REQUEST. It doesn't make any sense because
there's no requirement for FILE_READ_EA bit to be set nor
STATUS_INVALID_DEVICE_REQUEST being used for something other than
"unsupported reparse points" in MS-FSA.
To fix it and improve compatibility, set FILE_READ_EA & SYNCHRONIZE
bits to match what Windows client currently does.
Tested-by: Sebastian Steinbeisser <Sebastian.Steinbeisser@lrz.de>
Acked-by: Tom Talpey <tom@talpey.com>
Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Chris Lew <quic_clew@quicinc.com>
Date: Wed May 29 11:09:57 2024 -0700
soc: qcom: smem: Add qcom_smem_bust_hwspin_lock_by_host()
[ Upstream commit 2e3f0d693875db698891ffe89a18121bda5b95b8 ]
Add qcom_smem_bust_hwspin_lock_by_host to enable remoteproc to bust the
hwspin_lock owned by smem. In the event the remoteproc crashes
unexpectedly, the remoteproc driver can invoke this API to try and bust
the hwspin_lock and release the lock if still held by the remoteproc
device.
Signed-off-by: Chris Lew <quic_clew@quicinc.com>
Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-3-c8b924ffa5a2@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Devyn Liu <liudingyuan@huawei.com>
Date: Tue Jul 30 11:20:39 2024 +0800
spi: hisi-kunpeng: Add validation for the minimum value of speed_hz
[ Upstream commit c3c4f22b7c814a6ee485ce294065836f8ede30fa ]
The speed specified by the user is used to calculate the clk_div based
on the max_speed_hz in hisi_calc_effective_speed. A very low speed
value can lead to a clk_div larger than the variable range. Avoid this
by setting the min_speed_hz so that such a small speed value is
rejected. __spi_validate() in spi.c will return -EINVAL for the
specified speed_hz lower than min_speed_hz.
Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
Reviewed-by: Jay Fang <f.fangjian@huawei.com>
Link: https://patch.msgid.link/20240730032040.3156393-2-liudingyuan@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Jun 3 15:51:06 2024 +0000
tcp: annotate data-races around tw->tw_ts_recent and tw->tw_ts_recent_stamp
[ Upstream commit 69e0b33a7fce4d96649b9fa32e56b696921aa48e ]
These fields can be read and written locklessly, add annotations
around these minor races.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Tue May 28 18:52:13 2024 +0200
thermal: trip: Use READ_ONCE() for lockless access to trip properties
[ Upstream commit a52641bc6293a24f25956a597e7f32148b0e2bb8 ]
When accessing trip temperature and hysteresis without locking, it is
better to use READ_ONCE() to prevent compiler optimizations possibly
affecting the read from being applied.
Of course, for the READ_ONCE() to be effective, WRITE_ONCE() needs to
be used when updating their values.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date: Fri May 10 20:12:41 2024 +0000
usb: typec: ucsi: Fix null pointer dereference in trace
[ Upstream commit 99516f76db48e1a9d54cdfed63c1babcee4e71a5 ]
ucsi_register_altmode checks IS_ERR for the alt pointer and treats
NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,
ucsi_register_displayport returns NULL which causes a NULL pointer
dereference in trace. Rather than return NULL, call
typec_port_register_altmode to register DisplayPort alternate mode
as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240510201244.2968152-2-jthies@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Simon Holesch <simon@holesch.de>
Date: Sun May 19 16:15:38 2024 +0200
usbip: Don't submit special requests twice
[ Upstream commit 8b6b386f9aa936ed0c190446c71cf59d4a507690 ]
Skip submitting URBs, when identical requests were already sent in
tweak_special_requests(). Instead call the completion handler directly
to return the result of the URB.
Even though submitting those requests twice should be harmless, there
are USB devices that react poorly to some duplicated requests.
One example is the ChipIdea controller implementation in U-Boot: The
second SET_CONFIGURATION request makes U-Boot disable and re-enable all
endpoints. Re-enabling an endpoint in the ChipIdea controller, however,
was broken until U-Boot commit b272c8792502 ("usb: ci: Fix gadget
reinit").
Signed-off-by: Simon Holesch <simon@holesch.de>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Reviewed-by: Hongren Zheng <i@zenithal.me>
Tested-by: Hongren Zheng <i@zenithal.me>
Link: https://lore.kernel.org/r/20240519141922.171460-1-simon@holesch.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Heng Qi <hengqi@linux.alibaba.com>
Date: Thu Aug 1 21:23:37 2024 +0800
virtio-net: check feature before configuring the vq coalescing command
[ Upstream commit b50f2af9fbc5c00103ca8b72752b15310bd77762 ]
Virtio spec says:
The driver MUST have negotiated the VIRTIO_NET_F_VQ_NOTF_COAL
feature when issuing commands VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET
and VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET.
So we add the feature negotiation check to
virtnet_send_{r,t}x_ctrl_coal_vq_cmd as a basis for the next bugfix patch.
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date: Sat May 4 11:52:09 2024 -0700
wifi: ath11k: initialize 'ret' in ath11k_qmi_load_file_target_mem()
[ Upstream commit 199f149e97dc7be80e5eed4b232529c1d1aa8055 ]
smatch flagged the following issue:
drivers/net/wireless/ath/ath11k/qmi.c:2401 ath11k_qmi_load_file_target_mem() error: uninitialized symbol 'ret'.
The reality is that 'ret' is initialized in every path through
ath11k_qmi_load_file_target_mem() except one, the case where the input
'len' is 0, and hence the "while (remaining)" loop is never entered.
But to make sure this case is also handled, add an initializer to the
declaration of 'ret'.
No functional changes, compile tested only.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240504-qmi_load_file_target_mem-v1-2-069fc44c45eb@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date: Tue May 7 13:45:03 2024 +0300
wifi: ath12k: initialize 'ret' in ath12k_dp_rxdma_ring_sel_config_wcn7850()
[ Upstream commit 3b9344740843d965e9e37fba30620b3b1c0afa4f ]
smatch flagged the following issue:
drivers/net/wireless/ath/ath12k/dp_rx.c:4065 ath12k_dp_rxdma_ring_sel_config_wcn7850() error: uninitialized symbol 'ret'.
In ath12k_dp_rxdma_ring_sel_config_wcn7850() if it were ever the case
that ab->hw_params->num_rxdma_per_pdev was 0 then 'ret' would be
uninitialized when it is returned. This should never be the case, but
to be safe and to quiet smatch, add an initializer to the declaration
of 'ret'.
No functional changes, compile tested only.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240504-ath12k_dp_rxdma_ring_sel_config_wcn7850-ret-v1-2-44d2843a2857@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date: Sat May 4 11:52:08 2024 -0700
wifi: ath12k: initialize 'ret' in ath12k_qmi_load_file_target_mem()
[ Upstream commit bb0b0a6b96e6de854cb1e349e17bd0e8bf421a59 ]
smatch flagged the following issue:
drivers/net/wireless/ath/ath12k/qmi.c:2619 ath12k_qmi_load_file_target_mem() error: uninitialized symbol 'ret'.
The reality is that 'ret' is initialized in every path through
ath12k_qmi_load_file_target_mem() except one, the case where the input
'len' is 0, and hence the "while (remaining)" loop is never entered.
But to make sure this case is also handled, add an initializer to the
declaration of 'ret'.
No functional changes, compile tested only.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240504-qmi_load_file_target_mem-v1-1-069fc44c45eb@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Jun 7 20:17:17 2024 +0200
wifi: cfg80211: make hash table duplicates more survivable
[ Upstream commit 7f12e26a194d0043441f870708093d9c2c3bad7d ]
Jiazi Li reported that they occasionally see hash table duplicates
as evidenced by the WARN_ON() in rb_insert_bss() in this code. It
isn't clear how that happens, nor have I been able to reproduce it,
but if it does happen, the kernel crashes later, when it tries to
unhash the entry that's now not hashed.
Try to make this situation more survivable by removing the BSS from
the list(s) as well, that way it's fully leaked here (as had been
the intent in the hash insert error path), and no longer reachable
through the list(s) so it shouldn't be unhashed again later.
Link: https://lore.kernel.org/r/20231026013528.GA24122@Jiazi.Li
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240607181726.36835-2-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon May 6 21:11:59 2024 +0200
wifi: cfg80211: restrict operation during radar detection
[ Upstream commit 2d33ecf5d0148671c74e68e18755b9411a7ba923 ]
Just like it's not currently possible to start radar
detection while already operating, it shouldn't be
possible to start operating while radar detection is
running. Fix that.
Also, improve the check whether operating (carrier
might not be up if e.g. attempting to join IBSS).
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506211158.ae8dca3d0d6c.I7c70a66a5fbdbc63a78fee8a34f31d1995491bc3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon May 27 19:06:08 2024 +0300
wifi: iwlwifi: mvm: use only beacon BSS load for active links
[ Upstream commit d9b7531fe98a0c2a0387270557cf0a514c28dd28 ]
For active links, don't take information that may have been
received in probe responses, as those are not protected. For
inactive links, there may not be a choice.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240527190228.6947dc462fa9.I2076961211d6785c8a15b4308e0e87a413148222@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Date: Fri May 10 17:06:40 2024 +0300
wifi: iwlwifi: remove fw_running op
[ Upstream commit 37733bffda3285d18bd1d72c14b3a1cf39c56a5e ]
fw_running assumes that memory can be retrieved only after alive.
This assumption is no longer true as we support dump before alive.
To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
bit in trans status is set before dumping instead of the prior check.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu May 23 12:11:40 2024 +0200
wifi: mac80211: check ieee80211_bss_info_change_notify() against MLD
[ Upstream commit a0ca76e5b7d550fcd74753d5fdaaf23f1a9bfdb4 ]
It's not valid to call ieee80211_bss_info_change_notify() with
an sdata that's an MLD, remove the FIXME comment (it's not true)
and add a warning.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240523121140.97a589b13d24.I61988788d81fb3cf97a490dfd3167f67a141d1fd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Zong-Zhe Yang <kevin_yang@realtek.com>
Date: Thu May 9 17:06:43 2024 +0800
wifi: rtw89: ser: avoid multiple deinit on same CAM
[ Upstream commit cea4066588308fa932b6b03486c608efff1d761c ]
We did deinit CAM in STA iteration in VIF loop. But, the STA iteration
missed to restrict the target VIF. So, if there are multiple VIFs, we
would deinit a CAM multiple times. Now, fix it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240509090646.35304-2-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Author: Perry Yuan <perry.yuan@amd.com>
Date: Mon Jul 29 08:46:26 2024 +0200
x86/CPU/AMD: Add models 0x60-0x6f to the Zen5 range
[ Upstream commit bf5641eccf71bcd13a849930e190563c3a19815d ]
Add some new Zen5 models for the 0x1A family.
[ bp: Merge the 0x60 and 0x70 ranges. ]
Signed-off-by: Perry Yuan <perry.yuan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20240729064626.24297-1-bp@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>