summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-07-09dpll: zl3073x: Add support to get/set priority on input pinsIvan Vecera
Add support for getting and setting input pin priority. Implement required callbacks and set appropriate capability for input pins. Although the pin priority make sense only if the DPLL is running in automatic mode we have to expose this capability unconditionally because input pins (references) are shared between all DPLLs where one of them can run in automatic mode while the other one not. Co-developed-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-11-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09dpll: zl3073x: Implement input pin selection in manual modeIvan Vecera
Implement input pin state setting if the DPLL is running in manual mode. The driver indicates manual mode if the DPLL mode is one of ref-lock, forced-holdover, freerun. Use these modes to implement input pin state change between connected and disconnected states. When the user set the particular pin as connected the driver marks this input pin as forced reference and switches the DPLL mode to ref-lock. When the use set the pin as disconnected the driver switches the DPLL to freerun or forced holdover mode. The switch to holdover mode is done if the DPLL has holdover capability (e.g is currently locked with holdover acquired). Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-10-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09dpll: zl3073x: Register DPLL devices and pinsIvan Vecera
Enumerate all available DPLL channels and registers a DPLL device for each of them. Check all input references and outputs and register DPLL pins for them. Number of registered DPLL pins depends on configuration of references and outputs. If the reference or output is configured as differential one then only one DPLL pin is registered. Both references and outputs can be also disabled from firmware configuration and in this case no DPLL pins are registered. All registrable references are registered to all available DPLL devices with exception of DPLLs that are configured in NCO (numerically controlled oscillator) mode. In this mode DPLL channel acts as PHC and cannot be locked to any reference. Device outputs are connected to one of synthesizers and each synthesizer is driven by some DPLL channel. So output pins belonging to given output are registered to DPLL device that drives associated synthesizer. Finally add kworker task to monitor async changes on all DPLL channels and input pins and to notify about them DPLL core. Output pins are not monitored as their parameters are not changed asynchronously by the device. Co-developed-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Prathosh Satish <Prathosh.Satish@microchip.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-9-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09dpll: zl3073x: Read DPLL types and pin properties from system firmwareIvan Vecera
Add support for reading of DPLL types and optional pin properties from the system firmware (DT, ACPI...). The DPLL types are stored in property 'dpll-types' as string array and possible values 'pps' and 'eec' are mapped to DPLL enums DPLL_TYPE_PPS and DPLL_TYPE_EEC. The pin properties are stored under 'input-pins' and 'output-pins' sub-nodes and the following ones are supported: * reg integer that specifies pin index * label string that is used by driver as board label * connection-type string that indicates pin connection type * supported-frequencies-hz array of u64 values what frequencies are supported / allowed for given pin with respect to hardware wiring Do not blindly trust system firmware and filter out frequencies that cannot be configured/represented in device (input frequencies have to be factorized by one of the base frequencies and output frequencies have to divide configured synthesizer frequency). Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-8-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09dpll: zl3073x: Fetch invariants during probeIvan Vecera
Several configuration parameters will remain constant at runtime, so we can load them during probe to avoid excessive reads from the hardware. Read the following parameters from the device during probe and store them for later use: * enablement status and frequencies of the synthesizers and their associated DPLL channels * enablement status and type (single-ended or differential) of input pins * associated synthesizers, signal format, and enablement status of outputs Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-7-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09dpll: Add basic Microchip ZL3073x supportIvan Vecera
Microchip Azurite ZL3073x represents chip family providing DPLL and optionally PHC (PTP) functionality. The chips can be connected be connected over I2C or SPI bus. They have the following characteristics: * up to 5 separate DPLL units (channels) * 5 synthesizers * 10 input pins (references) * 10 outputs * 20 output pins (output pin pair shares one output) * Each reference and output can operate in either differential or single-ended mode (differential mode uses 2 pins) * Each output is connected to one of the synthesizers * Each synthesizer is driven by one of the DPLL unit The device uses 7-bit addresses and 8-bits values. It exposes 8-, 16-, 32- and 48-bits registers in address range <0x000,0x77F>. Due to 7bit addressing, the range is organized into pages of 128 bytes, with each page containing a page selector register at address 0x7F. For reading/writing multi-byte registers, the device supports bulk transfers. Add basic functionality to access device registers, probe functionality both I2C and SPI cases and add devlink support to provide info and to set clock ID parameter. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250704182202.1641943-6-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09virtio-net: xsk: rx: move the xdp->data adjustment to buf_to_xdp()Bui Quang Minh
This commit does not do any functional changes. It moves xdp->data adjustment for buffer other than first buffer to buf_to_xdp() helper so that the xdp_buff adjustment does not scatter over different functions. Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Link: https://patch.msgid.link/20250705075515.34260-1-minhquangbui99@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: ngbevf: add link update flowMengyuan Lou
Add link update flow to wangxun 1G virtual functions. Get link status from pf in mbox, and if it is failed then check the vx_status, because vx_status switching is too slow. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-13-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: ngbevf: init interrupts and request irqsMengyuan Lou
Add specific parameters for irq alloc, then use wx_init_interrupt_scheme to initialize interrupt allocation in probe. Add .ndo_start_xmit support and start all queues. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-12-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: ngbevf: add sw init pci info and reset hardwareMengyuan Lou
Do sw init and reset hw for ngbevf virtual functions, then register netdev. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-11-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: wangxun: add ngbevf buildMengyuan Lou
Add doc build infrastructure for ngbevf driver. Implement the basic PCI driver loading and unloading interface. Initialize the id_table which support 1G virtual functions for Wangxun. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-10-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: txgbevf: add link update flowMengyuan Lou
Add link update flow to wangxun 10/25/40G virtual functions. Get link status from pf in mbox, and if it is failed then check the vx_status, because vx_status switching is too slow. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-9-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: txgbevf: Support Rx and Tx process pathMengyuan Lou
Improve the configuration of Rx and Tx ring. Setup and alloc resources. Configure Rx and Tx unit on hardware. Add .ndo_start_xmit support and start all queues. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-8-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: txgbevf: init interrupts and request irqsMengyuan Lou
Add irq alloc flow functions for vf. Alloc pcie msix irqs for drivers and request_irq for tx/rx rings and misc other events. If the application is successful, config vertors for interrupts. Enable interrupts mask in wxvf_irq_enable. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-7-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: txgbevf: add sw init pci info and reset hardwareMengyuan Lou
Add sw init and reset hw for txgbevf virtual functions which initialize basic parameters, and then register netdev. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-6-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: wangxun: add txgbevf buildMengyuan Lou
Add doc build infrastructure for txgbevf driver. Implement the basic PCI driver loading and unloading interface. Initialize the id_table which support 10/25/40G virtual functions for Wangxun. Ioremap the space of bar0 and bar4 which will be used. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-5-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: libwx: add wangxun vf common apiMengyuan Lou
Add common wx_configure_vf and wx_set_mac_vf for ngbevf and txgbevf. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-4-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: libwx: add base vf api for vf driversMengyuan Lou
Implement mbox_write_and_read_ack functions which are used to set basic functions like set_mac, get_link.etc for vf. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-3-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09net: libwx: add mailbox api for wangxun vf driversMengyuan Lou
Implements the mailbox interfaces for Wangxun vf drivers which will be used in txgbevf and ngbevf. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-2-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-09x86/hyperv: Clean up hv_map/unmap_interrupt() return valuesNuno Das Neves
Fix the return values of these hypercall helpers so they return a negated errno either directly or via hv_result_to_errno(). Update the callers to check for errno instead of using hv_status_success(), and remove redundant error printing. While at it, rearrange some variable declarations to adhere to style guidelines i.e. "reverse fir tree order". Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1751582677-30930-5-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1751582677-30930-5-git-send-email-nunodasneves@linux.microsoft.com>
2025-07-09PCI: hv: Don't load the driver for baremetal root partitionMukesh Rathor
The root partition only uses VMBus when running nested. When running on baremetal the Hyper-V PCI driver is not needed, so do not initialize it. Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/1751582677-30930-2-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1751582677-30930-2-git-send-email-nunodasneves@linux.microsoft.com>
2025-07-09net: mana: Fix warnings for missing export.h header inclusionNaman Jain
Fix below warning in Hyper-V's MANA drivers that comes when kernel is compiled with W=1 option. Include export.h in driver files to fix it. * warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250611100459.92900-7-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250611100459.92900-7-namjain@linux.microsoft.com>
2025-07-09PCI: hv: Fix warnings for missing export.h header inclusionNaman Jain
Fix below warning in Hyper-V PCI driver that comes when kernel is compiled with W=1 option. Include export.h in driver files to fix it. * warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250611100459.92900-6-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250611100459.92900-6-namjain@linux.microsoft.com>
2025-07-09clocksource: hyper-v: Fix warnings for missing export.h header inclusionNaman Jain
Fix below warning in Hyper-V clocksource driver that comes when kernel is compiled with W=1 option. Include export.h in driver files to fix it. * warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250611100459.92900-5-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250611100459.92900-5-namjain@linux.microsoft.com>
2025-07-09Drivers: hv: Fix warnings for missing export.h header inclusionNaman Jain
Fix below warning in Hyper-V drivers that comes when kernel is compiled with W=1 option. Include export.h in driver files to fix it. * warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250611100459.92900-2-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250611100459.92900-2-namjain@linux.microsoft.com>
2025-07-09Drivers: hv: Fix the check for HYPERVISOR_CALLBACK_VECTORNaman Jain
__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-09Drivers: hv: Select CONFIG_SYSFB only if EFI is enabledMichael Kelley
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-09PM: sleep: Call pm_restore_gfp_mask() after dpm_resume()Rafael J. Wysocki
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 Torvalds
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: of: initialize local variable passed to the .of_xlate() callbackAlexander Stein
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-09drm/gem: Fix race in drm_gem_handle_create_tail()Simona Vetter
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-09drm/framebuffer: Acquire internal references on GEM handlesThomas Zimmermann
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-09pch_uart: Fix dma_sync_sg_for_device() nents valueThomas Fourier
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 Hovold
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-09Merge tag 'usb-serial-6.16-rc6' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial device id for 6.16-rc6 Here's a new modem device id. Everything has been in linux-next with no reported issues. * tag 'usb-serial-6.16-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Foxconn T99W640
2025-07-09pmdomain: governor: Consider CPU latency tolerance from pm_domain_cpu_govMaulik Shah
pm_domain_cpu_gov is selecting a cluster idle state but does not consider latency tolerance of child CPUs. This results in deeper cluster idle state whose latency does not meet latency tolerance requirement. Select deeper idle state only if global and device latency tolerance of all child CPUs meet. Test results on SM8750 with 300 usec PM-QoS on CPU0 which is less than domain idle state entry (2150) + exit (1983) usec latency mentioned in devicetree, demonstrate the issue. # echo 300 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us Before: (Usage is incrementing) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 29817 537 8 270 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 30348 542 8 271 0 After: (Usage is not incrementing due to latency tolerance) ====== # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 # cat /sys/kernel/debug/pm_genpd/power-domain-cluster0/idle_states State Time Spent(ms) Usage Rejected Above Below S0 39319 626 14 307 0 Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Fixes: e94999688e3a ("PM / Domains: Add genpd governor for CPUs") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250709-pmdomain_qos-v2-1-976b12257899@oss.qualcomm.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-07-09usb: gadget: configfs: Fix OOB read on empty string writeXinyu Liu
When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately. Signed-off-by: Xinyu Liu <katieeliu@tencent.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/tencent_B1C9481688D0E95E7362AB2E999DE8048207@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-09Merge tag 'iwlwifi-next-2025-07-09' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi features, notably: - PNVM integrated in the ucode image - more cleanups in the transport layer ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-09lenovo-wmi-hotkey: Avoid triggering error -5 due to missing mute LEDJackie Dong
Not all of Lenovo non-ThinkPad devices support both mic mute LED (on F4) and audio mute LED (on F1). Some of them only support one mute LED, some of them don't have any mute LEDs. If any of the mute LEDs is missing, the driver reports error -5. Check if the device supports a mute LED or not. Do not trigger error -5 message from missing a mute LED if it is not supported on the device. Signed-off-by: Jackie Dong <xy-jackie@139.com> Suggested-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250709035716.36267-1-xy-jackie@139.com [ij: major edits to the changelog.] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-09wifi: iwlwifi: mvm: remove support for iwl_wowlan_info_notif_v4Miri Korenblit
FWs with this version are no longer supported on any device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.1668a7430521.I488d69251aed62f0b11a2553f972a1730bc8b6cf@changeid
2025-07-09wifi: iwlwifi: bump minimum API version in BZMiri Korenblit
Stop supporting older FWs Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.71404c289481.Iea4f3d36e18029a817ec5d6641d08ac5ee025678@changeid
2025-07-09wifi: iwlwifi: mvm: remove unneeded argumentMiri Korenblit
iwl_mvm_set_key_rx_seq is called only once when the installed argument is false. Remove this argument. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.2586112afd70.Iddf9a2b24546cb3a1506d68ca41ed215f88cff5c@changeid
2025-07-09wifi: iwlwifi: mvm: remove MLO GTK rekey codeMiri Korenblit
iwlmvm driver does not support MLO. Remove this code Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.4957e50dee91.I2a432256dbc3069e0300e1f833e10a93d203f538@changeid
2025-07-09wifi: iwlwifi: pcie: rename iwl_pci_gen1_2_probe() argumentJohannes Berg
Using 'trans' for the mac config is confusing, rename the argument to 'mac_cfg'. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.72d87406f8d7.I8b39f01e06ad7791efe718c267cbf367233920a3@changeid
2025-07-09wifi: iwlwifi: match discrete/integrated to fix some namesJohannes Berg
Some device names were wrong because our internal data suggested that discrete Ga devices have B-step RF, when they actually have C-step. However, matching the step for them is bad anyway. Change the code to be able to find the devinfo depending on the device being integrated or discrete. This is only for the names, since the RF config cannot be different for the same RF because it's discrete or integrated, so add a kunit test that ensures both (a) the RF config is the same and (b) the name is different (the latter really only because that's the whole point of having a match on the discrete/integrated bit.) Remove the RF step matching since it's no longer needed now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.e048a94659f1.Ie5919c70e9d8e3a28152aaf3cdffd19ed3d4f5c7@changeid
2025-07-09wifi: iwlwifi: remove Intel driver load messageJohannes Berg
There's really not much value in printing something just because the driver loaded, remove that message. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.fe33c279a45d.I16a9cbcfce92a1d1b8b26a20ea9911e8a5a0b1cc@changeid
2025-07-09wifi: iwlwifi: mvm/mld: make PHC messages debug messagesJohannes Berg
These have no real value for normal users, print them as debug messages instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.bd2df0705d89.Ic6f042588ef17719653c077ff89a8b9149c22f92@changeid
2025-07-09wifi: iwlwifi: trans: remove iwl_trans_initMiri Korenblit
We needed it for setting up trans parameters that could change later in the probe flow. This is no longer true, now we know all the parameters before we allocate the trans, so we can just send the right parameters to iwl_trans_alloc and have all initializations done there. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> .../net/wireless/intel/iwlwifi/iwl-trans.c | 25 ++-------- .../net/wireless/intel/iwlwifi/iwl-trans.h | 8 +-- .../intel/iwlwifi/pcie/gen1_2/trans.c | 50 ++++++++++++------- 3 files changed, 41 insertions(+), 42 deletions(-) Link: https://patch.msgid.link/20250709081300.9602fde079de.Iaede14c91095560852f9b441f1e16546b0a06bdd@changeid
2025-07-09wifi: iwlwifi: pcie move common probe logicMiri Korenblit
Move the parts of the probe that are not gen specific to the common probe function. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.91aee0874e79.Ib762365933d4dd4fc0bf07833226cd7118dee0a1@changeid
2025-07-09wifi: iwlwifi: bump FW API to 102 for BZ/SC/DRMiri Korenblit
Start supporting FW API version 102 on those devices. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709081300.da98a7b6be42.I77150bbf55eb160dbe0ef75c3e28afc053f27ec3@changeid
generated by cgit (git 2.34.1) at 2025-09-15 06:07:28 +0000