[net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

[net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

[Christian Marangi]

This is a new variant of the previous submitted patch adding a similar
feature.

Old Aeonsemi Firmware permitted only to enable or disable In Band
support and it couldn't be disabled after (or there wasn't a
way to detect the current state of it)

As suggested by Russell this was bad Implementation. Some talk
with Aeonsemi permitted to release a new firmware with correct
implementation.

This series adds support for this if new firmware (1.9.1+) is
used. On the new firmware, 2 new IPC command are introduced
to GET the current state of DPC RA (Rate Adaption) or SET it.
(DPC RA is effectively In Band mode)

It was verified on the same scenario and can confirm it works
as expected. (Airoha AN7581/AN7583 with and without In Band
mode) (If PCS is set to In Band and PHY isn't then no
connection, so it's easy to verify correct functionality of
this)

The new firmware is currently submitted to linux-firmware
awaiting it to be merged.

For old firmware to save on compatibility we still enable
In Band by default (this is what the current driver do)

This was discovered to be needed in some scenario as is effectively
the most compatible featureset.

On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to
one of the Switch port and such switch supports only In Band when
set to USXGMII (assuming the Switch expect an SFP module to be
attached where in absence of i2c or MDIO line In Band is always
required)

Changes v2:
- Rework to new firmware version IPC command
- Add DBG IPC command
- Store FW major/minor version

Christian Marangi (3):
  net: phy: as21xxx: save firmware version major/minor version
  net: phy: as21xxx: add support for DBG command
  net: phy: as21xxx: fill in inband caps and better handle inband

 drivers/net/phy/as21xxx.c | 316 +++++++++++++++++++++++++++++++++-----
 1 file changed, 280 insertions(+), 36 deletions(-)

-- 
2.51.0

[net-next PATCH v2 1/3] net: phy: as21xxx: save firmware version major/minor version

[Christian Marangi]

On PHY probe, save the firmware version major/minor version to use it
later to validate if a command is supported in the loaded firmware.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/net/phy/as21xxx.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/phy/as21xxx.c b/drivers/net/phy/as21xxx.c
index 005277360656..a5344abde91a 100644
--- a/drivers/net/phy/as21xxx.c
+++ b/drivers/net/phy/as21xxx.c
@@ -183,6 +183,9 @@ struct as21xxx_led_pattern_info {
 };
 
 struct as21xxx_priv {
+	u8 fw_major_ver;
+	u8 fw_minor_ver;
+
 	bool parity_status;
 	/* Protect concurrent IPC access */
 	struct mutex ipc_lock;
@@ -570,6 +573,7 @@ static int aeon_ipc_sync_parity(struct phy_device *phydev,
 static int aeon_ipc_get_fw_version(struct phy_device *phydev)
 {
 	u16 ret_data[AEON_IPC_DATA_NUM_REGISTERS], data[1];
+	struct as21xxx_priv *priv = phydev->priv;
 	char fw_version[AEON_IPC_DATA_MAX + 1];
 	int ret;
 
@@ -585,6 +589,17 @@ static int aeon_ipc_get_fw_version(struct phy_device *phydev)
 	fw_version[ret] = '\0';
 
 	phydev_info(phydev, "Firmware Version: %s\n", fw_version);
+	/*
+	 * Firmware is the format x.x.x
+	 * Save in priv struct to check validate feature support
+	 * in new firmware version.
+	 */
+	ret = sscanf(fw_version, "%hhu.%hhu", &priv->fw_major_ver,
+		     &priv->fw_minor_ver);
+	if (ret < 2) {
+		priv->fw_major_ver = 0;
+		priv->fw_minor_ver = 0;
+	}
 
 	return 0;
 }
-- 
2.51.0

[net-next PATCH v2 2/3] net: phy: as21xxx: add support for DBG command

[Christian Marangi]

Rework the msg send logic to support sending DBG command.

These DBG command use a special way to send and receive data and use
data in u8 size and are used to tweak advanced (and later introduced)
feature of the PHY.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/net/phy/as21xxx.c | 190 +++++++++++++++++++++++++++++++-------
 1 file changed, 155 insertions(+), 35 deletions(-)

diff --git a/drivers/net/phy/as21xxx.c b/drivers/net/phy/as21xxx.c
index a5344abde91a..2098fa6a2f63 100644
--- a/drivers/net/phy/as21xxx.c
+++ b/drivers/net/phy/as21xxx.c
@@ -59,6 +59,10 @@
 #define IPC_CMD_SYS_CPU			0x2  /* SYS_CPU */
 #define IPC_CMD_BULK_DATA		0xa  /* Pass bulk data in ipc registers. */
 #define IPC_CMD_BULK_WRITE		0xc  /* Write bulk data to memory */
+#define IPC_CMD_DBG			0x16
+#define IPC_CMD_POLL			0x17
+#define IPC_CMD_WRITE_BUF		0x18
+#define IPC_CMD_READ_BUF		0x19
 #define IPC_CMD_CFG_PARAM		0x1a /* Write config parameters to memory */
 #define IPC_CMD_NG_TESTMODE		0x1b /* Set NG test mode and tone */
 #define IPC_CMD_TEMP_MON		0x15 /* Temperature monitoring function */
@@ -115,6 +119,12 @@
 /* Sub command of CMD_TEMP_MON */
 #define IPC_CMD_TEMP_MON_GET		0x4
 
+/* Sub command of CMD_DBG */
+#define IPC_DBG_DPC			0x8b
+
+#define IPC_DATA_DBG_SEC		GENMASK(15, 8)
+#define IPC_DATA_DBG_CMD		GENMASK(7, 0)
+
 #define AS21XXX_MDIO_AN_C22		0xffe0
 
 #define PHY_ID_AS21XXX			0x75009410
@@ -451,18 +461,9 @@ static int aeon_ipc_send_cmd(struct phy_device *phydev,
 	return 0;
 }
 
-/* If data is NULL, return 0 or negative error.
- * If data not NULL, return number of Bytes received from IPC or
- * a negative error.
- */
-static int aeon_ipc_send_msg(struct phy_device *phydev,
-			     u16 opcode, u16 *data, unsigned int data_len,
-			     u16 *ret_data)
+static int aeon_ipc_set_msg_data(struct phy_device *phydev, u16 *data,
+				 unsigned int data_len)
 {
-	struct as21xxx_priv *priv = phydev->priv;
-	unsigned int ret_size;
-	u16 cmd, ret_sts;
-	int ret;
 	int i;
 
 	/* IPC have a max of 8 register to transfer data,
@@ -475,46 +476,69 @@ static int aeon_ipc_send_msg(struct phy_device *phydev,
 		phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_DATA(i),
 			      data[i]);
 
-	cmd = FIELD_PREP(AEON_IPC_CMD_SIZE, data_len) |
-	      FIELD_PREP(AEON_IPC_CMD_OPCODE, opcode);
-
-	mutex_lock(&priv->ipc_lock);
-
-	ret = aeon_ipc_send_cmd(phydev, priv, cmd, &ret_sts);
-	if (ret) {
-		phydev_err(phydev, "failed to send ipc msg for %x: %d\n",
-			   opcode, ret);
-		goto out;
-	}
-
-	if (!data)
-		goto out;
+	return 0;
+}
 
-	if ((ret_sts & AEON_IPC_STS_STATUS) == AEON_IPC_STS_STATUS_ERROR) {
-		ret = -EINVAL;
-		goto out;
-	}
+static int
+aeon_ipc_get_msg_ret_data(struct phy_device *phydev, u16 ret_sts,
+			  u16 *ret_data) __must_hold(&priv->ipc_lock)
+{
+	unsigned int ret_size;
+	int ret;
+	int i;
 
 	/* Prevent IPC from stack smashing the kernel.
 	 * We can't trust IPC to return a good value and we always
 	 * preallocate space for 16 Bytes.
 	 */
 	ret_size = FIELD_GET(AEON_IPC_STS_SIZE, ret_sts);
-	if (ret_size > AEON_IPC_DATA_MAX) {
-		ret = -EINVAL;
-		goto out;
-	}
+	if (ret_size > AEON_IPC_DATA_MAX)
+		return -EINVAL;
 
 	/* Read data from IPC data register for ret_size value from IPC */
 	for (i = 0; i < DIV_ROUND_UP(ret_size, sizeof(u16)); i++) {
 		ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_IPC_DATA(i));
 		if (ret < 0)
-			goto out;
+			return ret;
 
 		ret_data[i] = ret;
 	}
 
-	ret = ret_size;
+	return ret_size;
+}
+
+/* If data is NULL, return 0 or negative error.
+ * If data not NULL, return number of Bytes received from IPC or
+ * a negative error.
+ */
+static int aeon_ipc_send_msg(struct phy_device *phydev,
+			     u16 opcode, u16 *data, unsigned int data_len,
+			     u16 *ret_data)
+{
+	struct as21xxx_priv *priv = phydev->priv;
+	u16 cmd, ret_sts;
+	int ret;
+
+	ret = aeon_ipc_set_msg_data(phydev, data, data_len);
+	if (ret)
+		return ret;
+
+	cmd = FIELD_PREP(AEON_IPC_CMD_SIZE, data_len) |
+	      FIELD_PREP(AEON_IPC_CMD_OPCODE, opcode);
+
+	mutex_lock(&priv->ipc_lock);
+
+	ret = aeon_ipc_send_cmd(phydev, priv, cmd, &ret_sts);
+	if (ret) {
+		phydev_err(phydev, "failed to send ipc msg for %x: %d\n",
+			   opcode, ret);
+		goto out;
+	}
+
+	if (!data)
+		goto out;
+
+	ret = aeon_ipc_get_msg_ret_data(phydev, ret_sts, ret_data);
 
 out:
 	mutex_unlock(&priv->ipc_lock);
@@ -604,6 +628,102 @@ static int aeon_ipc_get_fw_version(struct phy_device *phydev)
 	return 0;
 }
 
+static int aeon_ipc_poll(struct phy_device *phydev)
+{
+	struct as21xxx_priv *priv = phydev->priv;
+	u16 ret_sts;
+	u16 cmd;
+	int ret;
+
+	cmd = FIELD_PREP(AEON_IPC_CMD_SIZE, 0) |
+	      FIELD_PREP(AEON_IPC_CMD_OPCODE, IPC_CMD_POLL);
+
+	mutex_lock(&priv->ipc_lock);
+
+	ret = aeon_ipc_send_cmd(phydev, phydev->priv, cmd, &ret_sts);
+	if (ret)
+		phydev_err(phydev, "Invalid IPC status on IPC poll: %x\n",
+			   ret_sts);
+
+	mutex_unlock(&priv->ipc_lock);
+
+	return ret;
+}
+
+static int aeon_ipc_dbg_cmd(struct phy_device *phydev, u16 dbg_sec,
+			    u16 dbg_cmd, u16 msg_size)
+{
+	u16 data[3];
+
+	data[0] = FIELD_PREP(IPC_DATA_DBG_SEC, dbg_sec) |
+		  FIELD_PREP(IPC_DATA_DBG_CMD, dbg_cmd);
+	data[1] = msg_size;
+
+	return aeon_ipc_send_msg(phydev, IPC_CMD_DBG, data,
+				 sizeof(data), NULL);
+}
+
+static int aeon_ipc_dbg_read_buf(struct phy_device *phydev, u16 *buf)
+{
+	struct as21xxx_priv *priv = phydev->priv;
+	u16 cmd, ret_sts;
+	int ret;
+
+	cmd = FIELD_PREP(AEON_IPC_CMD_SIZE, 0) |
+	      FIELD_PREP(AEON_IPC_CMD_OPCODE, IPC_CMD_READ_BUF);
+
+	mutex_lock(&priv->ipc_lock);
+
+	ret = aeon_ipc_send_cmd(phydev, phydev->priv, cmd, &ret_sts);
+	if (ret)
+		goto out;
+
+	ret = aeon_ipc_get_msg_ret_data(phydev, ret_sts, buf);
+
+out:
+	mutex_unlock(&priv->ipc_lock);
+
+	return ret;
+}
+
+static int aeon_ipc_dbg_write_buf(struct phy_device *phydev, u8 *data,
+				  u8 data_len)
+{
+	u16 msg_data[AEON_IPC_DATA_NUM_REGISTERS];
+	struct as21xxx_priv *priv = phydev->priv;
+	u16 cmd, ret_sts;
+	int ret;
+	int i;
+
+	/* Make sure we don't try to write more data than supported */
+	if (data_len * 2 > AEON_IPC_DATA_MAX)
+		return -EINVAL;
+
+	/* Pack u8 DBG data in u16 buffer */
+	for (i = 0; i < data_len; i += 2) {
+		msg_data[i] = data[i];
+		msg_data[i] |= data[i + 1] << 8;
+	}
+
+	ret = aeon_ipc_set_msg_data(phydev, msg_data, data_len * 2);
+	if (ret)
+		return ret;
+
+	cmd = FIELD_PREP(AEON_IPC_CMD_SIZE, data_len) |
+	      FIELD_PREP(AEON_IPC_CMD_OPCODE, IPC_CMD_WRITE_BUF);
+
+	mutex_lock(&priv->ipc_lock);
+
+	ret = aeon_ipc_send_cmd(phydev, priv, cmd, &ret_sts);
+	if (ret)
+		phydev_err(phydev, "failed to send IPC msg for %x: %d\n",
+			   IPC_CMD_WRITE_BUF, ret);
+
+	mutex_unlock(&priv->ipc_lock);
+
+	return ret;
+}
+
 static int aeon_dpc_ra_enable(struct phy_device *phydev)
 {
 	u16 data[2];
-- 
2.51.0

[net-next PATCH v2 3/3] net: phy: as21xxx: fill in inband caps and better handle inband

[Christian Marangi]

The as21xxx control In-Band support with the DPC RateAdapation
configuration.

Tested on a Banana Pi R4 PRO (MT7988a) and on Airoha AN7581/AN7583 where
In Band is controlled by disabling Autoneg on the PCS, where the PHY
correctly transfer packet with In Band disabled on the PCS and DPC RA
disabled on the PHY. It was also confirmed that with In Band enabled on
the PCS and DPC RA enabled on the PHY also packets gets transmitted
correctly.

With this new information, fill in the .inband_caps() OP and set the
.config_inband() to enable DPC RA when inband is enabled.

Support for this feature is enabled only on PHY firmware >= 1.9 as on
previous version the DPC RA could only be enabled and a PHY reset (and
Firmware reloaded) was needed to change this at runtime.

To keep compatibility with some HW configuration, we enable DPC RA by
default for older firmware. This is needed as on Banana Pi R4 PRO, one
of the 2 as21xxx PHY is attached to a Switch that requires the PHY in In
Band mode with Rate Adaption.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/net/phy/as21xxx.c | 111 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/as21xxx.c b/drivers/net/phy/as21xxx.c
index 2098fa6a2f63..60ec7af6e386 100644
--- a/drivers/net/phy/as21xxx.c
+++ b/drivers/net/phy/as21xxx.c
@@ -125,6 +125,10 @@
 #define IPC_DATA_DBG_SEC		GENMASK(15, 8)
 #define IPC_DATA_DBG_CMD		GENMASK(7, 0)
 
+/* DBG_DPC sub command */
+#define IPC_DPC_RA_SET_CFG		0x2
+#define IPC_DPC_RA_GET_CFG		0x7
+
 #define AS21XXX_MDIO_AN_C22		0xffe0
 
 #define PHY_ID_AS21XXX			0x75009410
@@ -724,6 +728,52 @@ static int aeon_ipc_dbg_write_buf(struct phy_device *phydev, u8 *data,
 	return ret;
 }
 
+static int aeon_ipc_dpc_ra_set(struct phy_device *phydev, bool enable)
+{
+	u8 data[1];
+	int ret;
+
+	ret = aeon_ipc_dbg_cmd(phydev, IPC_DBG_DPC,
+			       IPC_DPC_RA_SET_CFG,
+			       sizeof(data));
+	if (ret)
+		return ret;
+
+	data[0] = enable;
+
+	ret = aeon_ipc_dbg_write_buf(phydev, data, sizeof(data));
+	if (ret)
+		return ret;
+
+	ret = aeon_ipc_poll(phydev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int aeon_ipc_dpc_ra_get(struct phy_device *phydev, bool *enabled)
+{
+	u16 ret_data[AEON_IPC_DATA_NUM_REGISTERS];
+	int ret;
+
+	ret = aeon_ipc_dbg_cmd(phydev, IPC_DBG_DPC,
+			       IPC_DPC_RA_GET_CFG, 0);
+	if (ret)
+		return ret;
+
+	ret = aeon_ipc_poll(phydev);
+	if (ret)
+		return ret;
+
+	ret = aeon_ipc_dbg_read_buf(phydev, ret_data);
+	if (ret < 0)
+		return ret;
+
+	*enabled = !!ret_data[0];
+	return 0;
+}
+
 static int aeon_dpc_ra_enable(struct phy_device *phydev)
 {
 	u16 data[2];
@@ -765,7 +815,11 @@ static int as21xxx_probe(struct phy_device *phydev)
 	if (ret)
 		return ret;
 
-	return aeon_dpc_ra_enable(phydev);
+	/* Enable DPC Rate Adaption by default on older firmware */
+	if (priv->fw_major_ver == 1 && priv->fw_minor_ver < 9)
+		return aeon_dpc_ra_enable(phydev);
+
+	return 0;
 }
 
 static int as21xxx_read_link(struct phy_device *phydev, int *bmcr)
@@ -1078,6 +1132,41 @@ static int as21xxx_match_phy_device(struct phy_device *phydev,
 	return ret;
 }
 
+static unsigned int as21xxx_inband_caps(struct phy_device *phydev,
+					phy_interface_t interface)
+{
+	struct as21xxx_priv *priv = phydev->priv;
+
+	/* Configuring DPC Rate Adaption (to permit In Band support)
+	 * is supported only from firmware version 1.9+
+	 */
+	if (priv->fw_major_ver > 1 || priv->fw_minor_ver >= 9)
+		return LINK_INBAND_ENABLE | LINK_INBAND_DISABLE;
+
+	/* On older firmware we enforce In Band by default
+	 * for compatibility reason.
+	 */
+	return LINK_INBAND_ENABLE;
+}
+
+static int as21xxx_config_inband(struct phy_device *phydev,
+				 unsigned int modes)
+{
+	bool enabled;
+	int ret;
+
+	ret = aeon_ipc_dpc_ra_get(phydev, &enabled);
+	if (ret)
+		return ret;
+
+	/* Ignore if already in the desired mode */
+	if ((modes == LINK_INBAND_ENABLE && enabled) ||
+	    (modes == LINK_INBAND_DISABLE && !enabled))
+		return 0;
+
+	return aeon_ipc_dpc_ra_set(phydev, modes == LINK_INBAND_ENABLE);
+}
+
 static struct phy_driver as21xxx_drivers[] = {
 	{
 		/* PHY expose in C45 as 0x7500 0x9410
@@ -1093,6 +1182,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21011JB1),
 		.name		= "Aeonsemi AS21011JB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1105,6 +1196,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21011PB1),
 		.name		= "Aeonsemi AS21011PB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1117,6 +1210,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21010PB1),
 		.name		= "Aeonsemi AS21010PB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1129,6 +1224,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21010JB1),
 		.name		= "Aeonsemi AS21010JB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1141,6 +1238,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21210PB1),
 		.name		= "Aeonsemi AS21210PB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1153,6 +1252,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21510JB1),
 		.name		= "Aeonsemi AS21510JB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1165,6 +1266,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21510PB1),
 		.name		= "Aeonsemi AS21510PB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1177,6 +1280,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21511JB1),
 		.name		= "Aeonsemi AS21511JB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1189,6 +1294,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21210JB1),
 		.name		= "Aeonsemi AS21210JB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
@@ -1201,6 +1308,8 @@ static struct phy_driver as21xxx_drivers[] = {
 		PHY_ID_MATCH_EXACT(PHY_ID_AS21511PB1),
 		.name		= "Aeonsemi AS21511PB1",
 		.probe		= as21xxx_probe,
+		.inband_caps	= as21xxx_inband_caps,
+		.config_inband	= as21xxx_config_inband,
 		.match_phy_device = as21xxx_match_phy_device,
 		.read_status	= as21xxx_read_status,
 		.led_brightness_set = as21xxx_led_brightness_set,
-- 
2.51.0

Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

[Russell King (Oracle)]

[Please note: gmail.com has become unreliable for email delivery,
google has too much power to decide what is spam and what isn't, with
no route for appeal. please consider switching to a different email
provider.]

On Fri, Jan 23, 2026 at 01:00:28PM +0100, Christian Marangi wrote:
> This is a new variant of the previous submitted patch adding a similar
> feature.
> 
> Old Aeonsemi Firmware permitted only to enable or disable In Band
> support and it couldn't be disabled after (or there wasn't a
> way to detect the current state of it)
> 
> As suggested by Russell this was bad Implementation. Some talk
> with Aeonsemi permitted to release a new firmware with correct
> implementation.
> 
> This series adds support for this if new firmware (1.9.1+) is
> used. On the new firmware, 2 new IPC command are introduced
> to GET the current state of DPC RA (Rate Adaption) or SET it.
> (DPC RA is effectively In Band mode)
> 
> It was verified on the same scenario and can confirm it works
> as expected. (Airoha AN7581/AN7583 with and without In Band
> mode) (If PCS is set to In Band and PHY isn't then no
> connection, so it's easy to verify correct functionality of
> this)
> 
> The new firmware is currently submitted to linux-firmware
> awaiting it to be merged.
> 
> For old firmware to save on compatibility we still enable
> In Band by default (this is what the current driver do)
> 
> This was discovered to be needed in some scenario as is effectively
> the most compatible featureset.
> 
> On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to
> one of the Switch port and such switch supports only In Band when
> set to USXGMII (assuming the Switch expect an SFP module to be
> attached where in absence of i2c or MDIO line In Band is always
> required)

Coupling the PHY's rate adaption with inband support, but not setting
phydev->rate_matching anywhere in this driver seems wrong, and highly
suspicious. I'm not sure what to think given what you've said above,
it just seems completely wrong what has happened here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

[Christian Marangi]

On Fri, Jan 23, 2026 at 12:16:45PM +0000, Russell King (Oracle) wrote:
> [Please note: gmail.com has become unreliable for email delivery,
> google has too much power to decide what is spam and what isn't, with
> no route for appeal. please consider switching to a different email
> provider.]
>

Thanks for reporting this. I'm also noticing for a while some legit
email from mailing list going to spam. I have a new mail from a long
time but never took the time to actually made the switch for kernel
submission. Also it's mostly new so I guess it needs to earn some cretis
as it will get directly rejected by some service. Chicken Egg problem...

> On Fri, Jan 23, 2026 at 01:00:28PM +0100, Christian Marangi wrote:
> > This is a new variant of the previous submitted patch adding a similar
> > feature.
> > 
> > Old Aeonsemi Firmware permitted only to enable or disable In Band
> > support and it couldn't be disabled after (or there wasn't a
> > way to detect the current state of it)
> > 
> > As suggested by Russell this was bad Implementation. Some talk
> > with Aeonsemi permitted to release a new firmware with correct
> > implementation.
> > 
> > This series adds support for this if new firmware (1.9.1+) is
> > used. On the new firmware, 2 new IPC command are introduced
> > to GET the current state of DPC RA (Rate Adaption) or SET it.
> > (DPC RA is effectively In Band mode)
> > 
> > It was verified on the same scenario and can confirm it works
> > as expected. (Airoha AN7581/AN7583 with and without In Band
> > mode) (If PCS is set to In Band and PHY isn't then no
> > connection, so it's easy to verify correct functionality of
> > this)
> > 
> > The new firmware is currently submitted to linux-firmware
> > awaiting it to be merged.
> > 
> > For old firmware to save on compatibility we still enable
> > In Band by default (this is what the current driver do)
> > 
> > This was discovered to be needed in some scenario as is effectively
> > the most compatible featureset.
> > 
> > On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to
> > one of the Switch port and such switch supports only In Band when
> > set to USXGMII (assuming the Switch expect an SFP module to be
> > attached where in absence of i2c or MDIO line In Band is always
> > required)
> 
> Coupling the PHY's rate adaption with inband support, but not setting
> phydev->rate_matching anywhere in this driver seems wrong, and highly
> suspicious. I'm not sure what to think given what you've said above,
> it just seems completely wrong what has happened here.
> 

Honestly speaking the Rate Adaption thing is what I found in some
strange API c code on the downstream driver where they say that in
DPC_RA RA is Rate Adaption.

My personal idea is that, that thing toggle also other stuff and not only
Rate Adaption.

On the Airoha PCS In Band is controlled by enabling and disabling AN
register (and this also apply to Mediatek PCS)

With AN enabled, DPC RA needs to be enabled or no traffic.
With AN disabled, DPC RA needs to be disabled or not traffic.

This both apply to Airoha and Mediatek PCS.

For the Switch, it's a different story. Everything is controlled by a
Firmware blob and it's only possible to send command to setup the
Serdes mode (USXGMII in this case)
I made lots of test with forcing speed or trying to find a way to make
it work but the only combo I found working was USXGMII + DPC_RA enabled.

For the lack of .get_rate_matching should be set to RATE_MATCH_NONE
AFAIK for this PHY.

To give more info comments in the downstream driver at dpc_ra_enable
have "Set USXGMII mode.".
But I verified that PCS at USXGMII (but no In Band) and DPC_RA off
I have correct link up and traffic. So it's not dropping to 10g base-r
somehow with DPC_RA disabled and if it was the case the PCS should be
configured for that mode (there are specific register for that).

> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

-- 
	Ansuel

Re: [net-next PATCH v2 0/3] net: phy: as21xxx: toggle In Band feature support

[Russell King (Oracle)]

On Fri, Jan 23, 2026 at 02:09:01PM +0100, Christian Marangi wrote:
> On Fri, Jan 23, 2026 at 12:16:45PM +0000, Russell King (Oracle) wrote:
> > [Please note: gmail.com has become unreliable for email delivery,
> > google has too much power to decide what is spam and what isn't, with
> > no route for appeal. please consider switching to a different email
> > provider.]
> >
> 
> Thanks for reporting this. I'm also noticing for a while some legit
> email from mailing list going to spam. I have a new mail from a long
> time but never took the time to actually made the switch for kernel
> submission. Also it's mostly new so I guess it needs to earn some cretis
> as it will get directly rejected by some service. Chicken Egg problem...

It's worse than that. Google is permanently rejecting patch series from
me now - you won't even get it in your "spam" folder. This is only going
to get worse, because there is no way to appeal against this, and
domains such as my own, and even kernel.org, have to just suck it
because google has all the power due to its dominance, caused by people
using it.

The only solution to this is to stop using gmail, causing it to lose
market share.

> > On Fri, Jan 23, 2026 at 01:00:28PM +0100, Christian Marangi wrote:
> > > This is a new variant of the previous submitted patch adding a similar
> > > feature.
> > > 
> > > Old Aeonsemi Firmware permitted only to enable or disable In Band
> > > support and it couldn't be disabled after (or there wasn't a
> > > way to detect the current state of it)
> > > 
> > > As suggested by Russell this was bad Implementation. Some talk
> > > with Aeonsemi permitted to release a new firmware with correct
> > > implementation.
> > > 
> > > This series adds support for this if new firmware (1.9.1+) is
> > > used. On the new firmware, 2 new IPC command are introduced
> > > to GET the current state of DPC RA (Rate Adaption) or SET it.
> > > (DPC RA is effectively In Band mode)
> > > 
> > > It was verified on the same scenario and can confirm it works
> > > as expected. (Airoha AN7581/AN7583 with and without In Band
> > > mode) (If PCS is set to In Band and PHY isn't then no
> > > connection, so it's easy to verify correct functionality of
> > > this)
> > > 
> > > The new firmware is currently submitted to linux-firmware
> > > awaiting it to be merged.
> > > 
> > > For old firmware to save on compatibility we still enable
> > > In Band by default (this is what the current driver do)
> > > 
> > > This was discovered to be needed in some scenario as is effectively
> > > the most compatible featureset.
> > > 
> > > On a BananaPi R4 Pro, one of the 2 AS21xxx PHY is connected to
> > > one of the Switch port and such switch supports only In Band when
> > > set to USXGMII (assuming the Switch expect an SFP module to be
> > > attached where in absence of i2c or MDIO line In Band is always
> > > required)
> > 
> > Coupling the PHY's rate adaption with inband support, but not setting
> > phydev->rate_matching anywhere in this driver seems wrong, and highly
> > suspicious. I'm not sure what to think given what you've said above,
> > it just seems completely wrong what has happened here.
> > 
> 
> Honestly speaking the Rate Adaption thing is what I found in some
> strange API c code on the downstream driver where they say that in
> DPC_RA RA is Rate Adaption.
> 
> My personal idea is that, that thing toggle also other stuff and not only
> Rate Adaption.
> 
> On the Airoha PCS In Band is controlled by enabling and disabling AN
> register (and this also apply to Mediatek PCS)
> 
> With AN enabled, DPC RA needs to be enabled or no traffic.
> With AN disabled, DPC RA needs to be disabled or not traffic.
> 
> This both apply to Airoha and Mediatek PCS.
> 
> For the Switch, it's a different story. Everything is controlled by a
> Firmware blob and it's only possible to send command to setup the
> Serdes mode (USXGMII in this case)
> I made lots of test with forcing speed or trying to find a way to make
> it work but the only combo I found working was USXGMII + DPC_RA enabled.
> 
> For the lack of .get_rate_matching should be set to RATE_MATCH_NONE
> AFAIK for this PHY.
> 
> To give more info comments in the downstream driver at dpc_ra_enable
> have "Set USXGMII mode.".
> But I verified that PCS at USXGMII (but no In Band) and DPC_RA off
> I have correct link up and traffic. So it's not dropping to 10g base-r
> somehow with DPC_RA disabled and if it was the case the PCS should be
> configured for that mode (there are specific register for that).

Let me be clear: if the PHY hardware is doing rate adaption, then the
driver needs to be setting phydev->rate_matching accordingly when
reading the other media parameters from the PHY, so that other parts
of the system know that the media speed is not the speed that the
host interface to the PHY needs to operate at.

Only if the PHY is _not_ doing rate adaption, then setting it to
RATE_MATCH_NONE is appropriate. All other cases, it should be set
to one of the others.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [net-next PATCH v2 2/3] net: phy: as21xxx: add support for DBG command

[Jakub Kicinski]

On Fri, 23 Jan 2026 13:00:30 +0100 Christian Marangi wrote:
> Rework the msg send logic to support sending DBG command.
> 
> These DBG command use a special way to send and receive data and use
> data in u8 size and are used to tweak advanced (and later introduced)
> feature of the PHY.

Unfortunately we can't have unused static functions, even transiently:

drivers/net/phy/as21xxx.c:631:12: warning: unused function 'aeon_ipc_poll' [-Wunused-function]
  631 | static int aeon_ipc_poll(struct phy_device *phydev)
      |            ^~~~~~~~~~~~~
drivers/net/phy/as21xxx.c:653:12: warning: unused function 'aeon_ipc_dbg_cmd' [-Wunused-function]
  653 | static int aeon_ipc_dbg_cmd(struct phy_device *phydev, u16 dbg_sec,
      |            ^~~~~~~~~~~~~~~~
drivers/net/phy/as21xxx.c:666:12: warning: unused function 'aeon_ipc_dbg_read_buf' [-Wunused-function]
  666 | static int aeon_ipc_dbg_read_buf(struct phy_device *phydev, u16 *buf)
      |            ^~~~~~~~~~~~~~~~~~~~~
drivers/net/phy/as21xxx.c:689:12: warning: unused function 'aeon_ipc_dbg_write_buf' [-Wunused-function]
  689 | static int aeon_ipc_dbg_write_buf(struct phy_device *phydev, u8 *data,
      |            ^~~~~~~~~~~~~~~~~~~~~~
-- 
pw-bot: cr