summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-19iommu/arm-smmu-v3: Remove CMDQ_OP_CFGI_CD_ALL from arm_smmu_cmdq_build_cmd()Jason Gunthorpe
Nothing uses this, just dead code. Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Tested-by: Pranjal Shrivastava <praan@google.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Samiullah Khawaja <skhawaja@google.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct arm_smmu_cmdJason Gunthorpe
Convert the batch's type to also get the remaining helper functions to use the new type and complete replacing naked u64s with the new struct. The low-level queue_write()/queue_read()/queue_remove_raw() functions remain u64-based since they are shared by event and PRI queues which have different entry sizes. Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Tested-by: Pranjal Shrivastava <praan@google.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Samiullah Khawaja <skhawaja@google.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission functionsJason Gunthorpe
Continue removing struct arm_smmu_cmdq_ent in favour of the HW based struct arm_smmu_cmd. Switch the lower level issue commands to work on the native struct by lifting arm_smmu_cmdq_build_cmd() into all the callers. Following patches will revise each of the arm_smmu_cmdq_build_cmd() call sites to replace it with the HW struct. Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Tested-by: Pranjal Shrivastava <praan@google.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Samiullah Khawaja <skhawaja@google.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq selection functionsJason Gunthorpe
Start removing the use of struct arm_smmu_cmdq_ent, starting at the lower levels of the call chain. Change the functions that determine what cmdq to issue the batch to into using struct arm_smmu_cmd directly. Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Tested-by: Pranjal Shrivastava <praan@google.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Samiullah Khawaja <skhawaja@google.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19iommu/arm-smmu-v3: Add struct arm_smmu_cmd to represent the HW format commandJason Gunthorpe
Like STE/CD, add a wrapper struct around the u64 array to represent the already FIELD_PREP'd command data. Unlike the STE/CD this is a u64 because the command submission path will have the swap to le64. This makes the API clearer when a u64 is referring to a formatted command and makes the following changes easier to follow. Move the command constants out of the struct and into an enum alongside the rest of the constants defining the HW format so the entire HW format is self contained and independent of struct arm_smmu_cmdq_ent. Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Tested-by: Pranjal Shrivastava <praan@google.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Samiullah Khawaja <skhawaja@google.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recoveryLukas Wunner
After a PCIe Uncorrectable Error has been reported by a device with Intel Vendor Specific Extended Capabilities and has been recovered through a Secondary Bus Reset, its driver calls intel_vsec_pci_probe() to rescan and reinitialize VSECs. intel_vsec_pci_probe() invokes pcim_enable_device() and thereby adds another devm action which calls pcim_disable_device() on driver unbind. So once the driver unbinds, pcim_disable_device() will be called as many times as an Uncorrectable Error occurred, plus one. This will lead to an enable_cnt imbalance on driver unbind. Additionally, since commit dc957ab6aa05 ("platform/x86/intel/vsec: Add private data for per-device data"), a devm_kzalloc() allocation is leaked on every Uncorrectable Error. Avoid by splitting the VSEC rescan out of intel_vsec_pci_probe() into a separate helper and calling that on PCIe error recovery. Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v6.0+ Link: https://patch.msgid.link/bd594d09fa866dc51dddc9a447c3b23f9b1402cc.1778736835.git.lukas@wunner.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: uniwill-laptop: Do not enable the charging limit even when forcedArmin Wolf
It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Link: https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-5-W_Armin@gmx.de Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: uniwill-laptop: Fix behavior of "force" module paramArmin Wolf
Users might want to force-enable all possible features even on machines with a valid device descriptor. Until now the "force" module param was ignored on such machines. Fix this to make it easier to test for support of new features. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-4-W_Armin@gmx.de Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: uniwill-laptop: Accept charging threshold of 0Armin Wolf
The power supply sysfs ABI states that: Not all hardware is capable of setting this to an arbitrary percentage. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver. The driver currently violates this ABI by rejecting a charging threshold of 0. Fix this by clamping this value to 1. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-3-W_Armin@gmx.de Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: uniwill-laptop: Properly initialize charging thresholdArmin Wolf
The EC might initialize the charge threshold with 0 to signal that said threshold is uninitialized. Detect this and replace said value with 100 to signal the EC that we want to take control of battery charging. Also set the threshold to 100 if the EC-provided value is invalid. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/surface: surfacepro3_button: Check ACPI_COMPANION()Rafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the surfacepro3_button driver. Fixes: d913a5a12b40 ("platform/surface: surfacepro3_button: Convert to a platform driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Chen Yu <yu.c.chen@intel.com> Link: https://patch.msgid.link/23119222.EfDdHjke4D@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULLRafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-vbtn driver. Fixes: 26173179fae1 ("platform/x86: intel-vbtn: Eval VBDL after registering our notifier") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3426431.aeNJFYEL58@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: intel_sar: Check ACPI_HANDLE() against NULLRafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel_sar driver. Fixes: dcfbd31ef4bc ("platform/x86: BIOS SAR driver for Intel M.2 Modem") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/14023870.uLZWGnKmhe@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: intel-hid: Check ACPI_HANDLE() against NULLRafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-hid driver. Fixes: ecc83e52b28c ("intel-hid: new hid event driver for hotkeys") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/1971512.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: hp_accel: Check ACPI_COMPANION() against NULLRafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the platform/x86 hp_accel driver. Fixes: 8ebcb6c94c71 ("platform/x86: hp_accel: Convert to be a platform driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2425918.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULLRafael J. Wysocki
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 adv_swbutton driver. Fixes: 3d904005f686 ("platform/x86: add support for Advantech software defined button") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/5115425.31r3eYUQgx@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19hp-wmi: fix support for thermal profile Omen 16-с0xxx laptopsКоненко Андрей Викторович
The HP Omen 16-c0xxx (board ID: 8902) has the same WMI interface as other Victus S boards, but requires additional quirks for correctly switching thermal profile. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to the omen_v1_legacy_thermal_params quirk. Testing on board 8902 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Signed-off-by: Konenko Andrey Viktorovich <admin@aquinas.su> Link: https://patch.msgid.link/T3DTKbKwQzOgk_0eUG-kMg@aquinas.su Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19fwctl: pds: Validate RPC input size before parsingHeechan Kang
The fwctl core allocates the device-specific RPC input buffer with fwctl_rpc.in_len and passes that buffer to the driver callback. pdsfc_fw_rpc() casts the buffer to struct fwctl_rpc_pds and then calls pdsfc_validate_rpc(), which reads fields from that structure before checking that the input buffer is large enough to contain it. A short in_len can make pds_fwctl read beyond the allocation. Reject pds RPC buffers that are smaller than struct fwctl_rpc_pds before parsing any pds-specific fields. Fixes: 92c66ee829b9 ("pds_fwctl: add rpc and query support") Link: https://patch.msgid.link/r/20260517062232.1858747-1-gganji11@naver.com Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Heechan Kang <gganji11@naver.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-19PCI: dwc: Use DEFINE_SHOW_ATTRIBUTE for ltssm_status debugfsHans Zhang
Replace the custom open function and file_operations with the standard DEFINE_SHOW_ATTRIBUTE macro to reduce boilerplate code. This also adds the previously missing .release() callback and fixes the seq_file leak during close. Signed-off-by: Hans Zhang <18255117159@163.com> [mani: added a note about implicit release callback change spotted by Sashiko] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260508133432.1964491-1-18255117159@163.com
2026-05-19platform/surface: aggregator_registry: omit battery & AC nodes on Surface ↵Oliver White
Laptop 7 Surface Laptop 7 exposes battery and AC status via Qualcomm PMIC GLINK qcom_battmgr. Registering the standard SSAM battery and AC client devices on this platform causes duplicate power-supply devices to appear. Drop the SSAM battery and AC nodes from the Surface Laptop 7 registry group so that only the qcom_battmgr power supplies are instantiated. Fixes: b27622f13172 ("platform/surface: Add OF support") Signed-off-by: Oliver White <oliverjwhite07@gmail.com> Link: https://patch.msgid.link/20260409034347.17381-1-oliverjwhite07@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19coresight: platform: defer connection counter increment until alloc succeedsJie Gan
coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path. Fixes: 3d4ff657e454 ("coresight: Dynamically add connections") Fixes: e3f4e68797a9 ("coresight: Store in-connections as well as out-connections") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260511-fix-ref-count-issue-v1-1-99d647810d3c@oss.qualcomm.com
2026-05-19spi: Add trace events for Qualcomm GENI SPI driversMark Brown
Praveen Talari <praveen.talari@oss.qualcomm.com> says: Add tracepoints to the Qualcomm GENI (Generic Interface) SPI driver. These trace events enable runtime debugging and performance analysis of SPI operations. The trace events capture SPI clock configuration, setup parameters, transfer details, interrupt status. Usage examples: Enable all SPI traces: echo 1 > /sys/kernel/tracing/events/spi/enable echo 1 > /sys/kernel/debug/tracing/events/qcom_geni_spi/enable cat /sys/kernel/debug/tracing/trace_pipe Example trace output: 1003.956560: spi_message_submit: spi16.0 000000001b20b93c 1003.956642: spi_controller_busy: spi16 1003.956643: spi_message_start: spi16.0 000000001b20b93c 1003.956646: geni_spi_setup_params: 888000.spi: cs=0 mode=0x00000020 mode_changed=0x00000007 cs_changed=0 1003.956647: spi_set_cs: spi16.0 activate 1003.956648: spi_transfer_start: spi16.0 00000000ea1cf8b6 len=16 tx=[4c-80-e4-ca-68-4d-95-aa-ee-99-ae-d7-69-e9-5f-39] rx=[00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00] 1003.956653: geni_spi_clk_cfg: 888000.spi: req_hz=20000000 sclk_hz=100000000 clk_idx=5 clk_div=5 bpw=8 1003.956691: geni_spi_transfer: 888000.spi: len=16 m_cmd=0x00000003 1003.956708: geni_spi_irq: 888000.spi: m_irq=0x08000081 dma_tx=0x00000000 dma_rx=0x00000000 1003.956717: spi_transfer_stop: spi16.0 00000000ea1cf8b6 len=16 tx=[4c-80-e4-ca-68-4d-95-aa-ee-99-ae-d7-69-e9-5f-39] rx=[4c-80-e4-ca-68-4d-95-aa-ee-99-ae-d7-69-e9-5f-39] 1003.956717: spi_set_cs: spi16.0 deactivate 1003.956718: spi_message_done: spi16.0 000000001b20b93c len=16/16 Link: https://patch.msgid.link/20260518-add-tracepoints-for-qcom-geni-spi-v3-0-7928f6810a79@oss.qualcomm.com
2026-05-19spi: qcom-geni: Add trace events for Qualcomm GENI SPI driverPraveen Talari
Add tracepoints to the Qualcomm GENI (Generic Interface) SPI driver. These trace events enable runtime debugging and performance analysis of SPI operations. The trace events capture SPI clock configuration, setup parameters, transfer details, interrupt status. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Link: https://patch.msgid.link/20260518-add-tracepoints-for-qcom-geni-spi-v3-2-7928f6810a79@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-19drm/i915/aux: use polling when irqs are unavailableMichał Grzelak
PTL with physically disconnected display was observed to have 40s longer execution time when testing xe_fault_injection@xe_guc_mmio_send_recv. The issue has not been seen when reverting commit 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read""). Apparently the configuration suffers from not having AUX enabled when using interrupts. One probable cause can be xe enabling interrupts too late: interrupts need memory allocations which currently can't be done before the display FB takeover is done. As for now, use polling for AUX in case interrupts are unavailable. Fixes: 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com
2026-05-19thunderbolt: Add support for USB4STREAMMika Westerberg
Introduce USB4STREAM protocol and Linux implementation. This allows two (or more) hosts to transfer data directly over Thunderbolt/USB4 cable through a character device without need to go through the network stack. Any application that supports read(2) and write(2) in some form should be able to use the device without changes. The data is sent out to the other side over a tunnel inside Thunderbolt/USB4 fabric. The character device is called /dev/tbstreamX where X is the minor number starting from 0. All stream devices need to be configured first. This is done through ConfigFS interface. There can be multiple streams at the same time (this depends on number of DMA rings and available HopIDs) and a single stream supports traffic in both directions. For example there could be an application that uses one stream as control channel and another one as bi-directional data channel. A real use-case for this is to take a backup as a part of recovery initramfs tooling (no need to setup networking or have ssh or similar tooling as part of the initramfs). Say we want to backup the disk of host1 to host2. First Thunderbolt/USB4 cable is connected between the hosts (there can be devices in the middle too) then the receiving side configures the stream: host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0 host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0/backup host2 # echo -1 > /sys/kernel/config/thunderbolt/stream/0-1.0/backup/in_hopid host2 # echo -1 > /sys/kernel/config/thunderbolt/stream/0-1.0/backup/out_hopid We use automatic HopID allocation (writing -1 to HopIDs) for simplicity. From this point forward the /dev/tbstream0 can be used pretty much as regular file: host2 # dd if=/dev/tbstream0 of=/tmp/host1.nvme0n1.backup-$(date +%F) bs=256k The host that is being backed up then configures the stream accordingly: host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0 host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0/backup Here we take advantage of the fact that host2 also announces the active streams through XDomain properties so the name "backup" gives us the HopIDs. It is also possible to configure them manually in the same way we did for host2. Then it is just a matter of copying the data over: host1 # dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k Similarly it is possible to transfer parts of the filesystem. For example copy contents of mydir over to the host2: host2 # gunzip < /dev/tbstream0 | tar xf - host1 # tar cf - mydir | gzip > /dev/tbstream0 Other end of the spectrum use-case is "borrowing" laptop (host1) camera to desktop (host2): host2 # gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! \ autovideosink host1 # gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080 ! \ jpegenc quality=90 ! filesink location=/dev/tbstream0 Once the streams are no longer needed they can be removed: host1 # cd /sys/kernel/config/thunderbolt/stream/ host1 # rmdir -p 0-503.0/backup host2 # cd /sys/kernel/config/thunderbolt/stream host2 # rmdir -p 0-1.0/backup Co-developed-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt: Add support for ConfigFSMika Westerberg
This adds ConfigFS support to USB4/Thunderbolt bus. By itself this just creates the subsystem but it exposes functions that can be used to register groups under it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt: Add tb_ring_flush()Mika Westerberg
This allows the caller to wait for the ring to be empty. We are going to need this in the upcoming userspace tunneling support. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt / net: Let the service drivers configure interrupt throttlingMika Westerberg
Instead of the core driver programming fixed value for throttling let the service drivers to specify the interval if they need this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt / net: Move ring_frame_size() to thunderbolt.hMika Westerberg
This function can be used outside of thunderbolt networking driver so move it to the common header. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt: Allow service drivers to specify their own propertiesMika Westerberg
The XDomain properties can be useful for service drivers, for example to implement a registry for the services they expose. So far there has been no need for service drivers to specify these but with the USB4STREAM driver that we are going to use them. This adds remote and local side properties that the service drivers have access to. Remote side is read-only but the local side can be changed by a service driver. Also provide a mechanism to notify the remote side that there are changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt: Add KUnit test for tb_property_merge_dir()Mika Westerberg
This makes sure it keeps working if we ever need to change it. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19thunderbolt: Add tb_property_merge_dir()Mika Westerberg
This allows merging one XDomain property directory into another. We are going to use this in the subsequent patch. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-19arm_mpam: Update architecture version check for MPAM MSCZeng Heng
In addition to updating the CPU MPAM version check, the MPAM MSC version check also need to be updated. mpam_msc_check_aidr() is added to check the MSC AIDR register, ensuring that both the major and minor version numbers fall within the supported range of the MPAM architecture version. Signed-off-by: Zeng Heng <zengheng4@huawei.com> [ morse: changed mpam_msc_check_aidr() to accept versions like v1.2 ] Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZELeo Jiang
Stop retrying queue allocation when qsz reaches PAGE_SIZE. Signed-off-by: Leo Jiang <leo.jiang1224@foxmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19Merge tag 'ovpn-net-20260514' of https://github.com/OpenVPN/ovpn-net-nextPaolo Abeni
Antonio Quartulli says: ==================== Included fixes: * fix TCP selftest failures by reducing number of attempted pings * fix RCU ptr deref outside of RCU read section * fix UAF in case of TCP peer failed to be added to hashtable * fix race condition between iface teardown and new peer being added * ensure dstats are updated with BH disabled to avoid concurrency * tag 'ovpn-net-20260514' of https://github.com/OpenVPN/ovpn-net-next: ovpn: disable BHs when updating device stats ovpn: fix race between deleting interface and adding new peer ovpn: respect peer refcount in CMD_NEW_PEER error path ovpn: tcp - use cached peer pointer in ovpn_tcp_close() selftests: ovpn: reduce remaining ping flood counts ==================== Link: https://patch.msgid.link/20260514231544.795993-1-antonio@openvpn.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19media: platform: amd: add DRM_AMDGPU dependencyArnd Bergmann
With DRM_AMDGPU=m and DRM_AMD_ISP=y, it is possible to configura VIDEO_AMD_ISP4_CAPTURE as built-in, but that fails to link: aarch64-linux-ld: drivers/media/platform/amd/isp4/isp4_interface.o: in function `isp4if_gpu_mem_alloc.isra.0': isp4_interface.c:(.text+0x1d0): undefined reference to `isp_kernel_buffer_alloc' aarch64-linux-ld: drivers/media/platform/amd/isp4/isp4_interface.o: in function `isp4if_dealloc_fw_gpumem': isp4_interface.c:(.text+0x26c): undefined reference to `isp_kernel_buffer_free' Add a dependency on the tristate DRM_AMDGPU symbol in addition to the boolean DRM_AMD_ISP=y, so this can only be built-in if the ISP driver is also linked into the kernel itself. Fixes: 9a54c285630c ("media: platform: amd: Introduce amd isp4 capture driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bin Du <Bin.Du@amd.com> Tested-by: Bin Du <Bin.Du@amd.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-19media: platform: amd: isp4: drop stale list reinit before freeBin Du
Newer Smatch snapshots no longer report the false positive around isp4if_send_fw_cmd(), so the extra list reinitialization before kfree() is no longer needed. Drop the stale list reinit and keep the cleanup path simpler. Signed-off-by: Bin Du <Bin.Du@amd.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-19media: ov13b10: Support multiple regulatorsArun T
The OV13B10 sensor driver currently handles a single regulator called avdd, however the sensor can be supplied by up to three regulators. Update the driver to handle all of them together using the regulator bulk API. Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-19platform/x86: int3472: Add TPS68470 board data for intel nvlArun T
The Intel NVL platform uses IPU8 powered by a TPS68470 PMIC, requiring board data to configure the GPIOs and regulators for proper camera sensor operation. Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-19platform/x86: int3472: Rename daisy-chain GPIO props to genericArun T
Rename the MSI-specific daisy-chain GPIO properties and software node to generic names so they can be reused by other platforms that also require daisy-chain GPIO configuration for TPS68470. Signed-off-by: Arun T <arun.t@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-19media: cec: core: add LIP supportHans Verkuil
Add support for the new CEC LIP opcodes. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Link: https://patch.msgid.link/9fb27f4a2133cf46b8e0fc126c2d1ef8b1bc30e1.1779115235.git.hverkuil+cisco@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Message-ID: <9fb27f4a2133cf46b8e0fc126c2d1ef8b1bc30e1.1779115235.git.hverkuil+cisco@kernel.org>
2026-05-19drm/imagination: Add support for trace pointsAlexandru Dadu
Add support for workload submission trace points. Co-developed-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260513-b4-pvr-trace-points-v1-1-81222d1a4c99@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfgAnna Maniscalco
arm_smmu_write_context_bank() assumes it is being called with RPM active, but it turns out that is not guaranteed in the path from qcom_adreno_smmu_set_ttbr0_cfg(), so it's possible for the register writes to get lost when configuring the context bank while the GPU is idle, leading to page faults later. Add the RPM calls here to make sure the SMMU is active before we touch it. Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19drm/imagination: Access FW initialised state with READ/WRITE_ONCEBrajesh Gupta
Update FW initialised state shared resource access with READ/WRITE_ONCE to prevent following: - Non-atomic access to variable in multi-thread/CPU case. - Merge successive loads from the same variable. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-4-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Rename FW booted to FW initialisedBrajesh Gupta
Rename the variable from 'booted' to 'initialised' to align with the driver's expectations and state, indicating that FW boot initialisation is complete and the firmware is fully initialised. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-3-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Don't timeout job if its fence has been signaledBrajesh Gupta
Verify the job’s fence in the timeout handler; if the firmware has since signaled completion, then report NO HANG. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-2-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Populate FW common context ID before passing to the FWBrajesh Gupta
Initialise the context ID for the FW common context correctly by moving the context allocation earlier. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-1-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19ipmi: Use LIST_HEAD() to initialize on stack list headJisheng Zhang
Use LIST_HEAD to initialize on stack list head. No intentional functional impact. Change generated with below coccinelle script: @@ identifier name; @@ - struct list_head name; + LIST_HEAD(name); ... when != name - INIT_LIST_HEAD(&name); Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Message-ID: <20260519055722.13161-1-jszhang@kernel.org> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19ipmi:kcs: Reduce the number of retriesCorey Minyard
The retry count was initially set to 10, which with the 5 second timeouts give 55 seconds to fail a message. The IPMI spec specifies the 5 second timeout, and it specifies retries for KCS but does not specify a number. 55 seconds is a long time, so reduce retries to 2. It matches the default in the BT state machine. This is 15 seconds, then, which is still a long time, but more reasonable. Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19drm/i915/selftests: Run vma tests only if current->mm is presentKrzysztof Karas
This set of tests require userspace memory to map objects, so run them only if this that memory is available. Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508080214.1979686-3-krzysztof.karas@intel.com