aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-13ext4: don't clear SB_RDONLY when remounting r/w until quota is re-enabledTheodore Ts'o1-1/+5
When a file system currently mounted read/only is remounted read/write, if we clear the SB_RDONLY flag too early, before the quota is initialized, and there is another process/thread constantly attempting to create a directory, it's possible to trigger the WARN_ON_ONCE(dquot_initialize_needed(inode)); in ext4_xattr_block_set(), with the following stack trace: WARNING: CPU: 0 PID: 5338 at fs/ext4/xattr.c:2141 ext4_xattr_block_set+0x2ef2/0x3680 RIP: 0010:ext4_xattr_block_set+0x2ef2/0x3680 fs/ext4/xattr.c:2141 Call Trace: ext4_xattr_set_handle+0xcd4/0x15c0 fs/ext4/xattr.c:2458 ext4_initxattrs+0xa3/0x110 fs/ext4/xattr_security.c:44 security_inode_init_security+0x2df/0x3f0 security/security.c:1147 __ext4_new_inode+0x347e/0x43d0 fs/ext4/ialloc.c:1324 ext4_mkdir+0x425/0xce0 fs/ext4/namei.c:2992 vfs_mkdir+0x29d/0x450 fs/namei.c:4038 do_mkdirat+0x264/0x520 fs/namei.c:4061 __do_sys_mkdirat fs/namei.c:4076 [inline] __se_sys_mkdirat fs/namei.c:4074 [inline] __x64_sys_mkdirat+0x89/0xa0 fs/namei.c:4074 Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=6513f6cb5cd6b5fc9f37e3bb70d273b94be9c34c Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: check iomap type only if ext4_iomap_begin() does not failBaokun Li1-1/+1
When ext4_iomap_overwrite_begin() calls ext4_iomap_begin() map blocks may fail for some reason (e.g. memory allocation failure, bare disk write), and later because "iomap->type ! = IOMAP_MAPPED" triggers WARN_ON(). When ext4 iomap_begin() returns an error, it is normal that the type of iomap->type may not match the expectation. Therefore, we only determine if iomap->type is as expected when ext4_iomap_begin() is executed successfully. Cc: [email protected] Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csumTudor Ambarus1-4/+2
When modifying the block device while it is mounted by the filesystem, syzbot reported the following: BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58 Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586 CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 crc16+0x206/0x280 lib/crc16.c:58 ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187 ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210 ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline] ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173 ext4_remove_blocks fs/ext4/extents.c:2527 [inline] ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline] ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958 ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416 ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342 ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622 notify_change+0xe50/0x1100 fs/attr.c:482 do_truncate+0x200/0x2f0 fs/open.c:65 handle_truncate fs/namei.c:3216 [inline] do_open fs/namei.c:3561 [inline] path_openat+0x272b/0x2dd0 fs/namei.c:3714 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f72f8a8c0c9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280 RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000 Replace le16_to_cpu(sbi->s_es->s_desc_size) with sbi->s_desc_size It reduces ext4's compiled text size, and makes the code more efficient (we remove an extra indirect reference and a potential byte swap on big endian systems), and there is no downside. It also avoids the potential KASAN / syzkaller failure, as a bonus. Reported-by: [email protected] Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42 Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3 Link: https://lore.kernel.org/all/[email protected]/ Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups") Cc: [email protected] Signed-off-by: Tudor Ambarus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: fix data races when using cached status extentsJan Kara1-17/+13
When using cached extent stored in extent status tree in tree->cache_es another process holding ei->i_es_lock for reading can be racing with us setting new value of tree->cache_es. If the compiler would decide to refetch tree->cache_es at an unfortunate moment, it could result in a bogus in_range() check. Fix the possible race by using READ_ONCE() when using tree->cache_es only under ei->i_es_lock for reading. Cc: [email protected] Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected] Suggested-by: Dmitry Vyukov <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: avoid deadlock in fs reclaim with page writebackJan Kara3-13/+40
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock. Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected] Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") CC: [email protected] Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: fix invalid free tracking in ext4_xattr_move_to_block()Theodore Ts'o1-2/+3
In ext4_xattr_move_to_block(), the value of the extended attribute which we need to move to an external block may be allocated by kvmalloc() if the value is stored in an external inode. So at the end of the function the code tried to check if this was the case by testing entry->e_value_inum. However, at this point, the pointer to the xattr entry is no longer valid, because it was removed from the original location where it had been stored. So we could end up calling kvfree() on a pointer which was not allocated by kvmalloc(); or we could also potentially leak memory by not freeing the buffer when it should be freed. Fix this by storing whether it should be freed in a separate variable. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://syzkaller.appspot.com/bug?id=5c2aee8256e30b55ccf57312c16d88417adbd5e1 Link: https://syzkaller.appspot.com/bug?id=41a6b5d4917c0412eb3b3c3c604965bed7d7420b Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: remove a BUG_ON in ext4_mb_release_group_pa()Theodore Ts'o1-1/+5
If a malicious fuzzer overwrites the ext4 superblock while it is mounted such that the s_first_data_block is set to a very large number, the calculation of the block group can underflow, and trigger a BUG_ON check. Change this to be an ext4_warning so that we don't crash the kernel. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220 Signed-off-by: Theodore Ts'o <[email protected]>
2023-05-13ext4: allow ext4_get_group_info() to failTheodore Ts'o5-29/+82
Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k. Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220 Signed-off-by: Theodore Ts'o <[email protected]> Reviewed-by: Jan Kara <[email protected]>
2023-05-13Merge tag 'block-6.4-2023-05-13' of git://git.kernel.dk/linuxLinus Torvalds5-104/+4
Pull block fixes from Jens Axboe: "Just a few minor fixes for drivers, and a deletion of a file that is woefully out-of-date these days" * tag 'block-6.4-2023-05-13' of git://git.kernel.dk/linux: Documentation/block: drop the request.rst file ublk: fix command op code check block/rnbd: replace REQ_OP_FLUSH with REQ_OP_WRITE nbd: Fix debugfs_create_dir error checking
2023-05-13cxl: Add missing return to cdat read error pathDave Jiang1-0/+1
Add a return to the error path when cxl_cdat_read_table() fails. Current code continues with the table pointer points to freed memory. Fixes: 7a877c923995 ("cxl/pci: Simplify CDAT retrieval error path") Signed-off-by: Dave Jiang <[email protected]> Reviewed-by: Davidlohr Bueso <[email protected]> Link: https://lore.kernel.org/r/168382793506.3510737.4792518576623749076.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <[email protected]>
2023-05-13tools/testing/cxl: Use DEFINE_STATIC_SRCU()Dan Williams1-1/+1
Starting with commit: 95433f726301 ("srcu: Begin offloading srcu_struct fields to srcu_update") ...it is no longer possible to do: static DEFINE_SRCU(x) Switch to DEFINE_STATIC_SRCU(x) to fix: tools/testing/cxl/test/mock.c:22:1: error: duplicate ‘static’ 22 | static DEFINE_SRCU(cxl_mock_srcu); | ^~~~~~ Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/168392709546.1135523.10424917245934547117.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <[email protected]>
2023-05-12x86/retbleed: Fix return thunk alignmentBorislav Petkov (AMD)1-2/+2
SYM_FUNC_START_LOCAL_NOALIGN() adds an endbr leading to this layout (leaving only the last 2 bytes of the address): 3bff <zen_untrain_ret>: 3bff: f3 0f 1e fa endbr64 3c03: f6 test $0xcc,%bl 3c04 <__x86_return_thunk>: 3c04: c3 ret 3c05: cc int3 3c06: 0f ae e8 lfence However, "the RET at __x86_return_thunk must be on a 64 byte boundary, for alignment within the BTB." Use SYM_START instead. Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2023-05-12Merge tag 'for-6.4-rc1-tag' of ↵Linus Torvalds11-33/+102
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull more btrfs fixes from David Sterba: - fix incorrect number of bitmap entries for space cache if loading is interrupted by some error - fix backref walking, this breaks a mode of LOGICAL_INO_V2 ioctl that is used in deduplication tools - zoned mode fixes: - properly finish zone reserved for relocation - correctly calculate super block zone end on ZNS - properly initialize new extent buffer for redirty - make mount option clear_cache work with block-group-tree, to rebuild free-space-tree instead of temporarily disabling it that would lead to a forced read-only mount - fix alignment check for offset when printing extent item * tag 'for-6.4-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: make clear_cache mount option to rebuild FST without disabling it btrfs: zero the buffer before marking it dirty in btrfs_redirty_list_add btrfs: zoned: fix full zone super block reading on ZNS btrfs: zoned: zone finish data relocation BG with last IO btrfs: fix backref walking not returning all inode refs btrfs: fix space cache inconsistency after error loading it from disk btrfs: print-tree: parent bytenr must be aligned to sector size
2023-05-12Merge tag '6.4-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds4-2/+28
Pull cifs client fixes from Steve French: - fix for copy_file_range bug for very large files that are multiples of rsize - do not ignore "isolated transport" flag if set on share - set rasize default better - three fixes related to shutdown and freezing (fixes 4 xfstests, and closes deferred handles faster in some places that were missed) * tag '6.4-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: release leases for deferred close handles when freezing smb3: fix problem remounting a share after shutdown SMB3: force unmount was failing to close deferred close files smb3: improve parallel reads of large files do not reuse connection if share marked as isolated cifs: fix pcchunk length type in smb2_copychunk_range
2023-05-12Merge tag 'vfs/v6.4-rc1/pipe' of ↵Linus Torvalds1-2/+4
gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs Pull vfs fix from Christian Brauner: "During the pipe nonblock rework the check for both O_NONBLOCK and IOCB_NOWAIT was dropped. Both checks need to be performed to ensure that files without O_NONBLOCK but IOCB_NOWAIT don't block when writing to or reading from a pipe. This just contains the fix adding the check for IOCB_NOWAIT back in" * tag 'vfs/v6.4-rc1/pipe' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs: pipe: check for IOCB_NOWAIT alongside O_NONBLOCK
2023-05-12Merge tag 'io_uring-6.4-2023-05-12' of git://git.kernel.dk/linuxLinus Torvalds1-5/+5
Pull io_uring fix from Jens Axboe: "Just a single fix making io_uring_sqe_cmd() available regardless of CONFIG_IO_URING, fixing a regression introduced during the merge window if nvme was selected but io_uring was not" * tag 'io_uring-6.4-2023-05-12' of git://git.kernel.dk/linux: io_uring: make io_uring_sqe_cmd() unconditionally available
2023-05-12Merge tag 'riscv-for-linus-6.4-rc2' of ↵Linus Torvalds2-6/+3
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fix from Palmer Dabbelt: "Just a single fix this week for a build issue. That'd usually be a good sign, but we've started to get some reports of boot failures on some hardware/bootloader configurations. Nothing concrete yet, but I've got a funny feeling that's where much of the bug hunting is going right now. Nothing's reproducing on my end, though, and this fixes some pretty concrete issues so I figured there's no reason to delay it: - a fix to the linker script to avoid orpahaned sections in kernel/pi" * tag 'riscv-for-linus-6.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fix orphan section warnings caused by kernel/pi
2023-05-12drm/i915/guc: Fix confused register capture list creationJohn Harrison3-34/+72
The GuC has a completely separate engine class enum when referring to register capture lists, which combines render and compute. The driver was using the 'normal' GuC specific engine class enum instead. That meant that it thought it was defining a capture list for compute engines, the list was actually being applied to the GSC engine. And if a platform didn't have a render engine, then it would get no compute register captures at all. Fix that. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Alan Previn <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-12drm/i1915/guc: Fix probe injection CI failures after recent changeJohn Harrison1-1/+1
A recent change bumped a 'notice' message up to 'error' level for debug builds to help trap incorrect configurations in CI systems. Unfortunately, the error condition in question is triggered by the error injection probe test. So change the message again to be 'probe error' level instead. Signed-off-by: John Harrison <[email protected]> Fixes: 760133d42f0a ("drm/i915/uc: Make unexpected firmware versions an error in debug builds") Cc: John Harrison <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Alan Previn <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-12Documentation/block: drop the request.rst fileRandy Dunlap2-100/+0
Documentation/block/request.rst is outdated and should be removed. Also delete its entry in the block/index.rst file. Signed-off-by: Randy Dunlap <[email protected]> Cc: Jens Axboe <[email protected]> Cc: [email protected] Cc: Jonathan Corbet <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-05-12pipe: check for IOCB_NOWAIT alongside O_NONBLOCKJens Axboe1-2/+4
Pipe reads or writes need to enable nonblocking attempts, if either O_NONBLOCK is set on the file, or IOCB_NOWAIT is set in the iocb being passed in. The latter isn't currently true, ensure we check for both before waiting on data or space. Fixes: afed6271f5b0 ("pipe: set FMODE_NOWAIT on pipes") Signed-off-by: Jens Axboe <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
2023-05-12ublk: fix command op code checkMing Lei1-1/+1
In case of CONFIG_BLKDEV_UBLK_LEGACY_OPCODES, type of cmd opcode could be 0 or 'u'; and type can only be 'u' if CONFIG_BLKDEV_UBLK_LEGACY_OPCODES isn't set. So fix the wrong check. Fixes: 2d786e66c966 ("block: ublk: switch to ioctl command encoding") Signed-off-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-05-12block/rnbd: replace REQ_OP_FLUSH with REQ_OP_WRITEGuoqing Jiang1-1/+1
Since flush bios are implemented as writes with no data and the preflush flag per Christoph's comment [1]. And we need to change it in rnbd accordingly. Otherwise, I got splatting when create fs from rnbd client. [ 464.028545] ------------[ cut here ]------------ [ 464.028553] WARNING: CPU: 0 PID: 65 at block/blk-core.c:751 submit_bio_noacct+0x32c/0x5d0 [ ... ] [ 464.028668] CPU: 0 PID: 65 Comm: kworker/0:1H Tainted: G OE 6.4.0-rc1 #9 [ 464.028671] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 464.028673] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [ 464.028717] RIP: 0010:submit_bio_noacct+0x32c/0x5d0 [ 464.028720] Code: 03 0f 85 51 fe ff ff 48 8b 43 18 8b 88 04 03 00 00 85 c9 0f 85 3f fe ff ff e9 be fd ff ff 0f b6 d0 3c 0d 74 26 83 fa 01 74 21 <0f> 0b b8 0a 00 00 00 e9 56 fd ff ff 4c 89 e7 e8 70 a1 03 00 84 c0 [ 464.028722] RSP: 0018:ffffaf3680b57c68 EFLAGS: 00010202 [ 464.028724] RAX: 0000000000060802 RBX: ffffa09dcc18bf00 RCX: 0000000000000000 [ 464.028726] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffa09dde081d00 [ 464.028727] RBP: ffffaf3680b57c98 R08: ffffa09dde081d00 R09: ffffa09e38327200 [ 464.028729] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa09dde081d00 [ 464.028730] R13: ffffa09dcb06e1e8 R14: 0000000000000000 R15: 0000000000200000 [ 464.028733] FS: 0000000000000000(0000) GS:ffffa09e3bc00000(0000) knlGS:0000000000000000 [ 464.028735] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 464.028736] CR2: 000055a4e8206c40 CR3: 0000000119f06000 CR4: 00000000003506f0 [ 464.028738] Call Trace: [ 464.028740] <TASK> [ 464.028746] submit_bio+0x1b/0x80 [ 464.028748] rnbd_srv_rdma_ev+0x50d/0x10c0 [rnbd_server] [ 464.028754] ? percpu_ref_get_many.constprop.0+0x55/0x140 [rtrs_server] [ 464.028760] ? __this_cpu_preempt_check+0x13/0x20 [ 464.028769] process_io_req+0x1dc/0x450 [rtrs_server] [ 464.028775] rtrs_srv_inv_rkey_done+0x67/0xb0 [rtrs_server] [ 464.028780] __ib_process_cq+0xbc/0x1f0 [ib_core] [ 464.028793] ib_cq_poll_work+0x2b/0xa0 [ib_core] [ 464.028804] process_one_work+0x2a9/0x580 [1]. https://lore.kernel.org/all/[email protected]/ Signed-off-by: Guoqing Jiang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-05-12nbd: Fix debugfs_create_dir error checkingIvan Orlov1-2/+2
The debugfs_create_dir function returns ERR_PTR in case of error, and the only correct way to check if an error occurred is 'IS_ERR' inline function. This patch will replace the null-comparison with IS_ERR. Signed-off-by: Ivan Orlov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-05-12Merge tag 'firewire-fixes-6.4-rc2' of ↵Linus Torvalds1-10/+11
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: - fix early release of request packet * tag 'firewire-fixes-6.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: net: fix unexpected release of object for asynchronous request packet
2023-05-12fbdev: stifb: Fix info entry in sti_struct on error pathHelge Deller1-0/+1
Minor fix to reset the info field to NULL in case of error. Signed-off-by: Helge Deller <[email protected]>
2023-05-12fbdev: modedb: Add 1920x1080 at 60 Hz video modeHelge Deller1-0/+5
Add typical resolution for Full-HD monitors. Signed-off-by: Helge Deller <[email protected]>
2023-05-12drm/i915/gt: drop dependency on VLV_DISPLAY_BASEJani Nikula1-2/+3
CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV display base area. Add VLV_GUNIT_BASE to drop dependency on VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in intel_gt_regs.h. v2: Add VLV_GUNIT_BASE (Ville) Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Enable PXP with MTL-GSC-CSAlan Previn5-10/+18
Enable PXP with MTL-GSC-CS: add the has_pxp into device info and increase the debugfs teardown timeouts to align with new GSC-CS + firmware specs. Now that we have 3 places that are selecting pxp timeouts based on tee vs gsccs back-end, let's add a helper. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee componentAlan Previn2-2/+16
On legacy platforms, KCR HW enabling is done at the time the mei component interface is bound. It's also disabled during unbind. However, for MTL onwards, we don't depend on a tee component to start sending GSC-CS firmware messages. Thus, immediately enable (or disable) KCR HW on PXP's init, fini and resume. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/uapi/pxp: Add a GET_PARAM for PXPAlan Previn4-7/+49
Because of the additional firmware, component-driver and initialization depedencies required on MTL platform before a PXP context can be created, UMD calling for PXP creation as a way to get-caps can take a long time. An actual real world customer stack has seen this happen in the 4-to-8 second range after the kernel starts (which sees MESA's init appear in the middle of this range as the compositor comes up). To avoid unncessary delays experienced by the UMD for get-caps purposes, add a GET_PARAM for I915_PARAM_PXP_SUPPORT. However, some failures can still occur after all the depedencies are met (such as firmware init flow failure, bios configurations or SOC fusing not allowing PXP enablement). Those scenarios will only be known to user space when it attempts creating a PXP context and is documented in the GEM UAPI headers. While making this change, create a helper that is common to both GET_PARAM caller and intel_pxp_start since the latter does similar checks. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Acked-by: Jordan Justen <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Add ARB session creation and cleanupAlan Previn6-7/+209
Add MTL's function for ARB session creation using PXP firmware version 4.3 ABI structure format. While relooking at the ARB session creation flow in intel_pxp_start, let's address missing UAPI documentation. Without actually changing backward compatible behavior, update i915's drm-uapi comments that describe the possible error values when creating a context with I915_CONTEXT_PARAM_PROTECTED_CONTENT: Since the first merge of PXP support on ADL, i915 returns -ENXIO if a dependency such as firmware or component driver was yet to be loaded or returns -EIO if the creation attempt failed when requested by the PXP firmware (specific firmware error responses are reported in dmesg). Add MTL's function for ARB session invalidation but this reuses PXP firmware version 4.2 ABI structure format. For both cases, in the back-end gsccs functions for sending messages to the firmware inspect the GSC-CS-Mem-Header's pending-bit which means the GSC firmware is busy and we should retry. Given the last hw requirement, lets also update functions in front-end layer that wait for session creation or teardown completion to use new worst case timeout periods. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Add GSC-CS backend to send GSC fw messagesAlan Previn5-2/+254
Add GSC engine based method for sending PXP firmware packets to the GSC firmware for MTL (and future) products. Use the newly added helpers to populate the GSC-CS memory header and send the message packet to the FW by dispatching the GSC_HECI_CMD_PKT instruction on the GSC engine. We use non-priveleged batches for submission to GSC engine which require two buffers for the request: - a buffer for the HECI packet that contains PXP FW commands - a batch-buffer that contains the engine instruction for sending the HECI packet to the GSC firmware. Thus, add the allocation and freeing of these buffers in gsccs init and fini. The GSC-fw may reply to commands with a SUCCESS but with an additional pending-bit set in the reply packet. This bit means the GSC-FW is currently busy and the caller needs to try again with the gsc_message_handle the fw returned. Thus, add a wrapper to continuously retry send_message while replaying the gsc_message_handle. Retries need to follow the arch-spec count and delay until GSC-FW replies with the real SUCCESS or timeout after that spec'd delay. The GSC-fw requires a non-zero host_session_handle provided by the caller to enable gsc_message_handle tracking. Thus, allocate the host_session_handle at init and destroy it at fini (the latter requiring an FYI to the gsc-firmware). Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSCAlan Previn2-0/+125
Add helper functions into a new file for heci-packet-submission. The helpers will handle generating the MTL GSC-CS Memory-Header and submission of the Heci-Cmd-Packet instructions to the engine. NOTE1: These common functions for heci-packet-submission will be used by different i915 callers: 1- GSC-SW-Proxy: This is pending upstream publication awaiting a few remaining opens 2- MTL-HDCP: An equivalent patch has also been published at: https://patchwork.freedesktop.org/series/111876/. (Patch 1) 3- PXP: This series. NOTE2: A difference in this patch vs what is appearing is in bullet 2 above is that HDCP (and SW-Proxy) will be using priveleged submission (GGTT and common gsc-uc-context) while PXP will be using non-priveleged PPGTT, context and batch buffer. Therefore this patch will only slightly overlap with the MTL-HDCP patches despite have very similar function names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT instructions require different flows and hw-specific code when done via PPGTT based submission (not different from other engines). MTL-HDCP contains the same intel_gsc_mtl_header_t structures as this but the helpers there are different. Both add the same new file names. NOTE3: Additional clarity about the heci-cmd-pkt layout and where the common helpers come in: - On MTL, when an i915 subsystem needs to send a command request to the security firmware, it will send that via the GSC- engine-command-streamer. - However those commands, (lets call them "gsc_specific_fw_api" calls), are not understood by the GSC command streamer hw. - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and passes it along to the GSC firmware. - The GSC FW on the other hand needs additional metadata to know which usage service is being called (PXP, HDCP, proxy, etc) along with session specific info. Thus an extra header called GSC-CS HECI Memory Header, (C) in below diagram is prepended before the FW specific API, (D). - Thus, the structural layout of the request submitted would need to look like the diagram below (for non-priv PXP). - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header) will populate blob (C) while additional helpers, different for PPGGTT (this patch) vs GGTT (HDCP series) will populate blobs (A) and (B) below. ___________________________________________________________ (A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) | | | | | _|________________________________________________ | | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in, | | | | pkt-addr-out, pkt-size-out) |-------- | | MI_BATCH_BUFFER_END | | | | |________________________________________________| | | | | | |_________________________________________________________| | | --------------------------------------------------------- | \|/ ______V___________________________________________ | _________________________________________ | |(C)| | | | | struct intel_gsc_mtl_header { | | | | validity marker | | | | heci_clent_id | | | | ... | | | | } | | | |_______________________________________| | |(D)| | | | | struct gsc_fw_specific_api_foobar { | | | | ... | | | | For an example, see | | | | 'struct pxp43_create_arb_in' at | | | | intel_pxp_cmd_interface_43.h | | | | | | | | } | | | | Struture depends on command type | | | | struct gsc_fw_specific_api_foobar { | | | |_______________________________________| | |________________________________________________| That said, this patch provides basic helpers but leaves the PXP subsystem (i.e. the caller) to handle (D) and everything else such as input/output size verification or handling the responses from security firmware (for example, requiring a retry). Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operationAlan Previn5-22/+58
Add MTL hw-plumbing enabling for KCR operation under PXP which includes: 1. Updating 'pick-gt' to get the media tile for KCR interrupt handling 2. Adding MTL's KCR registers for PXP operation (init, status-checking, etc.). While doing #2, lets create a separate registers header file for PXP to be consistent with other i915 global subsystems. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/pxp: Add GSC-CS back-end resource init and cleanupAlan Previn6-6/+117
For MTL, the PXP back-end transport uses the GSC engine to submit HECI packets through the HW to the GSC firmware for PXP arb session management. This submission uses a non-priveleged batch buffer, a buffer for the command packet and of course a context targeting the GSC-CS. Thus for MTL, we need to allocate and free a set of execution submission resources for the management of the arbitration session. Lets start with the context creation first since that object and its usage is very straight-forward. We'll add the buffer allocation and freeing later when we introduce the gsccs' send-message function. Do this one time allocation of gsccs specific resources in a new gsccs source file with intel_pxp_gsccs_init / fini functions and hook them up from the PXP front-end. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11Merge tag 'drm-fixes-2023-05-12' of git://anongit.freedesktop.org/drm/drmLinus Torvalds29-100/+188
Pull drm fixes from Dave Airlie: "About the usual for this stage, bunch of amdgpu, a few i915 and a scattering of fixes across the board" dsc: - macro fixes simplefb: - fix VESA format scheduler: - timeout handling fix fbdev: - avoid potential out-of-bounds access in generic fbdev emulation ast: - improve AST2500+ compat on ARM mipi-dsi: - small mipi-dsi fix amdgpu: - VCN3 fixes - APUs always support PCI atomics - legacy power management fixes - DCN 3.1.4 fix - DCFCLK fix - fix several RAS irq refcount mismatches - GPU Reset fix - GFX 11.0.4 fix i915: - taint kernel when force_probe is used - NULL deref and div-by-zero fixes for display - GuC error capture fix for Xe devices" * tag 'drm-fixes-2023-05-12' of git://anongit.freedesktop.org/drm/drm: (24 commits) drm/amdgpu: change gfx 11.0.4 external_id range drm/amdgpu/jpeg: Remove harvest checking for JPEG3 drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras drm/amd/pm: avoid potential UBSAN issue on legacy asics drm/i915: taint kernel when force probing unsupported devices drm/i915/dp: prevent potential div-by-zero drm/i915: Fix NULL ptr deref by checking new_crtc_state drm/i915/guc: Don't capture Gen8 regs on Xe devices drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend drm/amdgpu: Fix vram recover doesn't work after whole GPU reset (v2) drm/amdgpu: drop gfx_v11_0_cp_ecc_error_irq_funcs drm/amd/display: Enforce 60us prefetch for 200Mhz DCFCLK modes drm/amd/display: Add symclk workaround during disable link output drm/amd/pm: parse pp_handle under appropriate conditions drm/amdgpu: set gfx9 onwards APU atomics support to be true drm/amdgpu/nv: update VCN 3 max HEVC encoding resolution drm/sched: Check scheduler work queue before calling timeout handling drm/mipi-dsi: Set the fwnode for mipi_dsi_device drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values ...
2023-05-11Merge tag 'xfs-6.4-rc1-fixes' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds14-63/+65
Pull xfs bug fixes from Dave Chinner: "Largely minor bug fixes and cleanups, th emost important of which are probably the fixes for regressions in the extent allocation code: - fixes for inode garbage collection shutdown racing with work queue updates - ensure inodegc workers run on the CPU they are supposed to - disable counter scrubbing until we can exclusively freeze the filesystem from the kernel - regression fixes for new allocation related bugs - a couple of minor cleanups" * tag 'xfs-6.4-rc1-fixes' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix xfs_inodegc_stop racing with mod_delayed_work xfs: disable reaping in fscounters scrub xfs: check that per-cpu inodegc workers actually run on that cpu xfs: explicitly specify cpu when forcing inodegc delayed work to run immediately xfs: fix negative array access in xfs_getbmap xfs: don't allocate into the data fork for an unshare request xfs: flush dirty data and drain directios before scrubbing cow fork xfs: set bnobt/cntbt numrecs correctly when formatting new AGs xfs: don't unconditionally null args->pag in xfs_bmap_btalloc_at_eof
2023-05-11fbdev: imsttfb: Fix use after free bug in imsttfb_probeZheng Wang1-7/+8
A use-after-free bug may occur if init_imstt invokes framebuffer_release and free the info ptr. The caller, imsttfb_probe didn't notice that and still keep the ptr as private data in pdev. If we remove the driver which will call imsttfb_remove to make cleanup, UAF happens. Fix it by return error code if bad case happens in init_imstt. Signed-off-by: Zheng Wang <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-05-12Merge tag 'amd-drm-fixes-6.4-2023-05-11' of ↵Dave Airlie14-71/+131
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amdgpu: - VCN3 fixes - APUs always support PCI atomics - Legacy power management fixes - DCN 3.1.4 fix - DCFCLK fix - Fix several RAS irq refcount mismatches - GPU Reset fix - GFX 11.0.4 fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-12Merge tag 'drm-intel-fixes-2023-05-11-1' of ↵Dave Airlie5-9/+25
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix to taint kernel when force_probe is used - Null deref and div-by-zero fixes for display - GuC error capture fix for Xe devices Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-12Merge tag 'drm-misc-fixes-2023-05-11' of ↵Dave Airlie10-20/+32
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes drm-misc-fixes for v6.4-rc2: - More DSC macro fixes. - Small mipi-dsi fix. - Scheduler timeout handling fix. --- drm-misc-fixes for v6.4-rc1: - Fix DSC macros. - Fix VESA format for simplefb. - Prohibit potential out-of-bounds access in generic fbdev emulation. - Improve AST2500+ compat on ARM. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915/irq: relocate gmbus and dp aux irq handlersJani Nikula5-24/+31
Move gmbus and dp aux irq handlers to their respective files. It should be up to them what to do with the irq, not the generic irq code. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e825385fc03cb3d53c1f0b66712eea42dad69d59.1683219363.git.jani.nikula@intel.com
2023-05-11drm/i915: use pat_index instead of cache_levelFei Yang36-238/+453
Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls the caching behavior in PTE has far more levels than what's defined in the enum. In addition, the PAT index is platform dependent, having to translate between i915_cache_level and PAT index is not reliable, and makes the code more complicated. From UMD's perspective there is also a necessity to set caching policy for performance fine tuning. It's much easier for the UMD to directly use PAT index because the behavior of each PAT index is clearly defined in Bspec. Having the abstracted i915_cache_level sitting in between would only cause more ambiguity. PAT is expected to work much like MOCS already works today, and by design userspace is expected to select the index that exactly matches the desired behavior described in the hardware specification. For these reasons this patch replaces i915_cache_level with PAT index. Also note, the cache_level is not completely removed yet, because the KMD still has the need of creating buffer objects with simple cache settings such as cached, uncached, or writethrough. For kernel objects, cache_level is used for simplicity and backward compatibility. For Pre-gen12 platforms PAT can have 1:1 mapping to i915_cache_level, so these two are interchangeable. see the use of LEGACY_CACHELEVEL. One consequence of this change is that gen8_pte_encode is no longer working for gen12 platforms due to the fact that gen12 platforms has different PAT definitions. In the meantime the mtl_pte_encode introduced specfically for MTL becomes generic for all gen12 platforms. This patch renames the MTL PTE encode function into gen12_pte_encode and apply it to all gen12. Even though this change looks unrelated, but separating them would temporarily break gen12 PTE encoding, thus squash them in one patch. Special note: this patch changes the way caching behavior is controlled in the sense that some objects are left to be managed by userspace. For such objects we need to be careful not to change the userspace settings.There are kerneldoc and comments added around obj->cache_coherent, cache_dirty, and how to bypass the checkings by i915_gem_object_has_cache_level. For full understanding, these changes need to be looked at together with the two follow-up patches, one disables the {set|get}_caching ioctl's and the other adds set_pat extension to the GEM_CREATE uAPI. Bspec: 63019 Cc: Chris Wilson <[email protected]> Signed-off-by: Fei Yang <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915: preparation for using PAT indexFei Yang9-11/+116
This patch is a preparation for replacing enum i915_cache_level with PAT index. Caching policy for buffer objects is set through the PAT index in PTE, the old i915_cache_level is not sufficient to represent all caching modes supported by the hardware. Preparing the transition by adding some platform dependent data structures and helper functions to translate the cache_level to pat_index. cachelevel_to_pat: a platform dependent array mapping cache_level to pat_index. max_pat_index: the maximum PAT index recommended in hardware specification Needed for validating the PAT index passed in from user space. i915_gem_get_pat_index: function to convert cache_level to PAT index. obj_to_i915(obj): macro moved to header file for wider usage. I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the convenience of coding. Cc: Chris Wilson <[email protected]> Cc: Matt Roper <[email protected]> Signed-off-by: Fei Yang <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-11drm/i915: Nuke intel_bios_is_port_dp_dual_mode()Ville Syrjälä3-15/+7
Now that we have encoder->devdata everwhere we don't need the intel_bios_is_port_dp_dual_mode() wrapper any more. And while at it let's include it in the child device log dump as well since the logic in there is a bit more complex than just DP&&HDMI. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Gustavo Sousa <[email protected]>
2023-05-11drm/i915: Flip VBT DDC pin maps aroundVille Syrjälä1-34/+36
Swap the roles of the index vs. value for the VBT DDC pin mapping tables. This is not strictly necessary for DDC pins but it will make this work exactly like the AUX CH mapping tables where the role reversal is necessary (or at least makes things easier). Consistency is good. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Gustavo Sousa <[email protected]>
2023-05-11drm/i915: Split map_aux_ch() into per-platform arraysVille Syrjälä1-73/+71
The big switch+if statement mess in map_aux_ch() is illegible. Split up into cleaner per-platform arrays like we already have for the gmbus pins. We use enum aux_ch as the index and the VBT thing as the value. Slightly non-intuitive perhaps but if we did it the other way around we'd have problems with AUX_CH_A being zero, and thus any non-populated element would look like AUX_CH_A. v2: flip the index vs. value around TODO: Didn't bother with the platform variants beyond the ones that really need remapping, which means if the VBT is bogus we end up with a nonexistent aux ch. Might be nice to check this a bit better. Yet another bitmask in device info? Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Gustavo Sousa <[email protected]>
2023-05-11drm/i915: Use REG_BIT() & co. for AUX CH registersVille Syrjälä3-55/+52
Modernize the DP AUX CH register definitions with REG_BIT() & co. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jouni Högander <[email protected]>
2023-05-11drm/i915: Define more PS_CTRL bitsVille Syrjälä1-0/+11
To avoid annoying spec lookups let's define more PS_CTRL bits in the header. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Luca Coelho <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.