summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-18RDMA/irdma: Add GEN3 virtual QP1 supportShiraz Saleem
Add a new RDMA virtual channel op during QP1 creation that allow the Control Plane (CP) to virtualize a regular QP as QP1 on non-default RDMA capable vPorts. Additionally, the CP will return the Qsets to use on the ib_device of the vPort. Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-9-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Introduce GEN3 vPort driver supportMustafa Ismail
In the IPU model, a function can host one or more logical network endpoints called vPorts. Each vPort may be associated with either a physical or an internal communication port, and can be RDMA capable. A vPort features a netdev and, if RDMA capable, must have an associated ib_dev. This change introduces a GEN3 auxiliary vPort driver responsible for registering a verbs device for every RDMA-capable vPort. Additionally, the UAPI is updated to prevent the binding of GEN3 devices to older user-space providers. Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-8-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Add GEN3 HW statistics supportKrzysztof Czurylo
Plug into the unified HW statistics framework by adding a hardware statistics map array for GEN3, defining the HW-specific width and location for each counter in the statistics buffer. Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-7-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Add GEN3 support for AEQ and CEQShiraz Saleem
Extend support for GEN3 devices by programming the necessary hardware IRQ registers and the updated descriptor fields for the Asynchronous Event Queue (AEQ) and Completion Event Queue (CEQ). Introduce a RDMA virtual channel operation with the Control Plane (CP) to associate interrupt vectors appropriately with AEQ and CEQ. Add new Asynchronous Event (AE) definitions specific to GEN3. Additionally, refactor the AEQ and CEQ setup into the irdma_ctrl_init_hw device control initialization routine. This completes the PCI device level initialization for RDMA in the core driver. Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-6-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Add GEN3 CQP support with deferred completionsKrzysztof Czurylo
GEN3 introduces asynchronous handling of Control QP (CQP) operations to minimize head-of-line blocking. Create the CQP using the updated GEN3- specific descriptor fields and implement the necessary support for this deferred completion mechanism. Signed-off-by: Krzysztof Czurylo <krzysztof.czurylo@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-5-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Discover and set up GEN3 hardware register layoutChristopher Bednarz
Discover the hardware register layout for GEN3 devices through an RDMA virtual channel operation with the Control Plane (CP). Set up the corresponding hardware attributes specific to GEN3 devices. Signed-off-by: Christopher Bednarz <christopher.n.bednarz@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-4-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Add GEN3 core driver supportMustafa Ismail
Introduce support for the GEN3 auxiliary core driver, which is responsible for initializing PCI-level RDMA resources. Facilitate host-driver communication with the device's Control Plane (CP) to discover capabilities and perform privileged operations through an RDMA-specific messaging interface built atop the IDPF mailbox and virtual channel protocol. Establish the RDMA virtual channel message interface and incorporate operations to retrieve the hardware version and discover capabilities from the CP. Additionally, set up the RDMA MMIO regions and initialize the RF structure. Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Co-developed-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-3-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18RDMA/irdma: Refactor GEN2 auxiliary driverMustafa Ismail
Refactor the irdma auxiliary driver and associated interfaces out of main.c and into a standalone GEN2-specific source file and rename as gen_2 driver. This is in preparation for adding GEN3 auxiliary drivers. Each HW generation will have its own gen-specific interface file. Additionally, move the Address Handle hash table and associated locks under rf struct. This will allow GEN3 code to migrate to use it easily. Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Co-developed-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Link: https://patch.msgid.link/20250827152545.2056-2-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-18net: renesas: rswitch: simplify rswitch_stop()Yury Norov (NVIDIA)
rswitch_stop() opencodes for_each_set_bit(). CC: Simon Horman <horms@kernel.org> Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250916163516.486827-1-yury.norov@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18mtd: rawnand: fsmc: Default to autodetect buswidthLinus Walleij
If you don't specify buswidth 2 (16 bits) in the device tree, FSMC doesn't even probe anymore: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro 10100000.flash nand: bus width 8 instead of 16 bits nand: No NAND device found fsmc-nand 10100000.flash: probe with driver fsmc-nand failed with error -22 With this patch to use autodetection unless buswidth is specified, the device is properly detected again: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro NAND 128MiB 1,8V 16-bit nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme Scanning device for bad blocks I don't know where or how this happened, I think some change in the nand core. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-09-18mtd: nand: move nand_check_erased_ecc_chunk() to nand/coreMarkus Stockhausen
The check function for bitflips in erased blocks will be needed by the Realtek ECC engine driver (which is currently under development). Right now it is located in raw/nand_base.c. While this is sufficient for the current usecases, there is no real dependency for an ECC engine on the raw nand library. Move the function over to a more generic place in core library. Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-09-18mtd: nand: ecc-mxic: Lower log level during initMiquel Raynal
A working init shall be silent rather than exposing the configuration with kernel messages at the error level. Thwart myself from the past and use the debug level for these. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-09-18eth: fbnic: support devmem TxJakub Kicinski
Support devmem Tx. We already use skb_frag_dma_map(), we just need to make sure we don't try to unmap the frags. Check if frag is unreadable and mark the ring entry. # ./tools/testing/selftests/drivers/net/hw/devmem.py TAP version 13 1..3 ok 1 devmem.check_rx ok 2 devmem.check_tx ok 3 devmem.check_tx_chunks # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 Acked-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916145401.1464550-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18usb: xhci: align PORTSC trace with one-based port numberingNiklas Neronin
In the xHCI driver, port numbers are typically described using a one-based index. However, tracing currently uses a zero-based index. To ensure consistency between tracing and dynamic debugging, update the trace port number to use a one-based index. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18usb: xhci: correct indentation for PORTSC tracing functionNiklas Neronin
Correct the indentation in USB Port Register Set (PORTSC) tracing. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18usb: xhci: improve TR Dequeue Pointer maskNiklas Neronin
Address the naming and usage of the TR Dequeue Pointer mask in the xhci driver. The Endpoint Context Field at offset 0x08 is defined as follows: Bit 0 Dequeue Cycle State (DCS) Bits 3:1 RsvdZ (Reserved and Zero) Bits 63:4 TR Dequeue Pointer When extracting the TR Dequeue Pointer for an Endpoint without Streams, in xhci_handle_cmd_set_deq(), the inverted Dequeue Cycle State mask (~EP_CTX_CYCLE_MASK) is used, inadvertently including the Reserved bits. Although bits 3:1 are typically zero, using the incorrect mask could cause issues. The existing mask, named "SCTX_DEQ_MASK," is misleading because "SCTX" implies exclusivity to Stream Contexts, whereas the TR Dequeue Pointer is applicable to both Stream and non-Stream Contexts. Rename the mask to "TR_DEQ_PTR_MASK", utilize GENMASK_ULL() macro and use the mask when handling the TR Dequeue Pointer field. Function xhci_get_hw_deq() returns the Endpoint Context Field 0x08, either directly from the Endpoint context or a Stream. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18usb: xhci-pci: add support for hosts with zero USB3 portsNiklas Neronin
Add xhci support for PCI hosts that have zero USB3 ports. Avoid creating a shared Host Controller Driver (HCD) when there is only one root hub. Additionally, all references to 'xhci->shared_hcd' are now checked before use. Only xhci-pci.c requires modification to accommodate this change, as the xhci core already supports configurations with zero USB3 ports. This capability was introduced when xHCI Platform and MediaTek added support for zero USB3 ports. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181 Tested-by: Nick Nielsen <nick.kainielsen@free.fr> Tested-by: grm1 <grm1@mailbox.org> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18usb: xhci: Update a comment about Stop Endpoint retriesMichal Pecio
Retries are no longer gated by a quirk, so remove that part. Add a brief explanation of the timeout. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running"Michal Pecio
This reverts commit 28a76fcc4c85dd39633fb96edb643c91820133e3. No actual HW bugs are known where Endpoint Context shows Running state but Stop Endpoint fails repeatedly with Context State Error and leaves the endpoint state unchanged. Stop Endpoint retries on Running EPs have been performed since early 2021 with no such issues reported so far. Trying to handle this hypothetical case brings a more realistic danger: if Stop Endpoint fails on an endpoint which hasn't yet started after a doorbell ring and enough latency occurs before this completion event is handled, the driver may time out and begin removing cancelled TDs from a running endpoint, even though one more retry would stop it reliably. Such high latency is rare but not impossible, and removing TDs from a running endpoint can cause more damage than not giving back a cancelled URB (which wasn't happening anyway). So err on the side of caution and revert to the old policy of always retrying if the EP appears running. [Remove stable tag as we are dealing with theoretical cases -Mathias] Fixes: 28a76fcc4c85d ("usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running") Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18accel/ivpu: Add support for user-managed preemption bufferAndrzej Kacprowski
Allow user mode drivers to manage preemption buffers, enabling memory savings by sharing a single buffer across multiple command queues within the same memory context. Introduce DRM_IVPU_PARAM_PREEMPT_BUFFER_SIZE to report the required preemption buffer size as specified by the firmware. The preemption buffer is now passed from user space as an entry in the BO list of DRM_IVPU_CMDQ_SUBMIT. The buffer must be non-mappable and large enough to hold preemption data. For backward compatibility, the kernel will allocate an internal preemption buffer if user space does not provide one. User space can only provide a single preemption buffer, simplifying the ioctl interface and parameter validation. A separate secondary preemption buffer is only needed to save below 4GB address space on 37xx and only if preemption buffers are not shared. Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250915103437.830086-1-karol.wachowski@linux.intel.com
2025-09-18accel/ivpu: Update JSM firmware API to latest 3.32.5 versionKarol Wachowski
Synchronize the JSM API header file with the latest 3.32.5 version to reflect all changes introduced in the new firmware API Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250916084131.848988-1-karol.wachowski@linux.intel.com
2025-09-18accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume failKarol Wachowski
Previously, aborting work could return early after engine reset or resume failure, skipping the necessary runtime_put cleanup leaving the device with incorrect reference count breaking runtime power management state. Replace early returns with goto statements to ensure runtime_put is always executed. Fixes: a47e36dc5d90 ("accel/ivpu: Trigger device recovery on engine reset/resume failure") Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250916084809.850073-1-karol.wachowski@linux.intel.com
2025-09-18drm/i915: add note on VLV/CHV hpll_freq and czclk_freq cachingJani Nikula
The caching at the initial read is a bit fragile in case, say, a further refactoring starts reading the frequencies at a time where it's not possible. Add a note about it. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250917135200.1932903-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-18drm/xe: Work around clang multiple goto-label errorThomas Hellström
When using drm_exec_retry_on_contention(), clang may consider all labels for which we take addresses in a function as potential retry goto targets, although strictly only one is possible. It will then in some situations generate false positive errors. In this case, the compiler, for some architectures, consider the might_lock(&m->job_mutex); as a potential goto target from drm_exec_retry_on_contention(), and errors. Work around that by moving the xe_validate / drm_exec transaction to a separate function. v2: - New commit message based on analysis of Nathan Chancellor Fixes: 59eabff2a352 ("drm/xe: Convert xe_bo_create_pin_map() for exhaustive eviction") Cc: Matthew Brost <matthew.brost@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509101853.nDmyxTEM-lkp@intel.com/ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://lore.kernel.org/r/20250911080324.180307-1-thomas.hellstrom@linux.intel.com
2025-09-18accel/ivpu: Remove unused firmware boot parametersAndrzej Kacprowski
Remove references to firmware boot parameters that were never used by any production version of device firmware. Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250915103553.830151-1-karol.wachowski@linux.intel.com
2025-09-18accel/ivpu: Refactor priority_bands_show for readabilityJacek Lawrynowicz
Reduce code duplication and improve the overall readability of the debugfs output for job scheduling priority bands. Additionally fix clang-tidy warning about missing default case in the switch statement. Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250915103401.830045-1-karol.wachowski@linux.intel.com
2025-09-18drm/i915/alpm: Remove error handling from get_lfps_cycle_min_max_timeJouni Högander
Getter for LFPS cycle min/max times is unnecessarily checking faulty port clock value. This doesn't make sense as erroneous port clock value would have been noticed already at this point. Remove this check and use 140/800 ns always when port clock > 540000. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250912064035.335329-1-jouni.hogander@intel.com
2025-09-18accel/ivpu: Reset cmdq->db_id on register failureKarol Wachowski
Ensure that cmdq->db_id is reset to 0 if ivpu_jsm_register_db fails, preventing potential reuse of invalid command queue with unregistered doorbell. Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20250915103421.830065-1-karol.wachowski@linux.intel.com
2025-09-17Input: imx6ul_tsc - use BIT, FIELD_{GET,PREP} and GENMASK macrosDario Binacchi
Replace opencoded masking and shifting, with BIT(), GENMASK(), FIELD_GET() and FIELD_PREP() macros. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250917080534.1772202-3-dario.binacchi@amarulasolutions.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-09-17Input: imx6ul_tsc - fix typo in register nameMichael Trimarchi
Replace 'SETING' with 'SETTING'. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250917080534.1772202-2-dario.binacchi@amarulasolutions.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-09-17Merge tag 'mm-hotfixes-stable-2025-09-17-21-10' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "15 hotfixes. 11 are cc:stable and the remainder address post-6.16 issues or aren't considered necessary for -stable kernels. 13 of these fixes are for MM. The usual shower of singletons, plus - fixes from Hugh to address various misbehaviors in get_user_pages() - patches from SeongJae to address a quite severe issue in DAMON - another series also from SeongJae which completes some fixes for a DAMON startup issue" * tag 'mm-hotfixes-stable-2025-09-17-21-10' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: zram: fix slot write race condition nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/* samples/damon/mtier: avoid starting DAMON before initialization samples/damon/prcl: avoid starting DAMON before initialization samples/damon/wsse: avoid starting DAMON before initialization MAINTAINERS: add Lance Yang as a THP reviewer MAINTAINERS: add Jann Horn as rmap reviewer mm/damon/sysfs: use dynamically allocated repeat mode damon_call_control mm/damon/core: introduce damon_call_control->dealloc_on_cancel mm: folio_may_be_lru_cached() unless folio_test_large() mm: revert "mm: vmscan.c: fix OOM on swap stress test" mm: revert "mm/gup: clear the LRU flag of a page before adding to LRU batch" mm/gup: local lru_add_drain() to avoid lru_add_drain_all() mm/gup: check ref_count instead of lru before migration
2025-09-17net/mlx5e: Use the 'num_doorbells' devlink paramCosmin Ratiu
Use the new devlink param to control how many doorbells mlx5e devices allocate and use. The maximum number of doorbells configurable is capped to the maximum number of channels. This only applies to the Ethernet part, the RDMA devices using mlx5 manage their own doorbells. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Use multiple CQ doorbellsCosmin Ratiu
Channel doorbells are now also used by all channel CQs. A new 'uar' parameter is added to 'struct mlx5e_create_cq_param', which is then used in mlx5e_alloc_cq. A single UAR page has two TX doorbells and a single CQ doorbell, so every consecutive pair of 'struct mlx5_sq_bfreg' (TX doorbells) uses the same underlying 'struct mlx5_uars_page' (CQ doorbell). So by using c->bfreg->up, CQs from every consecutive channel pair will share the same CQ doorbell. Non-channel associated CQs keep using the global CQ doorbell. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Use multiple TX doorbellsCosmin Ratiu
First, allocate more doorbells in mlx5e_create_mdev_resources: - one doorbell remains 'global' and will be used by all non-channel associated SQs (e.g. ASO, HWS, PTP, ...). - allocate additional 'num_doorbells' doorbells. This defaults to minimum between 8 and max number of channels. mlx5e_channel_pick_doorbell() now spreads out channel SQs across available doorbells. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Prepare for using different CQ doorbellsCosmin Ratiu
Completion queues (CQs) in mlx5 use the same global doorbell, which may become contended when accessed concurrently from many cores. This patch prepares the CQ management code for supporting different doorbells per CQ. This will be used in downstream patches to allow separate doorbells to be used by channels CQs. The main change is moving the 'uar' pointer from struct mlx5_core_cq to struct mlx5e_cq, as the uar page to be used is better off stored directly there. Other users of mlx5_core_cq also store the UAR to be used separately and therefore the pointer being removed is dead weight for them. As evidence, in this patch there are two users which set the mcq.uar pointer but didn't use it, Software Steering and old Innova CQ creation code. Instead, they rang the doorbell directly from another pointer. The 'uar' pointer added to struct mlx5e_cq remains in a hot cacheline (as before), because it may get accessed for each packet. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Prepare for using multiple TX doorbellsCosmin Ratiu
The driver allocates a single doorbell per device and uses it for all Send Queues (SQs). This can become a bottleneck due to the high number of concurrent MMIO accesses when ringing the same doorbell from many channels. This patch makes the doorbells used by channel queues configurable. mlx5e_channel_pick_doorbell() is added to select the doorbell to be used for a given channel, picking the default for now. When opening a channel, the selected doorbell is saved to the channel struct and used whenever channel-related queues are created. Finally, 'uar_page' is added to 'struct mlx5e_create_sq_param' to control which doorbell to use when allocating an SQ, since that can happen outside channel context (e.g. for PTP). Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Store the global doorbell in mlx5_privCosmin Ratiu
The global doorbell is used for more than just Ethernet resources, so move it out of mlx5e_hw_objs into a common place (mlx5_priv), to avoid non-Ethernet modules (e.g. HWS, ASO) depending on Ethernet structs. Use this opportunity to consolidate it with the 'uar' pointer already there, which was used as an RX doorbell. Underneath the 'uar' pointer is identical to 'bfreg->up', so store a single resource and use that instead. For CQ doorbells, care is taken to always use bfreg->up->index instead of bfreg->index, which may refer to a subsequent UAR page from the same ALLOC_UAR batch on some NICs. This paves the way for cleanly supporting multiple doorbells in the Ethernet driver. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Remove unused 'xsk' param of mlx5e_build_xdpsq_paramCosmin Ratiu
This was added in commit [1], but its only use removed in commit [2]. The parameter is unused, so remove it from the function parameter list. [1] commit 9ded70fa1d81 ("net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode") [2] commit 1a9304859b3a ("net/mlx5: XDP, Enable TX side XDP multi-buffer support") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Remove unused 'offset' field from mlx5_sq_bfregCosmin Ratiu
The 'offset' field was introduced in the original commit [1] and never used until commit [2], which added an unnecessary use. Remove the field and refactor the write-combining test to use a local variable instead. [1] commit a6d51b68611e ("net/mlx5: Introduce blue flame register allocator") [2] commit d98995b4bf98 ("net/mlx5: Reimplement write combining test") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Fix typo of MLX5_EQ_DOORBEL_OFFSETCosmin Ratiu
Also convert it to a simple define. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18wifi: rtw89: wow: enable TKIP related featureChih-Kang Chang
For chips that supports TKIP HW encryption and decryption, enable TKIP cipher for WoWLAN feature. Additionally, the TX MIC KEY and RX MIC KEY is opposite in FW. Therefore, reverse the MIC KEY direction in H2C format, and also reverse it from AOAC report before reporting to mac80211. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065434.39324-1-pkshih@realtek.com
2025-09-17net: dsa: mv88e6xxx: move mv88e6xxx_hwtstamp_work() prototypeRussell King (Oracle)
Since mv88e6xxx_hwtstamp_work() is defined in hwtstamp.c, its prototype should be in hwtstamp.h, so move it there. Remove it's redundant stub definition, as both hwtstamp.c (the function provider) and ptp.c (the consumer) are both dependent on the same config symbol. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused 88E6165 register definitionsRussell King (Oracle)
Remove the unused 88E6165 register definitions. For the port registers, add a comment describing that each arrival and departure offset is for a set of four registers that correspond with status, two timestamp registers and the PTP sequence ID captured from the packet. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove duplicated register definitionRussell King (Oracle)
There are two identical MV88E6XXX_PTP_GC_ETYPE definitions in ptp.h, and MV88E6XXX_PTP_ETHERTYPE in hwtstamp.h which all refer to the exact same register. As the code that accesses this register is in hwtstamp.c, use the hwtstamp.h definition, and remove the unnecessary duplicated definition in ptp.h Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused TAI definitionsRussell King (Oracle)
Remove the TAI definitions that the code never uses. Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: rename TAI definitions according to coreRussell King (Oracle)
The TAI_EVENT_STATUS and TAI_CFG definitions are only used for the 88E6352-family of TAI implementations. Rename them as such, and remove the TAI_EVENT_TIME_* definitions that are unused (although we read them as a block.) Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18wifi: rtw89: 8922a: add TAS feature supportKuan-Chung Chen
Add TAS support for 8922AE. Unlike AX ICs, BE ICs introduce a TAS timer switch. The firmware starts a TAS timer to periodically collect TX power information and notify the driver via C2H events. To avoid unnecessary C2H events, the TAS timer is enabled during core_start(). Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065429.39269-1-pkshih@realtek.com
2025-09-18wifi: rtw89: open C2H event waiting window first before sending H2C commandZong-Zhe Yang
Some H2C commands need to wait for target C2H events to confirm they are executed well. The characteristics of a target C2H event will be encoded into a value, called condition. Then, the corresponding H2C command will wait for it. And, C2H events will complete a condition according to their own characteristics. So, when conditions of both side match, the corresponding H2C command will be completed. Originally, condition waiting window is opened after the H2C command is sent. However, for CPU-bound systems, target C2H event might be already done before the H2C command opens condition waiting window. Without that, C2H event won't match condition, and it will complete nothing. Finally, H2C command wait will time out. Hence, now open condition waiting window first for H2C commands which need to wait for target C2H events. The waiting function is split to two parts, prepare and evaluate. And, waiting side becomes the below where prepare part and evaluate part must be a pair. waiting prepare: condition (open condition waiting window) Do the needed things to trigger completing side. Record errors that will cause no real completer. waiting evaluate: prepare, errors (start waiting for completion if things are fine; otherwise, clean up and return final result.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065352.39082-1-pkshih@realtek.com
2025-09-18wifi: rtw89: renew a completion for each H2C command waiting C2H eventZong-Zhe Yang
Logically before a waiting side which has already timed out turns the atomic status back to idle, a completing side could still pass atomic condition and call complete. It will make the following H2C commands, waiting C2H events, get a completion unexpectedly early. Hence, renew a completion for each H2C command waiting a C2H event. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065343.39023-1-pkshih@realtek.com
2025-09-18wifi: rtw89: 8852b: enable beacon tracking supportKuan-Chung Chen
Enable beacon tracking support on 8852B to improve connection stability. 8852B firmware has supported the power level H2C since version 0.29.128. This H2C is one of the required elements for beacon tracking, allowing control of the maximum receive window while in power save mode. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065337.38966-1-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-10 13:11:48 +0000