<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-02T11:09:54+00:00</updated>
<entry>
<title>idpf: nullify pointers after they are freed</title>
<updated>2026-04-02T11:09:54+00:00</updated>
<author>
<name>Li Li</name>
<email>boolli@google.com</email>
</author>
<published>2026-01-23T06:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b8410e13e7d245c345f81df48291930f0f5e64f'/>
<id>urn:sha1:7b8410e13e7d245c345f81df48291930f0f5e64f</id>
<content type='text'>
commit bc3b31977314433e4685ae92853d1b6e91ad7bc2 upstream.

rss_data-&gt;rss_key needs to be nullified after it is freed.
Checks like "if (!rss_data-&gt;rss_key)" in the code could fail
if it is not nullified.

Tested: built and booted the kernel.

Fixes: 83f38f210b85 ("idpf: Fix RSS LUT NULL pointer crash on early ethtool operations")
Signed-off-by: Li Li &lt;boolli@google.com&gt;
Reviewed-by: Aleksandr Loktionov &lt;aleksandr.loktionov@intel.com&gt;
Tested-by: Samuel Salin &lt;Samuel.salin@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmasp: Fix network filter wake for asp-3.0</title>
<updated>2026-04-02T11:09:54+00:00</updated>
<author>
<name>Justin Chen</name>
<email>justin.chen@broadcom.com</email>
</author>
<published>2026-01-20T19:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=acf942d0dccd896e60bb1b3d2261f9abef7f2d74'/>
<id>urn:sha1:acf942d0dccd896e60bb1b3d2261f9abef7f2d74</id>
<content type='text'>
commit bbb11b8d758d17a4ce34b8ed0b49de150568265b upstream.

We need to apply the tx_chan_offset to the netfilter cfg channel or the
output channel will be incorrect for asp-3.0 and newer.

Fixes: e9f31435ee7d ("net: bcmasp: Add support for asp-v3.0")
Signed-off-by: Justin Chen &lt;justin.chen@broadcom.com&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20260120192339.2031648-1-justin.chen@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmasp: Restore programming of TX map vector register</title>
<updated>2026-04-02T11:09:54+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>florian.fainelli@broadcom.com</email>
</author>
<published>2025-07-18T21:22:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1c0a49ce24c4393f98107feedabeb12161f1d776'/>
<id>urn:sha1:1c0a49ce24c4393f98107feedabeb12161f1d776</id>
<content type='text'>
commit 18ff09c1b94fa1584b31d3f4e9eecdca29230ce5 upstream.

On ASP versions v2.x we need to program the TX map vector register to
properly exercise end-to-end flow control, otherwise the TX engine can
either lock-up, or cause the hardware calculated checksum to be
wrong/corrupted when multiple back to back packets are being submitted
for transmission. This register defaults to 0, which means no flow
control being applied.

Fixes: e9f31435ee7d ("net: bcmasp: Add support for asp-v3.0")
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20250718212242.3447751-1-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: Fix leaking event log memory</title>
<updated>2026-04-02T11:09:54+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=d94f9b0ba28a205caf95902ee88b42bdb8af83d0'/>
<id>urn:sha1:d94f9b0ba28a205caf95902ee88b42bdb8af83d0</id>
<content type='text'>
[ Upstream commit ee66bc29578391c9b48523dc9119af67bd5c7c0f ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>xen/privcmd: unregister xenstore notifier on module exit</title>
<updated>2026-04-02T11:09:54+00:00</updated>
<author>
<name>GuoHan Zhao</name>
<email>zhaoguohan@kylinos.cn</email>
</author>
<published>2026-03-25T12:02:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33dce5758914b5c6efe2a974581a7719b100efea'/>
<id>urn:sha1:33dce5758914b5c6efe2a974581a7719b100efea</id>
<content type='text'>
[ Upstream commit cd7e1fef5a1ca1c4fcd232211962ac2395601636 ]

Commit 453b8fb68f36 ("xen/privcmd: restrict usage in
unprivileged domU") added a xenstore notifier to defer setting the
restriction target until Xenstore is ready.

XEN_PRIVCMD can be built as a module, but privcmd_exit() leaves that
notifier behind. Balance the notifier lifecycle by unregistering it on
module exit.

This is harmless even if xenstore was already ready at registration
time and the notifier was never queued on the chain.

Fixes: 453b8fb68f3641fe ("xen/privcmd: restrict usage in unprivileged domU")
Signed-off-by: GuoHan Zhao &lt;zhaoguohan@kylinos.cn&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Message-ID: &lt;20260325120246.252899-1-zhaoguohan@kylinos.cn&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA</title>
<updated>2026-04-02T11:09:53+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ideasonboard.com</email>
</author>
<published>2026-03-11T05:34:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea56f1a6049415e76a9a580b216e66ea04383f40'/>
<id>urn:sha1:ea56f1a6049415e76a9a580b216e66ea04383f40</id>
<content type='text'>
[ Upstream commit a17ce4bc6f4f9acf77ba416c36791a15602e53aa ]

A single AXIDMA controller can have one or two channels. When it has two
channels, the reset for both are tied together: resetting one channel
resets the other as well. This creates a problem where resetting one
channel will reset the registers for both channels, including clearing
interrupt enable bits for the other channel, which can then lead  to
timeouts as the driver is waiting for an interrupt which never comes.

The driver currently has a probe-time work around for this: when a
channel is created, the driver also resets and enables the
interrupts. With two channels the reset for the second channel will
clear the interrupt enables for the first one. The work around in the
driver is just to manually enable the interrupts again in
xilinx_dma_alloc_chan_resources().

This workaround only addresses the probe-time issue. When channels are
reset at runtime (e.g., in xilinx_dma_terminate_all() or during error
recovery), there's no corresponding mechanism to restore the other
channel's interrupt enables. This leads to one channel having its
interrupts disabled while the driver expects them to work, causing
timeouts and DMA failures.

A proper fix is a complicated matter, as we should not reset the other
channel when it's operating normally. So, perhaps, there should be some
kind of synchronization for a common reset, which is not trivial to
implement. To add to the complexity, the driver also supports other DMA
types, like VDMA, CDMA and MCDMA, which don't have a shared reset.

However, when the two-channel AXIDMA is used in the (assumably) normal
use case, providing DMA for a single memory-to-memory device, the common
reset is a bit smaller issue: when something bad happens on one channel,
or when one channel is terminated, the assumption is that we also want
to terminate the other channel. And thus resetting both at the same time
is "ok".

With that line of thinking we can implement a bit better work around
than just the current probe time work around: let's enable the
AXIDMA interrupts at xilinx_dma_start_transfer() instead.
This ensures interrupts are enabled whenever a transfer starts,
regardless of any prior resets that may have cleared them.

This approach is also more logical: enable interrupts only when needed
for a transfer, rather than at resource allocation time, and, I think,
all the other DMA types should also use this model, but I'm reluctant to
do such changes as I cannot test them.

The reset function still enables interrupts even though it's not needed
for AXIDMA anymore, but it's common code for all DMA types (VDMA, CDMA,
MCDMA), so leave it unchanged to avoid affecting other variants.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ideasonboard.com&gt;
Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine")
Link: https://patch.msgid.link/20260311-xilinx-dma-fix-v2-1-a725abb66e3c@ideasonboard.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction</title>
<updated>2026-04-02T11:09:53+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@nabladev.com</email>
</author>
<published>2026-03-16T22:25:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ba972cf9fe49240dd08f3c06c59c5035aee045c5'/>
<id>urn:sha1:ba972cf9fe49240dd08f3c06c59c5035aee045c5</id>
<content type='text'>
[ Upstream commit c7d812e33f3e8ca0fa9eeabf71d1c7bc3acedc09 ]

The segment .control and .status fields both contain top bits which are
not part of the buffer size, the buffer size is located only in the bottom
max_buffer_len bits. To avoid interference from those top bits, mask out
the size using max_buffer_len first, and only then subtract the values.

Fixes: a575d0b4e663 ("dmaengine: xilinx_dma: Introduce xilinx_dma_get_residue")
Signed-off-by: Marek Vasut &lt;marex@nabladev.com&gt;
Link: https://patch.msgid.link/20260316222530.163815-1-marex@nabladev.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA</title>
<updated>2026-04-02T11:09:53+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@nabladev.com</email>
</author>
<published>2026-03-16T22:18:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc2c68f3aa13c5d3c3852c4a63ac3c95cd42563c'/>
<id>urn:sha1:dc2c68f3aa13c5d3c3852c4a63ac3c95cd42563c</id>
<content type='text'>
[ Upstream commit f61d145999d61948a23cd436ebbfa4c3b9ab8987 ]

The cyclic DMA calculation is currently entirely broken and reports
residue only for the first segment. The problem is twofold.

First, when the first descriptor finishes, it is moved from active_list
to done_list, but it is never returned back into the active_list. The
xilinx_dma_tx_status() expects the descriptor to be in the active_list
to report any meaningful residue information, which never happens after
the first descriptor finishes. Fix this up in xilinx_dma_start_transfer()
and if the descriptor is cyclic, lift it from done_list and place it back
into active_list list.

Second, the segment .status fields of the descriptor remain dirty. Once
the DMA did one pass on the descriptor, the .status fields are populated
with data by the DMA, but the .status fields are not cleared before reuse
during the next cyclic DMA round. The xilinx_dma_get_residue() recognizes
that as if the descriptor was complete and had 0 residue, which is bogus.
Reinitialize the status field before placing the descriptor back into the
active_list.

Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine")
Signed-off-by: Marek Vasut &lt;marex@nabladev.com&gt;
Link: https://patch.msgid.link/20260316221943.160375-1-marex@nabladev.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: xilinx: xilinx_dma: Fix dma_device directions</title>
<updated>2026-04-02T11:09:53+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@nabladev.com</email>
</author>
<published>2026-03-16T22:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7317ae215d3f1a67e07d5c3061ef4c47e516f479'/>
<id>urn:sha1:7317ae215d3f1a67e07d5c3061ef4c47e516f479</id>
<content type='text'>
[ Upstream commit e9cc95397bb7da13fe8a5b53a2f23cfaf9018ade ]

Unlike chan-&gt;direction , struct dma_device .directions field is a
bitfield. Turn chan-&gt;direction into a bitfield to make it compatible
with struct dma_device .directions .

Fixes: 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions")
Signed-off-by: Marek Vasut &lt;marex@nabladev.com&gt;
Link: https://patch.msgid.link/20260316221728.160139-1-marex@nabladev.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()</title>
<updated>2026-04-02T11:09:53+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=e21da2ad8844585040fe4b82be1ad2fe99d40074'/>
<id>urn:sha1:e21da2ad8844585040fe4b82be1ad2fe99d40074</id>
<content type='text'>
[ Upstream commit e1c9866173c5f8521f2d0768547a01508cb9ff27 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
