summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-08-05gcc-plugins: randstruct: Remove GCC 4.7 or newer requirementThorsten Blum
Since the kernel currently requires GCC 5.1 as a minimum, remove the unnecessary GCC version >= 4.7 check. Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Link: https://lore.kernel.org/r/20240723165332.1947-1-thorsten.blum@toblux.com Signed-off-by: Kees Cook <kees@kernel.org>
2024-08-05refcount: Report UAF for refcount_sub_and_test(0) when counter==0Petr Pavlu
When a reference counter is at zero and refcount_sub_and_test() is invoked to subtract zero, the function accepts this request without any warning and returns true. This behavior does not seem ideal because the counter being already at zero indicates a use-after-free. Furthermore, returning true by refcount_sub_and_test() in this case potentially results in a double-free done by its caller. Modify the underlying function __refcount_sub_and_test() to warn about this case as a use-after-free and have it return false to avoid the potential double-free. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240717130023.5675-1-petr.pavlu@suse.com Signed-off-by: Kees Cook <kees@kernel.org>
2024-08-05Merge tag 'linux_kselftest-fixes-6.11-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fix from Shuah Khan: "A single fix to the conditional in ksft.py script which incorrectly flags a test suite failed when there are skipped tests in the mix. The logic is fixed to take skipped tests into account and report the test as passed" * tag 'linux_kselftest-fixes-6.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: ksft: Fix finished() helper exit code on skipped tests
2024-08-05drm/msm/dpu: take plane rotation into account for wide planesDmitry Baryshkov
Take into account the plane rotation and flipping when calculating src positions for the wide plane parts. This is not an issue yet, because rotation is only supported for the UBWC planes and wide UBWC planes are rejected anyway because in parallel multirect case only the half of the usual width is supported for tiled formats. However it's better to fix this now rather than stumbling upon it later. Fixes: 80e8ae3b38ab ("drm/msm/dpu: add support for wide planes") Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/601059/ Link: https://lore.kernel.org/r/20240627-dpu-virtual-wide-v5-3-5efb90cbb8be@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dpu: relax YUV requirementsDmitry Baryshkov
YUV formats require only CSC to be enabled. Even decimated formats should not require scaler. Relax the requirement and don't check for the scaler block while checking if YUV format can be enabled. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/601049/ Link: https://lore.kernel.org/r/20240627-dpu-virtual-wide-v5-2-5efb90cbb8be@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dpu: limit QCM2290 to RGB formats onlyDmitry Baryshkov
The QCM2290 doesn't have CSC blocks, so it can not support YUV formats even on ViG blocks. Fix the formats declared by _VIG_SBLK_NOSCALE(). Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/601048/ Link: https://lore.kernel.org/r/20240627-dpu-virtual-wide-v5-1-5efb90cbb8be@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsDmitry Baryshkov
If the dpu_format_populate_layout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pin_count on the GEM object and causes a splat during DRM file closure: msm_obj->pin_count WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124 hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20 Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/600714/ Link: https://lore.kernel.org/r/20240625-dpu-mode-config-width-v5-1-501d984d634f@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dp: reset the link phy params before link trainingAbhinav Kumar
Before re-starting link training reset the link phy params namely the pre-emphasis and voltage swing levels otherwise the next link training begins at the previously cached levels which can result in link training failures. Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8350-HDK Reviewed-by: Stephen Boyd <swboyd@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/605946/ Link: https://lore.kernel.org/r/20240725220450.131245-1-quic_abhinavk@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()Abhinav Kumar
For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set(). This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call. Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/59 Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8350-HDK Patchwork: https://patchwork.freedesktop.org/patch/606729/ Link: https://lore.kernel.org/r/20240731191723.3050932-1-quic_abhinavk@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05cgroup/cpuset: Eliminate unncessary sched domains rebuilds in hotplugWaiman Long
It was found that some hotplug operations may cause multiple rebuild_sched_domains_locked() calls. Some of those intermediate calls may use cpuset states not in the final correct form leading to incorrect sched domain setting. Fix this problem by using the existing force_rebuild flag to inhibit immediate rebuild_sched_domains_locked() calls if set and only doing one final call at the end. Also renaming the force_rebuild flag to force_sd_rebuild to make its meaning for clear. Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-08-05cgroup/cpuset: Clear effective_xcpus on cpus_allowed clearing only if ↵Waiman Long
cpus.exclusive not set Commit e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") adds a user writable cpuset.cpus.exclusive file for setting exclusive CPUs to be used for the creation of partitions. Since then effective_xcpus depends on both the cpuset.cpus and cpuset.cpus.exclusive setting. If cpuset.cpus.exclusive is set, effective_xcpus will depend only on cpuset.cpus.exclusive. When it is not set, effective_xcpus will be set according to the cpuset.cpus value when the cpuset becomes a valid partition root. When cpuset.cpus is being cleared by the user, effective_xcpus should only be cleared when cpuset.cpus.exclusive is not set. However, that is not currently the case. # cd /sys/fs/cgroup/ # mkdir test # echo +cpuset > cgroup.subtree_control # cd test # echo 3 > cpuset.cpus.exclusive # cat cpuset.cpus.exclusive.effective 3 # echo > cpuset.cpus # cat cpuset.cpus.exclusive.effective // was cleared Fix it by clearing effective_xcpus only if cpuset.cpus.exclusive is not set. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Cc: stable@vger.kernel.org # v6.7+ Reported-by: Chen Ridong <chenridong@huawei.com> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-08-05cgroup/cpuset: fix panic caused by partcmd_updateChen Ridong
We find a bug as below: BUG: unable to handle page fault for address: 00000003 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4 RIP: 0010:partition_sched_domains_locked+0x483/0x600 Code: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9 RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202 RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80 RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002 R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0 Call Trace: <TASK> ? show_regs+0x8c/0xa0 ? __die_body+0x23/0xa0 ? __die+0x3a/0x50 ? page_fault_oops+0x1d2/0x5c0 ? partition_sched_domains_locked+0x483/0x600 ? search_module_extables+0x2a/0xb0 ? search_exception_tables+0x67/0x90 ? kernelmode_fixup_or_oops+0x144/0x1b0 ? __bad_area_nosemaphore+0x211/0x360 ? up_read+0x3b/0x50 ? bad_area_nosemaphore+0x1a/0x30 ? exc_page_fault+0x890/0xd90 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? asm_exc_page_fault+0x26/0x30 ? partition_sched_domains_locked+0x483/0x600 ? partition_sched_domains_locked+0xf0/0x600 rebuild_sched_domains_locked+0x806/0xdc0 update_partition_sd_lb+0x118/0x130 cpuset_write_resmask+0xffc/0x1420 cgroup_file_write+0xb2/0x290 kernfs_fop_write_iter+0x194/0x290 new_sync_write+0xeb/0x160 vfs_write+0x16f/0x1d0 ksys_write+0x81/0x180 __x64_sys_write+0x21/0x30 x64_sys_call+0x2f25/0x4630 do_syscall_64+0x44/0xb0 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f44a553c887 It can be reproduced with cammands: cd /sys/fs/cgroup/ mkdir test cd test/ echo +cpuset > ../cgroup.subtree_control echo root > cpuset.cpus.partition cat /sys/fs/cgroup/cpuset.cpus.effective 0-3 echo 0-3 > cpuset.cpus // taking away all cpus from root This issue is caused by the incorrect rebuilding of scheduling domains. In this scenario, test/cpuset.cpus.partition should be an invalid root and should not trigger the rebuilding of scheduling domains. When calling update_parent_effective_cpumask with partcmd_update, if newmask is not null, it should recheck newmask whether there are cpus is available for parect/cs that has tasks. Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Chen Ridong <chenridong@huawei.com> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-08-05drm/msm/dp: fix the max supported bpp logicAbhinav Kumar
Fix the dp_panel_get_supported_bpp() API to return the minimum supported bpp correctly for relevant cases and use this API to correct the behavior of DP driver which hard-codes the max supported bpp to 30. This is incorrect because the number of lanes and max data rate supported by the lanes need to be taken into account. Replace the hardcoded limit with the appropriate math which accounts for the accurate number of lanes and max data rate. changes in v2: - Fix the dp_panel_get_supported_bpp() and use it - Drop the max_t usage as dp_panel_get_supported_bpp() already returns the min_bpp correctly now changes in v3: - replace min_t with just min as all params are u32 Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/43 Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8350-HDK Reviewed-by: Stephen Boyd <swboyd@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/607073/ Link: https://lore.kernel.org/r/20240805202009.1120981-1-quic_abhinavk@quicinc.com Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05drm/msm/dpu: don't play tricks with debug macrosDmitry Baryshkov
DPU debugging macros need to be converted to a proper drm_debug_* macros, however this is a going an intrusive patch, not suitable for a fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER to make sure that DPU debugging messages always end up in the drm debug messages and are controlled via the usual drm.debug mask. I don't think that it is a good idea for a generic DPU_DEBUG macro to be tied to DRM_UT_KMS. It is used to report a debug message from driver, so by default it should go to the DRM_UT_DRIVER channel. While refactoring debug macros later on we might end up with particular messages going to ATOMIC or KMS, but DRIVER should be the default. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/606932/ Link: https://lore.kernel.org/r/20240802-dpu-fix-wb-v2-2-7eac9eb8e895@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
2024-08-05syscalls: fix fstat() entry againArnd Bergmann
The previous patch to fix the newfstatat() syscall entry ended up breaking fstat() instead. Unfortunately these two are not handled the same way, so I messed this one up the exact opposite way. Fixes: 343416f0c11c ("syscalls: fix syscall macros for newfstat/newfstatat") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-08-05docs: KVM: Fix register ID of SPSR_FIQTakahiro Itazuri
Fixes the register ID of SPSR_FIQ. SPSR_FIQ is a 64-bit register and the 64-bit register size mask is 0x0030000000000000ULL. Fixes: fd3bc912d3d1 ("KVM: Documentation: Document arm64 core registers in detail") Signed-off-by: Takahiro Itazuri <itazur@amazon.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230606154628.95498-1-itazur@amazon.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-08-05arm64: dts: ti: k3-j722s: Fix gpio-range for main_pmx0Jared McArthur
Commit 5e5c50964e2e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed a hole within gpio-range for main_pmx0. As a result, automatic mapping of GPIO to pin control for gpios within the main_pmx0 domain is broken. Fix this by correcting the gpio-range. Fixes: 5e5c50964e2e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties") Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Link: https://lore.kernel.org/r/20240801210414.715306-4-j-mcarthur@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-05arm64: dts: ti: k3-am62p: Fix gpio-range for main_pmx0Jared McArthur
Commit d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed a hole within gpio-range for main_pmx0. As a result, automatic mapping of GPIO to pin control for gpios within the main_pmx0 domain is broken. Fix this by correcting the gpio-range. Fixes: d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Link: https://lore.kernel.org/r/20240801210414.715306-3-j-mcarthur@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-05arm64: dts: ti: k3-am62p: Add gpio-ranges for mcu_gpio0Jared McArthur
Commit d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed introducing the range description for the mcu_gpio node. As a result, automatic mapping of GPIO to pin control for mcu gpios is broken. Fix this by introducing the proper ranges. Fixes: d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Link: https://lore.kernel.org/r/20240801210414.715306-2-j-mcarthur@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-05ASoC: cs35l56: Handle OTP read latency over SoundWireRichard Fitzgerald
Use the late-read buffer in the CS35L56 SoundWire interface to read OTP memory. The OTP memory has a longer access latency than chip registers and cannot guarantee to return the data value in the SoundWire control response if the bus clock is >4.8 MHz. The Cirrus SoundWire peripheral IP exposes the bridge-to-bus read buffer and status bits. For a read from OTP the bridge status bits are polled to wait for the OTP data to be loaded into the read buffer and the data is then read from there. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: e1830f66f6c6 ("ASoC: cs35l56: Add helper functions for amp calibration") Link: https://patch.msgid.link/20240805140839.26042-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-05ASoC: codecs: lpass-macro: fix missing codec versionJohan Hovold
Recent changes that started checking the codec version broke audio on the Lenovo ThinkPad X13s: wsa_macro 3240000.codec: Unsupported Codec version (0) wsa_macro 3240000.codec: probe with driver wsa_macro failed with error -22 rx_macro 3200000.rxmacro: Unsupported Codec version (0) rx_macro 3200000.rxmacro: probe with driver rx_macro failed with error -22 Add the missing codec version to the lookup table so that the codec drivers probe successfully. Note that I'm just assuming that this is a 2.0 codec based on the fact that this device uses the older register layout. Fixes: 378918d59181 ("ASoC: codecs: lpass-macro: add helpers to get codec version") Fixes: dbacef05898d ("ASoC: codec: lpass-rx-macro: prepare driver to accomdate new codec versions") Fixes: 727de4fbc546 ("ASoC: codecs: lpass-wsa-macro: Correct support for newer v2.5 version") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240729131351.27886-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-05i2c: qcom-geni: Add missing clk_disable_unprepare in geni_i2c_runtime_resumeGaosheng Cui
Add the missing clk_disable_unprepare() before return in geni_i2c_runtime_resume(). Fixes: 14d02fbadb5d ("i2c: qcom-geni: add desc struct to prepare support for I2C Master Hub variant") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-08-05Merge tag 'slab-fixes-for-6.11-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab fix from Vlastimil Babka: "Since v6.8 we've had a subtle breakage in SLUB with KFENCE enabled, that can cause a crash. It hasn't been found earlier due to quite specific conditions necessary (OOM during kmem_cache_alloc_bulk())" * tag 'slab-fixes-for-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: mm, slub: do not call do_slab_free for kfence object
2024-08-05drm/bridge-connector: Fix double free in error handling pathsCristian Ciocaltea
The recent switch to drmm allocation in drm_bridge_connector_init() may cause double free on bridge_connector in some of the error handling paths. Drop the explicit kfree() calls on bridge_connector. Fixes: c12907be57b1 ("drm/bridge-connector: switch to using drmm allocations") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: default avatarRobert Foss <rfoss@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240711-bridge-connector-fix-dbl-free-v1-1-d558b2d0eb93@collabora.com
2024-08-05timekeeping: Fix bogus clock_was_set() invocation in do_adjtimex()Thomas Gleixner
The addition of the bases argument to clock_was_set() fixed up all call sites correctly except for do_adjtimex(). This uses CLOCK_REALTIME instead of CLOCK_SET_WALL as argument. CLOCK_REALTIME is 0. As a result the effect of that clock_was_set() notification is incomplete and might result in timers expiring late because the hrtimer code does not re-evaluate the affected clock bases. Use CLOCK_SET_WALL instead of CLOCK_REALTIME to tell the hrtimers code which clock bases need to be re-evaluated. Fixes: 17a1b8826b45 ("hrtimer: Add bases argument to clock_was_set()") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/877ccx7igo.ffs@tglx
2024-08-05ntp: Safeguard against time_constant overflowJustin Stitt
Using syzkaller with the recently reintroduced signed integer overflow sanitizer produces this UBSAN report: UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:738:18 9223372036854775806 + 4 cannot be represented in type 'long' Call Trace: handle_overflow+0x171/0x1b0 __do_adjtimex+0x1236/0x1440 do_adjtimex+0x2be/0x740 The user supplied time_constant value is incremented by four and then clamped to the operating range. Before commit eea83d896e31 ("ntp: NTP4 user space bits update") the user supplied value was sanity checked to be in the operating range. That change removed the sanity check and relied on clamping after incrementing which does not work correctly when the user supplied value is in the overflow zone of the '+ 4' operation. The operation requires CAP_SYS_TIME and the side effect of the overflow is NTP getting out of sync. Similar to the fixups for time_maxerror and time_esterror, clamp the user space supplied value to the operating range. [ tglx: Switch to clamping ] Fixes: eea83d896e31 ("ntp: NTP4 user space bits update") Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Miroslav Lichvar <mlichvar@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20240517-b4-sio-ntp-c-v2-1-f3a80096f36f@google.com Closes: https://github.com/KSPP/linux/issues/352
2024-08-05ntp: Clamp maxerror and esterror to operating rangeJustin Stitt
Using syzkaller alongside the newly reintroduced signed integer overflow sanitizer spits out this report: UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:461:16 9223372036854775807 + 500 cannot be represented in type 'long' Call Trace: handle_overflow+0x171/0x1b0 second_overflow+0x2d6/0x500 accumulate_nsecs_to_secs+0x60/0x160 timekeeping_advance+0x1fe/0x890 update_wall_time+0x10/0x30 time_maxerror is unconditionally incremented and the result is checked against NTP_PHASE_LIMIT, but the increment itself can overflow, resulting in wrap-around to negative space. Before commit eea83d896e31 ("ntp: NTP4 user space bits update") the user supplied value was sanity checked to be in the operating range. That change removed the sanity check and relied on clamping in handle_overflow() which does not work correctly when the user supplied value is in the overflow zone of the '+ 500' operation. The operation requires CAP_SYS_TIME and the side effect of the overflow is NTP getting out of sync. Miroslav confirmed that the input value should be clamped to the operating range and the same applies to time_esterror. The latter is not used by the kernel, but the value still should be in the operating range as it was before the sanity check got removed. Clamp them to the operating range. [ tglx: Changed it to clamping and included time_esterror ] Fixes: eea83d896e31 ("ntp: NTP4 user space bits update") Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Miroslav Lichvar <mlichvar@redhat.com> Link: https://lore.kernel.org/all/20240517-b4-sio-ntp-usec-v2-1-d539180f2b79@google.com Closes: https://github.com/KSPP/linux/issues/354
2024-08-05arm64: dts: ti: k3-am62-verdin-dahlia: Keep CTRL_SLEEP_MOCI# regulator onFrancesco Dolcini
This reverts commit 3935fbc87ddebea5439f3ab6a78b1e83e976bf88. CTRL_SLEEP_MOCI# is a signal that is defined for all the SoM implementing the Verdin family specification, this signal is supposed to control the power enable in the carrier board when the system is in deep sleep mode. However this is not possible with Texas Instruments AM62 SoC, IOs output buffer is disabled in deep sleep and IOs are in tri-state mode. Given that we cannot properly control this pin, force it to be always high to minimize potential issues. Fixes: 3935fbc87dde ("arm64: dts: ti: k3-am62-verdin-dahlia: support sleep-moci") Cc: <stable@vger.kernel.org> Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1361669/am625-gpio-output-state-in-deep-sleep/5244802 Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240731054804.6061-1-francesco@dolcini.it Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-05drm/mediatek: Set sensible cursor width/height values to fix crashAngeloGioacchino Del Regno
Hardware-speaking, there is no feature-reduced cursor specific plane, so this driver reserves the last all Overlay plane as a Cursor plane, but sets the maximum cursor width/height to the maximum value that the full overlay plane can use. While this could be ok, it raises issues with common userspace using libdrm (especially Mutter, but other compositors too) which will crash upon performing allocations and/or using said cursor plane. Reduce the maximum width/height for the cursor to 512x512 pixels, value taken from IGT's maximum cursor size test, which succeeds. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Fei Shao <fshao@chromium.org> Tested-by: Fei Shao <fshao@chromium.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240718082410.204459-1-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2024-08-05ALSA: line6: Fix racy access to midibufTakashi Iwai
There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. Reported-by: syzbot+78eccfb8b3c9a85fc6c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/00000000000000949c061df288c5@google.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20240805130129.10872-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-05drm/omap: add CONFIG_MMU dependencyArnd Bergmann
Compile-testing with CONFIG_MMU disabled causes a link error in omapdrm: arm-linux-gnueabi-ld: drivers/gpu/drm/omapdrm/omap_gem.o: in function `omap_gem_fault_2d': omap_gem.c:(.text+0x36e): undefined reference to `vmf_insert_mixed' arm-linux-gnueabi-ld: drivers/gpu/drm/omapdrm/omap_gem.o: in function `omap_gem_fault': omap_gem.c:(.text+0x74a): undefined reference to `vmf_insert_mixed' Avoid this by adding a Kconfig dependency. Fixes: dc6fcaaba5a5 ("drm/omap: Allow build with COMPILE_TEST=y") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240719095942.3841009-1-arnd@kernel.org
2024-08-05ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULLRichard Fitzgerald
Call efi_rt_services_supported() to check that efi.get_variable exists before calling it. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 1cad8725f2b9 ("ASoC: cs-amp-lib: Add helpers for factory calibration data") Link: https://patch.msgid.link/20240805114222.15722-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-05ASoC: cs35l56: Stop creating ALSA controls for firmware coefficientsSimon Trimmer
A number of laptops have gone to market with old firmware versions that export controls that have since been hidden, but we can't just install a newer firmware because the firmware for each product is customized and qualified by the OEM. The issue is that alsactl save and restore has no idea what controls are good to persist which can lead to misconfiguration. There is no reason that the UCM or user should need to interact with any of the ALSA controls for the firmware coefficients so they can be removed entirely. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20240805102721.30102-3-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-05ASoC: wm_adsp: Add control_add callback and export wm_adsp_control_add()Simon Trimmer
The callback allows codec drivers to affect how firmware coefficients are added as controls. For example a codec driver may selectively add controls by choosing to call wm_adsp_control_add() based on some filter logic. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20240805102721.30102-2-simont@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-05pmdomain: imx: scu-pd: Remove duplicated clocksAlexander Stein
These clocks are already added to the list. Remove the duplicates ones. Fixes: a67d780720ff ("genpd: imx: scu-pd: add more PDs") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240717080334.2210988-1-alexander.stein@ew.tq-group.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-08-05net: usb: qmi_wwan: fix memory leak for not ip packetsDaniele Palmas
Free the unused skb when not ip packets arrive. Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-05Merge branch 'virtio-net-rq-coalescing' into mainDavid S. Miller
Heng Qi says: ==================== virtio-net: unbreak vq resizing if vq coalescing is not supported Currently, if the driver does not negotiate the vq coalescing feature but supports vq resize, the vq resize action, which could have been successfully executed, is interrupted due to the failure in configuring the vq coalescing parameters. This issue needs to be fixed. Changelog ========= v3->v4: - Add a comment for patch[2/2]. v2->v3: - Break out the feature check and the fix into separate patches. v1->v2: - Rephrase the subject. - Put the feature check inside the virtnet_send_{r,t}x_ctrl_coal_vq_cmd. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-05virtio-net: unbreak vq resizing when coalescing is not negotiatedHeng Qi
Don't break the resize action if the vq coalescing feature named VIRTIO_NET_F_VQ_NOTF_COAL is not negotiated. Fixes: f61fe5f081cf ("virtio-net: fix the vq coalescing setting for vq resize") Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by: Eugenio Pé rez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-05virtio-net: check feature before configuring the vq coalescing commandHeng Qi
Virtio spec says: The driver MUST have negotiated the VIRTIO_NET_F_VQ_NOTF_COAL feature when issuing commands VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET. So we add the feature negotiation check to virtnet_send_{r,t}x_ctrl_coal_vq_cmd as a basis for the next bugfix patch. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-08-05drm/i915/display: correct dual pps handling for MTL_PCH+Dnyaneshwar Bhadane
On the PCH side the second PPS was introduced in ICP+.Add condition On MTL_PCH and greater platform also having the second PPS. Note that DG1/2 south block only has the single PPS, so need to exclude the fake DG1/2 PCHs Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11488 Fixes: 93cbc1accbce ("drm/i915/mtl: Add fake PCH for Meteor Lake") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801111141.574854-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit da1878b61c8d480c361ba6a39ce8a31c80b65826) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-08-05wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850Baochen Qiang
In transmit path, it is likely that the iova is not aligned to PCIe TLP max payload size, which is 128 for WCN7850. Normally in such cases hardware is expected to split the packet into several parts in a manner such that they, other than the first one, have aligned iova. However due to hardware limitations, WCN7850 does not behave like that properly with some specific unaligned iova in transmit path. This easily results in target hang in a KPI transmit test: packet send/receive failure, WMI command send timeout etc. Also fatal error seen in PCIe level: ... Capabilities: ... ... DevSta: ... FatalErr+ ... ... ... Work around this by manually moving/reallocating payload buffer such that we can map it to a 128 bytes aligned iova. The moving requires sufficient head room or tail room in skb: for the former we can do ourselves a favor by asking some extra bytes when registering with mac80211, while for the latter we can do nothing. Moving/reallocating buffer consumes additional CPU cycles, but the good news is that an aligned iova increases PCIe efficiency. In my tests on some X86 platforms the KPI results are almost consistent. Since this is seen only with WCN7850, add a new hardware parameter to differentiate from others. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Cc: <stable@vger.kernel.org> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240715023814.20242-1-quic_bqiang@quicinc.com
2024-08-05ALSA: hda: cs35l41: Stop creating ALSA Controls for firmware coefficientsStefan Binding
When the CS35L41 loads its firmware, it has a number of controls to affect its behaviour. Currently, these controls are exposed as ALSA Controls. These controls were never intended to be exposed to users but the firmware doesn't mark them hidden, so make the driver ignore them. Any changes in the coefficients handled by these controls needs to be matched to the individual system by SSID, which is already handled using the tuning file, when firmware is loaded, so UCM should not be setting these controls anyway. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://patch.msgid.link/20240801155047.456540-1-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-05ALSA: hda: cs35l56: Stop creating ALSA controls for firmware coefficientsSimon Trimmer
A number of laptops have gone to market with old firmware versions that export controls that have since been hidden, but we can't just install a newer firmware because the firmware for each product is customized and qualified by the OEM. The issue is that alsactl save and restore has no idea what controls are good to persist which can lead to misconfiguration. There is no reason that the UCM or user should need to interact with any of the ALSA controls for the firmware coefficients so they can be removed entirely, this also simplifies the driver. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Link: https://patch.msgid.link/20240801143139.34549-1-simont@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-05kprobes: Fix to check symbol prefixes correctlyMasami Hiramatsu (Google)
Since str_has_prefix() takes the prefix as the 2nd argument and the string as the first, is_cfi_preamble_symbol() always fails to check the prefix. Fix the function parameter order so that it correctly check the prefix. Link: https://lore.kernel.org/all/172260679559.362040.7360872132937227206.stgit@devnote2/ Fixes: de02f2ac5d8c ("kprobes: Prohibit probing on CFI preamble symbol") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2024-08-05bpf: kprobe: remove unused declaring of bpf_kprobe_overrideMenglong Dong
After the commit 66665ad2f102 ("tracing/kprobe: bpf: Compare instruction pointer with original one"), "bpf_kprobe_override" is not used anywhere anymore, and we can remove it now. Link: https://lore.kernel.org/all/20240710085939.11520-1-dongml2@chinatelecom.cn/ Fixes: 66665ad2f102 ("tracing/kprobe: bpf: Compare instruction pointer with original one") Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2024-08-04Input: uinput - reject requests with unreasonable number of slotsDmitry Torokhov
From: Dmitry Torokhov <dmitry.torokhov@gmail.com> When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request. Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts. Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+0122fa359a69694395d5@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5 Link: https://lore.kernel.org/r/Zqgi7NYEbpRsJfa2@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-08-04Input: edt-ft5x06 - add support for FocalTech FT8201Felix Kaechele
The driver supports the FT8201 chip as well. It registers up to 10 touch points. Tested on: Lenovo ThinkSmart View (CD-18781Y), LCM: BOE TV080WXM-LL4 Signed-off-by: Felix Kaechele <felix@kaechele.ca> Link: https://lore.kernel.org/r/20240804031310.331871-3-felix@kaechele.ca Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-08-04dt-bindings: input: touchscreen: edt-ft5x06: Document FT8201 supportFelix Kaechele
Document FocalTech FT8201 support by adding the compatible. Signed-off-by: Felix Kaechele <felix@kaechele.ca> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240804031310.331871-2-felix@kaechele.ca Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-08-04Linux 6.11-rc2v6.11-rc2Linus Torvalds
2024-08-04profiling: remove profile=sleep supportTetsuo Handa
The kernel sleep profile is no longer working due to a recursive locking bug introduced by commit 42a20f86dc19 ("sched: Add wrapper for get_wchan() to keep task blocked") Booting with the 'profile=sleep' kernel command line option added or executing # echo -n sleep > /sys/kernel/profiling after boot causes the system to lock up. Lockdep reports kthreadd/3 is trying to acquire lock: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: get_wchan+0x32/0x70 but task is already holding lock: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370 with the call trace being lock_acquire+0xc8/0x2f0 get_wchan+0x32/0x70 __update_stats_enqueue_sleeper+0x151/0x430 enqueue_entity+0x4b0/0x520 enqueue_task_fair+0x92/0x6b0 ttwu_do_activate+0x73/0x140 try_to_wake_up+0x213/0x370 swake_up_locked+0x20/0x50 complete+0x2f/0x40 kthread+0xfb/0x180 However, since nobody noticed this regression for more than two years, let's remove 'profile=sleep' support based on the assumption that nobody needs this functionality. Fixes: 42a20f86dc19 ("sched: Add wrapper for get_wchan() to keep task blocked") Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>