|SUCCESS| [v4] net/axgbe: mask unsupported PHY half-duplex modes

[dpdklab at iol.unh.edu]

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

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-16

Below is the review of the patch. The review focuses on correctness,
coding style compliance, and adherence to DPDK guidelines.

commit <SHA not provided in patch file>
Author: Ashok Kumar Natarajan <ashokkumar.natarajan at amd.com>

[PATCH v4] net/axgbe: mask unsupported PHY half-duplex modes

The AXGBE MAC supports only full-duplex operation at all speeds.
However, the PHY auto-negotiation configuration could advertise
half-duplex modes, including 10BASE-T, 100BASE-TX, and 1000BASE-T,
which are not supported by the MAC.

Update the Clause 22 and Clause 40 PHY advertisement handling to mask
all half-duplex modes while preserving existing PHY, strap, and
vendor-specific configuration using read-modify-write.

To maintain backward compatibility, full-duplex advertisement for
10/100 and 1000BASE-T is preserved by default when no explicit PHY
advertising mask is provided.

This ensures IEEE 802.3 compliant PHY advertisement while avoiding
regressions on platforms relying on PHY default configuration.

> diff --git a/drivers/net/axgbe/axgbe_phy.h b/drivers/net/axgbe/axgbe_phy.h
> index e5568cce5f..9d6496c3cf 100644
> --- a/drivers/net/axgbe/axgbe_phy.h
> +++ b/drivers/net/axgbe/axgbe_phy.h
> @@ -82,6 +82,10 @@
>  #define ADVERTISE_LPACK         0x4000  /* Ack link partners response  */
>  #define ADVERTISE_NPAGE         0x8000  /* Next page bit               */
>  
> +/* IEEE 802.3 Clause 40: 1000BASE-T Advertisement Control */
> +#define ADVERTISE_1000FULL	0x0200
> +#define ADVERTISE_1000HALF	0x0100

These new defines use tab alignment inconsistent with the existing
defines above, which use spaces. The coding style guide requires
consistent alignment. Should these use spaces like ADVERTISE_LPACK above?

> diff --git a/drivers/net/axgbe/axgbe_phy_impl.c b/drivers/net/axgbe/axgbe_phy_impl.c
> index 369d766884..4abf5fdea9 100644
> --- a/drivers/net/axgbe/axgbe_phy_impl.c
> +++ b/drivers/net/axgbe/axgbe_phy_impl.c
> @@ -303,23 +303,114 @@ static int axgbe_phy_write(struct axgbe_port *pdata, u16 reg, u16 value)
>  
>  static int axgbe_phy_config_advert(struct axgbe_port *pdata)
>  {
> -	u16 advert;
> +	u32 adv = pdata->phy.advertising;
> +	u16 advert, orig_advert;
> +	u16 ctrl1000, orig_ctrl1000;
>  	int ret;

[ ... ]

> +	/*
> +	 * Clause 22 (10/100) advertisement configuration.
> +	 *
> +	 * AXGBE MAC supports only full-duplex operation.
> +	 * Half-duplex modes are masked while preserving any
> +	 * PHY-specific or reserved bits.
> +	 */
>  	ret = pdata->phy_if.phy_impl.read(pdata, MII_ADVERTISE, &advert);
>  	if (ret) {
> -		PMD_DRV_LOG_LINE(ERR, "Failed to read ADVERTISE register");
> +		PMD_DRV_LOG_LINE(ERR,
> +				"PHY read failed: MII_ADVERTISE");

This line break looks unusual. Does this formatting comply with the
80-character line limit rules when the PMD_DRV_LOG_LINE macro expands?

>  		return ret;
>  	}
>  
> -	advert |= ADVERTISE_FULL;
> -	advert |= ADVERTISE_PAUSE_CAP;
> +	orig_advert = advert;
> +
> +	/* Always advertise IEEE 802.3 CSMA/CD selector */
> +	advert |= ADVERTISE_CSMA;
> +
> +	/* AXGBE does not support 10/100 half-duplex */
> +	advert &= ~(ADVERTISE_10HALF | ADVERTISE_100HALF);
> +
> +	/*
> +	 * Treat adv == 0 as a legacy/default configuration where the driver
> +	 * does not impose an explicit policy and preserves the historical
> +	 * behavior of advertising all supported full-duplex speeds.
> +	 */
> +	if (!adv) {

Does this implicit comparison against zero comply with the coding style
guide? The guide states that comparisons should be explicit.

> +		advert |= ADVERTISE_10FULL | ADVERTISE_100FULL;
> +		advert |= ADVERTISE_PAUSE_CAP;
> +	} else {
> +		if (adv & ADVERTISED_10baseT_Full)
> +			advert |= ADVERTISE_10FULL;
> +		else
> +			advert &= ~ADVERTISE_10FULL;

The pattern if/else with bit set/clear could be simplified. Is the
separate clearing necessary when the half-duplex mask above already
cleared those bits?

> +
> +		if (adv & ADVERTISED_100baseT_Full)
> +			advert |= ADVERTISE_100FULL;
> +		else
> +			advert &= ~ADVERTISE_100FULL;
> +
> +		if (adv & ADVERTISED_Pause)
> +			advert |= ADVERTISE_PAUSE_CAP;
> +		else
> +			advert &= ~ADVERTISE_PAUSE_CAP;
> +
> +		if (adv & ADVERTISED_Asym_Pause)
> +			advert |= ADVERTISE_PAUSE_ASYM;
> +		else
> +			advert &= ~ADVERTISE_PAUSE_ASYM;
> +	}
> +
> +	if (advert != orig_advert) {
> +		ret = pdata->phy_if.phy_impl.write(pdata,
> +				MII_ADVERTISE,
> +				advert);

This indentation looks unusual. Does this comply with the continuation
line indentation rules?

> +		if (ret) {
> +			PMD_DRV_LOG_LINE(ERR,
> +					"PHY write failed: MII_ADVERTISE");
> +			return ret;
> +		}
> +	}
> +
> +	/*
> +	 * Clause 40 (1000BASE-T) advertisement configuration.
> +	 *
> +	 * AXGBE MAC supports only full-duplex operation at 1Gbps.
> +	 * Half-duplex advertisement is always cleared.
> +	 * Existing PHY or vendor-specific bits are preserved.
> +	 */
> +	ret = pdata->phy_if.phy_impl.read(pdata, MII_CTRL1000, &ctrl1000);
>  	if (ret) {
> -		PMD_DRV_LOG_LINE(ERR, "Failed to write ADVERTISE register");
> +		PMD_DRV_LOG_LINE(ERR,
> +				"PHY read failed: MII_CTRL1000");
>  		return ret;
>  	}
> +
> +	orig_ctrl1000 = ctrl1000;
> +
> +	/* Clear unsupported 1000BASE-T half-duplex */
> +	ctrl1000 &= ~ADVERTISE_1000HALF;
> +
> +	/*
> +	 * As with Clause 22 advertisement, adv == 0 indicates that no explicit
> +	 * advertising policy was requested. In this case, preserve the legacy
> +	 * behaviour of advertising 1000BASE-T full-duplex by default.
> +	 */
> +	if (!adv || (adv & ADVERTISED_1000baseT_Full))

Does this implicit comparison of adv against zero comply with the coding
style guide requirement for explicit comparisons?

> +		ctrl1000 |= ADVERTISE_1000FULL;
> +	else
> +		ctrl1000 &= ~ADVERTISE_1000FULL;
> +
> +	if (ctrl1000 != orig_ctrl1000) {
> +		ret = pdata->phy_if.phy_impl.write(pdata,
> +				MII_CTRL1000,
> +				ctrl1000);
> +		if (ret) {
> +			PMD_DRV_LOG_LINE(ERR,
> +					"PHY write failed: MII_CTRL1000");
> +			return ret;
> +		}
> +	}
> +
>  	return 0;
>  }

The logic appears functionally sound. The read-modify-write pattern
properly preserves existing register bits. Error paths correctly return
error codes. No obvious resource leaks or use-after-free issues detected.

The main concerns are:
1. Implicit comparisons against zero for adv variable
2. Inconsistent whitespace/alignment in header file defines
3. Unusual indentation in multi-line function calls