<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/amd, branch v7.2-rc5</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc5</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-21T19:47:59+00:00</updated>
<entry>
<title>pds_core: check for workqueue allocation failure</title>
<updated>2026-07-21T19:47:59+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T21:27:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3a660ca49e2c3807bffe0519db3cff677a5906e0'/>
<id>urn:sha1:3a660ca49e2c3807bffe0519db3cff677a5906e0</id>
<content type='text'>
pdsc_init_pf() does not check whether create_singlethread_workqueue()
succeeded.

Fail probe on failure. The workqueue is set up before the timer and
mutexes, so its failure path must unwind only the earlier setup.

Fixes: c2dbb0904310 ("pds_core: health timer and workqueue")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Brett Creeley &lt;brett.creeley@amd.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260714212713.1788438-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: fix auxiliary device add/del races</title>
<updated>2026-07-21T19:46:43+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T21:07:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfa33cd513c7ceb93c5a4c30e5662acd73c0a916'/>
<id>urn:sha1:bfa33cd513c7ceb93c5a4c30e5662acd73c0a916</id>
<content type='text'>
Two paths add or delete the same slot (pf-&gt;vfs[vf_id].padev): a VF's
pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler.
They serialize on config_lock, but neither guards the slot under it
correctly.

add() registers and stores a new auxiliary device without first checking
the slot, so a second add of an already-populated slot leaks the first
device. del() makes that check outside config_lock, so two concurrent
dels can both pass it; the first clears the slot, and the second
dereferences a NULL pointer.

Check and update the slot under config_lock in both paths.

Fixes: b699bdc720c0 ("pds_core: specify auxiliary_device to be created")
Reported-by: sashiko-bot@kernel.org # Running on a local machine
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Brett Creeley &lt;brett.creeley@amd.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260714210745.1785625-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: order completion reads after the ownership check</title>
<updated>2026-07-21T19:45:17+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T20:41:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd6b1cc748cd28147c113f9daa76393916ad9494'/>
<id>urn:sha1:dd6b1cc748cd28147c113f9daa76393916ad9494</id>
<content type='text'>
pdsc_process_adminq() and pdsc_process_notifyq() decide a completion is
valid from its ownership field - the color bit for the adminq, the event
id for the notifyq - then read the rest of the descriptor, with no
barrier in between.

On a weakly ordered architecture the CPU may read the payload first. Add
dma_rmb() between the ownership read and the payload reads.

Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Eric Joyner &lt;eric.joyner@amd.com&gt;
Link: https://patch.msgid.link/20260714204145.1782390-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: yield the CPU while waiting for the adminq to drain</title>
<updated>2026-07-21T19:43:23+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T20:14:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a11f0b8a204296fe7db9eaec53441012222cb004'/>
<id>urn:sha1:a11f0b8a204296fe7db9eaec53441012222cb004</id>
<content type='text'>
pdsc_adminq_wait_and_dec_once_unused() busy-waits for adminq_refcnt to
drop to one:

	while (!refcount_dec_if_one(&amp;pdsc-&gt;adminq_refcnt))
		cpu_relax();

The refcount is held by pdsc_adminq_post() for the duration of an
in-flight command, which can wait up to devcmd_timeout seconds
(PDS_CORE_DEVCMD_TIMEOUT is 5) for the hardware to complete. cpu_relax()
is not a reschedule point, so on a non-preemptible kernel this loop can
spin on the CPU for several seconds, starving other tasks on that core.

Add cond_resched() to the loop so the waiter yields to other runnable
tasks while it polls, keeping cpu_relax() as the busy-wait hint between
checks.

Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Eric Joyner &lt;eric.joyner@amd.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260714201456.1776153-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: fix use-after-free on workqueue during remove</title>
<updated>2026-07-21T19:42:26+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T18:02:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ad134881508c36b65c1a8864f8bec53adbd3327'/>
<id>urn:sha1:0ad134881508c36b65c1a8864f8bec53adbd3327</id>
<content type='text'>
In pdsc_remove(), the workqueue is destroyed before pdsc_teardown()
is called. This ordering allows two paths to queue work on the
destroyed workqueue:

1. If pdsc_teardown() -&gt; pdsc_devcmd_reset() times out, the error
   path in pdsc_devcmd_locked() queues health_work.

2. A NotifyQ event can trigger the ISR and queue work before free_irq()
   is called in pdsc_teardown().

Fix by moving destroy_workqueue() after pdsc_teardown() so the
workqueue outlives every queuer; destroy_workqueue() then flushes any
work still pending.

Draining the queued work also requires ordering the teardown so the
resources that work touches are freed last:

  - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync()
    the queue's work and only then clear qcq-&gt;intx, so
    pdsc_process_adminq()'s read of qcq-&gt;intx for interrupt-credit
    return cannot race with the clear.

  - Free adminqcq before notifyqcq: the shared adminq ISR is released
    when adminqcq is freed, and the adminq work accesses notifyqcq, so
    both must be stopped before notifyqcq is freed.

Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://patchwork.kernel.org/comment/27002369/
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Link: https://patch.msgid.link/20260714180223.1642792-3-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: fix deadlock between reset thread and remove</title>
<updated>2026-07-21T19:42:26+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-14T18:02:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab0eec0ff0a421737a37f510ceab5c6ea59cd05a'/>
<id>urn:sha1:ab0eec0ff0a421737a37f510ceab5c6ea59cd05a</id>
<content type='text'>
pci_reset_function() acquires device_lock before performing the reset.
pdsc_remove() is called by the PCI core with device_lock already held.
If pdsc_pci_reset_thread() is running when pdsc_remove() is called,
destroy_workqueue() will block waiting for the work to complete, while
the work is blocked waiting for device_lock - deadlock.

Use pci_try_reset_function() which uses pci_dev_trylock() internally.
This acquires both the device lock and the PCI config access lock
without blocking - if either lock is contended, it returns -EAGAIN
immediately. This avoids the deadlock while also ensuring proper
config space access serialization during the reset.

The pci_dev_get/put calls are also removed as they were unnecessary -
the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing
the work completes before remove returns. The PCI core holds its
reference to pci_dev throughout the entire unbind sequence.

Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread")
Reported-by: sashiko-bot &lt;sashiko-bot@kernel.org&gt;
Closes: https://patchwork.kernel.org/comment/27002369/
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Harshitha Ramamurthy &lt;hramamurthy@google.com&gt;
Link: https://patch.msgid.link/20260714180223.1642792-2-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN</title>
<updated>2026-07-21T16:12:36+00:00</updated>
<author>
<name>Prashanth Kumar KR</name>
<email>PrashanthKumar.K.R@amd.com</email>
</author>
<published>2026-07-09T09:50:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4bf22afe53a1de4b44b04cf677fd5199089cbdff'/>
<id>urn:sha1:4bf22afe53a1de4b44b04cf677fd5199089cbdff</id>
<content type='text'>
MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed
mode switching after CL37 auto-negotiation and is only meaningful in
SGMII MAC mode. The original code unconditionally set this bit on
every call to xgbe_an37_set(), including when called from
xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after
AN was disabled, causing the XPCS to autonomously switch speed from
stale AN state during subsequent mode changes, breaking SGMII speed
negotiation on 1G copper SFP modules.

Patrick: This was breaking negotiation for all 1G SFP modules,
not just copper modules.

Fixes: 42fd432fe6d3 ("amd-xgbe: align CL37 AN sequence as per databook")
Reported-by: Patrick Oppenlander &lt;patrick.oppenlander@gmail.com&gt;
Link: https://lore.kernel.org/netdev/CAEg67GmFS0Q4oSZkz8zWdOzckSth9_vBPiOy6a7-d697C2w2Xg@mail.gmail.com
Signed-off-by: Prashanth Kumar KR &lt;PrashanthKumar.K.R@amd.com&gt;
Tested-by: Patrick Oppenlander &lt;patrick.oppenlander@gmail.com&gt;
Link: https://patch.msgid.link/20260709095006.3683940-1-prashanthkumar.k.r@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: reject component parameter in legacy firmware update</title>
<updated>2026-07-21T13:01:20+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-07-08T16:36:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7be2552e601c247a328a5aba6fc06ac844b94a16'/>
<id>urn:sha1:7be2552e601c247a328a5aba6fc06ac844b94a16</id>
<content type='text'>
The legacy firmware update path does not support per-component updates.
If a user specifies a component parameter with devlink flash, reject
the request with -EOPNOTSUPP rather than silently ignoring the component
parameter and flashing the entire firmware image.

Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink")
Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260708163649.128620-1-nikhil.rao@amd.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: au1000: move free_irq out of the close-time spinlocked section</title>
<updated>2026-06-24T02:10:29+00:00</updated>
<author>
<name>Runyu Xiao</name>
<email>runyu.xiao@seu.edu.cn</email>
</author>
<published>2026-06-19T15:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f48763beab4eea41fc480c9702ec6eebe8d75e4f'/>
<id>urn:sha1:f48763beab4eea41fc480c9702ec6eebe8d75e4f</id>
<content type='text'>
au1000_close() calls free_irq() while aup-&gt;lock is still held with
spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ
descriptor request mutex, so it does not belong inside the close-time
spinlocked section.

This was found by our static analysis tool and then confirmed by manual
review of the in-tree au1000_close() .ndo_stop path. The reviewed path
keeps aup-&gt;lock held across the MAC reset, queue stop and
free_irq(dev-&gt;irq, dev).

A directed runtime validation kept that ndo_stop carrier and the same
free_irq(dev-&gt;irq, dev) operation under the driver lock. Lockdep reported
"BUG: sleeping function called from invalid context" and "Invalid wait
context" while free_irq() was taking desc-&gt;request_mutex, with
au1000_close() and free_irq() on the stack.

Drop aup-&gt;lock before freeing the IRQ. The protected close-time work still
stops the device and queue before IRQ teardown, but the sleepable IRQ core
path now runs outside the spinlocked section.

Signed-off-by: Runyu Xiao &lt;runyu.xiao@seu.edu.cn&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260619151816.1144289-1-runyu.xiao@seu.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>pds_core: quiesce DMA before freeing resources</title>
<updated>2026-06-09T00:19:56+00:00</updated>
<author>
<name>Nikhil P. Rao</name>
<email>nikhil.rao@amd.com</email>
</author>
<published>2026-06-04T21:36:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6443f4f20bdae726fe01cf5946fba9742a0ffda6'/>
<id>urn:sha1:6443f4f20bdae726fe01cf5946fba9742a0ffda6</id>
<content type='text'>
pdsc_teardown() frees DMA buffers but does not disable bus mastering,
leaving the device able to perform DMA after the buffers are freed.
This can lead to use-after-free if the device writes to freed memory.

Add pci_clear_master() to pdsc_teardown() to disable bus mastering
before freeing resources, ensuring all DMA is quiesced.

Add pci_set_master() to pdsc_setup() to re-enable bus mastering,
which is needed for the firmware recovery path since pdsc_teardown()
now disables it.

Signed-off-by: Nikhil P. Rao &lt;nikhil.rao@amd.com&gt;
Link: https://patch.msgid.link/20260604213637.3844317-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
