summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-25ASoC: Intel: bytcr_wm5102: Add BYT_WM5102_OUT_MAP quirkHans de Goede
Some x86 WM5102 designs don't use the SPK pins for speaker output instead they use the HPOUT2L + HPOUT2R for the speakers. Add an BYT_WM5102_OUT_MAP quirk mechanism to allow selecting between 2 output maps, one for the speakers on the SPK output pins and one for the speakers on the HPOUT2 pins. The new HPOUT2 map is enabled by default on CHT because this is used on the Lenovo Yoga Tab 3 YT3-X90 model which is the only Cherry Trail design currently supported. If different CHT designs turn up which need different output maps we can add DMI quirks to select a different map later. The userspace UCM profile also needs to know about this so setup a components string with this info too. While at it also drop the unused "Line Out" route. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231025143513.291753-4-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25ASoC: Intel: bytcr_wm5102: Add BYT_WM5102_MCLK_19_2MHZ quirkHans de Goede
The Cherry Trail SoC only supports 19200000 as clk-frequency for the pmc_plt_clk used for the audio codec. Add a BYT_WM5102_MCLK_19_2MHZ quirk for this and enable this by default on Cherry Trail SoCs. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231025143513.291753-3-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25ASoC: Intel: bytcr_wm5102: Add BYT_WM5102_SSP2 quirkHans de Goede
Add the standard intel board file quirk mechanism also used in many other intel board drivers and add a BYT_WM5102_SSP2 quirk setting for designs using SSP2 instead of SSP0. And enable the new BYT_WM5102_SSP2 quirk on Cherry Trail devices since those always use SSP2. The logging of the quirks uses dev_info_once() because probe() may run multiple times because of snd_soc_register_card() returning -EPROBE_DEFER. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231025143513.291753-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25drm/doc: document DRM_IOCTL_MODE_CREATE_DUMBSimon Ser
The main motivation is to repeat that dumb buffers should not be abused for anything else than basic software rendering with KMS. User-space devs are more likely to look at the IOCTL docs than to actively search for the driver-oriented "Dumb Buffer Objects" section. v2: reference DRM_CAP_DUMB_BUFFER, DRM_CAP_DUMB_PREFERRED_DEPTH and DRM_CAP_DUMB_PREFER_SHADOW (Pekka) Signed-off-by: Simon Ser <contact@emersion.fr> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821131548.269204-1-contact@emersion.fr
2023-10-25genirq/matrix: Exclude managed interrupts in irq_matrix_allocated()Chen Yu
When a CPU is about to be offlined, x86 validates that all active interrupts which are targeted to this CPU can be migrated to the remaining online CPUs. If not, the offline operation is aborted. The validation uses irq_matrix_allocated() to retrieve the number of vectors which are allocated on the outgoing CPU. The returned number of allocated vectors includes also vectors which are associated to managed interrupts. That's overaccounting because managed interrupts are: - not migrated when the affinity mask of the interrupt targets only the outgoing CPU - migrated to another CPU, but in that case the vector is already pre-allocated on the potential target CPUs and must not be taken into account. As a consequence the check whether the remaining online CPUs have enough capacity for migrating the allocated vectors from the outgoing CPU might fail incorrectly. Let irq_matrix_allocated() return only the number of allocated non-managed interrupts to make this validation check correct. [ tglx: Amend changelog and fixup kernel-doc comment ] Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator") Reported-by: Wendy Wang <wendy.wang@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20231020072522.557846-1-yu.c.chen@intel.com
2023-10-25Documentation: kernel-parameters: Add earlyprintk=bios on SHGeert Uytterhoeven
Document the use of the "earlyprintk=bios[,keep]" kernel parameter option on SuperH systems with a SuperH standard BIOS. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/febc920964f2f0919d21775132e84c5cc270177e.1697708489.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25sh: bios: Revive earlyprintk supportGeert Uytterhoeven
The SuperH BIOS earlyprintk code is protected by CONFIG_EARLY_PRINTK. However, when this protection was added, it was missed that SuperH no longer defines an EARLY_PRINTK config symbol since commit e76fe57447e88916 ("sh: Remove old early serial console code V2"), so BIOS earlyprintk can no longer be used. Fix this by reviving the EARLY_PRINTK config symbol. Fixes: d0380e6c3c0f6edb ("early_printk: consolidate random copies of identical code") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/c40972dfec3dcc6719808d5df388857360262878.1697708489.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25sh: machvec: Remove custom ioport_{un,}map()Arnd Bergmann
These functions were only used on the microdev board that is now gone, so remove them to simplify the ioport handling. This could be further simplified to use the generic I/O port accessors now. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230914155523.3839811-4-arnd@kernel.org Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25sh: Remove superhyway bus supportArnd Bergmann
The superhyway bus driver was only referenced on SH4-202, which is now gone, so remove it all as well. I could find no trace of anything ever calling superhyway_register_driver(), not in the git history but also not on the web, so I assume this has never served any purpose on mainline kernels. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230914155523.3839811-3-arnd@kernel.org Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25sh: Remove unused SH4-202 supportArnd Bergmann
This early prototype of the SH4 CPU was only used in the "microdev" board that is now removed, so all of the SH4-202 supoprt can also be removed. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230914155523.3839811-2-arnd@kernel.org Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25sh: Remove stale microdev boardArnd Bergmann
This board was an early prototype platform for early SH4 CPUs and related to the already removed SH5 cayman platform. The microdev board itself has been kept in the tree for this long despite being in a bad shape even 20 years ago when it got merged, with no working PCI support and ugly workarounds for its I/O port implementation that try to emulate PC style peripheral access despite being quite different in reality. As far as I can tell, the ethernet, display, USB and PCI devices on it already broke at some point (afbb9d8d5266b, 46bc85872040a), so I think we can just removeit entirely. Link: https://lore.kernel.org/lkml/09094baf-dadf-4bce-9f63-f2a1f255f9a8@app.fastmail.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230914155523.3839811-1-arnd@kernel.org Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
2023-10-25Revert "Merge branch 'mv88e6xxx-dsa-bindings'"Jakub Kicinski
This reverts the following commits: commit 53313ed25ba8 ("dt-bindings: marvell: Add Marvell MV88E6060 DSA schema") commit 0f35369b4efe ("dt-bindings: marvell: Rewrite MV88E6xxx in schema") commit 605a5f5d406d ("ARM64: dts: marvell: Fix some common switch mistakes") commit bfedd8423643 ("ARM: dts: nxp: Fix some common switch mistakes") commit 2b83557a588f ("ARM: dts: marvell: Fix some common switch mistakes") commit ddae07ce9bb3 ("dt-bindings: net: mvusb: Fix up DSA example") commit b5ef61718ad7 ("dt-bindings: net: dsa: Require ports or ethernet-ports") As repoted by Vladimir, it breaks boot on the Turris MOX board. Link: https://lore.kernel.org/all/20231025093632.fb2qdtunzaznd73z@skbuf/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-25swiotlb: do not try to allocate a TLB bigger than MAX_ORDER pagesPetr Tesarik
When allocating a new pool at runtime, reduce the number of slabs so that the allocation order is at most MAX_ORDER. This avoids a kernel warning in __alloc_pages(). The warning is relatively benign, because the pool size is subsequently reduced when allocation fails, but it is silly to start with a request that is known to fail, especially since this is the default behavior if the kernel is built with CONFIG_SWIOTLB_DYNAMIC=y and booted without any swiotlb= parameter. Reported-by: Ben Greear <greearb@candelatech.com> Closes: https://lore.kernel.org/netdev/4f173dd2-324a-0240-ff8d-abf5c191be18@candelatech.com/ Fixes: 1aaa736815eb ("swiotlb: allocate a new memory pool when existing pools are full") Signed-off-by: Petr Tesarik <petr.tesarik1@huawei-partners.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-10-25HID: uclogic: Fix a work->entry not empty bug in __queue_work()Jinjie Ruan
When CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch kernel and then the below work->entry not empty bug occurs. In hid_test_uclogic_exec_event_hook_test(), the filter->work is not initialized to be added to p.event_hooks->list, and then the schedule_work() in uclogic_exec_event_hook() will call __queue_work(), which check whether the work->entry is empty and cause the below warning call trace. So call INIT_WORK() with a fake work to solve the issue. After applying this patch, the below work->entry not empty bug never occurs. WARNING: CPU: 0 PID: 2177 at kernel/workqueue.c:1787 __queue_work.part.0+0x780/0xad0 Modules linked in: CPU: 0 PID: 2177 Comm: kunit_try_catch Tainted: G B W N 6.6.0-rc2+ #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__queue_work.part.0+0x780/0xad0 Code: 44 24 20 0f b6 00 84 c0 74 08 3c 03 0f 8e 52 03 00 00 f6 83 00 01 00 00 02 74 6f 4c 89 ef e8 c7 d8 f1 02 f3 90 e9 e5 f8 ff ff <0f> 0b e9 63 fc ff ff 89 e9 49 8d 57 68 4c 89 e6 4c 89 ff 83 c9 02 RSP: 0000:ffff888102bb7ce8 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff888106b8e460 RCX: ffffffff84141cc7 RDX: 1ffff11020d71c8c RSI: 0000000000000004 RDI: ffff8881001d0118 RBP: dffffc0000000000 R08: 0000000000000001 R09: ffffed1020576f92 R10: 0000000000000003 R11: ffff888102bb7980 R12: ffff888106b8e458 R13: ffff888119c38800 R14: 0000000000000000 R15: ffff8881001d0100 FS: 0000000000000000(0000) GS:ffff888119c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888119506000 CR3: 0000000005286001 CR4: 0000000000770ef0 DR0: ffffffff8fdd6ce0 DR1: ffffffff8fdd6ce1 DR2: ffffffff8fdd6ce3 DR3: ffffffff8fdd6ce5 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xc9/0x260 ? __queue_work.part.0+0x780/0xad0 ? report_bug+0x345/0x400 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x40 ? asm_exc_invalid_op+0x16/0x20 ? _raw_spin_lock+0x87/0xe0 ? __queue_work.part.0+0x780/0xad0 ? __queue_work.part.0+0x249/0xad0 queue_work_on+0x48/0x50 uclogic_exec_event_hook.isra.0+0xf7/0x160 hid_test_uclogic_exec_event_hook_test+0x2f1/0x5d0 ? try_to_wake_up+0x151/0x13e0 ? uclogic_exec_event_hook.isra.0+0x160/0x160 ? _raw_spin_lock_irqsave+0x8d/0xe0 ? __sched_text_end+0xa/0xa ? __sched_text_end+0xa/0xa ? migrate_enable+0x260/0x260 ? kunit_try_run_case_cleanup+0xe0/0xe0 kunit_generic_run_threadfn_adapter+0x4a/0x90 ? kunit_try_catch_throw+0x80/0x80 kthread+0x2b5/0x380 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x70 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 </TASK> Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20231009064245.3573397-3-ruanjinjie@huawei.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-10-25HID: uclogic: Fix user-memory-access bug in ↵Jinjie Ruan
uclogic_params_ugee_v2_init_event_hooks() When CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch kernel and then the below user-memory-access bug occurs. In hid_test_uclogic_params_cleanup_event_hooks(),it call uclogic_params_ugee_v2_init_event_hooks() with the first arg=NULL, so when it calls uclogic_params_ugee_v2_has_battery(), the hid_get_drvdata() will access hdev->dev with hdev=NULL, which will cause below user-memory-access. So add a fake_device with quirks member and call hid_set_drvdata() to assign hdev->dev->driver_data which avoids the null-ptr-def bug for drvdata->quirks in uclogic_params_ugee_v2_has_battery(). After applying this patch, the below user-memory-access bug never occurs. general protection fault, probably for non-canonical address 0xdffffc0000000329: 0000 [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x0000000000001948-0x000000000000194f] CPU: 5 PID: 2189 Comm: kunit_try_catch Tainted: G B W N 6.6.0-rc2+ #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600 Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00 RSP: 0000:ffff88810679fc88 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0 R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92 R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080 FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0 DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6 DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? uclogic_params_ugee_v2_init_event_hooks+0x87/0x600 ? sched_clock_cpu+0x69/0x550 ? uclogic_parse_ugee_v2_desc_gen_params+0x70/0x70 ? load_balance+0x2950/0x2950 ? rcu_trc_cmpxchg_need_qs+0x67/0xa0 hid_test_uclogic_params_cleanup_event_hooks+0x9e/0x1a0 ? uclogic_params_ugee_v2_init_event_hooks+0x600/0x600 ? __switch_to+0x5cf/0xe60 ? migrate_enable+0x260/0x260 ? __kthread_parkme+0x83/0x150 ? kunit_try_run_case_cleanup+0xe0/0xe0 kunit_generic_run_threadfn_adapter+0x4a/0x90 ? kunit_try_catch_throw+0x80/0x80 kthread+0x2b5/0x380 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x70 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace 0000000000000000 ]--- RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600 Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00 RSP: 0000:ffff88810679fc88 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0 R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92 R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080 FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0 DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6 DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 1 seconds.. Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20231009064245.3573397-2-ruanjinjie@huawei.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-10-25io_uring/rw: disable IOCB_DIO_CALLER_COMPJens Axboe
If an application does O_DIRECT writes with io_uring and the file system supports IOCB_DIO_CALLER_COMP, then completions of the dio write side is done from the task_work that will post the completion event for said write as well. Whenever a dio write is done against a file, the inode i_dio_count is elevated. This enables other callers to use inode_dio_wait() to wait for previous writes to complete. If we defer the full dio completion to task_work, we are dependent on that task_work being run before the inode i_dio_count can be decremented. If the same task that issues io_uring dio writes with IOCB_DIO_CALLER_COMP performs a synchronous system call that calls inode_dio_wait(), then we can deadlock as we're blocked sleeping on the event to become true, but not processing the completions that will result in the inode i_dio_count being decremented. Until we can guarantee that this is the case, then disable the deferred caller completions. Fixes: 099ada2c8726 ("io_uring/rw: add write support for IOCB_DIO_CALLER_COMP") Reported-by: Andres Freund <andres@anarazel.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-10-25hexagon: Remove unusable symbols from the ptrace.h uapiThomas Huth
Kernel-internal prototypes, references to current_thread_info() and code hidden behind a CONFIG_HEXAGON_ARCH_VERSION switch are certainly not usable in userspace, so this should not reside in a uapi header. Move the code into an internal version of ptrace.h instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-25drm/amd: Disable ASPM for VI w/ all Intel systemsMario Limonciello
Originally we were quirking ASPM disabled specifically for VI when used with Alder Lake, but it appears to have problems with Rocket Lake as well. Like we've done in the case of dpm for newer platforms, disable ASPM for all Intel systems. Cc: stable@vger.kernel.org # 5.15+ Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default") Reported-and-tested-by: Paolo Gentili <paolo.gentili@canonical.com> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036742 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-25io_uring/fdinfo: lock SQ thread while retrieving thread cpu/pidJens Axboe
We could race with SQ thread exit, and if we do, we'll hit a NULL pointer dereference when the thread is cleared. Grab the SQPOLL data lock before attempting to get the task cpu and pid for fdinfo, this ensures we have a stable view of it. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=218032 Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-10-25Merge tag 'mvebu-arm-6.7-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/drivers mvebu arm for 6.7 (part 1) Fix missing of_node_put in dove code base * tag 'mvebu-arm-6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: soc: dove: add missing of_node_put Link: https://lore.kernel.org/r/87zg0e8w4v.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-25Merge tag 'ti-driver-soc-for-v6.7' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers TI SoC driver updates for v6.7 - Generic fixups: Convert to platform remove callback returning void - ti_sci: Minor fixups and mark driver as non-removable - k3-socinfo: Documentation fixups, cosmetic fixups - knav_qmss_queue: Optimize with device_get_match_data Signed-off-by: Nishanth Menon <nm@ti.com> * tag 'ti-driver-soc-for-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: soc: ti: k3-socinfo: Avoid overriding return value soc: ti: k3-socinfo: Fix typo in bitfield documentation soc: ti: knav_qmss_queue: Use device_get_match_data() firmware: ti_sci: Use device_get_match_data() soc/ti: wkup_m3_ipc: Convert to platform remove callback returning void soc/ti: smartreflex: Convert to platform remove callback returning void soc/ti: pruss: Convert to platform remove callback returning void soc/ti: pm33xx: Convert to platform remove callback returning void soc/ti: knav_qmss_queue: Convert to platform remove callback returning void soc/ti: knav_dma: Convert to platform remove callback returning void soc/ti: k3-ringacc: Convert to platform remove callback returning void firmware: ti_sci: Mark driver as non removable firmware: ti_sci: refactor deprecated strncpy firmware: ti_sci: Use list_for_each_entry() helper Link: https://lore.kernel.org/r/20231018165226.33x5cjn5jmgnm3di@magnolia Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-25hid: cp2112: Fix IRQ shutdown stopping polling for all IRQs on chipDanny Kaehn
Previously cp2112_gpio_irq_shutdown() always cancelled the gpio_poll_worker, even if other IRQs were still active, and did not set the gpio_poll flag to false. This resulted in any call to _shutdown() resulting in interrupts no longer functioning on the chip until a _remove() occurred (a.e. the cp2112 is unplugged or system rebooted). Only cancel polling if all IRQs are disabled/masked, and correctly set the gpio_poll flag, allowing polling to restart when an interrupt is next enabled. Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com> Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling") Link: https://lore.kernel.org/r/20231011182317.1053344-1-danny.kaehn@plexus.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2023-10-25Merge tag 'devfreq-next-for-6.7' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Merge devfreq updates for v6.7 from Chanwoo Choi: " Detailed description for this pull request: 1. Update devfreq core - Switch to dev_pm_opp_find_freq_(ceil/floor)_indexed() APIs to support the specific device like UFS which handle the multiple clocks through OPP (Operationg Performance Point) framework. 2. Update the devfreq / devfreq-event drivers - Add perf support to the Rockchip DFI(DDR Monitor Module) devfreq-event driver. : Generalize rockchip-dfi.c to support new RK3568/RK3588 using different DDR type. : Covert devicetree bidning document format to yaml. : DFI is a unit which is suitable for measuring DDR utilization for the DDR frequency scaling driver. Add perf support feature to rockchip-dfi.c to extend DFI usage. The perf support has been tested on a RK3568 and a RK3399. - Protect the OPP handling code in critical section because the voltage of shared OPP might be changed by multiple drivers on Mediatek CCI devfreq driver. - Use device_get_match_data() on Samsung Exynos PPMU devfreq-event driver." * tag 'devfreq-next-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: (26 commits) dt-bindings: devfreq: event: rockchip,dfi: Add rk3588 support dt-bindings: devfreq: event: rockchip,dfi: Add rk3568 support dt-bindings: devfreq: event: convert Rockchip DFI binding to yaml PM / devfreq: rockchip-dfi: add support for RK3588 PM / devfreq: rockchip-dfi: account for multiple DDRMON_CTRL registers PM / devfreq: rockchip-dfi: make register stride SoC specific PM / devfreq: rockchip-dfi: Add perf support PM / devfreq: rockchip-dfi: give variable a better name PM / devfreq: rockchip-dfi: Prepare for multiple users PM / devfreq: rockchip-dfi: Pass private data struct to internal functions PM / devfreq: rockchip-dfi: Handle LPDDR4X PM / devfreq: rockchip-dfi: Handle LPDDR2 correctly PM / devfreq: rockchip-dfi: Add RK3568 support PM / devfreq: rockchip-dfi: Clean up DDR type register defines PM / devfreq: rk3399_dmc,dfi: generalize DDRTYPE defines PM / devfreq: rockchip-dfi: introduce channel mask PM / devfreq: rockchip-dfi: Use free running counter PM / devfreq: mediatek: unlock on error in mtk_ccifreq_target() PM / devfreq: exynos-ppmu: Use device_get_match_data() PM / devfreq: rockchip-dfi: dfi store raw values in counter struct ...
2023-10-25Merge tag 'opp-updates-6.7' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge OPP (operating performance points) updates for 6.7 from Viresh Kumar: "- Extend support for the opp-level beyond required-opps (Ulf Hansson). - Add dev_pm_opp_find_level_floor() (Krishna chaitanya chundru). - dt-bindings: Allow opp-peak-kBpsfor kryo CPUs, support Qualcomm Krait SoCs and document named opp-microvolt property (Bjorn Andersson, Dmitry Baryshkov and Christian Marangi). - Fix -Wunsequenced warning (Nathan Chancellor). - General cleanup (Viresh Kumar)." * tag 'opp-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: dt-bindings: opp: opp-v2-kryo-cpu: Document named opp-microvolt property OPP: No need to defer probe from _opp_attach_genpd() OPP: Remove genpd_virt_dev_lock OPP: Reorder code in _opp_set_required_opps_genpd() OPP: Add _link_required_opps() to avoid code duplication OPP: Fix formatting of if/else block dt-bindings: opp: opp-v2-kryo-cpu: support Qualcomm Krait SoCs OPP: Fix -Wunsequenced in _of_add_opp_table_v1() dt-bindings: opp: opp-v2-kryo-cpu: Allow opp-peak-kBps OPP: debugfs: Fix warning with W=1 builds OPP: Remove doc style comments for internal routines OPP: Add dev_pm_opp_find_level_floor() OPP: Extend support for the opp-level beyond required-opps OPP: Switch to use dev_pm_domain_set_performance_state() OPP: Extend dev_pm_opp_data with a level OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility PM: domains: Implement the ->set_performance_state() callback for genpd PM: domains: Introduce dev_pm_domain_set_performance_state()
2023-10-25drm/i915/pmu: Check if pmu is closed before stopping eventUmesh Nerlige Ramappa
When the driver unbinds, pmu is unregistered and i915->uabi_engines is set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine events, it issues a warn_on because engine lookup fails. All perf hooks are taking care of this using a pmu->closed flag that is set when PMU unregisters. The stop event seems to have been left out. Check for pmu->closed in pmu_event_stop as well. Based on discussion here - https://patchwork.freedesktop.org/patch/492079/?series=105790&rev=2 v2: s/is/if/ in commit title v3: Add fixes tag and cc stable Cc: <stable@vger.kernel.org> # v5.11+ Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231020152441.3764850-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 31f6a06f0c543b43a38fab10f39e5fc45ad62aa2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-10-25regulator: fixed: add support for under-voltage IRQOleksij Rempel
Add interrupt support for under-voltage notification. This functionality can be used on systems capable to detect under-voltage state and having enough capacity to let the SoC do some emergency preparation. This change enforce default policy to shutdown system as soon as interrupt is triggered. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231025084614.3092295-6-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25regulator: dt-bindings: fixed-regulator: Add under-voltage interrupt supportOleksij Rempel
Add under-voltage interrupt support. This can be used with simple regulators having no other way to communicate an under-voltage event except as by toggling some GPIO line. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231025084614.3092295-4-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25drm/i915/mcr: Hold GT forcewake during steering operationsMatt Roper
The steering control and semaphore registers are inside an "always on" power domain with respect to RC6. However there are some issues if higher-level platform sleep states are entering/exiting at the same time these registers are accessed. Grabbing GT forcewake and holding it over the entire lock/steer/unlock cycle ensures that those sleep states have been fully exited before we access these registers. This is expected to become a formally documented/numbered workaround soon. Note that this patch alone isn't expected to have an immediately noticeable impact on MCR (mis)behavior; an upcoming pcode firmware update will also be necessary to provide the other half of this workaround. v2: - Move the forcewake inside the Xe_LPG-specific IP version check. This should only be necessary on platforms that have a steering semaphore. Fixes: 3100240bf846 ("drm/i915/mtl: Add hardware-level lock for steering") Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231019170241.2102037-2-matthew.d.roper@intel.com (cherry picked from commit 8fa1c7cd1fe9cdfc426a603e1f1eecd3f463c487) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-10-25Merge tag 'thermal-v6.7-rc1' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux Merge thermal control (ARM drivers mostly) updates for 6.7-rc1 from Daniel Lezcano: "- Add support for Mediatek LVTS MT8192 driver along with the suspend/resume routines (Balsam Chihi) - Fix probe for THERMAL_V2 for the Mediatek LVTS driver (Markus Schneider-Pargmann) - Remove duplicate error message in the max76620 driver when thermal_of_zone_register() fails as the sub routine already show one (Thierry Reding) - Add i.MX7D compatible bindings to fix a warning from dtbs_check for the imx6ul platform (Alexander Stein) - Add sa8775p compatible for the QCom tsens driver (Priyansh Jain) - Fix error check in lvts_debugfs_init() which is checking against NULL instead of PTR_ERR() on the LVTS Mediatek driver (Minjie Du) - Remove unused variable in the thermal/tools (Kuan-Wei Chiu) - Document the imx8dl thermal sensor (Fabio Estevam) - Add variable names in callback prototypes to prevent warning from checkpatch.pl for the imx8mm driver (Bragatheswaran Manickavel) - Add missing unevaluatedProperties on child node schemas for tegra124 (Rob Herring) - Add mt7988 support for the Mediatek LVTS driver (Frank Wunderlich)" * tag 'thermal-v6.7-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: thermal/qcom/tsens: Drop ops_v0_1 thermal/drivers/mediatek/lvts_thermal: Update calibration data documentation thermal/drivers/mediatek/lvts_thermal: Add mt8192 support thermal/drivers/mediatek/lvts_thermal: Add suspend and resume dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 thermal/drivers/mediatek: Fix probe for THERMAL_V2 thermal/drivers/max77620: Remove duplicate error message dt-bindings: timer: add imx7d compatible dt-bindings: net: microchip: Allow nvmem-cell usage dt-bindings: imx-thermal: Add #thermal-sensor-cells property dt-bindings: thermal: tsens: Add sa8775p compatible thermal/drivers/mediatek/lvts_thermal: Fix error check in lvts_debugfs_init() tools/thermal: Remove unused 'mds' and 'nrhandler' variables dt-bindings: thermal: fsl,scu-thermal: Document imx8dl thermal/drivers/imx8mm_thermal: Fix function pointer declaration by adding identifier name dt-bindings: thermal: nvidia,tegra124-soctherm: Add missing unevaluatedProperties on child node schemas thermal/drivers/mediatek/lvts_thermal: Add mt7988 support thermal/drivers/mediatek/lvts_thermal: Make coeff configurable dt-bindings: thermal: mediatek: Add LVTS thermal sensors for mt7988 dt-bindings: thermal: mediatek: Add mt7988 lvts compatible
2023-10-25ASoC: codecs: Add aw88399 amplifier driverWeidong Wang
Add i2c and amplifier registration for aw88399 and their associated operation functions. Signed-off-by: Weidong Wang <wangweidong.a@awinic.com> Link: https://lore.kernel.org/r/20231025112625.959587-4-wangweidong.a@awinic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25ASoC: codecs: Add code for bin parsing compatible with aw88399Weidong Wang
Add aw88399 compatible code to the aw88395_lib.c file so that it can parse aw88399's bin file. Reviewed-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Weidong Wang <wangweidong.a@awinic.com> Link: https://lore.kernel.org/r/20231025112625.959587-3-wangweidong.a@awinic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25ASoC: dt-bindings: Add schema for "awinic,aw88399"Weidong Wang
Add the awinic,aw88399 property to the awinic,aw88395.yaml file. Signed-off-by: Weidong Wang <wangweidong.a@awinic.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231025112625.959587-2-wangweidong.a@awinic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-25Merge tag 'cpufreq-arm-updates-6.7' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge ARM cpufreq updates for 6.7 from Viresh Kumar: "- Add support for several Qualcomm SoC versions and other similar changes (Christian Marangi, Dmitry Baryshkov, Luca Weiss, Neil Armstrong, Richard Acayan, Robert Marko, Rohit Agarwal, Stephan Gerhold and Varadarajan Narayanan). - Cleanups to the tegra cpufreq driver (Sumit Gupta). - Use of_property_read_reg() to parse "reg" in pmac32 driver (Rob Herring). - Add support for TI's am62p5 Soc (Bryan Brattlof). - Make ARM_BRCMSTB_AVS_CPUFREQ depends on !ARM_SCMI_CPUFREQ (Florian Fainelli). - Update Kconfig to mention i.MX7 as well (Alexander Stein)." * tag 'cpufreq-arm-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (25 commits) dt-bindings: cpufreq: qcom-hw: document SM8650 CPUFREQ Hardware cpufreq: arm: Kconfig: Add i.MX7 to supported SoC for ARM_IMX_CPUFREQ_DT cpufreq: qcom-nvmem: add support for IPQ8064 cpufreq: qcom-nvmem: also accept operating-points-v2-krait-cpu cpufreq: qcom-nvmem: drop pvs_ver for format a fuses dt-bindings: cpufreq: qcom-cpufreq-nvmem: Document krait-cpu cpufreq: qcom-nvmem: add support for IPQ6018 dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ6018 cpufreq: qcom-nvmem: Add MSM8909 cpufreq: qcom-nvmem: Simplify driver data allocation dt-bindings: cpufreq: cpufreq-qcom-hw: Add SDX75 compatible cpufreq: ARM_BRCMSTB_AVS_CPUFREQ cannot be used with ARM_SCMI_CPUFREQ cpufreq: ti-cpufreq: Add opp support for am62p5 SoCs cpufreq: dt-platdev: add am62p5 to blocklist cpufreq: tegra194: remove redundant AND with cpu_online_mask cpufreq: tegra194: use refclk delta based loop instead of udelay cpufreq: tegra194: save CPU data to avoid repeated SMP calls dt-bindings: cpufreq: cpufreq-qcom-hw: add SDM670 compatible dt-bindings: cpufreq: qcom-nvmem: Document MSM8909 cpufreq: dt: platdev: Add MSM8909 to blocklist ...
2023-10-25perf: arm_cspmu: use acpi_dev_hid_uid_match() for matching _HID and _UIDRaag Jadav
Convert manual _UID references to use the standard ACPI helpers. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-25Revert "wifi: ath11k: call ath11k_mac_fils_discovery() without condition"Kalle Valo
This reverts commit e149353e6562f3e3246f75dfc4cca6a0cc5b4efc. The commit caused QCA6390 hw2.0 firmware WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1 to crash during disconnect: [71990.787525] ath11k_pci 0000:72:00.0: firmware crashed: MHI_CB_EE_RDDM Closes: https://lore.kernel.org/all/87edhu3550.fsf@kernel.org/ Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20231023164120.651151-1-kvalo@kernel.org
2023-10-25wifi: ath12k: Introduce and use ath12k_sta_to_arsta()Jeff Johnson
Currently, the logic to return an ath12k_sta pointer, given a ieee80211_sta pointer, uses typecasting throughout the driver. In general, conversion functions are preferable to typecasting since using a conversion function allows the compiler to validate the types of both the input and output parameters. ath12k already defines a conversion function ath12k_vif_to_arvif() for a similar conversion. So introduce ath12k_sta_to_arsta() for this use case, and convert all of the existing typecasting to use this function. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019-upstream-ath12k_sta_to_arsta-v1-1-06f06f693338@quicinc.com
2023-10-25dt-bindings: cpufreq: qcom-hw: document SM8650 CPUFREQ HardwareNeil Armstrong
Document the CPUFREQ Hardware on the SM8650 Platform. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25cpufreq: arm: Kconfig: Add i.MX7 to supported SoC for ARM_IMX_CPUFREQ_DTAlexander Stein
Since commit a5a9dffcc903 ("ARM: imx: Switch imx7d to imx-cpufreq-dt for speed-grading") i.MX7 uses this driver as well. Add it to the description text. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25cpufreq: qcom-nvmem: add support for IPQ8064Christian Marangi
IPQ8064 comes in 3 families: * IPQ8062 up to 1.0GHz * IPQ8064/IPQ8066/IPQ8068 up to 1.4GHz * IPQ8065/IPQ8069 up to 1.7Ghz So, in order to be able to support one OPP table, add support for IPQ8064 family based of SMEM SoC ID-s and correctly set the version so opp-supported-hw can be correctly used. Bit are set with the following logic: * IPQ8062 BIT 0 * IPQ8064/IPQ8066/IPQ8068 BIT 1 * IPQ8065/IPQ8069 BIT 2 speed is never fused, only pvs values are fused. IPQ806x SoC doesn't have pvs_version so we drop and we use the new pattern: opp-microvolt-speed0-pvs<PSV_VALUE> Example: - for ipq8062 psv2 opp-microvolt-speed0-pvs2 = < 925000 878750 971250> Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> [ Viresh: Fixed rebase conflict. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25cpufreq: qcom-nvmem: also accept operating-points-v2-krait-cpuDmitry Baryshkov
the qcom-cpufreq-nvmem driver attempts to support both Qualcomm Kryo (newer 64-bit ARMv8 cores) and Krait (older 32-bit ARMv7 cores). It makes no sense to use 'operating-points-v2-kryo-cpu' compatibility node for the Krait cores. Add support for 'operating-points-v2-krait-cpu' compatibility string. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25cpufreq: qcom-nvmem: drop pvs_ver for format a fusesDmitry Baryshkov
The fuses used on msm8960 / apq8064 / ipq806x families of devices do not have the pvs version. Drop this argument from parsing function. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25dt-bindings: cpufreq: qcom-cpufreq-nvmem: Document krait-cpuChristian Marangi
Document newly introduced operating-points-v2-krait-cpu compatible to the list of accepted compatible for opp-v2-kryo-cpu nodes. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25cpufreq: qcom-nvmem: add support for IPQ6018Robert Marko
IPQ6018 SoC series comes in multiple SKU-s, and not all of them support high frequency OPP points. SoC itself does however have a single bit in QFPROM to indicate the CPU speed-bin. That bit is used to indicate frequency limit of 1.5GHz, but that alone is not enough as IPQ6000 only goes up to 1.2GHz, but SMEM ID can be used to limit it further. IPQ6018 compatible is blacklisted from DT platdev as the cpufreq device will get created by NVMEM CPUFreq driver. Signed-off-by: Robert Marko <robimarko@gmail.com> [ Viresh: Fixed rebase conflict. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2023-10-25drm/logicvc: Kconfig: select REGMAP and REGMAP_MMIOSui Jingfeng
drm/logicvc driver is depend on REGMAP and REGMAP_MMIO, should select this two kconfig option, otherwise the driver failed to compile on platform without REGMAP_MMIO selected: ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/gpu/drm/logicvc/logicvc-drm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1 make: *** [Makefile:1978: modpost] Error 2 Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller") Link: https://patchwork.freedesktop.org/patch/msgid/20230608024207.581401-1-suijingfeng@loongson.cn Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
2023-10-25wifi: ath12k: fix htt mlo-offset event lockingJohan Hovold
The ath12k active pdevs are protected by RCU but the htt mlo-offset event handling code calling ath12k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Cc: stable@vger.kernel.org # v6.2 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019113650.9060-3-johan+linaro@kernel.org
2023-10-25wifi: ath12k: fix dfs-radar and temperature event lockingJohan Hovold
The ath12k active pdevs are protected by RCU but the DFS-radar and temperature event handling code calling ath12k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as RCU read-side critical sections to avoid any potential use-after-free issues. Note that the temperature event handler looks like a place holder currently but would still trigger an RCU lockdep splat. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Cc: stable@vger.kernel.org # v6.2 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019113650.9060-2-johan+linaro@kernel.org
2023-10-25wifi: ath11k: fix gtk offload status event lockingJohan Hovold
The ath11k active pdevs are protected by RCU but the gtk offload status event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. Fixes: a16d9b50cfba ("ath11k: support GTK rekey offload") Cc: stable@vger.kernel.org # 5.18 Cc: Carl Huang <quic_cjhuang@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019155342.31631-1-johan+linaro@kernel.org
2023-10-25wifi: ath11k: fix htt pktlog lockingJohan Hovold
The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org # 5.6 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019112521.2071-1-johan+linaro@kernel.org
2023-10-25wifi: ath11k: fix dfs radar event lockingJohan Hovold
The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org # 5.6 Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019153115.26401-3-johan+linaro@kernel.org
2023-10-25wifi: ath11k: fix temperature event lockingJohan Hovold
The ath11k active pdevs are protected by RCU but the temperature event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section as reported by RCU lockdep: ============================= WARNING: suspicious RCU usage 6.6.0-rc6 #7 Not tainted ----------------------------- drivers/net/wireless/ath/ath11k/mac.c:638 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/0/0. ... Call trace: ... lockdep_rcu_suspicious+0x16c/0x22c ath11k_mac_get_ar_by_pdev_id+0x194/0x1b0 [ath11k] ath11k_wmi_tlv_op_rx+0xa84/0x2c1c [ath11k] ath11k_htc_rx_completion_handler+0x388/0x510 [ath11k] Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Fixes: a41d10348b01 ("ath11k: add thermal sensor device support") Cc: stable@vger.kernel.org # 5.7 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231019153115.26401-2-johan+linaro@kernel.org
generated by cgit (git 2.34.1) at 2025-09-14 21:45:03 +0000