aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-26pinctrl: sophgo: add support for CV1800B SoCInochi Amaoto7-0/+1409
Sophgo CV1800 series SoCs share common control logic but have different register mapping. For maintenance, split the driver and pin definition of the SoC. Add base driver for CV1800 series SoC and pin definition of CV1800B. Signed-off-by: Inochi Amaoto <[email protected]> Link: https://lore.kernel.org/IA1PR20MB4953B260E04EC53F6A01EB30BBB32@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Linus Walleij <[email protected]>
2024-08-26dt-bindings: pinctrl: Add pinctrl for Sophgo CV1800 series SoC.Inochi Amaoto6-0/+537
Add pinctrl support for Sophgo CV1800 series SoC. Signed-off-by: Inochi Amaoto <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]> Link: https://lore.kernel.org/IA1PR20MB4953680DE7977CAD906DBDB4BBB32@IA1PR20MB4953.namprd20.prod.outlook.com Signed-off-by: Linus Walleij <[email protected]>
2024-08-26drm/ttm: fix kernel-doc typo for @trylock_onlyJani Nikula1-1/+1
s/tryock_only/trylock_only/ Fixes: da966b82bf3d ("drm/ttm: Provide a generic LRU walker helper") Cc: Thomas Hellström <[email protected]> Cc: Christian König <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-08-26pinctrl: freescale: imx-scmi: Use kmemdup_array instead of kmemdup for ↵Shen Lichuan1-1/+1
multiple allocation Let the kmemdup_array() take care about multiplication and possible overflows. Signed-off-by: Shen Lichuan <[email protected]> Reviewed-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-08-26drm/i915: remove unused leftover basedie step codeJani Nikula3-7/+0
The basedie step initialization as well as its last users were removed in commit 326e30e4624c ("drm/i915: Drop dead code for pvc"). Follow through with removing the unused macros and struct member and debug logging. Suggested-by: Matt Roper <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-08-26ALSA: usb-audio: Use kmemdup_array instead of kmemdup for multiple allocationShen Lichuan1-2/+2
Let the kmemdup_array() take care about multiplication and possible overflows. Using kmemdup_array() is more appropriate and makes the code easier to audit. Signed-off-by: Shen Lichuan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-26Merge tag 'renesas-pinctrl-for-v6.12-tag1' of ↵Linus Walleij2-26/+20
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: renesas: Updates for v6.12 - Document support for the Renesas RZ/G2M v3.0 (r8a774a3) SoC, - Miscellaneous fixes and improvements. Signed-off-by: Linus Walleij <[email protected]>
2024-08-26ALSA: hda/realtek: support HP Pavilion Aero 13-bg0xxx Mute LEDHendrik Borghorst1-0/+1
This patch adds the HP Pavilion Aero 13 (13-bg0xxx) (year 2024) to list of quirks for keyboard LED mute indication. The laptop has two LEDs (one for speaker and one for mic mute). The pre-existing quirk ALC245_FIXUP_HP_X360_MUTE_LEDS chains both the quirk for mic and speaker mute. Tested on 6.11.0-rc4 with the aforementioned laptop. Signed-off-by: Hendrik Borghorst <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-26bus: mhi: host: make mhi_bus_type constKunwu Chan2-2/+2
Now that the driver core can properly handle constant struct bus_type, move the mhi_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kunwu Chan <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]>
2024-08-26drivers/pinctrl: Switch to use kmemdup_array()Shen Lichuan1-2/+2
Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Shen Lichuan <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-08-26drm/xe: Remove NULL check of lrc->bo in xe_lrc_snapshot_capture()Apoorva Singh1-1/+1
- lrc->bo NULL check is not needed in xe_lrc_snapshot_capture() as its already been taken care of in xe_lrc_init(). Signed-off-by: Apoorva Singh <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-08-26bus: mhi: host: pci_generic: Fix the name for the Telit FE990AFabio Porcedda1-2/+11
Add a mhi_pci_dev_info struct specific for the Telit FE990A modem in order to use the correct product name. Cc: [email protected] # 6.1+ Fixes: 0724869ede9c ("bus: mhi: host: pci_generic: add support for Telit FE990 modem") Signed-off-by: Fabio Porcedda <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]>
2024-08-26m68k: defconfig: Update defconfigs for v6.11-rc1Geert Uytterhoeven12-24/+0
- Drop CONFIG_CRYPTO_SM2=m (removed in commit 46b3ff73afc815f1 ("crypto: sm2 - Remove sm2 algorithm")), - Drop CONFIG_TEST_USER_COPY=m (replaced by auto-modular CONFIG_USERCOPY_KUNIT_TEST in commit cf6219ee889fb304 ("usercopy: Convert test_user_copy to KUnit test")). Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/bfe0530e290cee9d350f89c4d41436f3de7cb2a5.1722248695.git.geert@linux-m68k.org
2024-08-26m68k: Fix kernel_clone_args.flags in m68k_clone()Finn Thain1-1/+1
Stan Johnson recently reported a failure from the 'dump' command: DUMP: Date of this level 0 dump: Fri Aug 9 23:37:15 2024 DUMP: Dumping /dev/sda (an unlisted file system) to /dev/null DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 3595695 blocks. DUMP: Context save fork fails in parent 671 The dump program uses the clone syscall with the CLONE_IO flag, that is, flags == 0x80000000. When that value is promoted from long int to u64 by m68k_clone(), it undergoes sign-extension. The new value includes CLONE_INTO_CGROUP so the validation in cgroup_css_set_fork() fails and the syscall returns -EBADF. Avoid sign-extension by casting to u32. Reported-by: Stan Johnson <[email protected]> Closes: https://lists.debian.org/debian-68k/2024/08/msg00000.html Fixes: 6aabc1facdb2 ("m68k: Implement copy_thread_tls()") Signed-off-by: Finn Thain <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/3463f1e5d4e95468dc9f3368f2b78ffa7b72199b.1723335149.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-08-26m68k: cmpxchg: Use swap() to improve codeThorsten Blum1-10/+5
Remove the local variable tmp and use the swap() macro instead. Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-08-26random: vDSO: reject unknown getrandom() flagsYann Droneaud1-0/+4
Like the getrandom() syscall, vDSO getrandom() must also reject unknown flags. [1] It would be possible to return -EINVAL from vDSO itself, but in the possible case that a new flag is added to getrandom() syscall in the future, it would be easier to get the behavior from the syscall, instead of erroring until the vDSO is extended to support the new flag or explicitly falling back. [1] Designing the API: Planning for Extension https://docs.kernel.org/process/adding-syscalls.html#designing-the-api-planning-for-extension Signed-off-by: Yann Droneaud <[email protected]> [Jason: reworded commit message] Signed-off-by: Jason A. Donenfeld <[email protected]>
2024-08-26drm/i915: remove unnecessary display includesJani Nikula7-11/+1
There are a number of leftover #include "display/..." directives that are completely unnecessary. Remove them to make it easier to spot the relevant ones. In one case, switch to a more specific include. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-08-26MAINTAINERS: Add Jean-Philippe as SMMUv3 SVA reviewerWill Deacon1-0/+4
Add Jean-Philippe as a reviewer for the Arm SMMUv3 SVA support, since he's been a consistent contributor to that code over the years and understands the relevant parts of the architecture much better than me. Cc: Robin Murphy <[email protected]> Cc: Jean-Philippe Brucker <[email protected]> Cc: Mostafa Saleh <[email protected]> Signed-off-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-26iommu: Do not return 0 from map_pages if it doesn't do anythingJason Gunthorpe3-6/+3
These three implementations of map_pages() all succeed if a mapping is requested with no read or write. Since they return back to __iommu_map() leaving the mapped output as 0 it triggers an infinite loop. Therefore nothing is using no-access protection bits. Further, VFIO and iommufd rely on iommu_iova_to_phys() to get back PFNs stored by map, if iommu_map() succeeds but iommu_iova_to_phys() fails that will create serious bugs. Thus remove this never used "nothing to do" concept and just fail map immediately. Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support") Fixes: e1d3c0fd701d ("iommu: add ARM LPAE page table allocator") Fixes: 745ef1092bcf ("iommu/io-pgtable: Move Apple DART support to its own file") Signed-off-by: Jason Gunthorpe <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-26iommufd: Do not allow creating areas without READ or WRITEJason Gunthorpe2-3/+11
This results in passing 0 or just IOMMU_CACHE to iommu_map(). Most of the page table formats don't like this: amdv1 - -EINVAL armv7s - returns 0, doesn't update mapped arm-lpae - returns 0 doesn't update mapped dart - returns 0, doesn't update mapped VT-D - returns -EINVAL Unfortunately the three formats that return 0 cause serious problems: - Returning ret = but not uppdating mapped from domain->map_pages() causes an infinite loop in __iommu_map() - Not writing ioptes means that VFIO/iommufd have no way to recover them and we will have memory leaks and worse during unmap Since almost nothing can support this, and it is a useless thing to do, block it early in iommufd. Cc: [email protected] Fixes: aad37e71d5c4 ("iommufd: IOCTLs for the io_pagetable") Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-26iommu/vt-d: Fix incorrect domain ID in context flush helperLu Baolu3-6/+11
The helper intel_context_flush_present() is designed to flush all related caches when a context entry with the present bit set is modified. It currently retrieves the domain ID from the context entry and uses it to flush the IOTLB and context caches. This is incorrect when the context entry transitions from present to non-present, as the domain ID field is cleared before calling the helper. Fix it by passing the domain ID programmed in the context entry before the change to intel_context_flush_present(). This ensures that the correct domain ID is used for cache invalidation. Fixes: f90584f4beb8 ("iommu/vt-d: Add helper to flush caches for context change") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/linux-iommu/[email protected]/ Signed-off-by: Lu Baolu <[email protected]> Tested-by: Alex Williamson <[email protected]> Reviewed-by: Alex Williamson <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jacob Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-08-26xfs: Fix the owner setting issue for rmap query in xfs fsmapZizhi Wo1-1/+1
I notice a rmap query bug in xfs_io fsmap: [root@fedora ~]# xfs_io -c 'fsmap -vvvv' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 1: 253:16 [8..23]: per-AG metadata 0 (8..23) 16 2: 253:16 [24..39]: inode btree 0 (24..39) 16 3: 253:16 [40..47]: per-AG metadata 0 (40..47) 8 4: 253:16 [48..55]: refcount btree 0 (48..55) 8 5: 253:16 [56..103]: per-AG metadata 0 (56..103) 48 6: 253:16 [104..127]: free space 0 (104..127) 24 ...... Bug: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 0 3' /mnt [root@fedora ~]# Normally, we should be able to get one record, but we got nothing. The root cause of this problem lies in the incorrect setting of rm_owner in the rmap query. In the case of the initial query where the owner is not set, __xfs_getfsmap_datadev() first sets info->high.rm_owner to ULLONG_MAX. This is done to prevent any omissions when comparing rmap items. However, if the current ag is detected to be the last one, the function sets info's high_irec based on the provided key. If high->rm_owner is not specified, it should continue to be set to ULLONG_MAX; otherwise, there will be issues with interval omissions. For example, consider "start" and "end" within the same block. If high->rm_owner == 0, it will be smaller than the founded record in rmapbt, resulting in a query with no records. The main call stack is as follows: xfs_ioc_getfsmap xfs_getfsmap xfs_getfsmap_datadev_rmapbt __xfs_getfsmap_datadev info->high.rm_owner = ULLONG_MAX if (pag->pag_agno == end_ag) xfs_fsmap_owner_to_rmap // set info->high.rm_owner = 0 because fmr_owner == -1ULL dest->rm_owner = 0 // get nothing xfs_getfsmap_datadev_rmapbt_query The problem can be resolved by simply modify the xfs_fsmap_owner_to_rmap function internal logic to achieve. After applying this patch, the above problem have been solved: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 0 3' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 Fixes: e89c041338ed ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Zizhi Wo <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-08-26xfs: don't bother reporting blocks trimmed via FITRIMDarrick J. Wong1-25/+11
Don't bother reporting the number of bytes that we "trimmed" because the underlying storage isn't required to do anything(!) and failed discard IOs aren't reported to the caller anyway. It's not like userspace can use the reported value for anything useful like adjusting the offset parameter of the next call, and it's not like anyone ever wrote a manpage about FITRIM's out parameters. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Christoph Hellwig <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-08-26xfs: xfs_finobt_count_blocks() walks the wrong btreeDave Chinner1-1/+1
As a result of the factoring in commit 14dd46cf31f4 ("xfs: split xfs_inobt_init_cursor"), mount started taking a long time on a user's filesystem. For Anders, this made mount times regress from under a second to over 15 minutes for a filesystem with only 30 million inodes in it. Anders bisected it down to the above commit, but even then the bug was not obvious. In this commit, over 20 calls to xfs_inobt_init_cursor() were modified, and some we modified to call a new function named xfs_finobt_init_cursor(). If that takes you a moment to reread those function names to see what the rename was, then you have realised why this bug wasn't spotted during review. And it wasn't spotted on inspection even after the bisect pointed at this commit - a single missing "f" isn't the easiest thing for a human eye to notice.... The result is that xfs_finobt_count_blocks() now incorrectly calls xfs_inobt_init_cursor() so it is now walking the inobt instead of the finobt. Hence when there are lots of allocated inodes in a filesystem, mount takes a -long- time run because it now walks a massive allocated inode btrees instead of the small, nearly empty free inode btrees. It also means all the finobt space reservations are wrong, so mount could potentially given ENOSPC on kernel upgrade. In hindsight, commit 14dd46cf31f4 should have been two commits - the first to convert the finobt callers to the new API, the second to modify the xfs_inobt_init_cursor() API for the inobt callers. That would have made the bug very obvious during review. Fixes: 14dd46cf31f4 ("xfs: split xfs_inobt_init_cursor") Reported-by: Anders Blomdell <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-08-26xfs: fix folio dirtying for XFILE_ALLOC callersDarrick J. Wong1-1/+1
willy pointed out that folio_mark_dirty is the correct function to use to mark an xfile folio dirty because it calls out to the mapping's aops to mark it dirty. For tmpfs this likely doesn't matter much since it currently uses nop_dirty_folio, but let's use the abstractions properly. Reported-by: [email protected] Fixes: 6907e3c00a40 ("xfs: add file_{get,put}_folio") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-08-26xfs: fix di_onlink checking for V1/V2 inodesDarrick J. Wong1-4/+10
"KjellR" complained on IRC that an old V4 filesystem suddenly stopped mounting after upgrading from 6.9.11 to 6.10.3, with the following splat when trying to read the rt bitmap inode: 00000000: 49 4e 80 00 01 02 00 01 00 00 00 00 00 00 00 00 IN.............. 00000010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 43 d2 a9 da 21 0f d6 30 ........C...!..0 00000030: 43 d2 a9 da 21 0f d6 30 00 00 00 00 00 00 00 00 C...!..0........ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 02 00 00 00 00 00 00 00 04 00 00 00 00 ................ 00000060: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As Dave Chinner points out, this is a V1 inode with both di_onlink and di_nlink set to 1 and di_flushiter == 0. In other words, this inode was formatted this way by mkfs and hasn't been touched since then. Back in the old days of xfsprogs 3.2.3, I observed that libxfs_ialloc would set di_nlink, but if the filesystem didn't have NLINK, it would then set di_version = 1. libxfs_iflush_int later sees the V1 inode and copies the value of di_nlink to di_onlink without zeroing di_onlink. Eventually this filesystem must have been upgraded to support NLINK because 6.10 doesn't support !NLINK filesystems, which is how we tripped over this old behavior. The filesystem doesn't have a realtime section, so that's why the rtbitmap inode has never been touched. Fix this by removing the di_onlink/di_nlink checking for all V1/V2 inodes because this is a muddy mess. The V3 inode handling code has always supported NLINK and written di_onlink==0 so keep that check. The removal of the V1 inode handling code when we dropped support for !NLINK obscured this old behavior. Reported-by: [email protected] Fixes: 40cb8613d612 ("xfs: check unused nlink fields in the ondisk inode") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-08-26drm/vmwgfx: Disable coherent dumb buffers without 3dZack Rusin1-2/+4
Coherent surfaces make only sense if the host renders to them using accelerated apis. Without 3d the entire content of dumb buffers stays in the guest making all of the extra work they're doing to synchronize between guest and host useless. Configurations without 3d also tend to run with very low graphics memory limits. The pinned console fb, mob cursors and graphical login manager tend to run out of 16MB graphics memory that those guests use. Fix it by making sure the coherent dumb buffers are only used on configs with 3d enabled. Signed-off-by: Zack Rusin <[email protected]> Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Reported-by: Christian Heusel <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Cc: Broadcom internal kernel review list <[email protected]> Cc: [email protected] Cc: <[email protected]> # v6.9+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Tested-by: Benjamin Coddington <[email protected]>
2024-08-26drm/vmwgfx: Fix prime with external buffersZack Rusin3-12/+118
Make sure that for external buffers mapping goes through the dma_buf interface instead of trying to access pages directly. External buffers might not provide direct access to readable/writable pages so to make sure the bo's created from external dma_bufs can be read dma_buf interface has to be used. Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't trigger this due to the fact that virtual machines will not have multiple GPUs but it enables better test coverage in IGT. Signed-off-by: Zack Rusin <[email protected]> Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export") Cc: <[email protected]> # v6.6+ Cc: Broadcom internal kernel review list <[email protected]> Cc: [email protected] Cc: <[email protected]> # v6.9+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]>
2024-08-26drm/vmwgfx: Prevent unmapping active read buffersZack Rusin2-2/+14
The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4") Cc: Broadcom internal kernel review list <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.19+ Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Martin Krastev <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]>
2024-08-26Merge branch 'icc-sm8350' into icc-nextGeorgi Djakov3-174/+1
A set of fixes that target stability of the SM8350 platform. * icc-sm8350 interconnect: qcom: sm8350: drop DISP nodes dt-bindings: interconnect: qcom,sm8350: drop DISP nodes interconnect: qcom: sm8250: Enable sync_state Link: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Georgi Djakov <[email protected]>
2024-08-26Merge branch 'icc-misc' into icc-nextGeorgi Djakov10-16/+3143
This series introduce new ICC drivers for some legacy socs while at it also updates a bit of qcs404 driver which seems to not receive much attention lately. * icc-misc dt-bindings: interconnect: qcom: Add Qualcomm MSM8976 NoC interconnect: qcom: Add MSM8976 interconnect provider driver dt-bindings: interconnect: qcom: Add Qualcomm MSM8937 NoC interconnect: qcom: Add MSM8937 interconnect provider driver interconnect: qcom: qcs404: Mark AP-owned nodes as such interconnect: qcom: qcs404: Add regmaps and more bus descriptions dt-bindings: interconnect: qcom: msm8939: Fix example interconnect: qcom: msm8953: Add ab_coeff dt-bindings: interconnect: qcom: msm8953: Fix 'See also' in description Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Georgi Djakov <[email protected]>
2024-08-26dt-bindings: interconnect: qcom: Do not require reg for sc8180x virt NoCsGeorgi Djakov1-0/+3
The virtual interconnect providers do not have their own IO address space, but this is not documented in the DT schema and the following warnings are reported by dtbs_check: sc8180x-lenovo-flex-5g.dtb: interconnect-camnoc-virt: 'reg' is a required property sc8180x-lenovo-flex-5g.dtb: interconnect-mc-virt: 'reg' is a required property sc8180x-lenovo-flex-5g.dtb: interconnect-qup-virt: 'reg' is a required property sc8180x-primus.dtb: interconnect-camnoc-virt: 'reg' is a required property sc8180x-primus.dtb: interconnect-mc-virt: 'reg' is a required property sc8180x-primus.dtb: interconnect-qup-virt: 'reg' is a required property Fix this by adding them to the list of compatibles that do not require the reg property. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2024-08-26dt-bindings: interconnect: qcom-bwmon: Document SA8775p bwmon compatiblesTengfei Fan1-0/+2
Document the compatibles used to describe the bwmons present on the SA8775p platform. Signed-off-by: Tengfei Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2024-08-25apparmor: fix policy_unpack_test on big endian systemsGuenter Roeck1-3/+3
policy_unpack_test fails on big endian systems because data byte order is expected to be little endian but is generated in host byte order. This results in test failures such as: # policy_unpack_test_unpack_array_with_null_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:150 Expected array_size == (u16)16, but array_size == 4096 (0x1000) (u16)16 == 16 (0x10) # policy_unpack_test_unpack_array_with_null_name: pass:0 fail:1 skip:0 total:1 not ok 3 policy_unpack_test_unpack_array_with_null_name # policy_unpack_test_unpack_array_with_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:164 Expected array_size == (u16)16, but array_size == 4096 (0x1000) (u16)16 == 16 (0x10) # policy_unpack_test_unpack_array_with_name: pass:0 fail:1 skip:0 total:1 Add the missing endianness conversions when generating test data. Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack") Cc: Brendan Higgins <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2024-08-25Revert "MIPS: csrc-r4k: Apply verification clocksource flags"Guenter Roeck1-3/+1
This reverts commit 7190401fc56fb5f02ee3d04476778ab000bbaf32. Verifying the clock source sometimes deems the MIPS clock to be unstable, at least in qemu. clocksource: timekeeping watchdog on CPU0: Marking clocksource 'MIPS' as unstable because the skew is too large: clocksource: 'jiffies' wd_nsec: 500000000 wd_now: ffff8bde wd_last: ffff8bac mask: ffffffff clocksource: 'MIPS' cs_nsec: 940634468 cs_now: 310181c4 cs_last: 28090a09 mask: ffffffff clocksource: Clocksource 'MIPS' skewed 440634468 ns (440 ms) over watchdog 'jiffies' interval of 500000000 ns (500 ms) clocksource: 'MIPS' is current clocksource. If this happens, network interfaces fail to come online. Signed-off-by: Guenter Roeck <[email protected]>
2024-08-25microblaze: don't treat zero reserved memory regions as errorMike Rapoport1-5/+0
Before commit 721f4a6526da ("mm/memblock: remove empty dummy entry") the check for non-zero of memblock.reserved.cnt in mmu_init() would always be true either because memblock.reserved.cnt is initialized to 1 or because there were memory reservations earlier. The removal of dummy empty entry in memblock caused this check to fail because now memblock.reserved.cnt is initialized to 0. Remove the check for non-zero of memblock.reserved.cnt because it's perfectly fine to have an empty memblock.reserved array that early in boot. Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Mike Rapoport <[email protected]> Reviewed-by: Wei Yang <[email protected]> Tested-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2024-08-25hwmon: (asus-ec-sensors) remove VRM temp X570-E GAMINGRoss Brown1-1/+1
X570-E GAMING does not have VRM temperature sensor. Signed-off-by: Ross Brown <[email protected]> Signed-off-by: Eugene Shalygin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2024-08-25x86/entry: Set FRED RSP0 on return to userspace instead of context switchXin Li (Intel)4-5/+27
The FRED RSP0 MSR points to the top of the kernel stack for user level event delivery. As this is the task stack it needs to be updated when a task is scheduled in. The update is done at context switch. That means it's also done when switching to kernel threads, which is pointless as those never go out to user space. For KVM threads this means there are two writes to FRED_RSP0 as KVM has to switch to the guest value before VMENTER. Defer the update to the exit to user space path and cache the per CPU FRED_RSP0 value, so redundant writes can be avoided. Provide fred_sync_rsp0() for KVM to keep the cache in sync with the actual MSR value after returning from guest to host mode. [ tglx: Massage change log ] Suggested-by: Sean Christopherson <[email protected]> Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Xin Li (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-25x86/msr: Switch between WRMSRNS and WRMSR with the alternatives mechanismAndrew Cooper3-16/+11
Per the discussion about FRED MSR writes with WRMSRNS instruction [1], use the alternatives mechanism to choose WRMSRNS when it's available, otherwise fallback to WRMSR. Remove the dependency on X86_FEATURE_WRMSRNS as WRMSRNS is no longer dependent on FRED. [1] https://lore.kernel.org/lkml/[email protected]/ Use DS prefix to pad WRMSR instead of a NOP. The prefix is ignored. At least that's the current information from the hardware folks. Signed-off-by: Andrew Cooper <[email protected]> Signed-off-by: Xin Li (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-25x86/entry: Test ti_work for zero before processing individual bitsXin Li (Intel)1-2/+8
In most cases, ti_work values passed to arch_exit_to_user_mode_prepare() are zeros, e.g., 99% in kernel build tests. So an obvious optimization is to test ti_work for zero before processing individual bits in it. Omit the optimization when FPU debugging is enabled, otherwise the FPU consistency check is never executed. Intel 0day tests did not find a perfermance regression with this change. Suggested-by: H. Peter Anvin (Intel) <[email protected]> Signed-off-by: Xin Li (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-25btrfs: run delayed iputs when flushing delallocJosef Bacik1-0/+2
We have transient failures with btrfs/301, specifically in the part where we do for i in $(seq 0 10); do write 50m to file rm -f file done Sometimes this will result in a transient quota error, and it's because sometimes we start writeback on the file which results in a delayed iput, and thus the rm doesn't actually clean the file up. When we're flushing the quota space we need to run the delayed iputs to make sure all the unlinks that we think have completed have actually completed. This removes the small window where we could fail to find enough space in our quota. CC: [email protected] # 5.15+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]>
2024-08-25KVM: selftests: aarch64: Add writable test for ID_AA64PFR1_EL1Shaoqin Huang1-3/+11
Add writable test for the ID_AA64PFR1_EL1 register. Signed-off-by: Shaoqin Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-08-25KVM: arm64: Allow userspace to change ID_AA64PFR1_EL1Shaoqin Huang1-1/+13
Allow userspace to change the guest-visible value of the register with different way of handling: - Since the RAS and MPAM is not writable in the ID_AA64PFR0_EL1 register, RAS_frac and MPAM_frac are also not writable in the ID_AA64PFR1_EL1 register. - The MTE is controlled by a separate UAPI (KVM_CAP_ARM_MTE) with an internal flag (KVM_ARCH_FLAG_MTE_ENABLED). So it's not writable. - For those fields which KVM doesn't know how to handle, they are not exposed to the guest (being disabled in the register read accessor), those fields value will always be 0. Those fields don't have a known behavior now, so don't advertise them to the userspace. Thus still not writable. Those fields include SME, RNDR_trap, NMI, GCS, THE, DF2, PFAR, MTE_frac, MTEX. - The BT, SSBS, CSV2_frac don't introduce any new registers which KVM doesn't know how to handle, they can be written without ill effect. So let them writable. Besides, we don't do the crosscheck in KVM about the CSV2_frac even if it depends on the value of CSV2, it should be made sure by the VMM instead of KVM. Signed-off-by: Shaoqin Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-08-25KVM: arm64: Use kvm_has_feat() to check if FEAT_SSBS is advertised to the guestShaoqin Huang1-6/+6
Currently KVM use cpus_have_final_cap() to check if FEAT_SSBS is advertised to the guest. But if FEAT_SSBS is writable and isn't advertised to the guest, this is wrong. Update it to use kvm_has_feat() to check if FEAT_SSBS is advertised to the guest, thus the KVM can do the right thing if FEAT_SSBS isn't advertised to the guest. Signed-off-by: Shaoqin Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-08-25KVM: arm64: Disable fields that KVM doesn't know how to handle in ↵Shaoqin Huang1-0/+8
ID_AA64PFR1_EL1 For some of the fields in the ID_AA64PFR1_EL1 register, KVM doesn't know how to handle them right now. So explicitly disable them in the register accessor, then those fields value will be masked to 0 even if on the hardware the field value is 1. This is safe because from a UAPI point of view that read_sanitised_ftr_reg() doesn't yet return a nonzero value for any of those fields. This will benifit the migration if the host and VM have different values when restoring a VM. Those fields include RNDR_trap, NMI, MTE_frac, GCS, THE, MTEX, DF2, PFAR. Signed-off-by: Shaoqin Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-08-25rust: enable rustdoc's `--generate-link-to-definition`Miguel Ojeda1-0/+1
In Rust 1.56.0 [1], rustdoc introduced the "jump to definition" feature [2], i.e. the unstable flag `--generate-link-to-definition`. It adds links to the source view of the documentation. For instance, in the source view of `rust/kernel/sync.rs`, for this code: impl Default for LockClassKey { fn default() -> Self { Self::new() } } It will add three hyperlinks: - `Default` points to the rendered "Trait `core::default::Default`" page (not the source view, since it goes to another crate, though this may change). - `LockClassKey` points to the `pub struct LockClassKey(...);` line in the same page, highlighting the line number. - `Self::new()` points to the `pub const fn new() -> Self { ... }` associated function, highlighting its line numbers (i.e. for the full function). This makes the source view more useful and a bit closer to the experience in e.g. the Elixir Cross Referencer [3]. I have provisionally enabled it for rust.docs.kernel.org [4] -- one can take a look at the source view there for an example of how it looks like. Thus enable it. Cc: Guillaume Gomez <[email protected]> Link: https://github.com/rust-lang/rust/pull/84176 [1] Link: https://github.com/rust-lang/rust/issues/89095 [2] Link: https://elixir.bootlin.com [3] Link: https://rust.docs.kernel.org [4] Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2024-08-25docs: rust: improve main page introducing a "Code documentation" sectionMiguel Ojeda2-4/+17
Clean the "Rust" main page by introducing a 'Code documentation" section to separate it from the rest of the text above. In addition, introduce the "Rust code documentation" term, which may be clearer than referring to a potentially unknown tool. Furthermore, for the HTML case, homogenize both `rustdoc` and non-`rustdoc` cases and use the term introduced above instead. Then, always generate the pregenerated version part, since now there is a section that is always generated and thus makes sense to do so. Finally, finish the new section with a link to more details about the Rust code documentation. The intention is that: - The non-HTML case mentions the code documentation too, making it more prominent for readers of non-HTML docs. - Both HTML cases read more naturally. - The pregenerated version is always mentioned, since it is likely useful for readers of non-HTML docs. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2024-08-25docs: rust: link to https://rust.docs.kernel.orgMiguel Ojeda2-3/+13
The Rust code documentation (i.e. `rustdoc`-generated docs) is now available at: https://rust.docs.kernel.org Thus document it and remove the `TODO` line. The generation uses a particular kernel configuration, based on x86_64, which may get tweaked over time. Older tags, and how they are generated, may also change in the future. We may consider freezing them at some point, but for the moment, the content should not be considered immutable. Thanks Konstantin for the support setting it up! Cc: Konstantin Ryabitsev <[email protected]> Acked-by: Konstantin Ryabitsev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2024-08-25perf/x86/intel: Limit the period on HaswellKan Liang1-2/+21
Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. Fixes: 3a632cb229bf ("perf/x86/intel: Add simple Haswell PMU support") Reported-by: Li Huafei <[email protected]> Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected] Closes: https://lore.kernel.org/lkml/[email protected]/
2024-08-25io_uring/kbuf: shrink nr_iovs/mode in struct buf_sel_argJens Axboe1-2/+2
nr_iovs is capped at 1024, and mode only has a few low values. We can safely make them u16, in preparation for adding a few more members. Signed-off-by: Jens Axboe <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.