|SUCCESS| net/txgbe: fix AML mailbox lock acquisition

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Fri May 22 12:34:05 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164259

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-22

I will analyze this patch against the DPDK coding standards and contribution guidelines.

git sha: 6a139ade82e7 (referenced in Fixes tag)
Author: Stephen Hemminger <stephen at networkplumber.org>
Subject: [PATCH] net/txgbe: fix AML mailbox lock acquisition

This patch fixes an inverted lock acquisition condition in the txgbe
driver's host interface command function. The rte_atomic32_test_and_set()
return value check was backwards, causing immediate exit when the lock
was busy and unnecessary delay when free.

> diff --git a/drivers/net/txgbe/base/txgbe_mng.c b/drivers/net/txgbe/base/txgbe_mng.c
> index a1974820b6..dcd8f58a68 100644
> --- a/drivers/net/txgbe/base/txgbe_mng.c
> +++ b/drivers/net/txgbe/base/txgbe_mng.c
> @@ -185,7 +185,7 @@ txgbe_host_interface_command_aml(struct txgbe_hw *hw, u32 *buffer,
>  	}
>  
>  	/* try to get lock */
> -	while (rte_atomic32_test_and_set(&hw->swfw_busy)) {
> +	while (rte_atomic32_test_and_set(&hw->swfw_busy) == 0) {

The explicit comparison to zero is a C coding style violation. According to
the DPDK coding style guide, "Do not explicitly compare to true, false, 0
or NULL."

Can this code use the preferred implicit form? For example:

    while (!rte_atomic32_test_and_set(&hw->swfw_busy)) {

>  		timeout--;
>  		if (!timeout)
>  			return TXGBE_ERR_TIMEOUT;

Does this function properly decrement timeout before checking? In
txgbe_host_interface_command_aml(), what is the initial value of timeout?
If the function starts with timeout set to some value N and immediately
enters the loop, does the first decrement happen before the lock is ever
successfully acquired? Can this cause premature timeout when the lock is
legitimately busy for exactly N-1 iterations?


More information about the test-report mailing list