summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-15Input: stmfts - make comments correctPetr Hodina
No functional change. Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip touchscreen") Signed-off-by: Petr Hodina <petr.hodina@protonmail.com> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20251215-fts-fixes-v1-2-8c1e3a63ebf1@ixit.cz Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-12-15Input: stmfts - correct wording for the warning messageDavid Heidelberg
We're trying to enable regulator, not disable it. Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip touchscreen") Suggested-by: Petr Hodina <petr.hodina@protonmail.com> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20251215-fts-fixes-v1-1-8c1e3a63ebf1@ixit.cz Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-12-16ata: libata-core: Disable LPM on ST2000DM008-2FR102Niklas Cassel
According to a user report, the ST2000DM008-2FR102 has problems with LPM. Reported-by: Emerson Pinter <e@pinter.dev> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220693 Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2025-12-15lsm: fix kernel-doc struct member namesRandy Dunlap
Use the correct struct member names to avoid kernel-doc warnings: Warning: include/linux/lsm_hooks.h:83 struct member 'name' not described in 'lsm_id' Warning: include/linux/lsm_hooks.h:183 struct member 'initcall_device' not described in 'lsm_info' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2025-12-16f2fs: improve check for enough free sectionsJoanne Chang
The check for enough sections in segment.h has the following issues: 1. has_not_enough_free_secs() should return "enough secs" when "free_secs >= upper_secs", not just structly greater. Conversely, it should only return "not enough secs" when "free_secs < lower_secs", not when they are equal. This accounts for the possibility that blocks can fit within curseg without requiring an additional free section. 2. __get_secs_required() currently separates the needed space to section and block parts, checking them against free sections and curseg, respectively. This does not consider the case where curseg cannot hold the whole block part, but excess free sections beyond the section part can accommodate some of the block part. 3. has_curseg_enough_space() only checks CURSEG_HOT_DATA for dentry blocks, but when active_logs=6, they may be placed in WARM and COLD sections. Also, the current logic does not consider that dentry and data blocks can be put in the same section when active_logs=2 or 6. This patch modifies the three functions to address the above issues: 1. Rename has_curseg_enough_space() to get_additional_blocks_required(). Calculate the minimum node, dentry, and data blocks curseg can accommodate. Then subtract these from the total required blocks of respective type to determine the worst-case number of blocks that must be placed in free sections. 2. In __get_secs_required(), get the number of blocks needing new sections from the new get_additional_blocks_required(). Return the upper bound of necessary free sections for these blocks. For active_logs=2 or 6, dentry blocks are combined with data blocks. 3. In has_not_enough_free_secs(), get the required sections from __get_secs_required(), and return “not enough secs” if “free_secs < required_secs”. Signed-off-by: Joanne Chang <joannechien@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2025-12-16f2fs: add a tracepoint to see large folio read submissionJaegeuk Kim
For example, 1327.539878: f2fs_preload_pages_start: dev = (252,16), ino = 14, i_size = 4294967296 start: 0, end: 8191 1327.539878: page_cache_sync_ra: dev=252:16 ino=e index=0 req_count=8192 order=9 size=0 async_size=0 ra_pages=4096 mmap_miss=0 prev_pos=-1 1327.539879: page_cache_ra_order: dev=252:16 ino=e index=0 order=9 size=4096 async_size=2048 ra_pages=4096 1327.541895: f2fs_readpages: dev = (252,16), ino = 14, start = 0 nrpage = 4096 1327.541930: f2fs_lookup_extent_tree_start: dev = (252,16), ino = 14, pgofs = 0, type = Read 1327.541931: f2fs_lookup_read_extent_tree_end: dev = (252,16), ino = 14, pgofs = 0, read_ext_info(fofs: 0, len: 1048576, blk: 4221440) 1327.541931: f2fs_map_blocks: dev = (252,16), ino = 14, file offset = 0, start blkaddr = 0x406a00, len = 0x1000, flags = 2, seg_type = 8, may_create = 0, multidevice = 0, flag = 0, err = 0 1327.541989: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 0, nr_pages = 512, dirty = 0, uptodate = 0 1327.542012: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 512, nr_pages = 512, dirty = 0, uptodate = 0 1327.542036: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 1024, nr_pages = 512, dirty = 0, uptodate = 0 1327.542080: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 1536, nr_pages = 512, dirty = 0, uptodate = 0 1327.542127: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 2048, nr_pages = 512, dirty = 0, uptodate = 0 1327.542151: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 2560, nr_pages = 512, dirty = 0, uptodate = 0 1327.542196: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 3072, nr_pages = 512, dirty = 0, uptodate = 0 1327.542219: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 3584, nr_pages = 512, dirty = 0, uptodate = 0 1327.542239: f2fs_submit_read_bio: dev = (252,16)/(252,16), rw = READ(R), DATA, sector = 33771520, size = 16777216 1327.542269: page_cache_sync_ra: dev=252:16 ino=e index=4096 req_count=8192 order=9 size=4096 async_size=2048 ra_pages=4096 mmap_miss=0 prev_pos=-1 1327.542289: page_cache_ra_order: dev=252:16 ino=e index=4096 order=9 size=4096 async_size=2048 ra_pages=4096 1327.544485: f2fs_readpages: dev = (252,16), ino = 14, start = 4096 nrpage = 4096 1327.544521: f2fs_lookup_extent_tree_start: dev = (252,16), ino = 14, pgofs = 4096, type = Read 1327.544521: f2fs_lookup_read_extent_tree_end: dev = (252,16), ino = 14, pgofs = 4096, read_ext_info(fofs: 0, len: 1048576, blk: 4221440) 1327.544522: f2fs_map_blocks: dev = (252,16), ino = 14, file offset = 4096, start blkaddr = 0x407a00, len = 0x1000, flags = 2, seg_type = 8, may_create = 0, multidevice = 0, flag = 0, err = 0 1327.544550: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 4096, nr_pages = 512, dirty = 0, uptodate = 0 1327.544575: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 4608, nr_pages = 512, dirty = 0, uptodate = 0 1327.544601: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 5120, nr_pages = 512, dirty = 0, uptodate = 0 1327.544647: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 5632, nr_pages = 512, dirty = 0, uptodate = 0 1327.544692: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 6144, nr_pages = 512, dirty = 0, uptodate = 0 1327.544734: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 6656, nr_pages = 512, dirty = 0, uptodate = 0 1327.544777: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 7168, nr_pages = 512, dirty = 0, uptodate = 0 1327.544805: f2fs_read_folio: dev = (252,16), ino = 14, DATA, FILE, index = 7680, nr_pages = 512, dirty = 0, uptodate = 0 1327.544826: f2fs_submit_read_bio: dev = (252,16)/(252,16), rw = READ(R), DATA, sector = 33804288, size = 16777216 1327.544852: f2fs_preload_pages_end: dev = (252,16), ino = 14, i_size = 4294967296 start: 8192, end: 8191 Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2025-12-16f2fs: support large folio for immutable non-compressed caseJaegeuk Kim
This patch enables large folio for limited case where we can get the high-order memory allocation. It supports the encrypted and fsverity files, which are essential for Android environment. How to test: - dd if=/dev/zero of=/mnt/test/test bs=1G count=4 - f2fs_io setflags immutable /mnt/test/test - echo 3 > /proc/sys/vm/drop_caches : to reload inode with large folio - f2fs_io read 32 0 1024 mmap 0 0 /mnt/test/test Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2025-12-15iommufd/selftest: Do not leak the hwpt if IOMMU_TEST_OP_MD_CHECK_MAP failsJason Gunthorpe
If the input validation fails it returned without freeing the hwpt refcount causing a leak. This triggers a WARN_ON when closing the fd: WARNING: drivers/iommu/iommufd/main.c:369 at iommufd_fops_release+0x385/0x430, CPU#1: repro/724 Found by szykaller. Fixes: e93d5945ed5b ("iommufd: Change the selftest to use iommupt instead of xarray") Link: https://patch.msgid.link/r/0-v1-c8ed57e24380+44ae-iommufd_selftest_hwpt_leak_jgg@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Reported-by: "Lai, Yi" <yi1.lai@linux.intel.com> Closes: https://lore.kernel.org/r/aTJGMaqwQK0ASj0G@ly-workstation Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-12-15iommufd/selftest: Make it clearer to gcc that the access is not out of boundsJason Gunthorpe
GCC gets a bit confused and reports: In function '_test_cmd_get_hw_info', inlined from 'iommufd_ioas_get_hw_info' at iommufd.c:779:3, inlined from 'wrapper_iommufd_ioas_get_hw_info' at iommufd.c:752:1: >> iommufd_utils.h:804:37: warning: array subscript 'struct iommu_test_hw_info[0]' is partly outside array bounds of 'struct iommu_test_hw_info_buffer_smaller[1]' [-Warray-bounds=] 804 | assert(!info->flags); | ~~~~^~~~~~~ iommufd.c: In function 'wrapper_iommufd_ioas_get_hw_info': iommufd.c:761:11: note: object 'buffer_smaller' of size 4 761 | } buffer_smaller; | ^~~~~~~~~~~~~~ While it is true that "struct iommu_test_hw_info[0]" is partly out of bounds of the input pointer, it is not true that info->flags is out of bounds. Unclear why it warns on this. Reuse an existing properly sized stack buffer and pass a truncated length instead to test the same thing. Fixes: af4fde93c319 ("iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl") Link: https://patch.msgid.link/r/0-v1-63a2cffb09da+4486-iommufd_gcc_bounds_jgg@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512032344.kaAcKFIM-lkp@intel.com/ Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-12-15iommufd: Fix building without dmabufArnd Bergmann
When DMABUF is disabled, trying to use it causes a link failure: x86_64-linux-ld: drivers/iommu/iommufd/io_pagetable.o: in function `iopt_map_file_pages': io_pagetable.c:(.text+0x1735): undefined reference to `dma_buf_get' x86_64-linux-ld: io_pagetable.c:(.text+0x1775): undefined reference to `dma_buf_put' Fixes: 44ebaa1744fd ("iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE") Link: https://patch.msgid.link/r/20251204100333.1034767-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-12-15hfsplus: fix volume corruption issue for generic/498Viacheslav Dubeyko
The xfstests' test-case generic/498 leaves HFS+ volume in corrupted state: sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/498.full for details) Ran: generic/498 Failures: generic/498 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Invalid leaf record count (It should be 16 instead of 2) ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x8000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/498 test executes such steps on final phase: mkdir $SCRATCH_MNT/A mkdir $SCRATCH_MNT/B mkdir $SCRATCH_MNT/A/C touch $SCRATCH_MNT/B/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/B/foo ln $SCRATCH_MNT/B/foo $SCRATCH_MNT/A/C/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/A "Simulate a power failure and mount the filesystem to check that what we explicitly fsync'ed exists." _flakey_drop_and_remount The FSCK tool complains about "Invalid leaf record count". HFS+ b-tree header contains leaf_count field is updated by hfs_brec_insert() and hfs_brec_remove(). The hfs_brec_insert() is involved into hard link creation process. However, modified in-core leaf_count field is stored into HFS+ b-tree header by hfs_btree_write() method. But, unfortunately, hfs_btree_write() hasn't been called by hfsplus_cat_write_inode() and hfsplus_file_fsync() stores not fully consistent state of the Catalog File's b-tree. This patch adds calling hfs_btree_write() method in the hfsplus_cat_write_inode() with the goal of storing consistent state of Catalog File's b-tree. Finally, it makes FSCK tool happy. sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #22 SMP PREEMPT_DYNAMIC Sat Dec 6 17:01:31 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 33s ... 31s Ran: generic/498 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251207035821.3863657-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2025-12-15hfsplus: fix volume corruption issue for generic/480Viacheslav Dubeyko
The xfstests' test-case generic/480 leaves HFS+ volume in corrupted state: sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/480.full for details) Ran: generic/480 Failures: generic/480 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. Incorrect number of file hard links ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. invalid VHB nextCatalogID Volume header needs minor repair (2, 0) Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000002 ** Repairing volume. Incorrect flags for file hard link (id = 19) (It should be 0x22 instead of 0x2) Incorrect flags for file inode (id = 18) (It should be 0x22 instead of 0x2) first link ID=0 is < 16 for fileinode=18 Error getting first link ID for inode = 18 (result=2) Invalid first link in hard link chain (id = 18) (It should be 19 instead of 0) Indirect node 18 needs link count adjustment (It should be 1 instead of 2) ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/480 test executes such steps on final phase: "Now remove of the links of our file and create a new file with the same name and in the same parent directory, and finally fsync this new file." unlink $SCRATCH_MNT/testdir/bar touch $SCRATCH_MNT/testdir/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir/bar "Simulate a power failure and mount the filesystem to check that replaying the fsync log/journal succeeds, that is the mount operation does not fail." _flakey_drop_and_remount The key issue in HFS+ logic is that hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods don't call hfsplus_cat_write_inode() for the case of modified inode objects. As a result, even if hfsplus_file_fsync() is trying to flush the dirty Catalog File, but because of not calling hfsplus_cat_write_inode() not all modified inodes save the new state into Catalog File's records. Finally, simulation of power failure results in inconsistent state of Catalog File and FSCK tool reports about volume corruption. This patch adds calling of hfsplus_cat_write_inode() method for modified inodes in hfsplus_link(), hfsplus_unlink(), hfsplus_rmdir(), hfsplus_symlink(), and hfsplus_mknod() methods. Also, it adds debug output in several methods. sudo ./check generic/480 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/480 16s ... 16s Ran: generic/480 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251205000054.3670326-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2025-12-15hfsplus: ensure sb->s_fs_info is always cleaned upMehdi Ben Hadj Khelifa
When hfsplus was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfsplus_kill_super(). Cc: stable@vger.kernel.org Fixes: 432f7c78cb00 ("hfsplus: convert hfsplus to use the new mount api") Reported-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20251201222843.82310-3-mehdi.benhadjkhelifa@gmail.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2025-12-15hfs: ensure sb->s_fs_info is always cleaned upMehdi Ben Hadj Khelifa
When hfs was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfs_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfs_kill_super(). Cc: stable@vger.kernel.org Fixes: ffcd06b6d13b ("hfs: convert hfs to use the new mount api") Reported-by: syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ad45f827c88778ff7df6 Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20251201222843.82310-2-mehdi.benhadjkhelifa@gmail.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2025-12-15drm/xe: Add more GT stats around pagefault mode switch flowsMatthew Brost
Add GT stats to measure the time spent switching between pagefault mode and dma-fence mode. Also add a GT stat to indicate when pagefault suspend is skipped because the system is idle. These metrics will help profile pagefault workloads while 3D and display are enabled. v2: - Use GT stats helper functions (Francois) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20251212182847.1683222-8-matthew.brost@intel.com
2025-12-15drm/xe: Add GT stats ktime helpersMatthew Brost
Normalize GT stats that record execution periods in code paths by adding helpers to perform the ktime calculation. Use these helpers in the SVM code. Suggested-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-7-matthew.brost@intel.com
2025-12-15drm/xe: Wait on in-syncs when swicthing to dma-fence modeMatthew Brost
If a dma-fence submission has in-fences and pagefault queues are running work, there is little incentive to kick the pagefault queues off the hardware until the dma-fence submission is ready to run. Therefore, wait on the in-fences of the dma-fence submission before removing the pagefault queues from the hardware. v2: - Fix kernel doc (CI) - Don't wait under lock (Thomas) - Make wait interruptable Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-6-matthew.brost@intel.com
2025-12-15drm/xe: Skip exec queue schedule toggle if queue is idle during suspendMatthew Brost
If an exec queue is idle, there is no need to issue a schedule disable to the GuC when suspending the queue’s execution. Opportunistically skip this step if the queue is idle and not a parallel queue. Parallel queues must have their scheduling state flipped in the GuC due to limitations in how submission is implemented in run_job(). Also if all pagefault queues can skip the schedule disable during a switch to dma-fence mode, do not schedule a resume for the pagefault queues after the next submission. v2: - Don't touch the LRC tail is queue is suspended but enabled in run_job (CI) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-5-matthew.brost@intel.com
2025-12-15drm/xe: Add debugfs knobs to control long running workload timeslicingMatthew Brost
Add debugfs knobs to control timeslicing for long-running workloads, allowing quick tuning of values when running benchmarks. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-4-matthew.brost@intel.com
2025-12-15drm/xe: Use usleep_range for accurate long-running workload timeslicingMatthew Brost
msleep is not very accurate in terms of how long it actually sleeps, whereas usleep_range is precise. Replace the timeslice sleep for long-running workloads with the more accurate usleep_range to avoid jitter if the sleep period is less than 20ms. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-3-matthew.brost@intel.com
2025-12-15drm/xe: Adjust long-running workload timeslices to reasonable valuesMatthew Brost
A 10ms timeslice for long-running workloads is far too long and causes significant jitter in benchmarks when the system is shared. Adjust the value to 5ms for preempt-fencing VMs, as the resume step there is quite costly as memory is moved around, and set it to zero for pagefault VMs, since switching back to pagefault mode after dma-fence mode is relatively fast. Also change min_run_period_ms to 'unsiged int' type rather than 's64' as only positive values make sense. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-2-matthew.brost@intel.com
2025-12-15MAINTAINERS: Update Nova GPU driver git linkPhilipp Stanner
Nova driver development has been moved to a different git repository. Update the MAINTAINERS entry to reflect that. Reported-by: Gary Guo <gary@garyguo.net> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251208140713.41330-3-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15irqchip/riscv-imsic: Add a CPU pm notifier to restore the IMSIC on exitNick Hu
The IMSIC might be reset when the system enters a low power state, but on exit nothing restores the registers, which prevents interrupt delivery. Solve this by registering a CPU power management notifier, which restores the IMSIC on exit. Signed-off-by: Nick Hu <nick.hu@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Cyan Yang <cyan.yang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://patch.msgid.link/20251202-preserve-aplic-imsic-v3-1-1844fbf1fe92@sifive.com
2025-12-15arm64: dts: renesas: r9a09g087: Add ICU supportCosmin Tanislav
The Renesas RZ/N2H (R9A09G087) SoC has an Interrupt Controller (ICU) block that routes external interrupts to the GIC's SPIs, with the ability of level-translation, and can also produce software and aggregate error interrupts. Add support for it. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251201112933.488801-5-cosmin-gabriel.tanislav.xa@renesas.com
2025-12-15arm64: dts: renesas: r9a09g077: Add ICU supportCosmin Tanislav
The Renesas RZ/T2H (R9A09G077) SoC has an Interrupt Controller (ICU) block that routes external interrupts to the GIC's SPIs, with the ability of level-translation, and can also produce software and aggregate error interrupts. Add support for it. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251201112933.488801-4-cosmin-gabriel.tanislav.xa@renesas.com
2025-12-15irqchip: Add RZ/{T2H,N2H} Interrupt Controller (ICU) driverCosmin Tanislav
The Renesas RZ/T2H (R9A09G077) and Renesas RZ/N2H (R9A09G087) SoCs have an Interrupt Controller (ICU) that supports interrupts from external pins IRQ0 to IRQ15, and SEI, and software-triggered interrupts INTCPU0 to INTCPU15. INTCPU0 to INTCPU13, IRQ0 to IRQ13 are non-safety interrupts, while INTCPU14, INTCPU15, IRQ14, IRQ15 and SEI are safety interrupts, and are exposed via a separate register space. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251201112933.488801-3-cosmin-gabriel.tanislav.xa@renesas.com
2025-12-15dt-bindings: interrupt-controller: Document RZ/{T2H,N2H} ICUCosmin Tanislav
The Renesas RZ/T2H (R9A09G077) and Renesas RZ/N2H (R9A09G087) SoCs have an Interrupt Controller (ICU) block that routes external interrupts to the GIC's SPIs, with the ability of level-translation, and can also produce software interrupts and aggregate error interrupts. It has 16 software triggered interrupts (INTCPUn), 16 external pin interrupts (IRQn), a System error interrupt (SEI), two Cortex-A55 error interrupts (CA55_ERRn), two Cortex-R52 error interrupts for each of the two cores (CR52x_ERRn), two Peripheral error interrupts (PERI_ERRn), two DSMIF error interrupts (DSMIF_ERRn), and two ENCIF error interrupts (ENCIF_ERRn). The IRQn and SEI interrupts are exposed externally, while the others are software triggered. INTCPU0 to INTCPU13, IRQ 0 to IRQ13 are non-safety interrupts, while INTCPU14, INTCPU15, IRQ14, IRQ15 and SEI are safety interrupts, and are exposed via a separate register space. Document them, and use RZ/T2H as a fallback for RZ/N2H as the ICU is entirely compatible. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251201112933.488801-2-cosmin-gabriel.tanislav.xa@renesas.com
2025-12-15irqchip/renesas-rzv2h: Add support for RZ/V2N SoCLad Prabhakar
Add support for the RZ/V2N Interrupt Control Unit (ICU) by introducing a dedicated compatible string in the irqchip driver. While the RZ/V2N ICU differs from the RZ/V2H(P) version in its register layout primarily due to a reduced set of ECCRAM related registers the irqchip driver does not currently access these registers. As a result, the RZ/V2N ICU can be safely handled by rzv2h_icu_probe for now, but it still requires a distinct compatible so that future changes can differentiate the SoCs when needed. [ tglx: Fixed up the made up subject prefix ] Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251127162447.320971-3-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-12-15dt-bindings: interrupt-controller: renesas,rzv2h-icu: Document RZ/V2N SoCLad Prabhakar
Document the Interrupt Control Unit (ICU) used on the Renesas RZ/V2N SoC. Although the ICU closely matches the design found on the RZ/V2H(P) family, it differs in its register layout, particularly in the reduced set of ECCRAM related registers. These variations require a distinct compatible string so that software can correctly match and handle the RZ/V2N implementation. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251127162447.320971-2-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-12-15irqchip/aslint-sswi: Request IO memory resourceVladimir Kondratiev
Make an aclint_sswi instance visible in the resource list, i.e. /proc/iomem Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251209142336.1061606-1-vladimir.kondratiev@mobileye.com
2025-12-15rust: drm: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-16-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: scatterlist: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-36-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: property: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-31-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: platform: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-28-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: pci: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-26-a2e13cbc17a6@google.com [ Consider latest helper additions. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15drm/xe/oa: Limit num_syncs to prevent oversized allocationsShuicheng Lin
The OA open parameters did not validate num_syncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations. Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS, returning -EINVAL when the limit is violated. v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh) Fixes: c8507a25cebd ("drm/xe/oa/uapi: Define and parse OA sync properties") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251205234715.2476561-6-shuicheng.lin@intel.com
2025-12-15drm/xe: Limit num_syncs to prevent oversized allocationsShuicheng Lin
The exec and vm_bind ioctl allow userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt & Ashutosh) v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt) v5: Do the check at the top of the exec func. (Matt) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Koen Koning <koen.koning@intel.com> Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6450 Cc: <stable@vger.kernel.org> # v6.12+ Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Carl Zhang <carl.zhang@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Ivan Briano <ivan.briano@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251205234715.2476561-5-shuicheng.lin@intel.com
2025-12-15drm/xe/guc: Fix version check for page-reclaim featureMichal Wajdeczko
Page reclamation interfaces were introduced in GuC firmware version 70.31.0 (which corresponds to GuC ABI version 1.14.0), but since this feature is also available for the VFs and VFs don't know the firmware version, use GuC compatibility version check instead. Fixes: 77ebc7c10d16 ("drm/xe/guc: Add page reclamation interface to GuC") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Brian Nguyen <brian3.nguyen@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251215170433.196398-1-michal.wajdeczko@intel.com
2025-12-15PCI: dwc: Enable MSI affinity supportRadu Rendec
Leverage the interrupt redirection infrastructure to enable CPU affinity support for MSI interrupts. Since the parent interrupt affinity cannot be changed, affinity control for the child interrupt (MSI) is achieved by redirecting the handler to run in IRQ work context on the target CPU. This patch was originally prepared by Thomas Gleixner (see Link tag below) in a patch series that was never submitted as is, and only parts of that series have made it upstream so far. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-4-rrendec@redhat.com
2025-12-15PCI: dwc: Code cleanupRadu Rendec
Code cleanup with no functional changes. These changes were originally made by Thomas Gleixner (see Link tag below) in a patch that was never submitted as is. Other parts of that patch were eventually submitted as commit 8e717112caf3 ("PCI: dwc: Switch to msi_create_parent_irq_domain()") and the remaining parts are the code cleanup changes: - Use guard()/scoped_guard() instead of open-coded lock/unlock. - Return void in a few functions whose return value is never used. - Simplify dw_handle_msi_irq() by using for_each_set_bit(). One notable deviation from the original patch is that it reverts back to a simple 1 by 1 iteration over the controllers inside dw_handle_msi_irq. The reason is that with the original changes, the IRQ offset was calculated incorrectly. This prepares the ground for enabling MSI affinity support, which was originally part of that same series that Thomas Gleixner prepared. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-3-rrendec@redhat.com
2025-12-15genirq: Add interrupt redirection infrastructureRadu Rendec
Add infrastructure to redirect interrupt handler execution to a different CPU when the current CPU is not part of the interrupt's CPU affinity mask. This is primarily aimed at (de)multiplexed interrupts, where the child interrupt handler runs in the context of the parent interrupt handler, and therefore CPU affinity control for the child interrupt is typically not available. With the new infrastructure, the child interrupt is allowed to freely change its affinity setting, independently of the parent. If the interrupt handler happens to be triggered on an "incompatible" CPU (a CPU that's not part of the child interrupt's affinity mask), the handler is redirected and runs in IRQ work context on a "compatible" CPU. No functional change is being made to any existing irqchip driver, and irqchip drivers must be explicitly modified to use the newly added infrastructure to support interrupt redirection. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-2-rrendec@redhat.com
2025-12-15rust: irq: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-20-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: io: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-19-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: dma: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-15-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15rust: device: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251202-define-rust-helper-v1-14-a2e13cbc17a6@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-15genirq: Remove setup_percpu_irq()Marc Zyngier
setup_percpu_irq() was always a bad kludge, and should have never been there the first place. Now that the last users are gone, remove it for good. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-7-maz@kernel.org
2025-12-15clocksource/drivers/mips-gic-timer: Move GIC timer to request_percpu_irq()Marc Zyngier
Teach the MIPS GIC timer about request_percpu_irq(), which ultimately will allow for the removal of the antiquated setup_percpu_irq() API. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-6-maz@kernel.org
2025-12-15MIPS: Move IP27 timer to request_percpu_irq()Marc Zyngier
Teach the SGI IP27 timer about request_percpu_irq(), which ultimately will allow for the removal of the antiquated setup_percpu_irq() API. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-5-maz@kernel.org
2025-12-15MIPS: Move IP30 timer to request_percpu_irq()Marc Zyngier
Teach the SGI IP30 timer about request_percpu_irq(), which ultimately will allow for the removal of the antiquated setup_percpu_irq() API. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-4-maz@kernel.org
2025-12-15genirq: Remove __request_percpu_irq() helperMarc Zyngier
With the IRQ timing stuff being gone, there is no need to specify a flag when requesting a percpu interrupt. Not only IRQF_TIMER was the only flag (set of flags actually) allowed, but nobody ever passed it. Get rid of __request_percpu_irq(), which was only getting 0 as flags, and promote request_percpu_irq_affinity() as its replacement. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20251210082242.360936-3-maz@kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 16:03:34 +0000