[PATCH net-next 0/3] TXGBE feat new AML firmware

[PATCH net-next 0/3] TXGBE feat new AML firmware

[Jiawen Wu]

The firmware of AML devices are redesigned to adapt to more PHY
interfaces. Optimize the driver to be compatible with the new firmware.

Jiawen Wu (3):
  net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module
  net: txgbe: optimize the flow to setup PHY for AML devices
  net: txgbe: rename txgbe_get_phy_link()

 drivers/net/ethernet/wangxun/libwx/wx_type.h  |  2 -
 .../net/ethernet/wangxun/txgbe/txgbe_aml.c    | 54 ++++++-------------
 .../net/ethernet/wangxun/txgbe/txgbe_type.h   |  5 +-
 3 files changed, 20 insertions(+), 41 deletions(-)

-- 
2.48.1

[PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Jiawen Wu]

In order to identify 40G and 100G QSFP modules, expend mailbox buffer
size to store more information read from the firmware.

Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
---
 drivers/net/ethernet/wangxun/txgbe/txgbe_type.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
index 41915d7dd372..9d53c7413f7b 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
@@ -352,7 +352,9 @@ struct txgbe_sfp_id {
 	u8 vendor_oui0;		/* A0H 0x25 */
 	u8 vendor_oui1;		/* A0H 0x26 */
 	u8 vendor_oui2;		/* A0H 0x27 */
-	u8 reserved[3];
+	u8 transceiver_type;	/* A0H 0x83 */
+	u8 sff_opt1;		/* A0H 0xC0 */
+	u8 reserved[5];
 };
 
 struct txgbe_hic_i2c_read {
-- 
2.48.1

Re: [PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Simon Horman]

On Sun, Sep 28, 2025 at 05:39:21PM +0800, Jiawen Wu wrote:
> In order to identify 40G and 100G QSFP modules, expend mailbox buffer
> size to store more information read from the firmware.

Hi,

I see that the message size is increased by 4 bytes,
including two new one-byte fields.
But I don't see how that is used by this patchset.
Could you expand on this a little?

> 
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>

...

RE: [PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Jiawen Wu]

On Mon, Sep 29, 2025 9:52 PM, Simon Horman wrote:
> On Sun, Sep 28, 2025 at 05:39:21PM +0800, Jiawen Wu wrote:
> > In order to identify 40G and 100G QSFP modules, expend mailbox buffer
> > size to store more information read from the firmware.
> 
> Hi,
> 
> I see that the message size is increased by 4 bytes,
> including two new one-byte fields.
> But I don't see how that is used by this patchset.
> Could you expand on this a little?

It is used for QSFP modules, I haven't added the part of these modules yet.
But the firmware was changed. So when using the new firmware, the module
cannot be identified due to incorrect length of mailbox buffer.

Re: [PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Andrew Lunn]

On Fri, Oct 10, 2025 at 03:42:00PM +0800, Jiawen Wu wrote:
> On Mon, Sep 29, 2025 9:52 PM, Simon Horman wrote:
> > On Sun, Sep 28, 2025 at 05:39:21PM +0800, Jiawen Wu wrote:
> > > In order to identify 40G and 100G QSFP modules, expend mailbox buffer
> > > size to store more information read from the firmware.
> > 
> > Hi,
> > 
> > I see that the message size is increased by 4 bytes,
> > including two new one-byte fields.
> > But I don't see how that is used by this patchset.
> > Could you expand on this a little?
> 
> It is used for QSFP modules, I haven't added the part of these modules yet.
> But the firmware was changed. So when using the new firmware, the module
> cannot be identified due to incorrect length of mailbox buffer.
 
And with old firmware? Can you tell the end of the message has not
been filled in with old firmware?

	Andrew

RE: [PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Jiawen Wu]

On Fri, Oct 10, 2025 9:53 PM, Andrew Lunn wrote:
> On Fri, Oct 10, 2025 at 03:42:00PM +0800, Jiawen Wu wrote:
> > On Mon, Sep 29, 2025 9:52 PM, Simon Horman wrote:
> > > On Sun, Sep 28, 2025 at 05:39:21PM +0800, Jiawen Wu wrote:
> > > > In order to identify 40G and 100G QSFP modules, expend mailbox buffer
> > > > size to store more information read from the firmware.
> > >
> > > Hi,
> > >
> > > I see that the message size is increased by 4 bytes,
> > > including two new one-byte fields.
> > > But I don't see how that is used by this patchset.
> > > Could you expand on this a little?
> >
> > It is used for QSFP modules, I haven't added the part of these modules yet.
> > But the firmware was changed. So when using the new firmware, the module
> > cannot be identified due to incorrect length of mailbox buffer.
> 
> And with old firmware? Can you tell the end of the message has not
> been filled in with old firmware?

The old firmware has not been released to the public, so there is no need
to worry about the compatibility on the old firmware.

Re: [PATCH net-next 1/3] net: txgbe: expend SW-FW mailbox buffer size to identify QSFP module

[Andrew Lunn]

> The old firmware has not been released to the public, so there is no need
> to worry about the compatibility on the old firmware.

Please add this to the commit message.

Once firmware is out in the wild, you need to consider backwards
compatibility. As reviewers, it is something we look at. So you can
save us time and effort by saying backwards compatibility is not
required because ...

	Andrew

[PATCH net-next 2/3] net: txgbe: optimize the flow to setup PHY for AML devices

[Jiawen Wu]

To adapt to new firmware for AML devices, the driver should send the
"SET_LINK_CMD" to the firmware only once when switching PHY interface
mode. And the unknown link speed is permitted in the mailbox buffer. The
firmware will configure the PHY completely when the conditions are met.

Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
---
 drivers/net/ethernet/wangxun/libwx/wx_type.h  |  2 -
 .../net/ethernet/wangxun/txgbe/txgbe_aml.c    | 50 ++++++-------------
 .../net/ethernet/wangxun/txgbe/txgbe_type.h   |  1 +
 3 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/drivers/net/ethernet/wangxun/libwx/wx_type.h b/drivers/net/ethernet/wangxun/libwx/wx_type.h
index d89b9b8a0a2c..4880268b620e 100644
--- a/drivers/net/ethernet/wangxun/libwx/wx_type.h
+++ b/drivers/net/ethernet/wangxun/libwx/wx_type.h
@@ -1271,8 +1271,6 @@ struct wx {
 
 	/* PHY stuff */
 	bool notify_down;
-	int adv_speed;
-	int adv_duplex;
 	unsigned int link;
 	int speed;
 	int duplex;
diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
index dc87ccad9652..1da92431c324 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
@@ -19,8 +19,8 @@ void txgbe_gpio_init_aml(struct wx *wx)
 {
 	u32 status;
 
-	wr32(wx, WX_GPIO_INTTYPE_LEVEL, TXGBE_GPIOBIT_2 | TXGBE_GPIOBIT_3);
-	wr32(wx, WX_GPIO_INTEN, TXGBE_GPIOBIT_2 | TXGBE_GPIOBIT_3);
+	wr32(wx, WX_GPIO_INTTYPE_LEVEL, TXGBE_GPIOBIT_2);
+	wr32(wx, WX_GPIO_INTEN, TXGBE_GPIOBIT_2);
 
 	status = rd32(wx, WX_GPIO_INTSTATUS);
 	for (int i = 0; i < 6; i++) {
@@ -42,11 +42,6 @@ irqreturn_t txgbe_gpio_irq_handler_aml(int irq, void *data)
 		wr32(wx, WX_GPIO_EOI, TXGBE_GPIOBIT_2);
 		wx_service_event_schedule(wx);
 	}
-	if (status & TXGBE_GPIOBIT_3) {
-		set_bit(WX_FLAG_NEED_LINK_CONFIG, wx->flags);
-		wx_service_event_schedule(wx);
-		wr32(wx, WX_GPIO_EOI, TXGBE_GPIOBIT_3);
-	}
 
 	wr32(wx, WX_GPIO_INTMASK, 0);
 	return IRQ_HANDLED;
@@ -96,6 +91,9 @@ static int txgbe_set_phy_link_hostif(struct wx *wx, int speed, int autoneg, int
 	case SPEED_10000:
 		buffer.speed = TXGBE_LINK_SPEED_10GB_FULL;
 		break;
+	default:
+		buffer.speed = TXGBE_LINK_SPEED_UNKNOWN;
+		break;
 	}
 
 	buffer.fec_mode = TXGBE_PHY_FEC_AUTO;
@@ -106,19 +104,18 @@ static int txgbe_set_phy_link_hostif(struct wx *wx, int speed, int autoneg, int
 					 WX_HI_COMMAND_TIMEOUT, true);
 }
 
-static void txgbe_get_link_capabilities(struct wx *wx)
+static void txgbe_get_link_capabilities(struct wx *wx, int *speed, int *duplex)
 {
 	struct txgbe *txgbe = wx->priv;
 
 	if (test_bit(PHY_INTERFACE_MODE_25GBASER, txgbe->sfp_interfaces))
-		wx->adv_speed = SPEED_25000;
+		*speed = SPEED_25000;
 	else if (test_bit(PHY_INTERFACE_MODE_10GBASER, txgbe->sfp_interfaces))
-		wx->adv_speed = SPEED_10000;
+		*speed = SPEED_10000;
 	else
-		wx->adv_speed = SPEED_UNKNOWN;
+		*speed = SPEED_UNKNOWN;
 
-	wx->adv_duplex = wx->adv_speed == SPEED_UNKNOWN ?
-			 DUPLEX_HALF : DUPLEX_FULL;
+	*duplex = *speed == SPEED_UNKNOWN ? DUPLEX_HALF : DUPLEX_FULL;
 }
 
 static void txgbe_get_phy_link(struct wx *wx, int *speed)
@@ -138,23 +135,11 @@ static void txgbe_get_phy_link(struct wx *wx, int *speed)
 
 int txgbe_set_phy_link(struct wx *wx)
 {
-	int speed, err;
-	u32 gpio;
+	int speed, duplex, err;
 
-	/* Check RX signal */
-	gpio = rd32(wx, WX_GPIO_EXT);
-	if (gpio & TXGBE_GPIOBIT_3)
-		return -ENODEV;
+	txgbe_get_link_capabilities(wx, &speed, &duplex);
 
-	txgbe_get_link_capabilities(wx);
-	if (wx->adv_speed == SPEED_UNKNOWN)
-		return -ENODEV;
-
-	txgbe_get_phy_link(wx, &speed);
-	if (speed == wx->adv_speed)
-		return 0;
-
-	err = txgbe_set_phy_link_hostif(wx, wx->adv_speed, 0, wx->adv_duplex);
+	err = txgbe_set_phy_link_hostif(wx, speed, 0, duplex);
 	if (err) {
 		wx_err(wx, "Failed to setup link\n");
 		return err;
@@ -230,14 +215,7 @@ int txgbe_identify_sfp(struct wx *wx)
 		return -ENODEV;
 	}
 
-	err = txgbe_sfp_to_linkmodes(wx, id);
-	if (err)
-		return err;
-
-	if (gpio & TXGBE_GPIOBIT_3)
-		set_bit(WX_FLAG_NEED_LINK_CONFIG, wx->flags);
-
-	return 0;
+	return txgbe_sfp_to_linkmodes(wx, id);
 }
 
 void txgbe_setup_link(struct wx *wx)
diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
index 9d53c7413f7b..b9a4ba48f5b9 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
@@ -314,6 +314,7 @@ void txgbe_up(struct wx *wx);
 int txgbe_setup_tc(struct net_device *dev, u8 tc);
 void txgbe_do_reset(struct net_device *netdev);
 
+#define TXGBE_LINK_SPEED_UNKNOWN        0
 #define TXGBE_LINK_SPEED_10GB_FULL      4
 #define TXGBE_LINK_SPEED_25GB_FULL      0x10
 
-- 
2.48.1

Re: [PATCH net-next 2/3] net: txgbe: optimize the flow to setup PHY for AML devices

[Jakub Kicinski]

On Sun, 28 Sep 2025 17:39:22 +0800 Jiawen Wu wrote:
> To adapt to new firmware for AML devices, the driver should send the
> "SET_LINK_CMD" to the firmware only once when switching PHY interface
> mode. And the unknown link speed is permitted in the mailbox buffer. The
> firmware will configure the PHY completely when the conditions are met.

Could you mention what the TXGBE_GPIOBIT_3 does, since you're removing
it all over the place?

RE: [PATCH net-next 2/3] net: txgbe: optimize the flow to setup PHY for AML devices

[Jiawen Wu]

On Tue, Sep 30, 2025 9:40 AM, Jakub Kicinski wrote:
> On Sun, 28 Sep 2025 17:39:22 +0800 Jiawen Wu wrote:
> > To adapt to new firmware for AML devices, the driver should send the
> > "SET_LINK_CMD" to the firmware only once when switching PHY interface
> > mode. And the unknown link speed is permitted in the mailbox buffer. The
> > firmware will configure the PHY completely when the conditions are met.
> 
> Could you mention what the TXGBE_GPIOBIT_3 does, since you're removing
> it all over the place?

Okay. It is used for RX signal, which indicate that PHY should be re-configured.
Now we remove it from the driver, let the firmware to configure PHY completely.

Re: [PATCH net-next 2/3] net: txgbe: optimize the flow to setup PHY for AML devices

[Andrew Lunn]

On Fri, Oct 10, 2025 at 03:48:57PM +0800, Jiawen Wu wrote:
> On Tue, Sep 30, 2025 9:40 AM, Jakub Kicinski wrote:
> > On Sun, 28 Sep 2025 17:39:22 +0800 Jiawen Wu wrote:
> > > To adapt to new firmware for AML devices, the driver should send the
> > > "SET_LINK_CMD" to the firmware only once when switching PHY interface
> > > mode. And the unknown link speed is permitted in the mailbox buffer. The
> > > firmware will configure the PHY completely when the conditions are met.
> > 
> > Could you mention what the TXGBE_GPIOBIT_3 does, since you're removing
> > it all over the place?
> 
> Okay. It is used for RX signal, which indicate that PHY should be re-configured.
> Now we remove it from the driver, let the firmware to configure PHY completely.

Does this rely on new firmware? Or has the firmware always configured
the PHY, and then the driver reconfigures it?

	Andrew

RE: [PATCH net-next 2/3] net: txgbe: optimize the flow to setup PHY for AML devices

[Jiawen Wu]

On Fri, Oct 10, 2025 9:52 PM, Andrew Lunn wrote:
> On Fri, Oct 10, 2025 at 03:48:57PM +0800, Jiawen Wu wrote:
> > On Tue, Sep 30, 2025 9:40 AM, Jakub Kicinski wrote:
> > > On Sun, 28 Sep 2025 17:39:22 +0800 Jiawen Wu wrote:
> > > > To adapt to new firmware for AML devices, the driver should send the
> > > > "SET_LINK_CMD" to the firmware only once when switching PHY interface
> > > > mode. And the unknown link speed is permitted in the mailbox buffer. The
> > > > firmware will configure the PHY completely when the conditions are met.
> > >
> > > Could you mention what the TXGBE_GPIOBIT_3 does, since you're removing
> > > it all over the place?
> >
> > Okay. It is used for RX signal, which indicate that PHY should be re-configured.
> > Now we remove it from the driver, let the firmware to configure PHY completely.
> 
> Does this rely on new firmware? Or has the firmware always configured
> the PHY, and then the driver reconfigures it?

Driver does not configure PHY, it just send the command to firmware when
switching PHY interface. For the old firmware,  the PHY is configured only when
"SET_LINK_CMD" is received. But the PHY would not be completely configured if RX
signal lost. So the driver will send the command when TXGBE_GPIOBIT_3 interrupt
occurs. For the new firmware, it will automatically configure PHY when RX signal
arrives.

[PATCH net-next 3/3] net: txgbe: rename txgbe_get_phy_link()

[Jiawen Wu]

The function txgbe_get_phy_link() is more appropriately named
txgbe_get_mac_link(), since it reads the link status from the MAC
register.

Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
---
 drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
index 1da92431c324..35eebdb07761 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
@@ -118,7 +118,7 @@ static void txgbe_get_link_capabilities(struct wx *wx, int *speed, int *duplex)
 	*duplex = *speed == SPEED_UNKNOWN ? DUPLEX_HALF : DUPLEX_FULL;
 }
 
-static void txgbe_get_phy_link(struct wx *wx, int *speed)
+static void txgbe_get_mac_link(struct wx *wx, int *speed)
 {
 	u32 status;
 
@@ -234,7 +234,7 @@ static void txgbe_get_link_state(struct phylink_config *config,
 	struct wx *wx = phylink_to_wx(config);
 	int speed;
 
-	txgbe_get_phy_link(wx, &speed);
+	txgbe_get_mac_link(wx, &speed);
 	state->link = speed != SPEED_UNKNOWN;
 	state->speed = speed;
 	state->duplex = state->link ? DUPLEX_FULL : DUPLEX_UNKNOWN;
-- 
2.48.1