Linux USB
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Birger Koblitz" <mail@birger-koblitz.de>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH net-next v19 13/13] ax88796b: Add support for AX88772D, AX88179A and AX88279
Date: Sun, 11 Oct 2026 04:55:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-167020@kernel.org> (raw)
In-Reply-To: <20261010-ax88179a-v19-13-7475173cfb56@birger-koblitz.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net/phy: ax88279 leaves 10baseT_Half_BIT in supported modes despite being full-duplex only
--

commit fca1c63dd8d205ab9ae6d1280f70589e1b085eb0
Author: Birger Koblitz <mail@birger-koblitz.de>

ax88796b: Add support for AX88772D, AX88179A and AX88279

The AX88772D, AX88179A and AX88279 are 100MBit, 1GBit and respectively
2.5 GBit PHYs that are found in ASIX USB-Ethernet controllers of the
same name.

> diff --git a/drivers/net/phy/ax88796b.c b/drivers/net/phy/ax88796b.c
> index f20ddf6491499..0df44e0e236ab 100644
> --- a/drivers/net/phy/ax88796b.c
> +++ b/drivers/net/phy/ax88796b.c

[ ... ]

> @@ -83,6 +96,107 @@ static int asix_ax88772a_read_status(struct phy_device *phydev)
>  	return 0;
>  }
>  
> +static int asix_ax88279_read_status(struct phy_device *phydev)
> +{

[ ... ]

> +	/* MDIO_AN_10GBT_STAT_LP2_5G is broken, but we can deduce that
> +	 * the link-partner advertised 2500M if remotely AN succceded
> +	 * for link speed > 1000M and we locally have a link speed of
> +	 * 2500M
> +	 */
> +	linkmode_clear_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->lp_advertising);
> +	val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_STAT);
> +	if (val >= 0 && val & MDIO_AN_10GBT_STAT_REMOK) {
> +		linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> +				 phydev->lp_advertising,
> +				 phydev->speed == SPEED_2500);
> +	}
> +	/* Only supports full duplex */
> +	phydev->duplex = DUPLEX_FULL;

[Severity: Medium]
Since the driver unconditionally forces the MAC to full-duplex here, could
this cause a duplex mismatch if 10M half-duplex is negotiated?

In asix_ax88279_get_features() below, genphy_c45_pma_read_abilities()
evaluates extended abilities and will set ETHTOOL_LINK_MODE_10baseT_Half_BIT
if 10Mbps is supported. If a peer supports only half-duplex (or
auto-negotiation otherwise selects it), the link will come up in half-duplex
on the wire while the driver unconditionally reports DUPLEX_FULL, leading to
late collisions and packet loss.

> +
> +	/* PHY switches interface between 2.5GBit and slower modes */
> +	if (phydev->speed == SPEED_2500)
> +		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> +	else
> +		phydev->interface = PHY_INTERFACE_MODE_SGMII;
> +
> +	return 0;
> +}

[ ... ]

> +static int asix_ax88279_get_features(struct phy_device *phydev)
> +{
> +	int ret;
> +
> +	/* MDIO_DEVS1/2 empty, so set mmds_present bits to allow reading abilities */
> +	phydev->c45_ids.mmds_present |= MDIO_DEVS_PMAPMD | MDIO_DEVS_AN;
> +
> +	linkmode_set_bit_array(phy_basic_ports_array, ARRAY_SIZE(phy_basic_ports_array),
> +			       phydev->supported);
> +
> +	ret = genphy_c45_pma_read_abilities(phydev);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* AX88279 does not support reported 100baseT-half duplex mode */
> +	linkmode_clear_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT, phydev->supported);

[Severity: Medium]
Does this code also need to clear ETHTOOL_LINK_MODE_10baseT_Half_BIT?

The driver manually clears 100baseT-Half due to a lack of support, but
appears to leave 10baseT-Half enabled in the supported modes despite the PHY
being full-duplex only.

> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010-ax88179a-v19-0-7475173cfb56@birger-koblitz.de?part=13

  reply	other threads:[~2026-10-11  4:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10  4:54 [PATCH net-next v19 00/13] ax88179_178a: Add support for AX88179A-based chips Birger Koblitz
2026-10-10  4:54 ` [PATCH net-next v19 01/13] phylink: Add phylink_mac_interrupt Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-11  5:32     ` Birger Koblitz
2026-10-10  4:54 ` [PATCH net-next v19 02/13] phylib: Add support for PHYs with broken forced mode Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 03/13] ax88179_178a: Split driver into library and device specific code Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 04/13] ax88179_178a: Add HW support for AX179A-based chips Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 05/13] ax88179_178a: Add EEE configuration support for AX88179A MACs Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 06/13] ax88179_178a: Add EEE configuration support for AX88179A PHYs Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 07/13] ax88179_178a: Add VLAN offload support for AX88179A Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 08/13] ax88179_178a: Add AX179A/AX279 multicast configuration Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 09/13] ax88179_178a: Add Suspend/resume support for AX88179A/772D/279 Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 10/13] ax88179_178a: Add ethtool get_drvinfo Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 11/13] ax88179_178a: Update driver name and information Birger Koblitz
2026-10-11  4:54   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 12/13] ax88179_178a: Add support for AX88179A/772D/279 EEPROM access Birger Koblitz
2026-10-11  4:55   ` sashiko-bot
2026-10-10  4:54 ` [PATCH net-next v19 13/13] ax88796b: Add support for AX88772D, AX88179A and AX88279 Birger Koblitz
2026-10-11  4:55   ` sashiko-bot [this message]
2026-10-10  6:20 ` [PATCH v19 0/13] ax88179_178a: Add support for AX88179A-based chips Jianhui Xu
2026-10-10  7:42   ` Birger Koblitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-167020@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mail@birger-koblitz.de \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox