- Linux-stable-mirror - lists.linaro.org

[PATCH v3 00/15] media: stm32: introduction of CSI / DCMIPP for STM32MP25

by Alain Volmat

This series introduces the camera pipeline support for the STM32MP25 SOC. The STM32MP25 has 3 pipelines, fed from a single camera input which can be either parallel or csi. This series adds the basic support for the 1st pipe (dump) which, in term of features is same as the one featured on the STM32MP13 SOC. It focuses on introduction of the CSI input stage for the DCMIPP, and the CSI specific new control code for the DCMIPP. One of the subdev of the DCMIPP, dcmipp_parallel is now renamed as dcmipp_input since it allows to not only control the parallel but also the csi interface. Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> --- Changes in v3: * stm32-csi: use clk_bulk api * stm32-csiL perform reset control within the probe - Link to v2: https://lore.kernel.org/r/20241105-csi_dcmipp_mp25-v2-0-b9fc8a7273c2@foss.s… --- Alain Volmat (15): media: stm32: dcmipp: correct dma_set_mask_and_coherent mask value dt-bindings: media: add description of stm32 csi media: stm32: csi: addition of the STM32 CSI driver media: stm32: dcmipp: use v4l2_subdev_is_streaming media: stm32: dcmipp: replace s_stream with enable/disable_streams media: stm32: dcmipp: rename dcmipp_parallel into dcmipp_input media: stm32: dcmipp: add support for csi input into dcmipp-input media: stm32: dcmipp: add bayer 10~14 bits formats media: stm32: dcmipp: add 1X16 RGB / YUV formats support media: stm32: dcmipp: avoid duplicated format on enum in bytecap media: stm32: dcmipp: fill media ctl hw_revision field dt-bindings: media: add the stm32mp25 compatible of DCMIPP media: stm32: dcmipp: add core support for the stm32mp25 arm64: dts: st: add csi & dcmipp node in stm32mp25 arm64: dts: st: enable imx335/csi/dcmipp pipeline on stm32mp257f-ev1 .../devicetree/bindings/media/st,stm32-dcmipp.yaml | 53 +- .../bindings/media/st,stm32mp25-csi.yaml | 125 +++ MAINTAINERS | 8 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 23 + arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 85 ++ drivers/media/platform/st/stm32/Kconfig | 14 + drivers/media/platform/st/stm32/Makefile | 1 + drivers/media/platform/st/stm32/stm32-csi.c | 1137 ++++++++++++++++++++ .../media/platform/st/stm32/stm32-dcmipp/Makefile | 2 +- .../st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 128 ++- .../st/stm32/stm32-dcmipp/dcmipp-byteproc.c | 119 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-common.h | 4 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-core.c | 116 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-input.c | 540 ++++++++++ .../st/stm32/stm32-dcmipp/dcmipp-parallel.c | 440 -------- 15 files changed, 2219 insertions(+), 576 deletions(-) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241007-csi_dcmipp_mp25-7779601f57da Best regards, -- Alain Volmat <alain.volmat(a)foss.st.com>

3 months

1
1
0 0

[PATCH] arm64: uaccess: Restrict user access to kernel memory in __copy_user_flushcache()

by Gax-c

From: Zichen Xie <zichenxie0106(a)gmail.com> raw_copy_from_user() do not call access_ok(), so this code allowed userspace to access any virtual memory address. Change it to copy_from_user(). Fixes: 9e94fdade4d8 ("arm64: uaccess: simplify __copy_user_flushcache()") Signed-off-by: Zichen Xie <zichenxie0106(a)gmail.com> Cc: stable(a)vger.kernel.org --- arch/arm64/lib/uaccess_flushcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/lib/uaccess_flushcache.c b/arch/arm64/lib/uaccess_flushcache.c index 7510d1a23124..fb138a3934db 100644 --- a/arch/arm64/lib/uaccess_flushcache.c +++ b/arch/arm64/lib/uaccess_flushcache.c @@ -24,7 +24,7 @@ unsigned long __copy_user_flushcache(void *to, const void __user *from, { unsigned long rc; - rc = raw_copy_from_user(to, from, n); + rc = copy_from_user(to, from, n); /* See above */ dcache_clean_pop((unsigned long)to, (unsigned long)to + n - rc); -- 2.34.1

3 months

3
2
0 0

[PATCH] perf: arm-ni: Fix attribute_group definition syntax

by Thomas Weißschuh

The sentinel NULL value does not make sense and is a syntax error in a structure definition. Remove it. Fixes: 4d5a7680f2b4 ("perf: Add driver for Arm NI-700 interconnect PMU") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Cc stable because although this commit is not yet released, it most likely will be by the time it hits mainline. --- drivers/perf/arm-ni.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/perf/arm-ni.c b/drivers/perf/arm-ni.c index 90fcfe693439ef3e18e23c6351433ac3c5ea78b5..fd7a5e60e96302fada29cd44e7bf9c582e93e4ce 100644 --- a/drivers/perf/arm-ni.c +++ b/drivers/perf/arm-ni.c @@ -247,7 +247,6 @@ static struct attribute *arm_ni_other_attrs[] = { static const struct attribute_group arm_ni_other_attr_group = { .attrs = arm_ni_other_attrs, - NULL }; static const struct attribute_group *arm_ni_attr_groups[] = { --- base-commit: 4a5df37964673effcd9f84041f7423206a5ae5f2 change-id: 20241117-arm-ni-syntax-250a83058529 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

3 months

2
2
0 0

[PATCH 6.1.y 0/3] ext4: Fix warning related to siphash and ext4 filesystem mounting

by Vasiliy Kovalev

Found by syzbot (https://syzkaller.appspot.com/bug?extid=9177d065333561cd6fd0): EXT4-fs (loop0): encrypted files will use data=ordered instead of data journaling mode EXT4-fs (loop0): 1 truncate cleaned up EXT4-fs (loop0): mounted filesystem without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4245 at fs/crypto/fname.c:567 fscrypt_fname_siphash+0xb9/0xf0 Modules linked in: CPU: 1 PID: 4245 Comm: syz-executor375 Not tainted 6.1.116-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:fscrypt_fname_siphash+0xb9/0xf0 fs/crypto/fname.c:567 Call Trace: <TASK> __ext4fs_dirhash+0xdd2/0x14c0 fs/ext4/hash.c:268 ext4fs_dirhash+0x1b8/0x320 fs/ext4/hash.c:322 htree_dirblock_to_tree+0x723/0x10d0 fs/ext4/namei.c:1125 ext4_htree_fill_tree+0x73d/0x13f0 fs/ext4/namei.c:1220 ext4_dx_readdir fs/ext4/dir.c:605 [inline] ext4_readdir+0x2e87/0x3880 fs/ext4/dir.c:142 iterate_dir+0x224/0x560 __do_sys_getdents64 fs/readdir.c:369 [inline] __se_sys_getdents64+0x209/0x4f0 fs/readdir.c:354 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3b/0xb0 arch/x86/entry/common.c:81 </TASK> These patches address a warning encountered when mounting ext4 filesystems with the default hash version set to SIPHASH while the casefold feature is not enabled. The warning occurs due to incorrect error handling and setup of the default hash version. [PATCH 1/3 ] ext4: factor out ext4_hash_info_init() Simplifies the ext4 filesystem setup by factoring out the ext4_hash_info_init function, with no functional change. [PATCH 2/3] ext4: filesystems without casefold feature cannot be mounted with siphash Ensures that ext4 filesystems with the default hash set to SIPHASH cannot be mounted if the casefold feature is not enabled. [PATCH 3/3] ext4: fix error message when rejecting the default hash Corrects the error message logic for rejecting filesystems with the default SIPHASH hash version, ensuring the error message doesn't incorrectly reference the casefold setup. Also moves the check to ext4_hash_info_init to ensure consistency.

3 months

1
3
0 0

[PATCH 6.6.y 0/2] ext4: Fix warning related to siphash and ext4 filesystem mounting

by Vasiliy Kovalev

Found by syzbot (https://syzkaller.appspot.com/bug?extid=340581ba9dceb7e06fb3) log (6.6.61): EXT4-fs (loop0): encrypted files will use data=ordered instead of data journaling mode EXT4-fs (loop0): 1 truncate cleaned up EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3775 at fs/crypto/fname.c:567 fscrypt_fname_siphash (fs/crypto/fname.c:567) CPU: 0 PID: 3775 Comm: fscrypt_fname_s Not tainted 6.6.61-un-def-alt1.kasan #1 RIP: 0010:fscrypt_fname_siphash (fs/crypto/fname.c:567 (discriminator 1)) Call Trace: <TASK> __ext4fs_dirhash (fs/ext4/hash.c:268) ext4fs_dirhash (fs/ext4/hash.c:322) htree_dirblock_to_tree (fs/ext4/namei.c:1127) ext4_htree_fill_tree (fs/ext4/namei.c:1222) ext4_readdir (fs/ext4/dir.c:608 fs/ext4/dir.c:142) iterate_dir (fs/readdir.c:106) __x64_sys_getdents64 (fs/readdir.c:406 fs/readdir.c:390 fs/readdir.c:390) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81) ... </TASK> These patches address a warning encountered when mounting ext4 filesystems with the default hash version set to SIPHASH while the casefold feature is not enabled. The warning occurs due to incorrect error handling and setup of the default hash version. [PATCH 1/2] ext4: filesystems without casefold feature cannot be mounted with siphash Ensures that ext4 filesystems with the default hash set to SIPHASH cannot be mounted if the casefold feature is not enabled. [PATCH 2/2] ext4: fix error message when rejecting the default hash Corrects the error message logic for rejecting filesystems with the default SIPHASH hash version, ensuring the error message doesn't incorrectly reference the casefold setup. Also moves the check to ext4_hash_info_init to ensure consistency.

3 months

1
2
0 0

[PATCH 6.1.y 0/4] fix error handling in mmap_region() and refactor (hotfixes)

by Lorenzo Stoakes

Critical fixes for mmap_region(), backported to 6.1.y. Some notes on differences from upstream: * We do NOT take commit 0fb4a7ad270b ("mm: refactor map_deny_write_exec()"), as this refactors code only introduced in 6.2. * We make reference in "mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling" to parisc, but the referenced functionality does not exist in this kernel. * In this kernel is_shared_maywrite() does not exist and the code uses VM_SHARED to determine whether mapping_map_writable() / mapping_unmap_writable() should be invoked. This backport therefore follows suit. * The vma_dummy_vm_ops static global doesn't exist in this kernel, so we use a local static variable in mmap_file() and vma_close(). * Each version of these series is confronted by a slightly different mmap_region(), so we must adapt the change for each stable version. The approach remains the same throughout, however, and we correctly avoid closing the VMA part way through any __mmap_region() operation. * This version of the kernel uses mas_preallocate() rather than the vma_iter_prealloc() wrapper and mas_destroy() rather than the vma_iter_free() wrapper, however the logic of rearranging the positioning of these remains the same, as well as avoiding the iterator leak we previously had on some error paths. Lorenzo Stoakes (4): mm: avoid unsafe VMA hook invocation when error arises on mmap hook mm: unconditionally close VMAs on error mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling mm: resolve faulty mmap_region() error path behaviour arch/arm64/include/asm/mman.h | 10 ++- include/linux/mman.h | 7 +- mm/internal.h | 19 ++++++ mm/mmap.c | 119 ++++++++++++++++++---------------- mm/nommu.c | 9 ++- mm/shmem.c | 3 - mm/util.c | 33 ++++++++++ 7 files changed, 129 insertions(+), 71 deletions(-) -- 2.47.0

3 months

4
11
0 0

[PATCH 6.1] fs/ntfs3: Add rough attr alloc_size check

by Bin Lan

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> [ Upstream commit c4a8ba334262e9a5c158d618a4820e1b9c12495c ] Reported-by: syzbot+c6d94bedd910a8216d25(a)syzkaller.appspotmail.com Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> --- fs/ntfs3/record.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ntfs3/record.c b/fs/ntfs3/record.c index 7ab452710572..0cdff04d084b 100644 --- a/fs/ntfs3/record.c +++ b/fs/ntfs3/record.c @@ -329,6 +329,9 @@ struct ATTRIB *mi_enum_attr(struct mft_inode *mi, struct ATTRIB *attr) if (attr->nres.c_unit) return NULL; + + if (alloc_size > mi->sbi->volume.size) + return NULL; } return attr; -- 2.43.0

3 months

1
0
0 0

[PATCH 6.1.y] hv_netvsc: Don't free decrypted memory

by Xiangyu Chen

From: Rick Edgecombe <rick.p.edgecombe(a)intel.com> [ Upstream commit bbf9ac34677b57506a13682b31a2a718934c0e31 ] In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The netvsc driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. Signed-off-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy(a)linux.intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Link: https://lore.kernel.org/r/20240311161558.1310-4-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Message-ID: <20240311161558.1310-4-mhklinux(a)outlook.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Xiangyu: Bp to fix CVE: CVE-2024-36911 resolved the conflicts] Signed-off-by: Xiangyu Chen <xiangyu.chen(a)windriver.com> --- drivers/net/hyperv/netvsc.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c index 3a834d4e1c84..3735bfbd9e8e 100644 --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -155,15 +155,19 @@ static void free_netvsc_device(struct rcu_head *head) kfree(nvdev->extension); - if (nvdev->recv_original_buf) - vfree(nvdev->recv_original_buf); - else - vfree(nvdev->recv_buf); + if (!nvdev->recv_buf_gpadl_handle.decrypted) { + if (nvdev->recv_original_buf) + vfree(nvdev->recv_original_buf); + else + vfree(nvdev->recv_buf); + } - if (nvdev->send_original_buf) - vfree(nvdev->send_original_buf); - else - vfree(nvdev->send_buf); + if (!nvdev->send_buf_gpadl_handle.decrypted) { + if (nvdev->send_original_buf) + vfree(nvdev->send_original_buf); + else + vfree(nvdev->send_buf); + } bitmap_free(nvdev->send_section_map); -- 2.43.0

3 months

1
0
0 0

[PATCH 6.1] gpiolib: cdev: Fix use after free in lineinfo_changed_notify

by Xiangyu Chen

From: Zhongqiu Han <quic_zhonhan(a)quicinc.com> [ Upstream commit 02f6b0e1ec7e0e7d059dddc893645816552039da ] The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Zhongqiu Han <quic_zhonhan(a)quicinc.com> Link: https://lore.kernel.org/r/20240505141156.2944912-1-quic_zhonhan@quicinc.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: Xiangyu Chen <xiangyu.chen(a)windriver.com> --- drivers/gpio/gpiolib-cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 55f640ef3fee..897d20996a8c 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -2860,9 +2860,9 @@ static int gpio_chrdev_release(struct inode *inode, struct file *file) struct gpio_chardev_data *cdev = file->private_data; struct gpio_device *gdev = cdev->gdev; - bitmap_free(cdev->watched_lines); blocking_notifier_chain_unregister(&gdev->notifier, &cdev->lineinfo_changed_nb); + bitmap_free(cdev->watched_lines); put_device(&gdev->dev); kfree(cdev); -- 2.43.0

3 months

1
0
0 0

[PATCH 6.6] drm/amd/pm: Vangogh: Fix kernel memory out of bounds write

by Bin Lan

From: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> [ Upstream commit 4aa923a6e6406b43566ef6ac35a3d9a3197fa3e8 ] KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] <TASK> [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather "brute force" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: 41cec40bc9ba ("drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics") Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Evan Quan <evan.quan(a)amd.com> Cc: Wenyou Yang <WenYou.Yang(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Link: https://lore.kernel.org/r/20241025145639.19124-1-tursulin@igalia.com Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703) Cc: stable(a)vger.kernel.org # v6.6+ Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> --- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c index f46cda889483..454216bd6f1d 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c @@ -256,10 +256,9 @@ static int vangogh_tables_init(struct smu_context *smu) goto err0_out; smu_table->metrics_time = 0; - if (smu_version >= 0x043F3E00) - smu_table->gpu_metrics_table_size = sizeof(struct gpu_metrics_v2_3); - else - smu_table->gpu_metrics_table_size = sizeof(struct gpu_metrics_v2_2); + smu_table->gpu_metrics_table_size = sizeof(struct gpu_metrics_v2_2); + smu_table->gpu_metrics_table_size = max(smu_table->gpu_metrics_table_size, sizeof(struct gpu_metrics_v2_3)); + smu_table->gpu_metrics_table_size = max(smu_table->gpu_metrics_table_size, sizeof(struct gpu_metrics_v2_4)); smu_table->gpu_metrics_table = kzalloc(smu_table->gpu_metrics_table_size, GFP_KERNEL); if (!smu_table->gpu_metrics_table) goto err1_out; -- 2.43.0

3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror