summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-10b43: add channel info table for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz channel info table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher in r2057_get_chantabent_rev7(). The dispatcher's case 8 currently handles radio_rev == 5 only. For radio_rev == 8 both output pointers stay NULL, b43_nphy_set_channel() returns an error and channel switch to the default channel fails. The new b43_nphy_chantab_phy_rev8_radio_rev8[] is 14 entries covering the standard 2.4 GHz channel set (2412..2472 in 5 MHz steps, plus 2484 for channel 14). Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-6-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz IPA TX gain table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_nphy_get_ipa_gain_table() in tables_nphy.c currently handles case 8 only for radio_rev == 5; radio_rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz IPA gain table available for this device b43-phyX ERROR: PHY init: Channel switch to default failed leaving b43_phy_init() to return an error and core_init to abort before the MAC is enabled. The high byte of every entry differs from the rev 5 sibling (0x40 vs 0x30): different PAD-gain code prefix for the rev 8 front-end. The low 24 bits coincide with rev 5 across the whole table - the gain step amplitudes are the same, only the PAD-gain selector prefix changes. Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-5-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: support radio 2057 rev 8Alessio Ferri
Add support for radio 2057 revision 8, paired with N-PHY rev 8 on the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block. Three correlated changes are needed for the same chip: - main.c: the radio_rev allow-list under B43_PHYTYPE_N currently accepts radio 2057 revisions 9 and 14 only; extend to include rev 8. - radio_2057.c: the existing r2057_rev8_init[] is a 54-entry stub declared inside a TODO comment block and never referenced from r2057_upload_inittabs(). Replace it with the full 412-entry register set actually programmed by the proprietary Broadcom wl driver on this radio. I couldn't find the origin of the original 54-entry stub - 8 of its entries do not appear at all in the rev 8 register set and 7 more carry different values. Loading it instead of using the real table leaves the radio hanging producing a "Microcode not responding" timeout. - radio_2057.c: r2057_upload_inittabs() case 8 handles radio_rev 5 and 7 only; add the radio_rev == 8 branch pointing at the new table. The init table is extracted from an MMIO dump of the radio register set programmed during proprietary driver initialisation on BCM6362 silicon (Broadcom wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-4-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: route d11 corerev 22 to 24-bit indirect radio accessAlessio Ferri
Rev 22 backports the older 802.11 core but pairs it with a radio in the 2057 family, which requires the 24-bit indirect path. With the current dispatch, corerev 22 falls into the legacy 4-wire branch, reads garbage for radio_id, and bails out with -EOPNOTSUPP at the "FOUND UNSUPPORTED RADIO" branch below. brcmsmac handles the same silicon family with the equivalent dispatch in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/ phy_cmn.c read_radio_reg() and write_radio_reg(): if ((D11REV_GE(pi->sh->corerev, 24)) || (D11REV_IS(pi->sh->corerev, 22) && (pi->pubpi.phy_type != PHY_TYPE_SSN))) { /* radioregaddr / radioregdata (indirect) */ } else { /* phy4waddr / phy4wdatalo (legacy) */ } b43 does not support SSN/SSLPN PHYs - they are rejected earlier in b43_phy_versioning() at the "unsupported PHY type" switch - so just adding the check corerev == 22 will do. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-3-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add d11 core revision 0x16 to id tableAlessio Ferri
Add d11 core revision 0x16 (= 22) to the b43 bcma device id table. The b43 bcma id table covers d11 revisions 0x11, 0x15, 0x17, 0x18, 0x1C, 0x1D, 0x1E, 0x28 and 0x2A. Revision 0x16 belongs to the same N-PHY family as revisions 0x17 and 0x18 (radio 2057) and needs no new PHY or radio code beyond the radio_rev 8 dispatcher entries added later in this series - only the device id entry is missing. Without it bcma scan enumerates the 802.11 core but no driver binds. The revision is used by the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block found in xDSL SoCs. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-2-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add firmware mappings for rev22Alessio Ferri
add the specific firmware mappings for rev22, and drop comments wondering about rev22 initvals Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-1-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10drm/i915/gem: Fix phys BO pread/pwrite with offsetJoonas Lahtinen
sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. Reported-by: Matthew Wilcox (Oracle) <willy@infradead.org> Fixes: c6790dc22312 ("drm/i915: Wean off drm_pci_alloc/drm_pci_free") Cc: <stable@vger.kernel.org> # v4.5+ Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Simona Vetter <simona@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260610060314.26111-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-06-10gpiolib: handle gpio-hogs only onceDaniel Drake
Commit d1d564ec49929 ("gpio: move hogs into GPIO core") introduced a behaviour change that breaks boot on Raspberry Pi 5 when using the firmware-supplied device tree: gpiochip_add_data_with_key: GPIOs 544..575 (/soc@107c000000/gpio@7d517c00) failed to register, -22 brcmstb-gpio 107d517c00.gpio: Could not add gpiochip for bank 1 brcmstb-gpio 107d517c00.gpio: probe with driver brcmstb-gpio failed with error -22 gpio-brcmstb registers two gpio_chips against the device tree node gpio@7d517c00, one for each bank. The firmware-supplied DT includes a gpio-hog on RP1 RUN, and this gpio-hog is attempted to be applied to *both* gpio_chips. This succeeds against bank 0 (which hosts the GPIO) and fails for bank 1 (which does not). In the previous implementation, failures to apply gpio-hogs were quietly ignored. In the new code, the error code propagates and causes probe to fail. Closely approximate the previous behaviour by using the OF_POPULATED flag to ensure that each gpio-hog is processed only once. The flag was previously being set before the gpio-hogs were processed, so as part of this change, the flag now gets set only after the gpio-hog is actioned. The handling of gpio-hogs on a DT node with multiple gpio_chips remains a bit incomplete/unclear, but this at least retains the ability to apply hogs to the first gpio_chip per node. Fixes: d1d564ec49929 ("gpio: move hogs into GPIO core") Signed-off-by: Daniel Drake <dan@reactivated.net> Link: https://patch.msgid.link/20260608210108.36248-1-dan@reactivated.net Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-10ata: pata_isapnp: Drop unused assignments from pnp_device_id arrayUwe Kleine-König (The Capable Hub)
Explicitly assigning .driver_data in drivers that don't use this member is silly and a bit irritating. Drop it. Also simplify the list terminator entry to be just empty to match what most other device_id tables do. There is no changed semantic, not even a change in the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-10gpio: fix cleanup path on hog failureBartosz Golaszewski
If gpiochip_hog_lines() successfully processes some hogs but fails on a later one, the error handling path in gpiochip_add_data_with_key() jumps directly to err_remove_of_chip. This leaks resources allocated earlier for ACPI, interrupts and hogs that were successfully processed. Use the right label in error path. Closes: https://sashiko.dev/#/patchset/20260608210108.36248-1-dan%40reactivated.net Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260609-gpio-hogs-fixes-v1-2-b4064f8070e7@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-10rust: make `build_assert` module the home of related macrosGary Guo
Given the macro scoping rules, all macros are rendered twice, in the module and in the top-level of kernel crate. Add `#[doc(hidden)]` to the macro definition and `#[doc(inline)]` to the re-export inside `build_assert` module so the top-level items are hidden. [ Sadly, because the definition is hidden, `rustdoc` decides to not list them as re-exports in the `prelude` page anymore, even if we refer to the not-actually-hidden item. - Miguel ] Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Acked-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260609142637.373347-1-gary@kernel.org [ Kept a single declaration in the prelude, and reworded since they already had `no_inline`. Removed other imports from `predefine` since we now use the prelude. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-06-10wifi: brcmfmac: flowring: simplify flow allocationRosen Penev
Use a flexible array member and kzalloc_flex to combine allocations. Simplifies code slightly. Add __counted_by for extra runtime analysis. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260608051102.6698-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10wifi: brcm80211: change current_bss to valueRosen Penev
Change to a single allocation and remove some boilerplate. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260608052854.11718-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10Merge tag 'ath-next-20260609' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v7.2 (PR #4) An assortment of cleanups and minor bug fixes across wcn36xx, ath9k, ath10k, ath11k, and ath12k. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-09accel/amdxdna: Clear sva pointer after unbindLizhi Hou
Add client->sva = NULL after the unbind makes it consistent with how amdxdna_sva_fini() already clears the pointer after unbinding. The IS_ERR_OR_NULL guard in sva_fini will then correctly skip the second unbind. Fixes: 3cc5d7a59519 ("accel/amdxdna: Add carveout memory support for non-IOMMU systems") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260604202815.2425882-1-lizhi.hou@amd.com
2026-06-10can: virtio: Add virtio CAN driverMatias Ezequiel Vara Larsen
Add virtio CAN driver based on Virtio 1.4 specification (see https://github.com/oasis-tcs/virtio-spec/tree/virtio-1.4). The driver implements a complete CAN bus interface over Virtio transport, supporting both CAN Classic and CAN-FD Ids. In term of frames, it supports classic and CAN FD. RTR frames are only supported with classic CAN. Usage: - "ip link set up can0" - start controller - "ip link set down can0" - stop controller - "candump can0" - receive frames - "cansend can0 123#DEADBEEF" - send frames Signed-off-by: Harald Mommer <harald.mommer@oss.qualcomm.com> Co-developed-by: Harald Mommer <harald.mommer@oss.qualcomm.com> Signed-off-by: Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@oss.qualcomm.com> Co-developed-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Damir Shaikhutdinov <Damir.Shaikhutdinov@opensynergy.com> Reviewed-by: Francesco Valla <francesco@valla.it> Tested-by: Francesco Valla <francesco@valla.it> Signed-off-by: Matias Ezequiel Vara Larsen <mvaralar@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <ahXNb+KzuHYbS24+@fedora>
2026-06-10virtio: add num_vf callback to virtio_busYui Washizu
Recent QEMU versions added support for virtio SR-IOV emulation, allowing virtio devices to expose SR-IOV VFs to the guest. However, virtio_bus does not implement the num_vf callback of bus_type, causing dev_num_vf() to return 0 for virtio devices even when SR-IOV VFs are active. net/core/rtnetlink.c calls dev_num_vf(dev->dev.parent) to populate IFLA_NUM_VF in RTM_GETLINK responses. For a virtio-net device, dev.parent points to the virtio_device, whose busis virtio_bus. Without num_vf, SR-IOV VF information is silently omitted from tools that rely on rtnetlink, such as 'ip link show'. Add a num_vf callback that delegates to dev_num_vf(dev->parent), which in turn reaches the underlying transport (pci_bus_type for virtio-pci) where the actual VF count is tracked. Non-PCI transports are unaffected as dev_num_vf() returns 0 when no num_vf callback is present. Signed-off-by: Yui Washizu <yui.washidu@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260310061454.683894-1-yui.washidu@gmail.com>
2026-06-10fw_cfg: Add support for LoongArch architectureHuacai Chen
Qemu fw_cfg support was missing for LoongArch, which made some functions unusable in virtual machines. So add the missing LoongArch defines. Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260529140559.1775511-1-chenhuacai@loongson.cn>
2026-06-10vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handlerSrujana Challa
Look up the IRQ index in oct_hw->irqs instead of assuming irq - irqs[0]. This supports non-contiguous IRQ numbers and avoids incorrect ring indexing when irqs[0] is not the base. Fixes: 26f8ce06af64 ("vdpa/octeon_ep: enable support for multiple interrupts per device") Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260224095226.1001151-5-schalla@marvell.com>
2026-06-10vdpa/octeon_ep: Add vDPA device event handling for firmware notificationsVamsi Attunuru
Handle vDPA device add and remove events from Octeon firmware. Use irq 0 for event delivery as device interrupts are multiplexed. Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260224095226.1001151-4-schalla@marvell.com>
2026-06-10vdpa/octeon_ep: Use 4 bytes for mailbox signatureVamsi Attunuru
The upper 4 bytes are reserved by the firmware for storing meta data. Use only lower 4 bytes to update the signature details. Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260224095226.1001151-3-schalla@marvell.com>
2026-06-10vdpa/octeon_ep: Fix PF->VF mailbox data address calculationSrujana Challa
The mailbox address was computed assuming 1 ring per VF. Read the actual rings-per-VF from OCTEP_EPF_RINFO and use it when calculating OCTEP_PF_MBOX_DATA offsets, fixing VF initialization when rings per VF > 1. Fixes: 8b6c724cdab8 ("virtio: vdpa: vDPA driver for Marvell OCTEON DPU devices") Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260224095226.1001151-2-schalla@marvell.com>
2026-06-10vhost: remove unnecessary module_init/exit functionsEthan Nelson-Moore
The vhost driver has unnecessary empty module_init and module_exit functions. Remove them. Note that if a module_init function exists, a module_exit function must also exist; otherwise, the module cannot be unloaded. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260131020010.45647-1-enelsonmoore@gmail.com>
2026-06-10vdpa/mlx5: Use kvzalloc_flex() for MTT command memoryRosen Penev
The create mkey command memory embeds the MTT array as a flexible array member. Use kvzalloc_flex() to allocate it directly instead of open-coding the struct_size() calculation with kvcalloc(). The MTT allocation still needs to be aligned to MLX5_VDPA_MTT_ALIGN bytes. Since each MTT entry is __be64, align the entry count directly and avoid carrying a separate byte length variable. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260508051837.1744409-1-rosenp@gmail.com>
2026-06-10vdpa_sim_net: switch to dynamic root deviceJohan Hovold
Driver core expects devices to be dynamically allocated and will, for example, complain loudly when no release function has been provided. Use root_device_register() to allocate and register the root device instead of open coding using a static device. Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260424104703.2619093-3-johan@kernel.org>
2026-06-10vdpa_sim_blk: switch to dynamic root deviceJohan Hovold
Driver core expects devices to be dynamically allocated and will, for example, complain loudly when no release function has been provided. Use root_device_register() to allocate and register the root device instead of open coding using a static device. Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260424104703.2619093-2-johan@kernel.org>
2026-06-10virtio-mem: Destroy mutex before freeing virtio_memMaurice Hieronymus
Add a call to mutex_destroy in the error code path as well as in the virtio_mem_remove code path. Signed-off-by: Maurice Hieronymus <mhi@mailbox.org> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20251123175750.445461-3-mhi@mailbox.org>
2026-06-10virtio-balloon: Destroy mutex before freeing virtio_balloonMaurice Hieronymus
Add a call to mutex_destroy in the error code path as well as in the virtballoon_remove code path. Signed-off-by: Maurice Hieronymus <mhi@mailbox.org> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20251123175750.445461-2-mhi@mailbox.org>
2026-06-10virtio_ring: Add READ_ONCE annotations for device-writable fieldsAlexander Graf
KCSAN reports data races when accessing virtio ring fields that are concurrently written by the device (host). These are legitimate concurrent accesses where the CPU reads fields that the device updates via DMA-like mechanisms. Add accessor functions that use READ_ONCE() to properly annotate these device-writable fields and prevent compiler optimizations that could in theory break the code. This also serves as documentation showing which fields are shared with the device. The affected fields are: - Split ring: used->idx, used->ring[].id, used->ring[].len - Packed ring: desc[].flags, desc[].id, desc[].len This patch was partially written using the help of Kiro, an AI coding assistant, to automate the mechanical work of generating the inline function definition. Signed-off-by: Alexander Graf <graf@amazon.com> [jth: Add READ_ONCE in virtqueue_kick_prepare_split ] Co-developed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Alexander Graf <graf@amazon.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260131102810.1254845-1-johannes.thumshirn@wdc.com>
2026-06-10vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFOArnd Bergmann
These two ioctls are incompatible on 32-bit x86 userspace, because the data structures are shorter than they are on 64-bit. Add a proper .compat_ioctl handler for x86 that reads the structures with the smaller padding before calling the internal handlers. On all other architectures, CONFIG_COMPAT_FOR_U64_ALIGNMENT is disabled and no special handling is required. Fixes: ad146355bfad ("vduse: Support querying information of IOVA regions") Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260213154051.4172275-1-arnd@kernel.org>
2026-06-10vhost/net: complete zerocopy ubufs only onceQing Ming
vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Qing Ming <a0yami@mailbox.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260601104300.197210-1-a0yami@mailbox.org>
2026-06-10VDUSE: avoid leaking information to userspaceJason Wang
The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace. Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Cc: stable@vger.kernel.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Xie Yongji <xieyongji@bytedance.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260130050750.4050-1-jasowang@redhat.com>
2026-06-10vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iterZhang Tianci
There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Cc: stable@vger.kernel.org Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com> Reviewed-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260226115550.1814-3-zhangtianci.1997@bytedance.com>
2026-06-10vduse: Requeue failed read to send_list headZhang Tianci
When copy_to_iter() fails in vduse_dev_read_iter(), put the message back at the head of send_list to preserve FIFO ordering and retry the oldest pending request first. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Reported-by: Michael S. Tsirkin <mst@redhat.com> Suggested-by: Xie Yongji <xieyongji@bytedance.com> Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com> Reviewed-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260226115550.1814-2-zhangtianci.1997@bytedance.com>
2026-06-10vdpa/mlx5: update MAC address handling in mlx5_vdpa_set_attr()Cindy Lu
Improve MAC address handling in mlx5_vdpa_set_attr() to ensure that old MAC entries are properly removed from the MPFS table before adding a new one. The new MAC address is then added to both the MPFS and VLAN tables. This change fixes an issue where the updated MAC address would not take effect until QEMU was rebooted. Signed-off-by: Cindy Lu <lulu@redhat.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260126094848.9601-4-lulu@redhat.com>
2026-06-10vdpa/mlx5: update mlx_features with driver state checkCindy Lu
Add logic in mlx5_vdpa_set_attr() to ensure the VIRTIO_NET_F_MAC feature bit is properly set only when the device is not yet in the DRIVER_OK (running) state. This makes the MAC address visible in the output of: vdpa dev config show -jp when the device is created without an initial MAC address. Signed-off-by: Cindy Lu <lulu@redhat.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260126094848.9601-2-lulu@redhat.com>
2026-06-10vdpa/ifcvf: handle dev_set_name() failure in ifcvf_vdpa_dev_add()Evgenii Burenchev
dev_set_name() may fail and return an error, but its return value is currently ignored and overwritten by _vdpa_register_device(). Abort device creation if dev_set_name() fails and release the device reference to avoid continuing with an improperly initialized struct device. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Evgenii Burenchev <evg28bur@yandex.ru> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Zhu Lingshan <lingshan.zhu@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260226152924.38790-1-evg28bur@yandex.ru>
2026-06-10virtio_console: read size from config space during device initFilip Hejsek
Previously, the size was only read upon receiving the config interrupt. This interrupt is sent when the size changes. However, we also need to read the initial size. Also make sure to only read the size from config if F_SIZE is enabled. Fixes: 9778829cffd4 ("virtio: console: Store each console's size in the console structure") Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260223-virtio-console-fix-v1-1-0cf08303b428@gmail.com>
2026-06-10virtio: rtc: tear down old virtqueues before restoreJia Jia
virtio_device_restore() resets the device and restores the negotiated features before calling ->restore(). viortc_freeze() intentionally leaves the existing virtqueues in place so the alarm queue can still wake the system, but viortc_restore() immediately calls viortc_init_vqs() without first deleting those old queues. If virtqueue reinitialization fails on virtio-pci, the transport error path can run vp_del_vqs() against a newly allocated vp_dev->vqs array while vdev->vqs still contains the old virtqueues. vp_del_vqs() then looks up queue state through the new array and can dereference a NULL info pointer in vp_del_vq(), crashing the guest kernel during restore. This can also happen during a non-faulty reinitialization, when one of the vp_find_vqs_msix() attempts is unsuccessful before a later attempt would succeed. Delete the stale virtqueues before rebuilding them. If restore fails before virtio_device_ready(), reuse the remove path to stop the device. Once the device is ready, return errors directly instead of deleting the virtqueues again. Fixes: 0623c7592768 ("virtio_rtc: Add module and driver core") Signed-off-by: Jia Jia <physicalmtea@gmail.com> Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260507120801.3677552-1-physicalmtea@gmail.com>
2026-06-10virtio-mmio: fix device release warning on module unloadJohan Hovold
Driver core expects devices to be allocated dynamically and complains loudly when a device that lacks a release function is freed. Use __root_device_register() to allocate and register the root device instead of open coding using a static device. Note that root_device_register(), which also creates a link to the module, cannot be used as the device is registered when parsing the module parameters which happens before the module kobject has been set up. Fixes: 81a054ce0b46 ("virtio-mmio: Devices parameter parsing") Cc: stable@vger.kernel.org # 3.5 Cc: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260427143710.14702-1-johan@kernel.org>
2026-06-10vhost/vdpa: validate virtqueue index in mmap and fault pathsQihang Tang
vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS. Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Acked-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260508075821.92656-1-q.h.hack.winter@gmail.com>
2026-06-10vduse: hold vduse_lock across IDR lookup in open pathQihang Tang
vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260508094659.94647-1-q.h.hack.winter@gmail.com>
2026-06-10vhost/vsock: Refuse the connection immediately when guest isn't readyDenis V. Lunev
When the host initiates an AF_VSOCK connect() to a guest that has not yet loaded the virtio-vsock transport (i.e. still booting), the caller blocks for VSOCK_DEFAULT_CONNECT_TIMEOUT. A caller that wants to know if the guest is up yet instead of waiting could theoretically tune SO_VM_SOCKETS_CONNECT_TIMEOUT, but it's tricky to find the right timeout, if not impossible: there's no way to distinguish "guest won't reply because it's not up yet" vs "guest is up and tried to reply, but was too slow". Furthermore, this delay is pointless: - If the guest doesn't initialize within this timeout, connect() returns ETIMEDOUT. - If the guest **does** initialize, it'll reply with RST immediately, because there won't be a listener on the port yet; connect() returns ECONNRESET. That's also inconsistent with the behavior at other initialization stages: if a connection is attempted when the guest driver is already loaded, but nothing is listening yet, we return ECONNRESET immediately without waiting. Fix this by checking the RX virtqueue backend in vhost_transport_send_pkt() before queuing. If it's NULL, return -EHOSTUNREACH immediately. Callers that used to get ETIMEDOUT will now usually get EHOSTUNREACH. Signed-off-by: Denis V. Lunev <den@openvz.org> Co-developed-by: Polina Vishneva <polina.vishneva@virtuozzo.com> Signed-off-by: Polina Vishneva <polina.vishneva@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260513145842.809404-1-polina.vishneva@virtuozzo.com>
2026-06-09Input: ipaq-micro-keys - simplify allocationRosen Penev
Embed the keycode array in the struct to have a single allocation. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260609213532.25181-1-rosenp@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10clocksource: move NXP timer selection to drivers/clocksourceEnric Balletbo i Serra
The Kconfig logic for selecting the scheduler clocksource on NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This prevents 64-bit architectures, such as the NXP S32 family, from enabling the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER). Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to drivers/clocksource/Kconfig. This allows the configuration to be shared across different architectures. Update the selection to include support for ARCH_S32 and add a "None" option restricted to ARCH_S32, since Vybrid lacks the ARM Architected Timer. The Vybrid Global Timer option is restricted to ARCH_MULTI_V7 SOC_VF610 platforms to prevent it from being visible on Cortex-M4 builds, which lack the ARM Global Timer hardware. Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support") Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260514-fix-nxp-timer-v3-1-a3e68fdb505e@redhat.com
2026-06-10clocksource/drivers/timer-tegra186: Reserve and service a kernel watchdogKartik Rajput
Tegra SoCs supports multiple watchdog timers. If the kernel crashes or hangs before userspace enables a watchdog, the system cannot recover and may remain bricked, e.g. after a failed OTA update. The driver currently leaves all watchdogs disabled until userspace configures them. Reserve first available watchdog as a kernel-only watchdog for Tegra186 and Tegra234. Arm it during probe (120s timeout) and keep it alive in the driver IRQ handler. Do not register it to userspace. Other available watchdogs remain exposed to userspace. This guarantees the system can reset itself in case of a hang or crash even when userspace never starts. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260507154557.2082697-5-kkartik@nvidia.com
2026-06-10clocksource/drivers/timer-tegra186: Register all accessible watchdog timersKartik Rajput
Tegra186+ SoCs expose multiple watchdog timers, but the driver only registers WDT(0). Iterate over num_wdts and, for each WDT, check the SCR (firewall) registers in the TKE block to determine whether Linux has read and write access. Register the watchdogs that are accessible. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260507154557.2082697-4-kkartik@nvidia.com
2026-06-10clocksource/drivers/timer-tegra186: Correct num_wdts for Tegra186 and Tegra234Kartik Rajput
On Tegra186 and Tegra234, WDT2 is connected to the Audio Processing Engine (APE) and cannot be accessed from Linux. Only WDT0 and WDT1 are accessible to Linux. Update num_wdts from 3 to 2 for both Tegra186 and Tegra234 to reflect the actual number of watchdogs available to Linux. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260507154557.2082697-3-kkartik@nvidia.com
2026-06-10clocksource/drivers/timer-tegra186: Fix support for multiple watchdog instancesKartik Rajput
Tegra SoCs support multiple watchdogs; currently only one (WDT0) is used. When multiple watchdogs are registered, tegra186_wdt_enable() overwrites the TKEIE(x) register, discarding any existing watchdog interrupt enable bits. As a result, enabling one watchdog inadvertently disables interrupts for the others. Fix this by preserving the existing TKEIE(x) value and updating it using a read-modify-write sequence. Fixes: 42cee19a9f83 ("clocksource: Add Tegra186 timers support") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260507154557.2082697-2-kkartik@nvidia.com
2026-06-09net: dsa: realtek: rtl8365mb: add bridge port flagsLuiz Angelo Daros de Luca
Implement support for bridge port flags to control learning and flooding behavior. This patch maps hardware functionalities to the following bridge flags: - BR_LEARNING - BR_FLOOD - BR_MCAST_FLOOD - BR_BCAST_FLOOD By default, all flooding types are enabled during port setup to ensure standard bridge behavior. Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Link: https://patch.msgid.link/20260606-realtek_forward-v13-9-b9e409687cbe@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-16 15:43:48 +0000