<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/dma/idxd, branch v7.2-rc2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-09T22:04:02+00:00</updated>
<entry>
<title>PCI/P2PDMA: Add Intel QAT, DSA, IAA devices to whitelist</title>
<updated>2026-06-09T22:04:02+00:00</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2026-06-04T15:12:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ba76b19fd4c7256787eab0283c759b18eb76876'/>
<id>urn:sha1:0ba76b19fd4c7256787eab0283c759b18eb76876</id>
<content type='text'>
The first device on a PCI root bus determines whether the host bridge is
whitelisted for P2PDMA.  All Intel Xeon chips since Ice Lake (ICX, 2021)
expose a device with ID 0x09a2 as first device.  It is loosely associated
with the IOMMU.  All these Xeon chips support P2PDMA, so since the addition
of the device with commit feaea1fe8b36 ("PCI/P2PDMA: Add Intel 3rd Gen
Intel Xeon Scalable Processors to whitelist"), P2PDMA has been allowed on
all new Xeons without the need to amend the whitelist:

Xeons with Performance Cores:
  Sapphire Rapids (SPR, 2023)
  Emerald Rapids (EMR, 2023)
  Granite Rapids (GNR, 2024)
  Diamond Rapids (DMR, 2026)

Xeons with Efficiency Cores:
  Sierra Forest (SRF, 2024)
  Clearwater Forest (CWF, 2026)

However these Xeons also expose accelerators as first device on a root bus
of its own:

  QuickAssist Technology (QAT, crypto &amp; compression accelerator)
  Data Streaming Accelerator (DSA, dma engine)
  In-Memory Analytics Accelerator (IAA, compression accelerator)

Whitelist them for P2PDMA as well.  Move their Device ID macros from the
accelerator drivers to &lt;linux/pci_ids.h&gt; for reuse by P2PDMA code.

Unfortunately the Device IDs vary across Xeon generations as additional
features were added to the accelerators.  This currently necessitates an
amendment for each new Xeon chip.

For future chips, this need shall be avoided by an ongoing effort to extend
ACPI HMAT with PCIe P2PDMA characteristics (latency, bandwidth, ordering
constraints).  The PCI core will be able look up in this BIOS-provided ACPI
table whether P2PDMA is supported, instead of relying on a whitelist that
needs to be amended continuously.

Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Acked-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt; # QAT
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/6aac4922b5fe7070b11874427a9285e42ddd05a4.1780585518.git.lukas@wunner.de
</content>
</entry>
<entry>
<title>dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()</title>
<updated>2026-03-09T11:27:11+00:00</updated>
<author>
<name>Tuo Li</name>
<email>islituo@gmail.com</email>
</author>
<published>2026-01-06T03:24:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1c9866173c5f8521f2d0768547a01508cb9ff27'/>
<id>urn:sha1:e1c9866173c5f8521f2d0768547a01508cb9ff27</id>
<content type='text'>
At the end of this function, d is the traversal cursor of flist, but the
code completes found instead. This can lead to issues such as NULL pointer
dereferences, double completion, or descriptor leaks.

Fix this by completing d instead of found in the final
list_for_each_entry_safe() loop.

Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto")
Signed-off-by: Tuo Li &lt;islituo@gmail.com&gt;
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix leaking event log memory</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee66bc29578391c9b48523dc9119af67bd5c7c0f'/>
<id>urn:sha1:ee66bc29578391c9b48523dc9119af67bd5c7c0f</id>
<content type='text'>
During the device remove process, the device is reset, causing the
configuration registers to go back to their default state, which is
zero. As the driver is checking if the event log support was enabled
before deallocating, it will fail if a reset happened before.

Do not check if the support was enabled, the check for 'idxd-&gt;evl'
being valid (only allocated if the HW capability is available) is
enough.

Fixes: 244da66cda35 ("dmaengine: idxd: setup event log configuration")
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-10-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix freeing the allocated ida too late</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c311f5e9248471a950f0a524c2fd736414d98900'/>
<id>urn:sha1:c311f5e9248471a950f0a524c2fd736414d98900</id>
<content type='text'>
It can happen that when the cdev .release() is called, the driver
already called ida_destroy(). Move ida_free() to the _del() path.

We see with DEBUG_KOBJECT_RELEASE enabled and forcing an early PCI
unbind.

Fixes: 04922b7445a1 ("dmaengine: idxd: fix cdev setup and free device lifetime issues")
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-9-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix memory leak when a wq is reset</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d9cfb5193a047a92a4d3c0e91ea4cc87c8f7c478'/>
<id>urn:sha1:d9cfb5193a047a92a4d3c0e91ea4cc87c8f7c478</id>
<content type='text'>
idxd_wq_disable_cleanup() which is called from the reset path for a
workqueue, sets the wq type to NONE, which for other parts of the
driver mean that the wq is empty (all its resources were released).

Only set the wq type to NONE after its resources are released.

Fixes: da32b28c95a7 ("dmaengine: idxd: cleanup workqueue config after disabling")
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-8-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix not releasing workqueue on .release()</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d33de353b1ff9023d5ec73b9becf80ea87af695'/>
<id>urn:sha1:3d33de353b1ff9023d5ec73b9becf80ea87af695</id>
<content type='text'>
The workqueue associated with an DSA/IAA device is not released when
the object is freed.

Fixes: 47c16ac27d4c ("dmaengine: idxd: fix idxd conf_dev 'struct device' lifetime")
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-7-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Wait for submitted operations on .device_synchronize()</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4fd3c4679f4f33873d7cb90b3eb553bea4db1038'/>
<id>urn:sha1:4fd3c4679f4f33873d7cb90b3eb553bea4db1038</id>
<content type='text'>
When the dmaengine "core" asks the driver to synchronize, send a Drain
operation to the device workqueue, which will wait for the already
submitted operations to finish.

Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-6-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Flush all pending descriptors</title>
<updated>2026-02-25T11:09:18+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a93f5747d0eef89a3158c91d185d37d0bca2491'/>
<id>urn:sha1:2a93f5747d0eef89a3158c91d185d37d0bca2491</id>
<content type='text'>
When used as a dmaengine, the DMA "core" might ask the driver to
terminate all pending requests, when that happens, flush all pending
descriptors.

In this context, flush means removing the requests from the pending
lists, so even if they are completed after, the user is not notified.

Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-5-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Flush kernel workqueues on Function Level Reset</title>
<updated>2026-02-25T11:09:17+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f019d7814bceb6d8a017b3e55cb53deb1e6fd36b'/>
<id>urn:sha1:f019d7814bceb6d8a017b3e55cb53deb1e6fd36b</id>
<content type='text'>
When a Function Level Reset (FLR) happens, terminate the pending
descriptors that were issued by in-kernel users and disable the
interrupts associated with those. They will be re-enabled after FLR
finishes.

idxd_wq_flush_desc() is declared on idxd.h because it's going to be
used in by the DMA backend in a future patch.

Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-4-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix possible invalid memory access after FLR</title>
<updated>2026-02-25T11:09:17+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2026-01-21T18:34:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d6077df7b75d26e4edf98983836c05d00ebabd8d'/>
<id>urn:sha1:d6077df7b75d26e4edf98983836c05d00ebabd8d</id>
<content type='text'>
In the case that the first Function Level Reset (FLR) concludes
correctly, but in the second FLR the scratch area for the saved
configuration cannot be allocated, it's possible for a invalid memory
access to happen.

Always set the deallocated scratch area to NULL after FLR completes.

Fixes: 98d187a98903 ("dmaengine: idxd: Enable Function Level Reset (FLR) for halt")
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-3-7ed70658a9d1@intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
</feed>
