summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-03-27sparc32: Do not select GENERIC_ISA_DMASam Ravnborg1-4/+0
[ Upstream commit 99bd9a4f87926e12ce60796d7db1d6b226aca5e3 ] sparc32 do not support generic isa dma, so do not select the symbol. This fixes the following warnings: dma.c:70:5: error: no previous prototype for 'request_dma' [-Werror=missing-prototypes] dma.c:88:6: error: no previous prototype for 'free_dma' [-Werror=missing-prototypes] Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 0fcb70851fbf ("Makefile.extrawarn: turn on missing-prototypes globally") Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Andreas Larsson <andreas@gaisler.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/r/20240224-sam-fix-sparc32-all-builds-v2-5-1f186603c5c4@ravnborg.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27mtd: maps: sun_uflash: Declare uflash_devinit staticSam Ravnborg1-1/+1
[ Upstream commit 6892982316846d4c40d12b0641d59519d868a784 ] This fixes the following warning: sun_uflash.c:50:5: error: no previous prototype for 'uflash_devinit' Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 0fcb70851fbf ("Makefile.extrawarn: turn on missing-prototypes globally") Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Andreas Larsson <andreas@gaisler.com> Cc: "David S. Miller" <davem@davemloft.net> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/r/20240224-sam-fix-sparc32-all-builds-v2-3-1f186603c5c4@ravnborg.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27sparc32: Use generic cmpdi2/ucmpdi2 variantsSam Ravnborg4-50/+4
[ Upstream commit 802a8874a3889a4a0d218d4f73e5855c96d5b8a8 ] Use the generic variants - the implementation is the same. As a nice side-effect fix the following warnings: cmpdi2.c: warning: no previous prototype for '__cmpdi2' [-Wmissing-prototypes] ucmpdi2.c: warning: no previous prototype for '__ucmpdi2' [-Wmissing-prototypes] Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 0fcb70851fbf ("Makefile.extrawarn: turn on missing-prototypes globally") Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk> Tested-by: Maciej W. Rozycki <macro@orcam.me.uk> # build-tested Cc: "David S. Miller" <davem@davemloft.net> Cc: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Tested-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/r/20240224-sam-fix-sparc32-all-builds-v2-1-1f186603c5c4@ravnborg.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: lp8788: Fully initialize backlight_properties during probeDaniel Thompson1-0/+1
[ Upstream commit 392346827fbe8a7fd573dfb145170d7949f639a6 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: c5a51053cf3b ("backlight: add new lp8788 backlight driver") Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220153532.76613-4-daniel.thompson@linaro.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: lm3639: Fully initialize backlight_properties during probeDaniel Thompson1-0/+1
[ Upstream commit abb5a5d951fbea3feb5c4ba179b89bb96a1d3462 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 0f59858d5119 ("backlight: add new lm3639 backlight driver") Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220153532.76613-3-daniel.thompson@linaro.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: da9052: Fully initialize backlight_properties during probeDaniel Thompson1-0/+1
[ Upstream commit 0285e9efaee8276305db5c52a59baf84e9731556 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 6ede3d832aaa ("backlight: add driver for DA9052/53 PMIC v1") Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220153532.76613-2-daniel.thompson@linaro.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: lm3630a: Don't set bl->props.brightness in get_brightnessLuca Weiss1-10/+4
[ Upstream commit 4bf7ddd2d2f0f8826f25f74c7eba4e2c323a1446 ] There's no need to set bl->props.brightness, the get_brightness function is just supposed to return the current brightness and not touch the struct. With that done we can also remove the 'goto out' and just return the value. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220-lm3630a-fixups-v1-2-9ca62f7e4a33@z3ntu.xyz Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: lm3630a: Initialize backlight_properties on initLuca Weiss1-0/+1
[ Upstream commit ad9aeb0e3aa90ebdad5fabf9c21783740eb95907 ] The backlight_properties struct should be initialized to zero before using, otherwise there will be some random values in the struct. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220-lm3630a-fixups-v1-1-9ca62f7e4a33@z3ntu.xyz Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: ktz8866: Correct the check for of_property_read_u32Jianhua Lu1-3/+3
[ Upstream commit f1ac3c9825f99c93a9833beee6b78aa386e55b0b ] of_property_read_u32 returns 0 when success, so reverse the return value to get the true value. Fixes: f8449c8f7355 ("backlight: ktz8866: Add support for Kinetic KTZ8866 backlight") Signed-off-by: Jianhua Lu <lujianhua000@gmail.com> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240129122829.16248-1-lujianhua000@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27backlight: hx8357: Fix potential NULL pointer dereferenceAndy Shevchenko1-4/+6
[ Upstream commit b1ba8bcb2d1ffce11b308ce166c9cc28d989e3b9 ] The "im" pins are optional. Add missing check in the hx8357_probe(). Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/642e1230-3358-4006-a17f-3f297897ae74@moroto.mountain Fixes: 7d84a63a39b7 ("backlight: hx8357: Convert to agnostic GPIO API") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240114143921.550736-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27leds: sgm3140: Add missing timer cleanup and flash gpio controlOndrej Jirman1-0/+3
[ Upstream commit 205c29887a333ee4b37596e6533373e38cb23947 ] Enabling strobe and then setting brightness to 0 causes the driver to enter invalid state after strobe end timer fires. We should cancel strobe mode resources when changing brightness (aka torch mode). Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver") Signed-off-by: Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20240217191133.1757553-1-megi@xff.cz Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27leds: aw2013: Unlock mutex before destroying itGeorge Stark1-0/+1
[ Upstream commit 6969d0a2ba1adc9ba6a49b9805f24080896c255c ] In the probe() callback in case of error mutex is destroyed being locked which is not allowed so unlock the mutex before destroying. Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231214173614.2820929-2-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27RISC-V: KVM: Forward SEED CSR access to user spaceAnup Patel1-0/+13
[ Upstream commit d808f0b1be4888a87524164bc7dad2242734de38 ] The SEED CSR access from VS/VU mode (guest) will always trap to HS-mode (KVM) when Zkr extension is available to the Guest/VM. Forward this CSR access to KVM user space so that it can be emulated based on the method chosen by VMM. Fixes: f370b4e668f0 ("RISC-V: KVM: Allow scalar crypto extensions for Guest/VM") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27powerpc/4xx: Fix warp_gpio_leds build failureMichael Ellerman1-0/+1
[ Upstream commit 5b9e00a6004cf837c43fdb8d5290df619de78024 ] The 44x/warp_defconfig build fails with: arch/powerpc/platforms/44x/warp.c:109:15: error: variable ‘warp_gpio_leds’ has initializer but incomplete type 109 | static struct platform_device warp_gpio_leds = { | ^~~~~~~~~~~~~~~ Fix it by including platform_device.h. Fixes: ef175b29a242 ("of: Stop circularly including of_device.h and of_platform.h") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240305123410.3306253-3-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27powerpc/embedded6xx: Fix no previous prototype for avr_uart_send() etc.Michael Ellerman2-3/+3
[ Upstream commit 20933531be0577cdd782216858c26150dbc7936f ] Move the prototypes into mpc10x.h which is included by all the relevant C files, fixes: arch/powerpc/platforms/embedded6xx/ls_uart.c:59:6: error: no previous prototype for 'avr_uart_configure' arch/powerpc/platforms/embedded6xx/ls_uart.c:82:6: error: no previous prototype for 'avr_uart_send' Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240305123410.3306253-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27power: supply: mm8013: fix "not charging" detectionThomas Weißschuh1-11/+2
[ Upstream commit cd38a0acca734a1117663d6f0da579d3965b6c93 ] The charge_behaviours property is meant as a control-knob that can be changed by the user. Page 23 of [0] which documents the flag CHG_INH as follows: CHG_INH : Charge Inhibit When the current is more than or equal to charge threshold current, charge inhibit temperature (upper/lower limit) ：1 charge permission temperature or the current is less than charge threshold current ：0 So this is pure read-only information which is better represented as POWER_SUPPLY_STATUS_NOT_CHARGING. [0] https://product.minebeamitsumi.com/en/product/category/ics/battery/fuel_gauge/parts/download/__icsFiles/afieldfile/2023/07/12/1_download_01_12.pdf Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240303-power_supply-charge_behaviour_prop-v2-1-8ebb0a7c2409@weissschuh.net Fixes: e39257cde7e8 ("power: supply: mm8013: Add more properties") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27mfd: cs42l43: Fix wrong GPIO_FN_SEL and SPI_CLK_CONFIG1 defaultsMaciej Strozek1-2/+2
[ Upstream commit 78334c343bef528b911da83a6b041d15a1a72efb ] Two regs have wrong values in existing fields, change them to match the datasheet. Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver") Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240301101547.2136948-1-mstrozek@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27modules: wait do_free_init correctlyChangbin Du3-4/+18
[ Upstream commit 8f8cd6c0a43ed637e620bbe45a8d0e0c2f4d5130 ] The synchronization here is to ensure the ordering of freeing of a module init so that it happens before W+X checking. It is worth noting it is not that the freeing was not happening, it is just that our sanity checkers raced against the permission checkers which assume init memory is already gone. Commit 1a7b7d922081 ("modules: Use vmalloc special flag") moved calling do_free_init() into a global workqueue instead of relying on it being called through call_rcu(..., do_free_init), which used to allowed us call do_free_init() asynchronously after the end of a subsequent grace period. The move to a global workqueue broke the gaurantees for code which needed to be sure the do_free_init() would complete with rcu_barrier(). To fix this callers which used to rely on rcu_barrier() must now instead use flush_work(&init_free_wq). Without this fix, we still could encounter false positive reports in W+X checking since the rcu_barrier() here can not ensure the ordering now. Even worse, the rcu_barrier() can introduce significant delay. Eric Chanudet reported that the rcu_barrier introduces ~0.1s delay on a PREEMPT_RT kernel. [ 0.291444] Freeing unused kernel memory: 5568K [ 0.402442] Run /sbin/init as init process With this fix, the above delay can be eliminated. Link: https://lkml.kernel.org/r/20240227023546.2490667-1-changbin.du@huawei.com Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag") Signed-off-by: Changbin Du <changbin.du@huawei.com> Tested-by: Eric Chanudet <echanude@redhat.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Xiaoyi Su <suxiaoyi@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27lib/stackdepot: off by one in depot_fetch_stack()Dan Carpenter1-1/+1
[ Upstream commit dc24559472a682eb124e869cb110e7a2fd857322 ] The stack_pools[] array has DEPOT_MAX_POOLS. The "pools_num" tracks the number of pools which are initialized. See depot_init_pool() for more details. If pool_index == pools_num_cached, this will read one element beyond what we want. If not all the pools are initialized, then the pool will be NULL, triggering a WARN(), and if they are all initialized it will read one element beyond the end of the array. Link: https://lkml.kernel.org/r/361ac881-60b7-471f-91e5-5bf8fe8042b2@moroto.mountain Fixes: b29d31885814 ("lib/stackdepot: store free stack records in a freelist") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27lib/stackdepot: fix first entry having a 0-handleOscar Salvador1-7/+9
[ Upstream commit 3ee34eabac2abb6b1b6fcdebffe18870719ad000 ] Patch series "page_owner: print stacks and their outstanding allocations", v10. page_owner is a great debug functionality tool that lets us know about all pages that have been allocated/freed and their specific stacktrace. This comes very handy when debugging memory leaks, since with some scripting we can see the outstanding allocations, which might point to a memory leak. In my experience, that is one of the most useful cases, but it can get really tedious to screen through all pages and try to reconstruct the stack <-> allocated/freed relationship, becoming most of the time a daunting and slow process when we have tons of allocation/free operations. This patchset aims to ease that by adding a new functionality into page_owner. This functionality creates a new directory called 'page_owner_stacks' under 'sys/kernel//debug' with a read-only file called 'show_stacks', which prints out all the stacks followed by their outstanding number of allocations (being that the times the stacktrace has allocated but not freed yet). This gives us a clear and a quick overview of stacks <-> allocated/free. We take advantage of the new refcount_f field that stack_record struct gained, and increment/decrement the stack refcount on every __set_page_owner() (alloc operation) and __reset_page_owner (free operation) call. Unfortunately, we cannot use the new stackdepot api STACK_DEPOT_FLAG_GET because it does not fulfill page_owner needs, meaning we would have to special case things, at which point makes more sense for page_owner to do its own {dec,inc}rementing of the stacks. E.g: Using STACK_DEPOT_FLAG_PUT, once the refcount reaches 0, such stack gets evicted, so page_owner would lose information. This patchset also creates a new file called 'set_threshold' within 'page_owner_stacks' directory, and by writing a value to it, the stacks which refcount is below such value will be filtered out. A PoC can be found below: # cat /sys/kernel/debug/page_owner_stacks/show_stacks > page_owner_full_stacks.txt # head -40 page_owner_full_stacks.txt prep_new_page+0xa9/0x120 get_page_from_freelist+0x801/0x2210 __alloc_pages+0x18b/0x350 alloc_pages_mpol+0x91/0x1f0 folio_alloc+0x14/0x50 filemap_alloc_folio+0xb2/0x100 page_cache_ra_unbounded+0x96/0x180 filemap_get_pages+0xfd/0x590 filemap_read+0xcc/0x330 blkdev_read_iter+0xb8/0x150 vfs_read+0x285/0x320 ksys_read+0xa5/0xe0 do_syscall_64+0x80/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 stack_count: 521 prep_new_page+0xa9/0x120 get_page_from_freelist+0x801/0x2210 __alloc_pages+0x18b/0x350 alloc_pages_mpol+0x91/0x1f0 folio_alloc+0x14/0x50 filemap_alloc_folio+0xb2/0x100 __filemap_get_folio+0x14a/0x490 ext4_write_begin+0xbd/0x4b0 [ext4] generic_perform_write+0xc1/0x1e0 ext4_buffered_write_iter+0x68/0xe0 [ext4] ext4_file_write_iter+0x70/0x740 [ext4] vfs_write+0x33d/0x420 ksys_write+0xa5/0xe0 do_syscall_64+0x80/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 stack_count: 4609 ... ... # echo 5000 > /sys/kernel/debug/page_owner_stacks/set_threshold # cat /sys/kernel/debug/page_owner_stacks/show_stacks > page_owner_full_stacks_5000.txt # head -40 page_owner_full_stacks_5000.txt prep_new_page+0xa9/0x120 get_page_from_freelist+0x801/0x2210 __alloc_pages+0x18b/0x350 alloc_pages_mpol+0x91/0x1f0 folio_alloc+0x14/0x50 filemap_alloc_folio+0xb2/0x100 __filemap_get_folio+0x14a/0x490 ext4_write_begin+0xbd/0x4b0 [ext4] generic_perform_write+0xc1/0x1e0 ext4_buffered_write_iter+0x68/0xe0 [ext4] ext4_file_write_iter+0x70/0x740 [ext4] vfs_write+0x33d/0x420 ksys_pwrite64+0x75/0x90 do_syscall_64+0x80/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 stack_count: 6781 prep_new_page+0xa9/0x120 get_page_from_freelist+0x801/0x2210 __alloc_pages+0x18b/0x350 pcpu_populate_chunk+0xec/0x350 pcpu_balance_workfn+0x2d1/0x4a0 process_scheduled_works+0x84/0x380 worker_thread+0x12a/0x2a0 kthread+0xe3/0x110 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 stack_count: 8641 This patch (of 7): The very first entry of stack_record gets a handle of 0, but this is wrong because stackdepot treats a 0-handle as a non-valid one. E.g: See the check in stack_depot_fetch() Fix this by adding and offset of 1. This bug has been lurking since the very beginning of stackdepot, but no one really cared as it seems. Because of that I am not adding a Fixes tag. Link: https://lkml.kernel.org/r/20240215215907.20121-1-osalvador@suse.de Link: https://lkml.kernel.org/r/20240215215907.20121-2-osalvador@suse.de Co-developed-by: Marco Elver <elver@google.com> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Oscar Salvador <osalvador@suse.de> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Andrey Konovalov <andreyknvl@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: dc24559472a6 ("lib/stackdepot: off by one in depot_fetch_stack()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/xe: Replace 'grouped target' in Makefile with pattern ruleDafna Hirschfeld1-1/+2
[ Upstream commit e62d2e00780b4a465c77d2229837495fcbc480d3 ] Since 'grouped target' is used only in 'make' 4.3, it should be avoided. Replace it with 'multi-target pattern rule' which has the same behavior. Fixes: 9616e74b796c ("drm/xe: Add support for OOB workarounds") Signed-off-by: Dafna Hirschfeld <dhirschfeld@habana.ai> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240302153927.2602241-1-dhirschfeld@habana.ai [ reword commit message ] Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 5224ed586ba7f9bba956655a1bfe5b75df7394d4) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/xe: Fix ref counting leak on page faultMatthew Brost1-2/+4
[ Upstream commit f7da398935f7ddabf1a098714593e032c875cd74 ] If a page fault occurs on VM not in fault a ref can be leaked. Fix this. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240301041036.238471-1-matthew.brost@intel.com (cherry picked from commit 27b5a3f237fe66dbf2288c2b50973aee8a427e41) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: usbtv: Remove useless locks in usbtv_video_free()Benjamin Gaignard1-7/+0
[ Upstream commit 65e6a2773d655172143cc0b927cdc89549842895 ] Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device. Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming. Fixes: c838530d230b ("media: media videobuf2: Be more flexible on the number of queue stored buffers") Fixes: f3d27f34fdd7 ("[media] usbtv: Add driver for Fushicai USBTV007 video frame grabber") Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil: fix minor spelling mistake in log message] Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/msm/dpu: add division of drm_display_mode's hskew parameterPaloma Arellano1-2/+4
[ Upstream commit 551ee0f210991d25f336bc27262353bfe99d3eed ] Setting up the timing engine when the physical encoder has a split role neglects dividing the drm_display_mode's hskew parameter. Let's fix this since this must also be done in preparation for implementing YUV420 over DP. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/579605/ Link: https://lore.kernel.org/r/20240222194025.25329-3-quic_parellan@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/msm/dpu: allow certain formats for CDM for DPPaloma Arellano1-1/+1
[ Upstream commit 32b6ff95b91240e632f55be35c6ccd4bbe7434e4 ] CDM block supports formats other than H1V2 for DP. Since we are now adding support for CDM over DP, relax the checks to allow all other formats for DP other than H1V2. Changes in v2: - Add fixes tag - Move patch to top of series Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block") Signed-off-by: Paloma Arellano <quic_parellan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/579606/ Link: https://lore.kernel.org/r/20240222194025.25329-2-quic_parellan@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27perf vendor events amd: Fix Zen 4 cache latency eventsSandipan Das2-0/+60
[ Upstream commit 498d3486376befe4e82b5334d44bbc86b1982ee4 ] L3PMCx0AC and L3PMCx0AD, used in l3_xi_sampled_latency* events, have a quirk that requires them to be programmed with SliceId set to 0x3. Without this, the events do not count at all and affects dependent metrics such as l3_read_miss_latency. If ThreadMask is not specified, the amd-uncore driver internally sets ThreadMask to 0x3, EnAllCores to 0x1 and EnAllSlices to 0x1 but does not set SliceId. Since SliceId must also be set to 0x3 in this case, specify all the other fields explicitly. E.g. $ sudo perf stat -e l3_xi_sampled_latency.all,l3_xi_sampled_latency_requests.all -a sleep 1 Before: Performance counter stats for 'system wide': 0 l3_xi_sampled_latency.all 0 l3_xi_sampled_latency_requests.all 1.005155399 seconds time elapsed After: Performance counter stats for 'system wide': 921,446 l3_xi_sampled_latency.all 54,210 l3_xi_sampled_latency_requests.all 1.005664472 seconds time elapsed Fixes: 5b2ca349c313 ("perf vendor events amd: Add Zen 4 uncore events") Signed-off-by: Sandipan Das <sandipan.das@amd.com> Reviewed-by: Ian Rogers <irogers@google.com> Cc: ananth.narayan@amd.com Cc: ravi.bangoria@amd.com Cc: eranian@google.com Signed-off-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20240301084431.646221-1-sandipan.das@amd.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27clk: qcom: gcc-ipq5018: fix register offset for GCC_UBI0_AXI_ARES resetGabor Juhos1-1/+1
[ Upstream commit 7d474b43087aa356d714d39870c90d77fc6f1186 ] The current register offset used for the GCC_UBI0_AXI_ARES reset seems wrong. Or at least, the downstream driver uses [1] the same offset which is used for other the GCC_UBI0_*_ARES resets. Change the code to use the same offset used in the downstream driver and also specify the reset bit explicitly to use the same format as the followup entries. 1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L3773 Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Link: https://lore.kernel.org/r/20240225-gcc-ipq5018-register-fixes-v1-3-3c191404d9f0@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27clk: qcom: gcc-ipq5018: fix 'halt_reg' offset of 'gcc_pcie1_pipe_clk'Gabor Juhos1-1/+1
[ Upstream commit 11b752ac5a07cbfd95592fac5237a02f45662926 ] The following table shows the values of the 'halt_reg' and the 'enable_reg' fields from the pcie clocks defined in the current driver: clock halt_reg enable_reg gcc_pcie0_ahb_clk 0x75010 0x75010 gcc_pcie0_aux_clk 0x75014 0x75014 gcc_pcie0_axi_m_clk 0x75008 0x75008 gcc_pcie0_axi_s_bridge_clk 0x75048 0x75048 gcc_pcie0_axi_s_clk 0x7500c 0x7500c gcc_pcie0_pipe_clk 0x75018 0x75018 gcc_pcie1_ahb_clk 0x76010 0x76010 gcc_pcie1_aux_clk 0x76014 0x76014 gcc_pcie1_axi_m_clk 0x76008 0x76008 gcc_pcie1_axi_s_bridge_clk 0x76048 0x76048 gcc_pcie1_axi_s_clk 0x7600c 0x7600c gcc_pcie1_pipe_clk 8* 0x76018 Based on the table, it is quite likely that the pcie0 and the pci1 clocks are using the same register layout, however it seems that the value of the 'halt_reg' field in the 'gcc_pcie1_pipe_clk' clock is wrong. In the downstream driver [1], the same '0x76018' value is used for both the 'halt_reg' and for the 'enable_reg' fields of the 'gcc_pcie1_pipe_clk' clock. Update the current driver to use the same value used downstream as probably that is the correct value. 1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L2316 Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Link: https://lore.kernel.org/r/20240225-gcc-ipq5018-register-fixes-v1-2-3c191404d9f0@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27clk: qcom: gcc-ipq5018: fix 'enable_reg' offset of 'gcc_gmac0_sys_clk'Gabor Juhos1-1/+1
[ Upstream commit f982adcc1b1c02a3114f68ac73c811cbfabe90fa ] The value of the 'enable_reg' field in the 'gcc_gmac0_sys_clk' clock definition seems wrong as it is greater than the 'max_register' value defined in the regmap configuration. Additionally, all other gmac specific branch clock definitions within the driver uses the same value both for the 'enable_reg' and for the 'halt_reg' fields. Due to the lack of documentation the correct value is not known. Looking into the downstream driver does not help either, as that uses the same (presumably wrong) value [1]. Nevertheless, change the 'enable_reg' field of 'gcc_gmac0_sys_clk' to use the value from the 'halt_reg' field so it follows the pattern used in other gmac clock definitions. The change is based on the assumption that the register layout of this clock is the same as the other gmac clocks. 1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L1889 Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Link: https://lore.kernel.org/r/20240225-gcc-ipq5018-register-fixes-v1-1-3c191404d9f0@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27powerpc/hv-gpci: Fix the H_GET_PERF_COUNTER_INFO hcall return value checksKajol Jain1-2/+27
[ Upstream commit ad86d7ee43b22aa2ed60fb982ae94b285c1be671 ] Running event hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ in one of the system throws below error: ---Logs--- # perf list | grep hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel PMU event] # perf stat -v -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Using CPUID 00800200 Control descriptor is not initialized Warning: hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event is not supported by the kernel. failed to read counter hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ Performance counter stats for 'system wide': <not supported> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ 2.000700771 seconds time elapsed The above error is because of the hcall failure as required permission "Enable Performance Information Collection" is not set. Based on current code, single_gpci_request function did not check the error type incase hcall fails and by default returns EINVAL. But we can have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER with detail_rc as GEN_BUF_TOO_SMALL, for which we need to act accordingly. Fix this issue by adding new checks in the single_gpci_request and h_gpci_event_init functions. Result after fix patch changes: # perf stat -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Error: No permission to enable hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event. Fixes: 220a0c609ad1 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") Reported-by: Akanksha J N <akanksha@linux.ibm.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229122847.101162-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27powerpc/pseries: Fix potential memleak in papr_get_attr()Qiheng Lin1-3/+5
[ Upstream commit cda9c0d556283e2d4adaa9960b2dc19b16156bae ] `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure. Fixes: 3c14b73454cf ("powerpc/pseries: Interface to represent PAPR firmware attributes") Signed-off-by: Qiheng Lin <linqiheng@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20221208133449.16284-1-linqiheng@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27powerpc/32: fix ADB_CUDA kconfig warningMichael Ellerman1-1/+1
[ Upstream commit b72c066ba85a131091498a15a62d6068997278a4 ] Fix a (randconfig) kconfig warning by correcting the select statement: WARNING: unmet direct dependencies detected for ADB_CUDA Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && !PPC_PMAC64 [=n] Selected by [y]: - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] && PPC32 [=y] The PPC32 isn't needed because ADB depends on (PPC_PMAC && PPC32). Fixes: a3ef2fef198c ("powerpc/32: Add dependencies of POWER_RESET for pmac32") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Tested: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240211221623.31112-1-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27mfd: cs42l43: Fix wrong register defaultsMaciej Strozek1-34/+34
[ Upstream commit c9e1e505cde1a8ddd0968b4d54ec2ea1937dfe00 ] A few regs have unnecessary values in defaults, change them to match the datasheet Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver") Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240229155616.118457-1-mstrozek@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipHsin-Yi Wang1-5/+7
[ Upstream commit c958e86e9cc1b48cac004a6e245154dfba8e163b ] It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240223212404.3709690-1-hsinyi@chromium.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27gpio: nomadik: fix offset bug in nmk_pmx_set()Théo Lebrun1-2/+4
[ Upstream commit 53cf6b72e074864b94ade97dcb6f30b5ac1a82dc ] Previously, the statement looked like: slpm[x] &= ~BIT(g->grp.pins[i]); Where: - slpm is a unsigned int pointer; - g->grp.pins[i] is a pin number. It can grow to more than 32. The expected shift amount is a pin bank offset. This bug does not occur on every group or pin: the altsetting must be NMK_GPIO_ALT_C and the pin must be 32 or above. It might have occured. For example, in pinctrl-nomadik-db8500.c, pin group i2c3_c_2 has the right altsetting and pins 229 and 230. Fixes: dbfe8ca259e1 ("pinctrl/nomadik: implement pin multiplexing") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://lore.kernel.org/r/20240228-mbly-gpio-v2-5-3ba757474006@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/amd/pm: Fix esm reg mask use to get pcie speedAsad Kamal3-6/+6
[ Upstream commit b485b899e5b8f83723833feca30a1a1e3df778df ] Fix mask used for esm ctrl register to get pcie link speed on smu_v11_0_3, smu_v13_0_2 & smu_v13_0_6 Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support") Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)") Fixes: f1c378593153 ("drm/amd/powerplay: add Arcturus support for gpu metrics export") Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/tests: helpers: Include missing drm_drv headerMaxime Ripard1-0/+2
[ Upstream commit 73984daf07a1a89ace8f0db6dd2d640654ebbbee ] We have a few functions declared in our kunit helpers header, some of them dereferencing the struct drm_driver. However, we don't include the drm_drv.h header file defining that structure, leading to compilation errors if we don't include both headers. Fixes: d98780310719 ("drm/tests: helpers: Allow to pass a custom drm_driver") Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240222-kms-hdmi-connector-state-v7-1-8f4af575fce2@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with ClangStephen Boyd1-1/+1
[ Upstream commit a743f26d03a96593c0f3d05dc26b388f45de67c9 ] Per commit b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with CC_OPTIMIZE_FOR_SIZE"), GCC is silently ignoring `-falign-functions=N` when passed `-Os`, causing functions to be improperly aligned. This doesn't seem to be a problem with Clang though, where enabling CALL_OPS with CC_OPTIMIZE_FOR_SIZE doesn't spit out any warnings at boot about misaligned patch-sites. Only forbid CALL_OPS if GCC is used and we're optimizing for size so that CALL_OPS can be used with clang optimizing for size. Cc: Jason Ling <jasonling@chromium.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Bill Wendling <morbo@google.com> Cc: Justin Stitt <justinstitt@google.com> Cc: llvm@lists.linux.dev Fixes: b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with CC_OPTIMIZE_FOR_SIZE") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240223064032.3463229-1-swboyd@chromium.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: mediatek: vcodec: avoid -Wcast-function-type-strict warningArnd Bergmann4-12/+4
[ Upstream commit bfb1b99802ef16045402deb855c197591dc78886 ] The ipi handler here tries hard to maintain const-ness of its argument, but by doing that causes a warning about function type casts: drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: error: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 38 | ipi_handler_t handler_const = (ipi_handler_t)handler; | ^~~~~~~~~~~~~~~~~~~~~~ Remove the hack and just use a non-const argument. Fixes: bf1d556ad4e0 ("media: mtk-vcodec: abstract firmware interface") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: ttpci: fix two memleaks in budget_av_attachZhipeng Lu1-3/+5
[ Upstream commit d0b07f712bf61e1a3cf23c87c663791c42e50837 ] When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: go7007: fix a memleak in go7007_load_encoderZhipeng Lu1-3/+5
[ Upstream commit b9b683844b01d171a72b9c0419a2d760d946ee12 ] In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. Fixes: 95ef39403f89 ("[media] go7007: remember boot firmware") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: dvb-frontends: avoid stack overflow warnings with clangArnd Bergmann1-26/+8
[ Upstream commit 7a4cf27d1f0538f779bf31b8c99eda394e277119 ] A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled. Fixes: 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27media: pvrusb2: fix uaf in pvr2_context_set_notifyEdward Adam Davis1-1/+1
[ Upstream commit 0a0b79ea55de8514e1750884e5fec77f9fdd01ee ] [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. Reported-and-tested-by: syzbot+ce750e124675d4599449@syzkaller.appspotmail.com Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload") Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/amdgpu: Fix missing break in ATOM_ARG_IMM Case of atom_get_src_int()Srinivasan Shanmugam1-1/+1
[ Upstream commit 7cf1ad2fe10634238b38442a851d89514cb14ea2 ] Missing break statement in the ATOM_ARG_IMM case of a switch statement, adds the missing break statement, ensuring that the program's control flow is as intended. Fixes the below: drivers/gpu/drm/amd/amdgpu/atom.c:323 atom_get_src_int() warn: ignoring unreachable code. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Cc: Jammy Zhou <Jammy.Zhou@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27HID: amd_sfh: Avoid disabling the interruptBasavaraj Natikar1-3/+27
[ Upstream commit c1db0073212ef39d5a46c2aea5e49bf884375ce4 ] HP ProBook x360 435 G7 using older version of firmware which doesn't support disabling the interrupt for all commands. Hence avoid disabling the interrupt for that particular model. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218104 Fixes: b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command") Co-developed-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27HID: amd_sfh: Update HPD sensor structure elementsBasavaraj Natikar1-3/+3
[ Upstream commit bbf0dec30696638b8bdc28cb2f5bf23f8d760b52 ] HPD sensor data is not populating properly because of wrong order of HPD sensor structure elements. So update the order of structure elements to match the HPD sensor data received from the firmware. Fixes: 24a31ea94922 ("HID: amd_sfh: Add initial support for HPD sensor") Co-developed-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27perf pmu: Fix a potential memory leak in perf_pmu__lookup()Christophe JAILLET1-4/+3
[ Upstream commit ef5de1613d7d92bdc975e6beb34bb0fa94f34078 ] The commit in Fixes has reordered some code, but missed an error handling path. 'goto err' now, in order to avoid a memory leak in case of error. Fixes: f63a536f03a2 ("perf pmu: Merge JSON events with sysfs at load time") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Ian Rogers <irogers@google.com> Cc: kernel-janitors@vger.kernel.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/9538b2b634894c33168dfe9d848d4df31fd4d801.1693085544.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if conditionNeil Armstrong1-2/+11
[ Upstream commit dc94d0cc718329a39ea2e986a123421a9203b471 ] The if condition for the SM8[45]50 GPU SMMU is too large, add the other compatible strings to the condition to only allow the clocks for the GPU SMMU nodes. Fixes: 4fff78dc2490 ("dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/578686/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/msm/a7xx: Fix LLC typoRob Clark1-1/+1
[ Upstream commit 0776ad9274d96d132131af66a5941df45b9d46b4 ] We'd miss actually activating LLC. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/573043/ Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27drm/msm/a6xx: specify UBWC config for sc7180Dmitry Baryshkov1-2/+1
[ Upstream commit 0d7dfc79fb9b4b81f642f84796111f2bae8427e2 ] Historically the Adreno driver has not been updating memory configuration registers on a618 (SC7180 platform) implying that the default configuration is fine. After the rework performed in the commit 8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function a6xx_calc_ubwc_config() still contained this shortcut and did not calculate UBWC configuration. However the function which now actually updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such check. Rather than adding the check to a6xx_set_ubwc_config(), fill in the UBWC config for a618 (based on readings from SC7180). Reported-by: Leonard Lausen <leonard@lausen.nl> Link: https://gitlab.freedesktop.org/drm/msm/-/issues/49 Fixes: 8814455a0e54 ("drm/msm: Refactor UBWC config setting") Cc: Connor Abbott <cwabbott0@gmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/579113/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-09 20:17:41 +0300