aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-11drm/msm: Avoid potential overflow in timeout_to_jiffies()Marek Vasut1-2/+2
The return type of ktime_divns() is s64. The timeout_to_jiffies() currently assigns the result of this ktime_divns() to unsigned long, which on 32 bit systems may overflow. Furthermore, the result of this function is sometimes also passed to functions which expect signed long, dma_fence_wait_timeout() is one such example. Fix this by adjusting the type of remaining_jiffies to s64, so we do not suffer overflow there, and return a value limited to range of 0..INT_MAX, which is safe for all usecases of this timeout. The above overflow can be triggered if userspace passes in too large timeout value, larger than INT_MAX / HZ seconds. The kernel detects it and complains about "schedule_timeout: wrong timeout value %lx" and generates a warning backtrace. Note that this fixes commit 6cedb8b377bb ("drm/msm: avoid using 'timespec'"), because the previously used timespec_to_jiffies() function returned unsigned long instead of s64: static inline unsigned long timespec_to_jiffies(const struct timespec *value) Fixes: 6cedb8b377bb ("drm/msm: avoid using 'timespec'") Signed-off-by: Marek Vasut <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Jordan Crouse <[email protected]> Cc: Rob Clark <[email protected]> Cc: [email protected] # 5.6+ Acked-by: Arnd Bergmann <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-10-11drm/msm: Fix devfreq NULL pointer dereference on a3xxStephan Gerhold1-0/+6
There is no devfreq on a3xx at the moment since gpu_busy is not implemented. This means that msm_devfreq_init() will return early and the entire devfreq setup is skipped. However, msm_devfreq_active() and msm_devfreq_idle() are still called unconditionally later, causing a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 0 PID: 133 Comm: ring0 Not tainted 5.15.0-rc1 #4 Hardware name: Longcheer L8150 (DT) pc : mutex_lock_io+0x2bc/0x2f0 lr : msm_devfreq_active+0x3c/0xe0 [msm] Call trace: mutex_lock_io+0x2bc/0x2f0 msm_gpu_submit+0x164/0x180 [msm] msm_job_run+0x54/0xe0 [msm] drm_sched_main+0x2b0/0x4a0 [gpu_sched] kthread+0x154/0x160 ret_from_fork+0x10/0x20 Fix this by adding a check in msm_devfreq_active/idle() which ensures that devfreq was actually initialized earlier. Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Reported-by: Nikita Travkin <[email protected]> Tested-by: Nikita Travkin <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-10-11drm/msm/dp: only signal audio when disconnected detected at dp_pm_resumeKuogee Hsieh1-5/+5
Currently there is audio not working problem after system resume from suspend if hdmi monitor stay plugged in at DUT. However this problem does not happen at normal operation but at a particular test case. The root cause is DP driver signal audio with connected state at resume which trigger audio trying to setup audio data path through DP main link but failed due to display port is not setup and enabled by upper layer framework yet. This patch only have DP driver signal audio only when DP is in disconnected state so that audio option shows correct state after system resume. DP driver will not signal audio with connected state until display enabled executed by upper layer framework where display port is setup completed and main link is running. Changes in V2: -- add details commit text Fixes: afc9b8b6bab8 ("drm/msm/dp: signal audio plugged change at dp_pm_resume") Signed-off-by: Kuogee Hsieh <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-10-11Merge tag 'linux-kselftest-kunit-fixes-5.15-rc6' of ↵Linus Torvalds9-9/+43
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull Kunit fixes from Shuah Khan: - Fixes to address the structleak plugin causing the stack frame size to grow immensely when used with KUnit. Fixes include adding a new makefile to disable structleak and using it from KUnit iio, device property, thunderbolt, and bitfield tests to disable it. - KUnit framework reference count leak in kfree_at_end - KUnit tool fix to resolve conflict between --json and --raw_output and generate correct test output in either case. - kernel-doc warnings due to mismatched arg names * tag 'linux-kselftest-kunit-fixes-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: fix kernel-doc warnings due to mismatched arg names bitfield: build kunit tests without structleak plugin thunderbolt: build kunit tests without structleak plugin device property: build kunit tests without structleak plugin iio/test-format: build kunit tests without structleak plugin gcc-plugins/structleak: add makefile var for disabling structleak kunit: fix reference count leak in kfree_at_end kunit: tool: better handling of quasi-bool args (--json, --raw_output)
2021-10-11Merge branch 'for-5.15-fixes' of ↵Linus Torvalds2-41/+43
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "All documentation / comment updates" * 'for-5.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroupv2, docs: fix misinformation in "device controller" section cgroup/cpuset: Change references of cpuset_mutex to cpuset_rwsem docs/cgroup: remove some duplicate words
2021-10-12Revert "drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb"Chun-Kuang Hu1-13/+3
This reverts commit c1ec54b7b5af25c779192253f5a9f05e95cb43d7. Commit c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb") would cause numerous mtk cmdq mailbox driver warning: WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 So revert that patch. Reported-by: Enric Balletbo Serra <[email protected]> Tested-by: Enric Balletbo Serra <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-10-12Revert "drm/mediatek: Remove struct cmdq_client"Chun-Kuang Hu1-62/+18
This reverts commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837. Commit c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb") would cause numerous mtk cmdq mailbox driver warning: WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 So revert that patch and all the patches depend on that patch. Reported-by: Enric Balletbo Serra <[email protected]> Tested-by: Enric Balletbo Serra <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-10-12Revert "drm/mediatek: Detect CMDQ execution timeout"Chun-Kuang Hu1-12/+2
This reverts commit 8cdcb365342402fdeb664479b0a04e9debef8efb. Commit c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb") would cause numerous mtk cmdq mailbox driver warning: WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 So revert that patch and all the patches depend on that patch. Reported-by: Enric Balletbo Serra <[email protected]> Tested-by: Enric Balletbo Serra <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-10-12Revert "drm/mediatek: Add cmdq_handle in mtk_crtc"Chun-Kuang Hu1-18/+10
This reverts commit bc9241be73d9b2b3bcb7033598521fd669639848. Commit c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb") would cause numerous mtk cmdq mailbox driver warning: WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 So revert that patch and all the patches depend on that patch. Reported-by: Enric Balletbo Serra <[email protected]> Tested-by: Enric Balletbo Serra <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-10-12Revert "drm/mediatek: Clear pending flag when cmdq packet is done"Chun-Kuang Hu1-42/+5
This reverts commit 9efb16c2fdd647d3888fd8dae84509f485cd554e. Commit c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb") would cause numerous mtk cmdq mailbox driver warning: WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 So revert that patch and all the patches depend on that patch. Reported-by: Enric Balletbo Serra <[email protected]> Tested-by: Enric Balletbo Serra <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-10-11Merge branch 'for-5.15-fixes' of ↵Linus Torvalds2-5/+18
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fixes from Tejun Heo: "One patch to add a missing __printf annotation and the other to enable deferred printing for debug dumps to avoid deadlocks when triggered from some contexts (e.g. console drivers)" * 'for-5.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: fix state-dump console deadlock workqueue: annotate alloc_workqueue() as printf
2021-10-11Merge tag 'for-5.15-rc5-tag' of ↵Linus Torvalds5-52/+97
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "A few more error handling fixes, stemming from code inspection, error injection or fuzzing" * tag 'for-5.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix abort logic in btrfs_replace_file_extents btrfs: check for error when looking up inode during dir entry replay btrfs: unify lookup return value when dir entry is missing btrfs: deal with errors when adding inode reference during log replay btrfs: deal with errors when replaying dir entry during log replay btrfs: deal with errors when checking if a dir entry exists during log replay btrfs: update refs for any root except tree log roots btrfs: unlock newly allocated extent buffer after error
2021-10-11arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZEMike Kravetz1-1/+1
For non-4K PAGE_SIZE configs, the largest gigantic huge page size is CONT_PMD_SHIFT order. On arm64 with 64K PAGE_SIZE, the gigantic page is 16G. Therefore, one should be able to specify 'hugetlb_cma=16G' on the kernel command line so that one gigantic page can be allocated from CMA. However, when adding such an option the following message is produced: hugetlb_cma: cma area should be at least 8796093022208 MiB This is because the calculation for non-4K gigantic page order is incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve(). Fixes: abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs") Cc: <[email protected]> # 5.9.x Signed-off-by: Mike Kravetz <[email protected]> Reviewed-by: Anshuman Khandual <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-10-11x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automaticallyBorislav Petkov1-1/+0
This Kconfig option was added initially so that memory encryption is enabled by default on machines which support it. However, devices which have DMA masks that are less than the bit position of the encryption bit, aka C-bit, require the use of an IOMMU or the use of SWIOTLB. If the IOMMU is disabled or in passthrough mode, the kernel would switch to SWIOTLB bounce-buffering for those transfers. In order to avoid that, 2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active") disables the default IOMMU passthrough mode so that devices for which the default 256K DMA is insufficient, can use the IOMMU instead. However 2, there are cases where the IOMMU is disabled in the BIOS, etc. (think the usual hardware folk "oops, I dropped the ball there" cases) or a driver doesn't properly use the DMA APIs or a device has a firmware or hardware bug, e.g.: ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active") However 3, in the above GPU use case, there are APIs like Vulkan and some OpenGL/OpenCL extensions which are under the assumption that user-allocated memory can be passed in to the kernel driver and both the GPU and CPU can do coherent and concurrent access to the same memory. That cannot work with SWIOTLB bounce buffers, of course. So, in order for those devices to function, drop the "default y" for the SME by default active option so that users who want to have SME enabled, will need to either enable it in their config or use "mem_encrypt=on" on the kernel command line. [ tlendacky: Generalize commit message. ] Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support") Reported-by: Paul Menzel <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Tom Lendacky <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-11workqueue: fix state-dump console deadlockJohan Hovold1-2/+16
Console drivers often queue work while holding locks also taken in their console write paths, something which can lead to deadlocks on SMP when dumping workqueue state (e.g. sysrq-t or on suspend failures). For serial console drivers this could look like: CPU0 CPU1 ---- ---- show_workqueue_state(); lock(&pool->lock); <IRQ> lock(&port->lock); schedule_work(); lock(&pool->lock); printk(); lock(console_owner); lock(&port->lock); where workqueues are, for example, used to push data to the line discipline, process break signals and handle modem-status changes. Line disciplines and serdev drivers can also queue work on write-wakeup notifications, etc. Reworking every console driver to avoid queuing work while holding locks also taken in their write paths would complicate drivers and is neither desirable or feasible. Instead use the deferred-printk mechanism to avoid printing while holding pool locks when dumping workqueue state. Note that there are a few WARN_ON() assertions in the workqueue code which could potentially also trigger a deadlock. Hopefully the ongoing printk rework will provide a general solution for this eventually. This was originally reported after a lockdep splat when executing sysrq-t with the imx serial driver. Fixes: 3494fc30846d ("workqueue: dump workqueues on sysrq-t") Cc: [email protected] # 4.0 Reported-by: Fabio Estevam <[email protected]> Tested-by: Fabio Estevam <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: John Ogness <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2021-10-11fs/ntfs3: Refactor ntfs_read_mftKonstantin Komarov1-14/+8
Don't save size of attribute reparse point as size of symlink. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11fs/ntfs3: Refactor ni_parse_reparseKonstantin Komarov2-5/+6
Change argument from void* to struct REPARSE_DATA_BUFFER* We copy data to buffer, so we can read it later in ntfs_read_mft. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11fs/ntfs3: Refactor ntfs_create_inodeKonstantin Komarov1-3/+8
Set size for symlink, so we don't need to calculate it on the fly. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11fs/ntfs3: Refactor ntfs_readlink_hlpKonstantin Komarov1-48/+43
Rename some variables. Returned err by default is EINVAL. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11fs/ntfs3: Rework ntfs_utf16_to_nlsKonstantin Komarov2-12/+9
Now ntfs_utf16_to_nls takes length as one of arguments. If length of symlink > 255, then we tried to convert length of symlink +- some random number. Now 255 symbols limit was removed. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11drm/i915: remember to call i915_sw_fence_finiMatthew Auld1-0/+1
Seems to fix some object-debug splat which appeared while debugging something unrelated. v2: s/guc_blocked/guc_state.blocked/ Signed-off-by: Matthew Auld <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Matthew Brost <[email protected]> Tested-by: Ville Syrjälä <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d576b31bdece7b5034047cbe21170e948198d32f) Signed-off-by: Jani Nikula <[email protected]>
2021-10-11fs/ntfs3: Fix memory leak if fill_super failedKonstantin Komarov1-34/+56
In ntfs_init_fs_context we allocate memory in fc->s_fs_info. In case of failed mount we must free it in ntfs_fill_super. We can't do it in ntfs_fs_free, because ntfs_fs_free called with fc->s_fs_info == NULL. fc->s_fs_info became NULL in sget_fc. Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctlTakashi Iwai1-1/+71
Michael Forney reported an incorrect padding type that was defined in the commit 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") for PCM control mmap data. His analysis is correct, and this caused the misplacements of PCM control data on 32bit arch and 32bit compat mode. The bug is that the __pad2 definition in __snd_pcm_mmap_control64 struct was wrongly with __pad_before_uframe, which should have been __pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and control mmap. Basically this bug leads to two problems: - The offset of avail_min field becomes wrong, it's placed right after appl_ptr without padding on little-endian - When appl_ptr and avail_min are read as 64bit values in kernel side, the values become either zero or corrupted (mixed up) One good news is that, because both user-space and kernel misunderstand the wrong offset, at least, 32bit application running on 32bit kernel works as is. Also, 64bit applications are unaffected because the padding size is zero. The remaining problem is the 32bit compat mode; as mentioned in the above, avail_min is placed right after appl_ptr on little-endian archs, 64bit kernel reads bogus values for appl_ptr updates, which may lead to streaming bugs like jumping, XRUN or whatever unexpected. (However, we haven't heard any serious bug reports due to this over years, so practically seen, it's fairly safe to assume that the impact by this bug is limited.) Ideally speaking, we should correct the wrong mmap status control definition. But this would cause again incompatibility with the existing binaries, and fixing it (e.g. by renumbering ioctls) would be really messy. So, as of this patch, we only correct the behavior of 32bit compat mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now handled differently in compat mode to read/write the 32bit values at the right offsets. The control mmap of 32bit apps on 64bit kernels has been already disabled (which is likely rather an overlook, but this worked fine at this time :), so covering SYNC_PTR ioctl should suffice as a fallback. Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Michael Forney <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Cc: <[email protected]> Cc: Rich Felker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-10-11fs/ntfs3: Keep prealloc for all types of filesKonstantin Komarov1-7/+1
Before we haven't kept prealloc for sparse files because we thought that it will speed up create / write operations. It lead to situation, when user reserved some space for sparse file, filled volume, and wasn't able to write in reserved file. With this commit we keep prealloc. Now xfstest generic/274 pass. Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov <[email protected]>
2021-10-11platform/x86: int1092: Fix non sequential device mode handlingShravan S2-9/+16
SAR information from BIOS may come in non sequential pattern. To overcome the issue, a check is made to extract the right SAR information using the device mode which is currently being used. Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Shravan S <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: intel_skl_int3472: Correct null checkDaniel Scally1-1/+1
The int3472-discrete driver can enter an error path after initialising int3472->clock.ena_gpio, but before it has registered the clock. This will cause a NULL pointer dereference, because clkdev_drop() is not null aware. Instead of guarding the call to skl_int3472_unregister_clock() by checking for .ena_gpio, check specifically for the presence of the clk_lookup, which will guarantee clkdev_create() has already been called. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453 Fixes: 7540599a5ef1 ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()") Signed-off-by: Daniel Scally <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2Zephaniah E. Loss-Cutler-Hull1-0/+1
This works just fine on my system. Signed-off-by: Zephaniah E. Loss-Cutler-Hull <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: amd-pmc: Add alternative acpi id for PMC controllerSachi King1-0/+1
The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. Include AMD0005 in the acpi id list. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Cc: <[email protected]> # 5.14+ Signed-off-by: Sachi King <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: intel_scu_ipc: Update timeout value in commentPrashant Malani1-1/+1
The comment decribing the IPC timeout hadn't been updated when the actual timeout was changed from 3 to 5 seconds in commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") . Since the value is anyway updated to 10s now, take this opportunity to update the value in the comment too. Signed-off-by: Prashant Malani <[email protected]> Cc: Benson Leung <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: intel_scu_ipc: Increase virtual timeout to 10sPrashant Malani1-1/+1
Commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") states that the recommended timeout range is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10 seconds, to account for situations where the 5 seconds is insufficient for disconnect command success. Signed-off-by: Prashant Malani <[email protected]> Cc: Benson Leung <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: intel_scu_ipc: Fix busy loop expiry timePrashant Malani1-1/+1
The macro IPC_TIMEOUT is already in jiffies (it is also used like that elsewhere in the file when calling wait_for_completion_timeout()). Don’t convert it using helper functions for the purposes of calculating the busy loop expiry time. Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”) Signed-off-by: Prashant Malani <[email protected]> Cc: Benson Leung <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMIHans de Goede1-0/+1
DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver, so it must depend on the Kconfig option which enables the main dell-wmi driver. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-10-11platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributesVadim Pasternak1-1/+1
Fix shift argument for function rol32(). It should be provided in bits, while was provided in bytes. Fixes: 86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes") Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() callVadim Pasternak1-1/+1
Change kstrtou32() argument 'base' to be zero instead of 'len'. It works by chance for setting one bit value, but it is not supposed to work in case value passed to mlxreg_io_attr_store() is greater than 1. It works for example, for: echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable But it will fail for: echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable, where n > 1. The flow for input buffer conversion is as below: _kstrtoull(const char *s, unsigned int base, unsigned long long *res) calls: rv = _parse_integer(s, base, &_res); For the second case, where n > 1: - _parse_integer() converts 's' to 'val'. For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3 'len' is set to 3 (string buffer 0x33 0x0a), etcetera. - 'base' is equal or greater then '2' (length of input buffer). As a result, _parse_integer() exits with result zero (rv): rv = 0; while (1) { ... if (val >= base)-> (2 >= 2) break; ... rv++; ... } And _kstrtoull() in their turn will fail: if (rv == 0) return -EINVAL; Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-10-11spi: bcm-qspi: clear MSPI spifie interrupt during probeKamal Dasu1-32/+45
Intermittent Kernel crash has been observed on probe in bcm_qspi_mspi_l2_isr() handler when the MSPI spifie interrupt bit has not been cleared before registering for interrupts. Fix the driver to move SoC specific custom interrupt handling code before we register IRQ in probe. Also clear MSPI interrupt status resgiter prior to registering IRQ handlers. Fixes: cc20a38612db ("spi: iproc-qspi: Add Broadcom iProc SoCs support") Signed-off-by: Kamal Dasu <[email protected]> Acked-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-10-11ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2Cameron Berkenpas1-1/+1
The previous patch's HDA verb initialization for the Lenovo 13s sequence was slightly off. This updated verb sequence has been tested and confirmed working. Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Cc: <[email protected]> Signed-off-by: Cameron Berkenpas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-10-11Merge tag 'ffa-fixes-5.15' of ↵Arnd Bergmann1-1/+9
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm FF-A driver fixes for v5.15 Couple of fixes addressing issues when FFA driver is build as a module. One adds the device unregistration which was missing and causes issue when loading the module second time after unloading once. Another one adds the missing remove callback on the ffa bus which was missing due to which modules depending on FFA(e.g. OPTEE) will fail to remove the device and faults next time that module is loaded again. * tag 'ffa-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Fix __ffa_devices_unregister firmware: arm_ffa: Add missing remove callback to ffa_bus_type Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-10-11xhci: Enable trust tx length quirk for Fresco FL11 USB controllerNikolay Martynov1-0/+2
Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth. Cc: [email protected] Signed-off-by: Nikolay Martynov <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-10-11xhci: Fix command ring pointer corruption while aborting a commandPavankumar Kondeti1-4/+10
The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Cc: [email protected] Signed-off-by: Pavankumar Kondeti <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-10-11USB: xhci: dbc: fix tty registration raceJohan Hovold1-15/+13
Make sure to allocate resources before registering the tty device to avoid having a racing open() and write() fail to enable rx or dereference a NULL pointer when accessing the uninitialised fifo. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: [email protected] # 4.16 Cc: Lu Baolu <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-10-11xhci: add quirk for host controllers that don't update endpoint DCSJonathan Bell3-2/+28
Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. [ bjorn: rebased to v5.14-rc2 ] Link: https://github.com/raspberrypi/linux/issues/3060 Cc: [email protected] Signed-off-by: Jonathan Bell <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-10-11xhci: guard accesses to ep_state in xhci_endpoint_reset()Jonathan Bell1-0/+5
See https://github.com/raspberrypi/linux/issues/3981 Two read-modify-write cycles on ep->ep_state are not guarded by xhci->lock. Fix these. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: [email protected] Signed-off-by: Jonathan Bell <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-10-10tracing: Fix missing * in comment blockColin Ian King1-1/+1
There is a missing * in a comment block, add it in. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-10-10bootconfig: init: Fix memblock leak in xbc_make_cmdline()Masami Hiramatsu1-0/+1
Free unused memblock in a error case to fix memblock leak in xbc_make_cmdline(). Link: https://lkml.kernel.org/r/163177339181.682366.8713781325929549256.stgit@devnote2 Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line") Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-10-10tracing: Fix memory leak in eprobe_register()Vamshi K Sthambamkadi1-0/+7
kmemleak report: unreferenced object 0xffff900a70ec7ec0 (size 32): comm "ftracetest", pid 2770, jiffies 4295042510 (age 311.464s) hex dump (first 32 bytes): c8 31 23 45 0a 90 ff ff 40 85 c7 6e 0a 90 ff ff .1#[email protected].... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009d3751fd>] kmem_cache_alloc_trace+0x2a2/0x440 [<0000000088b8124b>] eprobe_register+0x1e3/0x350 [<000000002a9a0517>] __ftrace_event_enable_disable+0x7c/0x240 [<0000000019109321>] event_enable_write+0x93/0xe0 [<000000007d85b320>] vfs_write+0xb9/0x260 [<00000000b94c5e41>] ksys_write+0x67/0xe0 [<000000005a08c81d>] __x64_sys_write+0x1a/0x20 [<00000000240bf576>] do_syscall_64+0x3b/0xc0 [<0000000043d5d9f6>] entry_SYSCALL_64_after_hwframe+0x44/0xae unreferenced object 0xffff900a56bbf280 (size 128): comm "ftracetest", pid 2770, jiffies 4295042510 (age 311.464s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff 00 00 00 00 01 00 00 00 ................ 80 69 3b b2 ff ff ff ff 20 69 3b b2 ff ff ff ff .i;..... i;..... backtrace: [<000000009d3751fd>] kmem_cache_alloc_trace+0x2a2/0x440 [<00000000c4e90fad>] eprobe_register+0x1fc/0x350 [<000000002a9a0517>] __ftrace_event_enable_disable+0x7c/0x240 [<0000000019109321>] event_enable_write+0x93/0xe0 [<000000007d85b320>] vfs_write+0xb9/0x260 [<00000000b94c5e41>] ksys_write+0x67/0xe0 [<000000005a08c81d>] __x64_sys_write+0x1a/0x20 [<00000000240bf576>] do_syscall_64+0x3b/0xc0 [<0000000043d5d9f6>] entry_SYSCALL_64_after_hwframe+0x44/0xae In new_eprobe_trigger(), allocated edata and trigger variables are never freed. To fix, free memory in disable_eprobe(). Link: https://lkml.kernel.org/r/20211008071802.GA2098@cosmos Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events") Signed-off-by: Vamshi K Sthambamkadi <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-10-10Linux 5.15-rc5Linus Torvalds1-1/+1
2021-10-10Merge tag 'powerpc-5.15-3' of ↵Linus Torvalds17-75/+234
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "A bit of a big batch, partly because I didn't send any last week, and also just because the BPF fixes happened to land this week. Summary: - Fix a regression hit by the IPR SCSI driver, introduced by the recent addition of MSI domains on pseries. - A big series including 8 BPF fixes, some with potential security impact and the rest various code generation issues. - Fix our program check assembler entry path, which was accidentally jumping into a gas macro and generating strange stack frames, which could confuse find_bug(). - A couple of fixes, and related changes, to fix corner cases in our machine check handling. - Fix our DMA IOMMU ops, which were not always returning the optimal DMA mask, leading to at least one device falling back to 32-bit DMA when it shouldn't. - A fix for KUAP handling on 32-bit Book3S. - Fix crashes seen when kdumping on some pseries systems. Thanks to Naveen N. Rao, Nicholas Piggin, Alexey Kardashevskiy, Cédric Le Goater, Christophe Leroy, Mahesh Salgaonkar, Abdul Haleem, Christoph Hellwig, Johan Almbladh, Stan Johnson" * tag 'powerpc-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init powerpc/32s: Fix kuap_kernel_restore() powerpc/pseries/msi: Add an empty irq_write_msi_msg() handler powerpc/64s: Fix unrecoverable MCE calling async handler from NMI powerpc/64/interrupt: Reconcile soft-mask state in NMI and fix false BUG powerpc/64: warn if local irqs are enabled in NMI or hardirq context powerpc/traps: do not enable irqs in _exception powerpc/64s: fix program check interrupt emergency stack path powerpc/bpf ppc32: Fix BPF_SUB when imm == 0x80000000 powerpc/bpf ppc32: Do not emit zero extend instruction for 64-bit BPF_END powerpc/bpf ppc32: Fix JMP32_JSET_K powerpc/bpf ppc32: Fix ALU32 BPF_ARSH operation powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC powerpc/security: Add a helper to query stf_barrier type powerpc/bpf: Fix BPF_SUB when imm == 0x80000000 powerpc/bpf: Fix BPF_MOD when imm == 1 powerpc/bpf: Validate branch ranges powerpc/lib: Add helper to check if offset is within conditional branch range powerpc/iommu: Report the correct most efficient DMA mask for PCI devices
2021-10-10Merge tag 'objtool_urgent_for_v5.15_rc5' of ↵Linus Torvalds6-50/+25
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Borislav Petkov: - Remove an extra section.len member in favour of section.sh_size - Align .altinstructions section creation with the kernel's by creating them with entry size of 0 - Fix objtool to convert a reloc symbol to a section offset and not to not warn about not knowing how * tag 'objtool_urgent_for_v5.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Remove redundant 'len' field from struct section objtool: Make .altinstructions section entry size consistent objtool: Remove reloc symbol type checks in get_alt_entry()
2021-10-10Merge tag 'x86_urgent_for_v5.15_rc5' of ↵Linus Torvalds9-14/+99
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - A FPU fix to properly handle invalid MXCSR values: 32-bit masks them out due to historical reasons and 64-bit kernels reject them - A fix to clear X86_FEATURE_SMAP when support for is not config-enabled - Three fixes correcting misspelled Kconfig symbols used in code - Two resctrl object cleanup fixes - Yet another attempt at fixing the neverending saga of botched x86 timers, this time because some incredibly smart hardware decides to turn off the HPET timer in a low power state - who cares if the OS is relying on it... - Check the full return value range of an SEV VMGEXIT call to determine whether it returned an error * tag 'x86_urgent_for_v5.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu: Restore the masking out of reserved MXCSR bits x86/Kconfig: Correct reference to MWINCHIP3D x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n x86/entry: Correct reference to intended CONFIG_64_BIT x86/resctrl: Fix kfree() of the wrong type in domain_add_cpu() x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails x86/hpet: Use another crystalball to evaluate HPET usability x86/sev: Return an error on a returned non-zero SW_EXITINFO1[31:0]
2021-10-09Merge branch 'i2c/for-current-fixed' of ↵Linus Torvalds3-3/+13
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Three driver bugfixes and one leak fix for the core" * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: mlxcpld: Modify register setting for 400KHz frequency i2c: mlxcpld: Fix criteria for frequency setting i2c: mediatek: Add OFFSET_EXT_CONF setting back i2c: acpi: fix resource leak in reconfiguration device addition