summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-07-10Drivers: hv: Fix the check for HYPERVISOR_CALLBACK_VECTORNaman Jain1-4/+5
__is_defined(HYPERVISOR_CALLBACK_VECTOR) would return 1, only if HYPERVISOR_CALLBACK_VECTOR macro is defined as 1. However its value is 0xf3 and this leads to __is_defined() returning 0. The expectation was to just check whether this MACRO is defined or not and get 1 if it's defined. Replace __is_defined with #ifdef blocks instead to fix it. Fixes: 1dc5df133b98 ("Drivers: hv: vmbus: Get the IRQ number from DeviceTree") Cc: stable@kernel.org Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Link: https://lore.kernel.org/r/20250707084322.1763-1-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250707084322.1763-1-namjain@linux.microsoft.com>
2025-07-10nbd: fix lockdep deadlock warningMing Lei1-1/+11
nbd grabs device lock nbd->config_lock for updating nr_hw_queues, this ways cause the following lock dependency: -> #2 (&disk->open_mutex){+.+.}-{4:4}: lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 __mutex_lock_common kernel/locking/mutex.c:602 [inline] __mutex_lock+0x166/0x1292 kernel/locking/mutex.c:747 mutex_lock_nested+0x14/0x1c kernel/locking/mutex.c:799 __del_gendisk+0x132/0xac6 block/genhd.c:706 del_gendisk+0xf6/0x19a block/genhd.c:819 nbd_dev_remove+0x3c/0xf2 drivers/block/nbd.c:268 nbd_dev_remove_work+0x1c/0x26 drivers/block/nbd.c:284 process_one_work+0x96a/0x1f32 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x5ce/0xde8 kernel/workqueue.c:3402 kthread+0x39c/0x7d4 kernel/kthread.c:464 ret_from_fork_kernel+0x2a/0xbb2 arch/riscv/kernel/process.c:214 ret_from_fork_kernel_asm+0x16/0x18 arch/riscv/kernel/entry.S:327 -> #1 (&set->update_nr_hwq_lock){++++}-{4:4}: lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 down_write+0x9c/0x19a kernel/locking/rwsem.c:1577 blk_mq_update_nr_hw_queues+0x3e/0xb86 block/blk-mq.c:5041 nbd_start_device+0x140/0xb2c drivers/block/nbd.c:1476 nbd_genl_connect+0xae0/0x1b24 drivers/block/nbd.c:2201 genl_family_rcv_msg_doit+0x206/0x2e6 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x514/0x78e net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x3be net/netlink/af_netlink.c:2534 genl_rcv+0x36/0x4c net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x4f0/0x82c net/netlink/af_netlink.c:1339 netlink_sendmsg+0x85e/0xdd6 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0xcc/0x160 net/socket.c:727 ____sys_sendmsg+0x63e/0x79c net/socket.c:2566 ___sys_sendmsg+0x144/0x1e6 net/socket.c:2620 __sys_sendmsg+0x188/0x246 net/socket.c:2652 __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __riscv_sys_sendmsg+0x70/0xa2 net/socket.c:2655 syscall_handler+0x94/0x118 arch/riscv/include/asm/syscall.h:112 do_trap_ecall_u+0x396/0x530 arch/riscv/kernel/traps.c:341 handle_exception+0x146/0x152 arch/riscv/kernel/entry.S:197 -> #0 (&nbd->config_lock){+.+.}-{4:4}: check_noncircular+0x132/0x146 kernel/locking/lockdep.c:2178 check_prev_add kernel/locking/lockdep.c:3168 [inline] check_prevs_add kernel/locking/lockdep.c:3287 [inline] validate_chain kernel/locking/lockdep.c:3911 [inline] __lock_acquire+0x12b2/0x24ea kernel/locking/lockdep.c:5240 lock_acquire kernel/locking/lockdep.c:5871 [inline] lock_acquire+0x1ac/0x448 kernel/locking/lockdep.c:5828 __mutex_lock_common kernel/locking/mutex.c:602 [inline] __mutex_lock+0x166/0x1292 kernel/locking/mutex.c:747 mutex_lock_nested+0x14/0x1c kernel/locking/mutex.c:799 refcount_dec_and_mutex_lock+0x60/0xd8 lib/refcount.c:118 nbd_config_put+0x3a/0x610 drivers/block/nbd.c:1423 nbd_release+0x94/0x15c drivers/block/nbd.c:1735 blkdev_put_whole+0xac/0xee block/bdev.c:721 bdev_release+0x3fe/0x600 block/bdev.c:1144 blkdev_release+0x1a/0x26 block/fops.c:684 __fput+0x382/0xa8c fs/file_table.c:465 ____fput+0x1c/0x26 fs/file_table.c:493 task_work_run+0x16a/0x25e kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0x118/0x134 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_trap_ecall_u+0x3f0/0x530 arch/riscv/kernel/traps.c:355 handle_exception+0x146/0x152 arch/riscv/kernel/entry.S:197 Also it isn't necessary to require nbd->config_lock, because blk_mq_update_nr_hw_queues() does grab tagset lock for sync everything. Fixes the issue by releasing ->config_lock & retry in case of concurrent updating nr_hw_queues. Fixes: 98e68f67020c ("block: prevent adding/deleting disk during updating nr_hw_queues") Reported-by: syzbot+2bcecf3c38cb3e8fdc8d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6855034f.a00a0220.137b3.0031.GAE@google.com Reviewed-by: Yu Kuai <yukuai3@huawei.com> Cc: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Link: https://lore.kernel.org/r/20250709111744.2353050-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-10Drivers: hv: Select CONFIG_SYSFB only if EFI is enabledMichael Kelley1-1/+1
Commit 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") selects CONFIG_SYSFB for Hyper-V guests so that screen_info is available to the VMBus driver to get the location of the framebuffer in Generation 2 VMs. However, if CONFIG_HYPERV is enabled but CONFIG_EFI is not, a kernel link error results in ARM64 builds because screen_info is provided by the EFI firmware interface. While configuring an ARM64 Hyper-V guest without EFI isn't useful since EFI is required to boot, the configuration is still possible and the link error should be prevented. Fix this by making the selection of CONFIG_SYSFB conditional on CONFIG_EFI being defined. For Generation 1 VMs on x86/x64, which don't use EFI, the additional condition is OK because such VMs get the framebuffer information via a mechanism that doesn't use screen_info. Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/linux-hyperv/20250610091810.2638058-1-arnd@kernel.org/ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506080820.1wmkQufc-lkp@intel.com/ Signed-off-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/stable/20250613230059.380483-1-mhklinux%40outlook.com Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Link: https://lore.kernel.org/r/20250613230059.380483-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250613230059.380483-1-mhklinux@outlook.com>
2025-07-10drm/xe: Expose fan control and voltage regulator versionRaag Jadav2-1/+157
Add sysfs attributes for late binding features which expose bound version to the user. v2: Rework attribute and macro naming (Badal) v3: Drop fancy formatting (Rodrigo) v4: Form version string using local variables (Rodrigo) Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250709164224.2676086-1-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-07-09PM: sleep: Call pm_restore_gfp_mask() after dpm_resume()Rafael J. Wysocki1-1/+1
Commit 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") changed two pm_restore_gfp_mask() calls in enter_state() and hibernation_restore() into one pm_restore_gfp_mask() call in dpm_resume_end(), but it put that call before the dpm_resume() invocation which is too early (some swap-backing devices may not be ready at that point). Moreover, this code ordering change was not even mentioned in the changelog of the commit mentioned above. Address this by moving that call after the dpm_resume() one. Fixes: 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/2797018.mvXUDI8C0e@rjwysocki.net
2025-07-09Merge tag 'pinctrl-v6.16-3' of ↵Linus Torvalds4-3/+40
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Mark som pins as invalid for IRQ use in the Qualcomm driver - Fix up the use of device properties on the MA35DX Nuvoton, apparently something went sidewise - Clear the GPIO debounce settings when going down for suspend in the AMD driver. Very good for some AMD laptops that now wake up from suspend again! - Add the compulsory .can_sleep bool flag in the AW9523 driver, should have been there from the beginning, now there are users finding the bug - Drop some bouncing email address from MAINTAINERS * tag 'pinctrl-v6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: aw9523: fix can_sleep flag for GPIO chip pinctrl: amd: Clear GPIO debounce for suspend pinctrl: nuvoton: Fix boot on ma35dx platforms MAINTAINERS: drop bouncing Lakshmi Sowjanya D pinctrl: qcom: msm: mark certain pins as invalid for interrupts
2025-07-09gpio: sim: allow to mark simulated lines as invalidBartosz Golaszewski1-2/+81
Add a new line-level, boolean property to the gpio-sim configfs interface called 'valid'. It's set by default and the user can unset it to make the line be included in the standard `gpio-reserved-ranges` property when the chip is registered with GPIO core. This allows users to specify which lines should not be available for requesting as GPIOs. Link: https://lore.kernel.org/r/20250630130358.40352-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-09gpio: of: initialize local variable passed to the .of_xlate() callbackAlexander Stein1-1/+1
of_flags is passed down to GPIO chip's xlate function, so ensure this one is properly initialized as - if the xlate callback does nothing with it - we may end up with various configuration errors like: gpio-720 (enable): multiple pull-up, pull-down or pull-disable enabled, invalid configuration Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20250708083829.658051-1-alexander.stein@ew.tq-group.com [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-09mmc: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus11-16/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20250704075434.3220506-1-sakari.ailus@linux.intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-07-09drm/gem: Fix race in drm_gem_handle_create_tail()Simona Vetter1-1/+9
Object creation is a careful dance where we must guarantee that the object is fully constructed before it is visible to other threads, and GEM buffer objects are no difference. Final publishing happens by calling drm_gem_handle_create(). After that the only allowed thing to do is call drm_gem_object_put() because a concurrent call to the GEM_CLOSE ioctl with a correctly guessed id (which is trivial since we have a linear allocator) can already tear down the object again. Luckily most drivers get this right, the very few exceptions I've pinged the relevant maintainers for. Unfortunately we also need drm_gem_handle_create() when creating additional handles for an already existing object (e.g. GETFB ioctl or the various bo import ioctl), and hence we cannot have a drm_gem_handle_create_and_put() as the only exported function to stop these issues from happening. Now unfortunately the implementation of drm_gem_handle_create() isn't living up to standards: It does correctly finishe object initialization at the global level, and hence is safe against a concurrent tear down. But it also sets up the file-private aspects of the handle, and that part goes wrong: We fully register the object in the drm_file.object_idr before calling drm_vma_node_allow() or obj->funcs->open, which opens up races against concurrent removal of that handle in drm_gem_handle_delete(). Fix this with the usual two-stage approach of first reserving the handle id, and then only registering the object after we've completed the file-private setup. Jacek reported this with a testcase of concurrently calling GEM_CLOSE on a freshly-created object (which also destroys the object), but it should be possible to hit this with just additional handles created through import or GETFB without completed destroying the underlying object with the concurrent GEM_CLOSE ioctl calls. Note that the close-side of this race was fixed in f6cd7daecff5 ("drm: Release driver references to handle before making it available again"), which means a cool 9 years have passed until someone noticed that we need to make this symmetry or there's still gaps left :-/ Without the 2-stage close approach we'd still have a race, therefore that's an integral part of this bugfix. More importantly, this means we can have NULL pointers behind allocated id in our drm_file.object_idr. We need to check for that now: - drm_gem_handle_delete() checks for ERR_OR_NULL already - drm_gem.c:object_lookup() also chekcs for NULL - drm_gem_release() should never be called if there's another thread still existing that could call into an IOCTL that creates a new handle, so cannot race. For paranoia I added a NULL check to drm_gem_object_release_handle() though. - most drivers (etnaviv, i915, msm) are find because they use idr_find(), which maps both ENOENT and NULL to NULL. - drivers using idr_for_each_entry() should also be fine, because idr_get_next does filter out NULL entries and continues the iteration. - The same holds for drm_show_memory_stats(). v2: Use drm_WARN_ON (Thomas) Reported-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Tested-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: stable@vger.kernel.org Cc: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250707151814.603897-1-simona.vetter@ffwll.ch
2025-07-09ata: libata-transport: replace scnprintf with sysfs_emit for simple attributesJonathan Velez1-2/+2
sprintf, snprintf, and scnprintf do not consider the PAGE_SIZE maximum of the temporary buffer used for outputting sysfs content and they may overrun the PAGE_SIZE buffer length. To avoid output defects with the ATA transport class simple attributes, use sysfs_emit instead of scnprintf(). This aligns with the sysfs guidance provided in Documentation/filesystems/sysfs.rst. Signed-off-by: Jonathan Velez <jonvelez12345@gmail.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20250709133330.3546-1-jonvelez12345@gmail.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-07-09fbcon: Fix outdated registered_fb reference in commentShixiong Ou1-2/+2
The variable was renamed to fbcon_registered_fb, but this comment was not updated along with the change. Correct it to avoid confusion. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info") [sima: Add Fixes: line.] Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250709103438.572309-1-oushixiong1025@163.com
2025-07-09PCI: endpoint: pci-epf-vntb: Allow BAR assignment via configfsJerome Brunet1-7/+125
The current BAR configuration for the PCI vNTB endpoint function allocates BARs in order, which lacks flexibility and does not account for platform-specific quirks. This is problematic on Renesas platforms, where BAR_4 is a fixed 256B region that ends up being used for MW1, despite being better suited for doorbells. Add new configfs attributes to allow users to specify arbitrary BAR assignments. If no configuration is provided, the driver retains its original behavior of sequential BAR allocation, preserving compatibility with existing userspace setups. This enables use cases such as assigning BAR_2 for MW1 and using the limited BAR_4 for doorbells on Renesas platforms. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: adjusted the indent of EPF_NTB_BAR_W, fixed kdoc & squashed bar fix] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-3-fc685a22ad28@baylibre.com
2025-07-09drm/ast: Gen7: Switch default registers to gen4+ stateThomas Zimmermann2-35/+1
Change the default register settings for Gen7 to mach Gen4 and later. Gen7 currently uses the settings for Gen1, which is most likely incorrect. Using Gen4+ settings enables E2M linear-access modes in VGACRA2. It appears to be related to the chip's PCIE2MBOX feature, which is unused. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-11-tzimmermann@suse.de
2025-07-09drm/ast: Gen7: Disable VGASR0[1] as on Gen4+Thomas Zimmermann1-0/+1
Set VGACRB6[5], which disables asynchronous sequencer resets via VGASR0[1]. This was most likely an oversight when adding support for Gen7. Aligns Gen7 with the earlier Gen4+. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-10-tzimmermann@suse.de
2025-07-09drm/ast: Split ast_set_def_ext_reg() by chip generationThomas Zimmermann7-40/+111
Duplicate ast_set_def_ext_reg() for individual chip generations and move call it into per-chip source files. Remove the original code. AST2100 and AST2500 reuse the function from earlier chips. AST2600 appears to be incorrect as it uses an older function. Keep this behavior for now. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-9-tzimmermann@suse.de
2025-07-09drm/ast: Handle known struct ast_dramstruct with helpersThomas Zimmermann3-19/+41
Most of struct ast_dramstruct stores hardware state. Some index values have known or special meaning. The known values are - 0xffff - Terminal entry in the array - 0xff00 - Delays the programming for usecs - 0x0004 - Sets the type of DRAM Add constants and helper macros for these cases. Also add a helper macro for testing. Update Gen1 and Gen2+ accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-8-tzimmermann@suse.de
2025-07-09drm/ast: Move struct ast_dramstruct to ast_post.hThomas Zimmermann4-13/+8
Declare struct ast_dramstruct in ast_post.h and remove its original header file. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-7-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen2+ and Gen1 POST code to separate source filesThomas Zimmermann6-370/+478
Move POST code for Gen2+ and Gen1 to separate source files and hide it in ast_2100_post() ans ast_2000_post(). With P2A configuration, the POST logic for these chip generations has been mingled in ast_init_dram_reg(). Hence, handle all generations in a single change. The split simplifies both cases. Also move the DRAM init tables for each Gen into the respective source file. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-6-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen4+ POST code to separate source fileThomas Zimmermann4-1262/+1302
Move POST code for Gen4+ to separate source file and hide it in ast_2300_post(). With P2A configuration, it performs a full board POST and enables the transmitter chip; otherwise it only enables the transmitter chip. Also fix coding style in several places. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-5-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen6+ POST code to separate source fileThomas Zimmermann6-522/+576
Move POST code for Gen6+ to separate source file and hide it in ast_2500_post(). With P2A configuration, it performs a full board POST; otherwise it enables the transmitter chip. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-4-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen7+ POST code to separate source fileThomas Zimmermann4-5/+48
Move POST code for Gen7+ to separate source file and hide it in ast_2600_post(). There's not much going on here except for enabling the DP transmitter chip. v2: - simplify logic (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-3-tzimmermann@suse.de
2025-07-09drm/ast: Declare helpers for POST in headerThomas Zimmermann2-5/+21
Provide POST helpers in header file before splitting up the AST POST code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-2-tzimmermann@suse.de
2025-07-09soc/tegra: cbb: Add support for CBB fabrics in Tegra254Sumit Gupta1-0/+58
Add support for CBB 2.0 based fabrics in Tegra254 SoC using ACPI. Fabrics reporting errors are: C2C, GPU and Display_Cluster. Tegra254 uses a hardware based lookup to get target node address, so the target_map tables for each fabric are no longer needed. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Add support for CBB fabrics in Tegra264Sumit Gupta1-0/+279
Add support for CBB 2.0 based fabrics in Tegra264 SoC using DT. Fabrics reporting errors are: SYSTEM, TOP0, UPHY0 and VISION. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Support HW lookup to get timed out target addressSumit Gupta1-5/+36
Add support for hardware based lookup to get the address of the timed out target node. This features is added in upcoming SoCs and avoids the need for creating per fabric target_map tables in the driver. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Improve handling for per SoC fabric dataSumit Gupta1-108/+131
Improve handling for the per SoC fabrics and targets. The below changes make them more flexible and ready for future SoC's. - Added SoC prefix to Fabric_ID enums. - Rename *lookup_target_timeout() to *sw_lookup_target_timeout() to make it separate from HW based lookup function to be added later. - Moved target_map within fabric_lookup table to make it easy to check whether SW vs HW lookup is supported and handle accordingly. - Slight improvements to some error prints. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Make error interrupt enable and status per SoCSumit Gupta1-2/+20
Make the error interrupt enable and error status fields as per SoC. Both of these fields can change for different SoC's. Moving them to per SoC data helps to set or clear the required bits only for a SoC. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Change master/slave to initiator/targetSumit Gupta2-119/+120
Change usage of 'Master/Slave' to 'Initiator/Target' as per the new convention. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUSSumit Gupta1-0/+2
When error is injected with the ERR_FORCE register, then this register is not auto cleared on clearing the ERR_STATUS register. This causes repeated interrupts on error injection. To fix, set the ERR_FORCE to zero along with clearing the ERR_STATUS register after handling error. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09platform/x86/amd/hsmp: Enhance the print messages to prevent confusionSuma Hegde2-8/+29
When the HSMP ACPI device is present, loading the amd_hsmp.ko module incorrectly displays the message "HSMP is not supported on Family:%x model:%x\n" despite being supported by the hsmp_acpi.ko module, leading to confusion. To address this issue, relocate the acpi_dev_present() check to the beginning of the hsmp_plt_init() and revise the print message to better reflect the current support status. Additionally, add more error messages in the error paths and debug messages to indicate successful probing for both hsmp_acpi.ko and amd_hsmp.ko modules. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Suma Hegde <suma.hegde@amd.com> Link: https://lore.kernel.org/r/20250709105413.2487851-1-suma.hegde@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-09firmware: tegra: bpmp: Use of_reserved_mem_region_to_resource() for ↵Rob Herring (Arm)1-7/+2
"memory-region" Use the newly added of_reserved_mem_region_to_resource() function to handle "memory-region" properties. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250703183434.2073375-1-robh@kernel.org Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-09drm/framebuffer: Acquire internal references on GEM handlesThomas Zimmermann4-26/+61
Acquire GEM handles in drm_framebuffer_init() and release them in the corresponding drm_framebuffer_cleanup(). Ties the handle's lifetime to the framebuffer. Not all GEM buffer objects have GEM handles. If not set, no refcounting takes place. This is the case for some fbdev emulation. This is not a problem as these GEM objects do not use dma-bufs and drivers will not release them while fbdev emulation is running. Framebuffer flags keep a bit per color plane of which the framebuffer holds a GEM handle reference. As all drivers use drm_framebuffer_init(), they will now all hold dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers"). In the GEM framebuffer helpers, restore the original ref counting on buffer objects. As the helpers for handle refcounting are now no longer called from outside the DRM core, unexport the symbols. v3: - don't mix internal flags with mode flags (Christian) v2: - track framebuffer handle refs by flag - drop gma500 cleanup (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/ Tested-by: Bert Karwatzki <spasswolf@web.de> Tested-by: Mario Limonciello <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Anusha Srivatsa <asrivats@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmermann@suse.de
2025-07-09serial: sh-sci: Add support for RZ/T2H SCIThierry Bultel6-10/+546
Define a new RSCI port type, and the RSCI 32 bits registers set. The RZ/T2H SCI has a a fifo, and a quite different set of registers from the original SH SCI ones. DMA is not supported yet. Signed-off-by: Thierry Bultel <thierry.bultel.yh@bp.renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250630202323.279809-6-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09serial: sh-sci: Use private port IDThierry Bultel2-71/+93
New port types cannot be added in serial_core.h, which is shared with userspace. In order to support new port types, the coming new ones will have BIT(7) set in the id value, and in this case, uartport->type is set to PORT_GENERIC. This commit therefore changes all the places where the port type is read, by not relying on uartport->type but on the private value stored in struct sci_port. Signed-off-by: Thierry Bultel <thierry.bultel.yh@bp.renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250630202323.279809-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09serial: sh-sci: Replace direct stop_rx/stop_tx calls with port ops in ↵Lad Prabhakar1-2/+2
sci_shutdown() Replace direct calls to sci_stop_rx() and sci_stop_tx() with port ops callbacks in sci_shutdown(). This enables the RSCI driver, which reuses the SCI core but implements its own stop_rx and stop_tx logic, to reuse sci_shutdown() without duplicating code. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250630202323.279809-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09serial: sh-sci: Add R-Car Gen5 supportKuninori Morimoto1-0/+3
Add "rcar-gen5-scif" compatible string for R-Car Gen5 support. Signed-off-by: Nghia Nguyen <nghia.nguyen.jg@renesas.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/87cyahdgfu.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09serial: 8520_ce4100: Reuse mem_serial_in() in ce4100_mem_serial_in()Andy Shevchenko1-7/+2
In one place in ce4100_mem_serial_in() the code may be replaced with mem_serial_in() call. Do it so and collapse two conditionals into one. Suggested-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250701134200.2621898-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09pch_uart: Fix dma_sync_sg_for_device() nents valueThomas Fourier1-1/+1
The dma_sync_sg_for_device() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned according to the documentation in Documentation/core-api/dma-api.rst:450: With the sync_sg API, all the parameters must be the same as those passed into the sg mapping API. Fixes: da3564ee027e ("pch_uart: add multi-scatter processing") Cc: stable <stable@kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250701113452.18590-2-fourier.thomas@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09serial: core: fix OF node leakJohan Hovold1-0/+3
Make sure to drop the OF node reference taken when initialising the control and port devices when the devices are later released. Fixes: d36f0e9a0002 ("serial: core: restore of_node information in sysfs") Cc: Aidan Stewart <astewart@tektelic.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20250708085817.16070-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09lpfc: don't use file->f_path.dentry for comparisonsAl Viro2-48/+50
If you want a home-grown switch, at least use enum for selector... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250708025734.GT1880847@ZenIV Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09debugfs_get_aux(): allow storing non-const void *Al Viro1-1/+1
typechecking is up to users, anyway... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250702212616.GI3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09fix tt_command_write()Al Viro1-20/+10
1) unbalanced debugfs_file_get(). Not needed in the first place - file_operations are accessed only via debugfs_create_file(), so debugfs wrappers will take care of that itself. 2) kmalloc() for a buffer used only for duration of a function is not a problem, but for a buffer no longer than 16 bytes? 3) strstr() is for finding substrings; for finding a character there's strchr(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: "Rafael J. Wysocki" <rafael@kernel.org> Link: https://lore.kernel.org/r/20250702212542.GH3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09netronome: don't bother with debugfs_real_fops()Al Viro1-5/+10
Just turn nfp_tx_q_show() into a wrapper for helper that gets told whether it's tx or xdp via an explicit argument and have nfp_xdp_q_show() call the underlying helper instead. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Reviewed-by: Louis Peens <louis.peens@corigine.com> Link: https://lore.kernel.org/r/20250702212205.GF3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09regmap: get rid of redundant debugfs_file_{get,put}()Al Viro1-10/+0
pointless in ->read()/->write() of file_operations used only via debugfs_create_file() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250702211602.GC3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09hfi1: get rid of redundant debugfs_file_{get,put}()Al Viro3-44/+2
All files in question are created via debugfs_create_file(), so exclusion with removals is provided by debugfs wrappers; as the matter of fact, hfi1-private wrappers had been redundant at least since 2017... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250702211508.GB3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09zynqmp: don't bother with debugfs_file_{get,put}() in proxied fopsAl Viro1-34/+4
When debugfs file has been created by debugfs_create_file_unsafe(), we do need the file_operations methods to use debugfs_file_{get,put}() to prevent concurrent removal; for files created by debugfs_create_file() that is done in the wrappers that call underlying methods, so there's no point whatsoever duplicating that in the underlying methods themselves. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250702211408.GA3406663@ZenIV Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09cpuidle: riscv-sbi: Drop redundant sync_state supportUlf Hansson1-21/+1
The recent updates to the genpd core, can entirely manage the sync_state support for the cpuidle-riscv-sbi-domain. More precisely, genpd prevents our ->power_off() callback from being invoked, until all of our consumers are ready for it. Let's therefore drop the sync_state support for the cpuidle-riscv-sbi-domain as it has become redundant. Cc: Anup Patel <anup@brainfault.org> Cc: linux-riscv@lists.infradead.org Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Colibri iMX8X Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # TI AM62A,Xilinx ZynqMP ZCU106 Reviewed-by: Rahul Pathak <rpathak@ventanamicro.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250701114733.636510-25-ulf.hansson@linaro.org
2025-07-09cpuidle: psci: Drop redundant sync_state supportUlf Hansson1-21/+1
The recent updates to the genpd core, can entirely manage the sync_state support for the cpuidle-psci-domain. More precisely, genpd prevents our ->power_off() callback from being invoked, until all of our consumers are ready for it. Let's therefore drop the sync_state support for the cpuidle-psci-domain as it has become redundant. Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Colibri iMX8X Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # TI AM62A,Xilinx ZynqMP ZCU106 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250701114733.636510-24-ulf.hansson@linaro.org
2025-07-09pmdomain: core: Leave powered-on genpds on until sync_stateUlf Hansson1-0/+4
Powering-off a genpd that was on during boot, before all of its consumer devices have been probed, is certainly prone to problems. For OF based platforms we can rely on using the sync_state mechanism that the fw_devlink provides, to understand when all consumers for a genpd provider have been probed. Let's therefore prevent these genpds from being powered-off until the ->sync_state() callback gets called. Note that, for non-OF based platform we will keep relying on the late_initcall_sync, which seems to be the best we can do for now. Suggested-by: Saravana Kannan <saravanak@google.com> Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Colibri iMX8X Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # TI AM62A,Xilinx ZynqMP ZCU106 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250701114733.636510-23-ulf.hansson@linaro.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 07:12:53 +0300