[PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Choong Yong Liang]

Intel platforms’ integrated Gigabit Ethernet controllers support
2.5Gbps mode statically using BIOS programming. In the current
implementation, the BIOS menu provides an option to select between
10/100/1000Mbps and 2.5Gbps modes. Based on the selection, the BIOS
programs the Phase Lock Loop (PLL) registers. The BIOS also read the
TSN lane registers from Flexible I/O Adapter (FIA) block and provided
10/100/1000Mbps/2.5Gbps information to the stmmac driver. But
auto-negotiation between 10/100/1000Mbps and 2.5Gbps is not allowed.
The new proposal is to support auto-negotiation between 10/100/1000Mbps
and 2.5Gbps . Auto-negotiation between 10, 100, 1000Mbps will use
in-band auto negotiation. Auto-negotiation between 10/100/1000Mbps and
2.5Gbps will work as the following proposed flow, the stmmac driver reads
the PHY link status registers then identifies the negotiated speed.
Based on the speed stmmac driver will identify TSN lane registers from
FIA then send IPC command to the Power Management controller (PMC)
through PMC driver/API. PMC will act as a proxy to programs the
PLL registers.

changelog:
v1 -> v2: 
 - Created intel_pmc_core.h in include/linux/platform_data/x86/ and
 export the desired functionality.
 - Add cur_link_an_mode to the kernel doc
 - Update cfg_link_an_mode value during phy driver changed
 - Combine 2 commits i.e. "stmmac: intel: Separate driver_data of ADL-N
 from TGL" and "net: stmmac: Add 1G/2.5G auto-negotiation
 support for ADL-N" into 1 commit.


v1 -> v2: 
 - Add static to pmc_lpm_modes declaration
 - Add cur_link_an_mode to the kernel doc
 - Combine 2 commits i.e. "stmmac: intel: Separate driver_data of ADL-N
 from TGL" and "net: stmmac: Add 1G/2.5G auto-negotiation
 support for ADL-N" into 1 commit.
---
Choong Yong Liang (1):
  stmmac: intel: Add 1G/2.5G auto-negotiation support for ADL-N

David E. Box (1):
  platform/x86: intel_pmc_core: Add IPC mailbox accessor function and
    add SoC register access

Tan, Tee Min (3):
  net: pcs: xpcs: combine C37 SGMII AN and 2500BASEX for Intel mGbE
    controller
  net: phy: update in-band AN mode when changing interface by PHY driver
  net: stmmac: enable Intel mGbE 1G/2.5G auto-negotiation support

 MAINTAINERS                                   |   1 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |   1 +
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 183 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h |  81 ++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  20 ++
 drivers/net/pcs/pcs-xpcs.c                    |  72 +++++--
 drivers/net/phy/marvell10g.c                  |   6 +
 drivers/net/phy/phylink.c                     |   4 +
 drivers/platform/x86/intel/pmc/core.c         |  60 ++++++
 include/linux/pcs/pcs-xpcs.h                  |   1 +
 include/linux/phy.h                           |   3 +
 .../linux/platform_data/x86/intel_pmc_core.h  |  41 ++++
 include/linux/stmmac.h                        |   1 +
 13 files changed, 458 insertions(+), 16 deletions(-)
 create mode 100644 include/linux/platform_data/x86/intel_pmc_core.h

-- 
2.25.1

[PATCH net-next v2 1/5] platform/x86: intel_pmc_core: Add IPC mailbox accessor function and add SoC register access

[Choong Yong Liang]

From: "David E. Box" <david.e.box@linux.intel.com>

- Exports intel_pmc_core_ipc() for host access to the PMC IPC mailbox
- Add support to use IPC command allows host to access SoC registers
through PMC firmware that are otherwise inaccessible to the host due to
security policies.

Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Chao Qin <chao.qin@intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 MAINTAINERS                                   |  1 +
 drivers/platform/x86/intel/pmc/core.c         | 60 +++++++++++++++++++
 .../linux/platform_data/x86/intel_pmc_core.h  | 41 +++++++++++++
 3 files changed, 102 insertions(+)
 create mode 100644 include/linux/platform_data/x86/intel_pmc_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 069e176d607a..8a034dee9da9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10648,6 +10648,7 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Maintained
 F:	Documentation/ABI/testing/sysfs-platform-intel-pmc
 F:	drivers/platform/x86/intel/pmc/
+F:	linux/platform_data/x86/intel_pmc_core.h
 
 INTEL PMIC GPIO DRIVERS
 M:	Andy Shevchenko <andy@kernel.org>
diff --git a/drivers/platform/x86/intel/pmc/core.c b/drivers/platform/x86/intel/pmc/core.c
index 5a36b3f77bc5..6fb1b0f453d8 100644
--- a/drivers/platform/x86/intel/pmc/core.c
+++ b/drivers/platform/x86/intel/pmc/core.c
@@ -20,6 +20,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/suspend.h>
+#include <linux/platform_data/x86/intel_pmc_core.h>
 
 #include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
@@ -28,6 +29,8 @@
 
 #include "core.h"
 
+#define PMC_IPCS_PARAM_COUNT           7
+
 /* Maximum number of modes supported by platfoms that has low power mode capability */
 const char *pmc_lpm_modes[] = {
 	"S0i2.0",
@@ -53,6 +56,63 @@ const struct pmc_bit_map msr_map[] = {
 	{}
 };
 
+int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
+{
+	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object params[PMC_IPCS_PARAM_COUNT] = {
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+		{.type = ACPI_TYPE_INTEGER,},
+	};
+	struct acpi_object_list arg_list = { PMC_IPCS_PARAM_COUNT, params };
+	union acpi_object *obj;
+	int status;
+
+	if (!ipc_cmd || !rbuf)
+		return -EINVAL;
+
+	/*
+	 * 0: IPC Command
+	 * 1: IPC Sub Command
+	 * 2: Size
+	 * 3-6: Write Buffer for offset
+	 */
+	params[0].integer.value = ipc_cmd->cmd;
+	params[1].integer.value = ipc_cmd->sub_cmd;
+	params[2].integer.value = ipc_cmd->size;
+	params[3].integer.value = ipc_cmd->wbuf[0];
+	params[4].integer.value = ipc_cmd->wbuf[1];
+	params[5].integer.value = ipc_cmd->wbuf[2];
+	params[6].integer.value = ipc_cmd->wbuf[3];
+
+	status = acpi_evaluate_object(NULL, "\\IPCS", &arg_list, &buffer);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	obj = buffer.pointer;
+	/* Check if the number of elements in package is 5 */
+	if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count == 5) {
+		const union acpi_object *objs = obj->package.elements;
+
+		if ((u8)objs[0].integer.value != 0)
+			return -EINVAL;
+
+		rbuf[0] = objs[1].integer.value;
+		rbuf[1] = objs[2].integer.value;
+		rbuf[2] = objs[3].integer.value;
+		rbuf[3] = objs[4].integer.value;
+	} else {
+		return -EINVAL;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(intel_pmc_core_ipc);
+
 static inline u32 pmc_core_reg_read(struct pmc *pmc, int reg_offset)
 {
 	return readl(pmc->regbase + reg_offset);
diff --git a/include/linux/platform_data/x86/intel_pmc_core.h b/include/linux/platform_data/x86/intel_pmc_core.h
new file mode 100644
index 000000000000..9bb3394fedcf
--- /dev/null
+++ b/include/linux/platform_data/x86/intel_pmc_core.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Intel Core SoC Power Management Controller Header File
+ *
+ * Copyright (c) 2023, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Authors: Choong Yong Liang <yong.liang.choong@linux.intel.com>
+ *          David E. Box <david.e.box@linux.intel.com>
+ */
+#ifndef INTEL_PMC_CORE_H
+#define INTEL_PMC_CORE_H
+
+#define IPC_SOC_REGISTER_ACCESS			0xAA
+#define IPC_SOC_SUB_CMD_READ			0x00
+#define IPC_SOC_SUB_CMD_WRITE			0x01
+
+struct pmc_ipc_cmd {
+	u32 cmd;
+	u32 sub_cmd;
+	u32 size;
+	u32 wbuf[4];
+};
+
+#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
+/**
+ * intel_pmc_core_ipc() - PMC IPC Mailbox accessor
+ * @ipc_cmd:  struct pmc_ipc_cmd prepared with input to send
+ * @rbuf:     Allocated u32[4] array for returned IPC data
+ *
+ * Return: 0 on success. Non-zero on mailbox error
+ */
+int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf);
+#else
+static inline int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_INTEL_PMC_CORE */
+
+#endif /* INTEL_PMC_CORE_H */
-- 
2.25.1

[PATCH net-next v2 2/5] net: pcs: xpcs: combine C37 SGMII AN and 2500BASEX for Intel mGbE controller

[Choong Yong Liang]

From: "Tan, Tee Min" <tee.min.tan@linux.intel.com>

This commit introduces xpcs_sgmii_2500basex_features[] that combine
xpcs_sgmii_features[] and xpcs_2500basex_features[] for Intel mGbE
controller that desire to interchange the speed mode of
10/100/1000/2500Mbps at runtime.

Also, we introduce xpcs_config_aneg_c37_sgmii_2500basex() function
which is called by the xpcs_do_config() with the new AN mode:
DW_SGMII_2500BASEX, and this new function will proceed next-level
calling to perform C37 SGMII AN/2500BASEX configuration based on
the PHY interface updated by PHY driver.

Signed-off-by: Tan, Tee Min <tee.min.tan@linux.intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 drivers/net/pcs/pcs-xpcs.c   | 72 ++++++++++++++++++++++++++++++------
 include/linux/pcs/pcs-xpcs.h |  1 +
 2 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 44b037646865..b35767f65d62 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -104,6 +104,21 @@ static const int xpcs_2500basex_features[] = {
 	__ETHTOOL_LINK_MODE_MASK_NBITS,
 };
 
+static const int xpcs_sgmii_2500basex_features[] = {
+	ETHTOOL_LINK_MODE_Pause_BIT,
+	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
+	ETHTOOL_LINK_MODE_Autoneg_BIT,
+	ETHTOOL_LINK_MODE_10baseT_Half_BIT,
+	ETHTOOL_LINK_MODE_10baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_100baseT_Half_BIT,
+	ETHTOOL_LINK_MODE_100baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
+	ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_2500baseX_Full_BIT,
+	ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+	__ETHTOOL_LINK_MODE_MASK_NBITS,
+};
+
 static const phy_interface_t xpcs_usxgmii_interfaces[] = {
 	PHY_INTERFACE_MODE_USXGMII,
 };
@@ -133,6 +148,12 @@ static const phy_interface_t xpcs_2500basex_interfaces[] = {
 	PHY_INTERFACE_MODE_MAX,
 };
 
+static const phy_interface_t xpcs_sgmii_2500basex_interfaces[] = {
+	PHY_INTERFACE_MODE_SGMII,
+	PHY_INTERFACE_MODE_2500BASEX,
+	PHY_INTERFACE_MODE_MAX,
+};
+
 enum {
 	DW_XPCS_USXGMII,
 	DW_XPCS_10GKR,
@@ -141,6 +162,7 @@ enum {
 	DW_XPCS_SGMII,
 	DW_XPCS_1000BASEX,
 	DW_XPCS_2500BASEX,
+	DW_XPCS_SGMII_2500BASEX,
 	DW_XPCS_INTERFACE_MAX,
 };
 
@@ -267,6 +289,7 @@ static int xpcs_soft_reset(struct dw_xpcs *xpcs,
 	case DW_AN_C37_SGMII:
 	case DW_2500BASEX:
 	case DW_AN_C37_1000BASEX:
+	case DW_SGMII_2500BASEX:
 		dev = MDIO_MMD_VEND2;
 		break;
 	default:
@@ -713,6 +736,8 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs,
 	else
 		ret &= ~DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
 
+	/* Disable 2.5G GMII for SGMII C37 mode */
+	ret &= ~DW_VR_MII_DIG_CTRL1_2G5_EN;
 	ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1, ret);
 	if (ret < 0)
 		return ret;
@@ -808,6 +833,26 @@ static int xpcs_config_2500basex(struct dw_xpcs *xpcs)
 	return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL, ret);
 }
 
+static int xpcs_config_aneg_c37_sgmii_2500basex(struct dw_xpcs *xpcs,
+						unsigned int neg_mode,
+						phy_interface_t interface)
+{
+	int ret = -EOPNOTSUPP;
+
+	switch (interface) {
+	case PHY_INTERFACE_MODE_SGMII:
+		ret = xpcs_config_aneg_c37_sgmii(xpcs, neg_mode);
+		break;
+	case PHY_INTERFACE_MODE_2500BASEX:
+		ret = xpcs_config_2500basex(xpcs);
+		break;
+	default:
+		break;
+	}
+
+	return ret;
+}
+
 int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
 		   const unsigned long *advertising, unsigned int neg_mode)
 {
@@ -844,6 +889,12 @@ int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
 		if (ret)
 			return ret;
 		break;
+	case DW_SGMII_2500BASEX:
+		ret = xpcs_config_aneg_c37_sgmii_2500basex(xpcs, neg_mode,
+							   interface);
+		if (ret)
+			return ret;
+		break;
 	default:
 		return -1;
 	}
@@ -1030,6 +1081,11 @@ static void xpcs_get_state(struct phylink_pcs *pcs,
 		}
 		break;
 	case DW_AN_C37_SGMII:
+	case DW_SGMII_2500BASEX:
+		/* 2500BASEX is not supported for in-band AN mode. */
+		if (state->interface == PHY_INTERFACE_MODE_2500BASEX)
+			break;
+
 		ret = xpcs_get_state_c37_sgmii(xpcs, state);
 		if (ret) {
 			pr_err("xpcs_get_state_c37_sgmii returned %pe\n",
@@ -1182,23 +1238,17 @@ static const struct xpcs_compat synopsys_xpcs_compat[DW_XPCS_INTERFACE_MAX] = {
 		.num_interfaces = ARRAY_SIZE(xpcs_10gbaser_interfaces),
 		.an_mode = DW_10GBASER,
 	},
-	[DW_XPCS_SGMII] = {
-		.supported = xpcs_sgmii_features,
-		.interface = xpcs_sgmii_interfaces,
-		.num_interfaces = ARRAY_SIZE(xpcs_sgmii_interfaces),
-		.an_mode = DW_AN_C37_SGMII,
-	},
 	[DW_XPCS_1000BASEX] = {
 		.supported = xpcs_1000basex_features,
 		.interface = xpcs_1000basex_interfaces,
 		.num_interfaces = ARRAY_SIZE(xpcs_1000basex_interfaces),
 		.an_mode = DW_AN_C37_1000BASEX,
 	},
-	[DW_XPCS_2500BASEX] = {
-		.supported = xpcs_2500basex_features,
-		.interface = xpcs_2500basex_interfaces,
-		.num_interfaces = ARRAY_SIZE(xpcs_2500basex_interfaces),
-		.an_mode = DW_2500BASEX,
+	[DW_XPCS_SGMII_2500BASEX] = {
+		.supported = xpcs_sgmii_2500basex_features,
+		.interface = xpcs_sgmii_2500basex_interfaces,
+		.num_interfaces = ARRAY_SIZE(xpcs_sgmii_2500basex_features),
+		.an_mode = DW_SGMII_2500BASEX,
 	},
 };
 
diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h
index ff99cf7a5d0d..a1625e1c5875 100644
--- a/include/linux/pcs/pcs-xpcs.h
+++ b/include/linux/pcs/pcs-xpcs.h
@@ -19,6 +19,7 @@
 #define DW_2500BASEX			3
 #define DW_AN_C37_1000BASEX		4
 #define DW_10GBASER			5
+#define DW_SGMII_2500BASEX		6
 
 struct xpcs_id;
 
-- 
2.25.1

[PATCH net-next v2 3/5] net: phy: update in-band AN mode when changing interface by PHY driver

[Choong Yong Liang]

From: "Tan, Tee Min" <tee.min.tan@linux.intel.com>

Add cur_link_an_mode into phy_device struct for PHY drivers to
communicate the in-band AN mode setting with phylink framework.

As there is a mechanism in PHY drivers to switch the PHY interface
between SGMII and 2500BaseX according to link speed. In this case,
the in-band AN mode should be switching based on the PHY interface
as well, if the PHY interface has been changed/updated by PHY driver.

For e.g., disable in-band AN in 2500BaseX mode, or enable in-band AN
back for SGMII mode (10/100/1000Mbps).

Signed-off-by: Tan, Tee Min <tee.min.tan@linux.intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 drivers/net/phy/marvell10g.c | 6 ++++++
 drivers/net/phy/phylink.c    | 4 ++++
 include/linux/phy.h          | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index d4bb90d76881..a9df19278618 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -30,6 +30,7 @@
 #include <linux/phy.h>
 #include <linux/sfp.h>
 #include <linux/netdevice.h>
+#include <linux/phylink.h>
 
 #define MV_PHY_ALASKA_NBT_QUIRK_MASK	0xfffffffe
 #define MV_PHY_ALASKA_NBT_QUIRK_REV	(MARVELL_PHY_ID_88X3310 | 0xa)
@@ -946,6 +947,9 @@ static void mv3310_update_interface(struct phy_device *phydev)
 	 * xaui / rxaui modes according to the speed.
 	 * Florian suggests setting phydev->interface to communicate this to the
 	 * MAC. Only do this if we are already in one of the above modes.
+	 * In-band Auto-negotiation is not supported in 2500BASE-X.
+	 * Setting phydev->cur_link_an_mode to communicate this to the
+	 * phylink framework.
 	 */
 	switch (phydev->speed) {
 	case SPEED_10000:
@@ -956,11 +960,13 @@ static void mv3310_update_interface(struct phy_device *phydev)
 		break;
 	case SPEED_2500:
 		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
+		phydev->cur_link_an_mode = MLO_AN_PHY;
 		break;
 	case SPEED_1000:
 	case SPEED_100:
 	case SPEED_10:
 		phydev->interface = PHY_INTERFACE_MODE_SGMII;
+		phydev->cur_link_an_mode = MLO_AN_INBAND;
 		break;
 	default:
 		break;
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 4f1c8bb199e9..f9cbb6d7e134 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1720,6 +1720,8 @@ static void phylink_phy_change(struct phy_device *phydev, bool up)
 		pl->phy_state.pause |= MLO_PAUSE_RX;
 	pl->phy_state.interface = phydev->interface;
 	pl->phy_state.link = up;
+	pl->cur_link_an_mode = phydev->cur_link_an_mode;
+	pl->cfg_link_an_mode = phydev->cur_link_an_mode;
 	mutex_unlock(&pl->state_mutex);
 
 	phylink_run_resolve(pl);
@@ -1824,6 +1826,8 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
 	if (pl->config->mac_managed_pm)
 		phy->mac_managed_pm = true;
 
+	pl->phydev->cur_link_an_mode = pl->cur_link_an_mode;
+
 	return 0;
 }
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index ba08b0e60279..4973f2852a79 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -619,6 +619,7 @@ struct macsec_ops;
  * @link_down_events: Number of times link was lost
  * @shared: Pointer to private data shared by phys in one package
  * @priv: Pointer to driver private data
+ * @cur_link_an_mode: Current AN mode setting with phylink framework
  *
  * interrupts currently only supports enabled or disabled,
  * but could be changed in the future to support enabling
@@ -757,6 +758,8 @@ struct phy_device {
 	/* MACsec management functions */
 	const struct macsec_ops *macsec_ops;
 #endif
+	/* For communicate the AN mode setting with phylink framework. */
+	u8 cur_link_an_mode;
 };
 
 /* Generic phy_device::dev_flags */
-- 
2.25.1

[PATCH net-next v2 4/5] net: stmmac: enable Intel mGbE 1G/2.5G auto-negotiation support

[Choong Yong Liang]

From: "Tan, Tee Min" <tee.min.tan@linux.intel.com>

Initially, Intel mGbE was only able to configure the overclocking of 2.5
times clock rate to enable 2.5Gbps in the BIOS during boot time. Kernel
driver had no access to modify the clock rate for 1G/2.5G mode at runtime.

Now, this patch enables the runtime 1G/2.5G auto-negotiation support to
gets rid of the dependency on BIOS to change the 1G/2.5G clock rate.

This patch adds several new functions below:-
- intel_tsn_interface_is_available(): This new function reads FIA lane
  ownership registers and common lane registers through IPC commands
  to know which lane the mGbE port is assigned to.
- stmmac_mac_prepare(): To obtain the latest PHY interface from phylink
  during initialization and call intel_config_serdes() to proceed with
  SERDES configuration.
- intel_config_serdes(): To configure the SERDES based on the assigned
  lane and latest PHY interface, it sends IPC command to the PMC through
  PMC driver/API. The PMC acts as a proxy for R/W on behalf of the driver.
- intel_set_reg_access(): Set the register access to the available TSN
  interface.

Signed-off-by: Tan, Tee Min <tee.min.tan@linux.intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |   1 +
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 134 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h |  79 +++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  20 +++
 include/linux/stmmac.h                        |   1 +
 5 files changed, 231 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 06c6871f8788..7841610a4746 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -262,6 +262,7 @@ config DWMAC_INTEL
 	default X86
 	depends on X86 && STMMAC_ETH && PCI
 	depends on COMMON_CLK
+	select INTEL_PMC_CORE
 	help
 	  This selects the Intel platform specific bus support for the
 	  stmmac driver. This driver is used for Intel Quark/EHL/TGL.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 979c755964b1..9f560f18132a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -5,6 +5,7 @@
 #include <linux/clk-provider.h>
 #include <linux/pci.h>
 #include <linux/dmi.h>
+#include <linux/platform_data/x86/intel_pmc_core.h>
 #include "dwmac-intel.h"
 #include "dwmac4.h"
 #include "stmmac.h"
@@ -14,6 +15,9 @@ struct intel_priv_data {
 	int mdio_adhoc_addr;	/* mdio address for serdes & etc */
 	unsigned long crossts_adj;
 	bool is_pse;
+	const int *tsn_lane_registers;
+	int max_tsn_lane_registers;
+	int pid_modphy;
 };
 
 /* This struct is used to associate PCI Function of MAC controller on a board,
@@ -93,7 +97,7 @@ static int intel_serdes_powerup(struct net_device *ndev, void *priv_data)
 	data &= ~SERDES_RATE_MASK;
 	data &= ~SERDES_PCLK_MASK;
 
-	if (priv->plat->max_speed == 2500)
+	if (priv->plat->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
 		data |= SERDES_RATE_PCIE_GEN2 << SERDES_RATE_PCIE_SHIFT |
 			SERDES_PCLK_37p5MHZ << SERDES_PCLK_SHIFT;
 	else
@@ -414,6 +418,106 @@ static void intel_mgbe_pse_crossts_adj(struct intel_priv_data *intel_priv,
 	}
 }
 
+#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
+static bool intel_tsn_interface_is_available(struct net_device *ndev,
+					     struct intel_priv_data *intel_priv)
+{
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	struct pmc_ipc_cmd tmp = {0};
+	u32 rbuf[4] = {0};
+	int ret, i, j;
+
+	if (priv->plat->serdes_powerup) {
+		tmp.cmd = IPC_SOC_REGISTER_ACCESS;
+		tmp.sub_cmd = IPC_SOC_SUB_CMD_READ;
+
+		for (i = 0; i < 5; i++) {
+			tmp.wbuf[0] = R_PCH_FIA_15_PCR_LOS1_REG_BASE + i;
+
+			ret = intel_pmc_core_ipc(&tmp, rbuf);
+			if (ret < 0) {
+				netdev_info(priv->dev,
+					    "Failed to read from PMC.\n");
+				return false;
+			}
+
+			for (j = 0; j <= intel_priv->max_tsn_lane_registers; j++)
+				if ((rbuf[0] >>
+				    (4 * (intel_priv->tsn_lane_registers[j] % 8)) &
+				     B_PCH_FIA_PCR_L0O) == 0xB)
+					return true;
+		}
+	}
+	return false;
+}
+
+static int intel_set_reg_access(const struct pmc_serdes_regs *regs, int max_regs)
+{
+	int ret = 0, i;
+
+	for (i = 0; i < max_regs; i++) {
+		struct pmc_ipc_cmd tmp = {0};
+		u32 buf[4] = {0};
+
+		tmp.cmd = IPC_SOC_REGISTER_ACCESS;
+		tmp.sub_cmd = IPC_SOC_SUB_CMD_WRITE;
+		tmp.wbuf[0] = (u32)regs[i].index;
+		tmp.wbuf[1] = regs[i].val;
+
+		ret = intel_pmc_core_ipc(&tmp, buf);
+		if (ret < 0)
+			return ret;
+	}
+
+	return ret;
+}
+
+static int intel_config_serdes(struct net_device *ndev, void *intel_data)
+{
+	struct intel_priv_data *intel_priv = intel_data;
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret = 0;
+
+	if (!intel_tsn_interface_is_available(ndev, intel_priv)) {
+		netdev_info(priv->dev,
+			    "No TSN interface available to set the registers.\n");
+		goto pmc_read_error;
+	}
+
+	if (intel_priv->pid_modphy == PID_MODPHY1) {
+		if (priv->plat->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
+			ret = intel_set_reg_access(pid_modphy1_2p5g_regs,
+						   ARRAY_SIZE(pid_modphy1_2p5g_regs));
+		} else {
+			ret = intel_set_reg_access(pid_modphy1_1g_regs,
+						   ARRAY_SIZE(pid_modphy1_1g_regs));
+		}
+	} else {
+		if (priv->plat->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
+			ret = intel_set_reg_access(pid_modphy3_2p5g_regs,
+						   ARRAY_SIZE(pid_modphy3_2p5g_regs));
+		} else {
+			ret = intel_set_reg_access(pid_modphy3_1g_regs,
+						   ARRAY_SIZE(pid_modphy3_1g_regs));
+		}
+	}
+
+	if (ret < 0)
+		goto pmc_read_error;
+
+pmc_read_error:
+	intel_serdes_powerdown(ndev, intel_priv);
+	intel_serdes_powerup(ndev, intel_priv);
+
+	return ret;
+}
+#else
+static int intel_config_serdes(struct net_device *ndev, void *intel_data)
+{
+	return -EOPNOTSUPP;
+}
+#endif /* CONFIG_INTEL_PMC_CORE */
+
 static void common_default_data(struct plat_stmmacenet_data *plat)
 {
 	plat->clk_csr = 2;	/* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
@@ -624,6 +728,8 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 static int ehl_common_data(struct pci_dev *pdev,
 			   struct plat_stmmacenet_data *plat)
 {
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
 	plat->rx_queues_to_use = 8;
 	plat->tx_queues_to_use = 8;
 	plat->flags |= STMMAC_FLAG_USE_PHY_WOL;
@@ -638,20 +744,28 @@ static int ehl_common_data(struct pci_dev *pdev,
 	plat->safety_feat_cfg->prtyen = 0;
 	plat->safety_feat_cfg->tmouten = 0;
 
+	intel_priv->tsn_lane_registers = ehl_tsn_lane_registers;
+	intel_priv->max_tsn_lane_registers = ARRAY_SIZE(ehl_tsn_lane_registers);
+
 	return intel_mgbe_common_data(pdev, plat);
 }
 
 static int ehl_sgmii_data(struct pci_dev *pdev,
 			  struct plat_stmmacenet_data *plat)
 {
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
 	plat->bus_id = 1;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
-	plat->speed_mode_2500 = intel_speed_mode_2500;
+	plat->max_speed = SPEED_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
+	plat->config_serdes = intel_config_serdes;
 
 	plat->clk_ptp_rate = 204800000;
 
+	intel_priv->pid_modphy = PID_MODPHY3;
+
 	return ehl_common_data(pdev, plat);
 }
 
@@ -704,10 +818,16 @@ static struct stmmac_pci_info ehl_pse0_rgmii1g_info = {
 static int ehl_pse0_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
-	plat->speed_mode_2500 = intel_speed_mode_2500;
+	plat->max_speed = SPEED_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
+	plat->config_serdes = intel_config_serdes;
+
+	intel_priv->pid_modphy = PID_MODPHY1;
+
 	return ehl_pse0_common_data(pdev, plat);
 }
 
@@ -745,10 +865,16 @@ static struct stmmac_pci_info ehl_pse1_rgmii1g_info = {
 static int ehl_pse1_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
-	plat->speed_mode_2500 = intel_speed_mode_2500;
+	plat->max_speed = SPEED_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
+	plat->config_serdes = intel_config_serdes;
+
+	intel_priv->pid_modphy = PID_MODPHY1;
+
 	return ehl_pse1_common_data(pdev, plat);
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index 0a37987478c1..75a336cf8af1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -50,4 +50,83 @@
 #define PCH_PTP_CLK_FREQ_19_2MHZ	(GMAC_GPO0)
 #define PCH_PTP_CLK_FREQ_200MHZ		(0)
 
+#define	PID_MODPHY1 0xAA
+#define	PID_MODPHY3 0xA8
+
+#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
+struct pmc_serdes_regs {
+	u8 index;
+	u32 val;
+};
+
+/* Modphy Register index */
+#define R_PCH_FIA_15_PCR_LOS1_REG_BASE			8
+#define R_PCH_FIA_15_PCR_LOS2_REG_BASE			9
+#define R_PCH_FIA_15_PCR_LOS3_REG_BASE			10
+#define R_PCH_FIA_15_PCR_LOS4_REG_BASE			11
+#define R_PCH_FIA_15_PCR_LOS5_REG_BASE			12
+#define B_PCH_FIA_PCR_L0O				GENMASK(3, 0)
+#define PID_MODPHY1_B_MODPHY_PCR_LCPLL_DWORD0		13
+#define PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD2		14
+#define PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD7		15
+#define PID_MODPHY1_N_MODPHY_PCR_LPPLL_DWORD10		16
+#define PID_MODPHY1_N_MODPHY_PCR_CMN_ANA_DWORD30	17
+#define PID_MODPHY3_B_MODPHY_PCR_LCPLL_DWORD0		18
+#define PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD2		19
+#define PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD7		20
+#define PID_MODPHY3_N_MODPHY_PCR_LPPLL_DWORD10		21
+#define PID_MODPHY3_N_MODPHY_PCR_CMN_ANA_DWORD30	22
+
+#define B_MODPHY_PCR_LCPLL_DWORD0_1G		0x46AAAA41
+#define N_MODPHY_PCR_LCPLL_DWORD2_1G		0x00000139
+#define N_MODPHY_PCR_LCPLL_DWORD7_1G		0x002A0003
+#define N_MODPHY_PCR_LPPLL_DWORD10_1G		0x00170008
+#define N_MODPHY_PCR_CMN_ANA_DWORD30_1G		0x0000D4AC
+#define B_MODPHY_PCR_LCPLL_DWORD0_2P5G		0x58555551
+#define N_MODPHY_PCR_LCPLL_DWORD2_2P5G		0x0000012D
+#define N_MODPHY_PCR_LCPLL_DWORD7_2P5G		0x001F0003
+#define N_MODPHY_PCR_LPPLL_DWORD10_2P5G		0x00170008
+#define N_MODPHY_PCR_CMN_ANA_DWORD30_2P5G	0x8200ACAC
+
+static const struct pmc_serdes_regs pid_modphy3_1g_regs[] = {
+	{ PID_MODPHY3_B_MODPHY_PCR_LCPLL_DWORD0,	B_MODPHY_PCR_LCPLL_DWORD0_1G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD2,	N_MODPHY_PCR_LCPLL_DWORD2_1G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD7,	N_MODPHY_PCR_LCPLL_DWORD7_1G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LPPLL_DWORD10,	N_MODPHY_PCR_LPPLL_DWORD10_1G },
+	{ PID_MODPHY3_N_MODPHY_PCR_CMN_ANA_DWORD30,	N_MODPHY_PCR_CMN_ANA_DWORD30_1G },
+	{}
+};
+
+static const struct pmc_serdes_regs pid_modphy3_2p5g_regs[] = {
+	{ PID_MODPHY3_B_MODPHY_PCR_LCPLL_DWORD0,	B_MODPHY_PCR_LCPLL_DWORD0_2P5G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD2,	N_MODPHY_PCR_LCPLL_DWORD2_2P5G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LCPLL_DWORD7,	N_MODPHY_PCR_LCPLL_DWORD7_2P5G },
+	{ PID_MODPHY3_N_MODPHY_PCR_LPPLL_DWORD10,	N_MODPHY_PCR_LPPLL_DWORD10_2P5G },
+	{ PID_MODPHY3_N_MODPHY_PCR_CMN_ANA_DWORD30,	N_MODPHY_PCR_CMN_ANA_DWORD30_2P5G },
+	{}
+};
+
+static const struct pmc_serdes_regs pid_modphy1_1g_regs[] = {
+	{ PID_MODPHY1_B_MODPHY_PCR_LCPLL_DWORD0,	B_MODPHY_PCR_LCPLL_DWORD0_1G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD2,	N_MODPHY_PCR_LCPLL_DWORD2_1G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD7,	N_MODPHY_PCR_LCPLL_DWORD7_1G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LPPLL_DWORD10,	N_MODPHY_PCR_LPPLL_DWORD10_1G },
+	{ PID_MODPHY1_N_MODPHY_PCR_CMN_ANA_DWORD30,	N_MODPHY_PCR_CMN_ANA_DWORD30_1G },
+	{}
+};
+
+static const struct pmc_serdes_regs pid_modphy1_2p5g_regs[] = {
+	{ PID_MODPHY1_B_MODPHY_PCR_LCPLL_DWORD0,	B_MODPHY_PCR_LCPLL_DWORD0_2P5G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD2,	N_MODPHY_PCR_LCPLL_DWORD2_2P5G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LCPLL_DWORD7,	N_MODPHY_PCR_LCPLL_DWORD7_2P5G },
+	{ PID_MODPHY1_N_MODPHY_PCR_LPPLL_DWORD10,	N_MODPHY_PCR_LPPLL_DWORD10_2P5G },
+	{ PID_MODPHY1_N_MODPHY_PCR_CMN_ANA_DWORD30,	N_MODPHY_PCR_CMN_ANA_DWORD30_2P5G },
+	{}
+};
+
+static const int ehl_tsn_lane_registers[] = {7, 8, 9, 10, 11};
+#else
+static const int ehl_tsn_lane_registers[] = {};
+#endif /* CONFIG_INTEL_PMC_CORE */
+
 #endif /* __DWMAC_INTEL_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e1f1c034d325..e2fa6d8ffd85 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1096,11 +1096,31 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 		stmmac_fpe_link_state_handle(priv, true);
 }
 
+#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
+static int stmmac_mac_prepare(struct phylink_config *config, unsigned int mode,
+			      phy_interface_t interface)
+{
+	struct net_device *ndev = to_net_dev(config->dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret = 0;
+
+	priv->plat->phy_interface = interface;
+
+	if (priv->plat->config_serdes)
+		ret = priv->plat->config_serdes(ndev, priv->plat->bsp_priv);
+
+	return ret;
+}
+#endif
+
 static const struct phylink_mac_ops stmmac_phylink_mac_ops = {
 	.mac_select_pcs = stmmac_mac_select_pcs,
 	.mac_config = stmmac_mac_config,
 	.mac_link_down = stmmac_mac_link_down,
 	.mac_link_up = stmmac_mac_link_up,
+#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
+	.mac_prepare = stmmac_mac_prepare,
+#endif
 };
 
 /**
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3d0702510224..e27369cd37f9 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -260,6 +260,7 @@ struct plat_stmmacenet_data {
 	int (*serdes_powerup)(struct net_device *ndev, void *priv);
 	void (*serdes_powerdown)(struct net_device *ndev, void *priv);
 	void (*speed_mode_2500)(struct net_device *ndev, void *priv);
+	int (*config_serdes)(struct net_device *ndev, void *priv);
 	void (*ptp_clk_freq_config)(struct stmmac_priv *priv);
 	int (*init)(struct platform_device *pdev, void *priv);
 	void (*exit)(struct platform_device *pdev, void *priv);
-- 
2.25.1

[PATCH net-next v2 5/5] stmmac: intel: Add 1G/2.5G auto-negotiation support for ADL-N

[Choong Yong Liang]

Add modphy register lane to have 1G/2.5G auto-negotiation support for
ADL-N.

Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 49 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h |  2 +
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 9f560f18132a..437c7697640f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -960,6 +960,53 @@ static int adls_sgmii_phy1_data(struct pci_dev *pdev,
 static struct stmmac_pci_info adls_sgmii1g_phy1_info = {
 	.setup = adls_sgmii_phy1_data,
 };
+
+static int adln_common_data(struct pci_dev *pdev,
+			    struct plat_stmmacenet_data *plat)
+{
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
+	plat->rx_queues_to_use = 6;
+	plat->tx_queues_to_use = 4;
+	plat->clk_ptp_rate = 204800000;
+
+	plat->safety_feat_cfg->tsoee = 1;
+	plat->safety_feat_cfg->mrxpee = 0;
+	plat->safety_feat_cfg->mestee = 1;
+	plat->safety_feat_cfg->mrxee = 1;
+	plat->safety_feat_cfg->mtxee = 1;
+	plat->safety_feat_cfg->epsi = 0;
+	plat->safety_feat_cfg->edpp = 0;
+	plat->safety_feat_cfg->prtyen = 0;
+	plat->safety_feat_cfg->tmouten = 0;
+
+	intel_priv->tsn_lane_registers = adln_tsn_lane_registers;
+	intel_priv->max_tsn_lane_registers = ARRAY_SIZE(adln_tsn_lane_registers);
+
+	return intel_mgbe_common_data(pdev, plat);
+}
+
+static int adln_sgmii_phy0_data(struct pci_dev *pdev,
+				struct plat_stmmacenet_data *plat)
+{
+	struct intel_priv_data *intel_priv = plat->bsp_priv;
+
+	plat->bus_id = 1;
+	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->max_speed = SPEED_2500;
+	plat->serdes_powerup = intel_serdes_powerup;
+	plat->serdes_powerdown = intel_serdes_powerdown;
+	plat->config_serdes = intel_config_serdes;
+
+	intel_priv->pid_modphy = PID_MODPHY1;
+
+	return adln_common_data(pdev, plat);
+}
+
+static struct stmmac_pci_info adln_sgmii1g_phy0_info = {
+	.setup = adln_sgmii_phy0_data,
+};
+
 static const struct stmmac_pci_func_data galileo_stmmac_func_data[] = {
 	{
 		.func = 6,
@@ -1342,7 +1389,7 @@ static const struct pci_device_id intel_eth_pci_id_table[] = {
 	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_1, &tgl_sgmii1g_phy1_info) },
 	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_0, &adls_sgmii1g_phy0_info) },
 	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_1, &adls_sgmii1g_phy1_info) },
-	{ PCI_DEVICE_DATA(INTEL, ADLN_SGMII1G, &tgl_sgmii1g_phy0_info) },
+	{ PCI_DEVICE_DATA(INTEL, ADLN_SGMII1G, &adln_sgmii1g_phy0_info) },
 	{ PCI_DEVICE_DATA(INTEL, RPLP_SGMII1G, &tgl_sgmii1g_phy0_info) },
 	{}
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index 75a336cf8af1..349c160c17b3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -124,8 +124,10 @@ static const struct pmc_serdes_regs pid_modphy1_2p5g_regs[] = {
 	{}
 };
 
+static const int adln_tsn_lane_registers[] = {6};
 static const int ehl_tsn_lane_registers[] = {7, 8, 9, 10, 11};
 #else
+static const int adln_tsn_lane_registers[] = {};
 static const int ehl_tsn_lane_registers[] = {};
 #endif /* CONFIG_INTEL_PMC_CORE */
 
-- 
2.25.1

Re: [PATCH net-next v2 3/5] net: phy: update in-band AN mode when changing interface by PHY driver

[Russell King (Oracle)]

On Fri, Aug 04, 2023 at 04:45:25PM +0800, Choong Yong Liang wrote:
> From: "Tan, Tee Min" <tee.min.tan@linux.intel.com>
> 
> Add cur_link_an_mode into phy_device struct for PHY drivers to
> communicate the in-band AN mode setting with phylink framework.
> 
> As there is a mechanism in PHY drivers to switch the PHY interface
> between SGMII and 2500BaseX according to link speed. In this case,
> the in-band AN mode should be switching based on the PHY interface
> as well, if the PHY interface has been changed/updated by PHY driver.
> 
> For e.g., disable in-band AN in 2500BaseX mode, or enable in-band AN
> back for SGMII mode (10/100/1000Mbps).
> 
> Signed-off-by: Tan, Tee Min <tee.min.tan@linux.intel.com>
> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> ---
>  drivers/net/phy/marvell10g.c | 6 ++++++
>  drivers/net/phy/phylink.c    | 4 ++++
>  include/linux/phy.h          | 3 +++
>  3 files changed, 13 insertions(+)
> 
> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> index d4bb90d76881..a9df19278618 100644
> --- a/drivers/net/phy/marvell10g.c
> +++ b/drivers/net/phy/marvell10g.c
> @@ -30,6 +30,7 @@
>  #include <linux/phy.h>
>  #include <linux/sfp.h>
>  #include <linux/netdevice.h>
> +#include <linux/phylink.h>
>  
>  #define MV_PHY_ALASKA_NBT_QUIRK_MASK	0xfffffffe
>  #define MV_PHY_ALASKA_NBT_QUIRK_REV	(MARVELL_PHY_ID_88X3310 | 0xa)
> @@ -946,6 +947,9 @@ static void mv3310_update_interface(struct phy_device *phydev)
>  	 * xaui / rxaui modes according to the speed.
>  	 * Florian suggests setting phydev->interface to communicate this to the
>  	 * MAC. Only do this if we are already in one of the above modes.
> +	 * In-band Auto-negotiation is not supported in 2500BASE-X.
> +	 * Setting phydev->cur_link_an_mode to communicate this to the
> +	 * phylink framework.
>  	 */
>  	switch (phydev->speed) {
>  	case SPEED_10000:
> @@ -956,11 +960,13 @@ static void mv3310_update_interface(struct phy_device *phydev)
>  		break;
>  	case SPEED_2500:
>  		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> +		phydev->cur_link_an_mode = MLO_AN_PHY;
>  		break;
>  	case SPEED_1000:
>  	case SPEED_100:
>  	case SPEED_10:
>  		phydev->interface = PHY_INTERFACE_MODE_SGMII;
> +		phydev->cur_link_an_mode = MLO_AN_INBAND;
>  		break;
>  	default:
>  		break;
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 4f1c8bb199e9..f9cbb6d7e134 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -1720,6 +1720,8 @@ static void phylink_phy_change(struct phy_device *phydev, bool up)
>  		pl->phy_state.pause |= MLO_PAUSE_RX;
>  	pl->phy_state.interface = phydev->interface;
>  	pl->phy_state.link = up;
> +	pl->cur_link_an_mode = phydev->cur_link_an_mode;
> +	pl->cfg_link_an_mode = phydev->cur_link_an_mode;
>  	mutex_unlock(&pl->state_mutex);
>  
>  	phylink_run_resolve(pl);
> @@ -1824,6 +1826,8 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
>  	if (pl->config->mac_managed_pm)
>  		phy->mac_managed_pm = true;
>  
> +	pl->phydev->cur_link_an_mode = pl->cur_link_an_mode;

I am really not happy with exposing phylink's AN mode into phylib.

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

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Andrew Lunn]

On Fri, Aug 04, 2023 at 04:45:22PM +0800, Choong Yong Liang wrote:
> Intel platforms’ integrated Gigabit Ethernet controllers support
> 2.5Gbps mode statically using BIOS programming. In the current
> implementation, the BIOS menu provides an option to select between
> 10/100/1000Mbps and 2.5Gbps modes. Based on the selection, the BIOS
> programs the Phase Lock Loop (PLL) registers. The BIOS also read the
> TSN lane registers from Flexible I/O Adapter (FIA) block and provided
> 10/100/1000Mbps/2.5Gbps information to the stmmac driver. But
> auto-negotiation between 10/100/1000Mbps and 2.5Gbps is not allowed.
> The new proposal is to support auto-negotiation between 10/100/1000Mbps
> and 2.5Gbps . Auto-negotiation between 10, 100, 1000Mbps will use
> in-band auto negotiation. Auto-negotiation between 10/100/1000Mbps and
> 2.5Gbps will work as the following proposed flow, the stmmac driver reads
> the PHY link status registers then identifies the negotiated speed.
> Based on the speed stmmac driver will identify TSN lane registers from
> FIA then send IPC command to the Power Management controller (PMC)
> through PMC driver/API. PMC will act as a proxy to programs the
> PLL registers.

Have you considered using out of band for all link modes? You might
end up with a cleaner architecture, and not need any phylink/phylib
hacks.

	Andrew

Re: [PATCH net-next v2 1/5] platform/x86: intel_pmc_core: Add IPC mailbox accessor function and add SoC register access

[Hans de Goede]

Hi David,

On 8/4/23 10:45, Choong Yong Liang wrote:
> From: "David E. Box" <david.e.box@linux.intel.com>
> 
> - Exports intel_pmc_core_ipc() for host access to the PMC IPC mailbox
> - Add support to use IPC command allows host to access SoC registers
> through PMC firmware that are otherwise inaccessible to the host due to
> security policies.
> 
> Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> Signed-off-by: Chao Qin <chao.qin@intel.com>
> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>

The new exported intel_pmc_core_ipc() function does not seem to
depend on any existing PMC code.

IMHO it would be better to put this in a new .c file under
arch/x86/platform/intel/ this is where similar helpers like
the iosf_mbi functions also live.

This also avoids Kconfig complications. Currently the
drivers/platform/x86/intel/pmc/core.c code is only
build if CONFIG_X86_PLATFORM_DEVICES and
CONFIG_INTEL_PMC_CORE are both set. So if a driver
wants to make sure this is enabled by selecting them
then it needs to select both.

Talking about Kconfig:

#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf);
#else
static inline int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
{
	return -ENODEV;
}
#endif /* CONFIG_INTEL_PMC_CORE */

Notice that CONFIG_INTEL_PMC_CORE is a tristate, so pmc might be build as a module where as a consumer of intel_pmc_core_ipc() might end up builtin in which case this will not work without extra Kconfig protection. And if you are going to add extra Kconfig you might just as well select or depend on INTEL_PMC_CORE and drop the #if .

Regards,

Hans






> ---
>  MAINTAINERS                                   |  1 +
>  drivers/platform/x86/intel/pmc/core.c         | 60 +++++++++++++++++++
>  .../linux/platform_data/x86/intel_pmc_core.h  | 41 +++++++++++++
>  3 files changed, 102 insertions(+)
>  create mode 100644 include/linux/platform_data/x86/intel_pmc_core.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 069e176d607a..8a034dee9da9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10648,6 +10648,7 @@ L:	platform-driver-x86@vger.kernel.org
>  S:	Maintained
>  F:	Documentation/ABI/testing/sysfs-platform-intel-pmc
>  F:	drivers/platform/x86/intel/pmc/
> +F:	linux/platform_data/x86/intel_pmc_core.h
>  
>  INTEL PMIC GPIO DRIVERS
>  M:	Andy Shevchenko <andy@kernel.org>
> diff --git a/drivers/platform/x86/intel/pmc/core.c b/drivers/platform/x86/intel/pmc/core.c
> index 5a36b3f77bc5..6fb1b0f453d8 100644
> --- a/drivers/platform/x86/intel/pmc/core.c
> +++ b/drivers/platform/x86/intel/pmc/core.c
> @@ -20,6 +20,7 @@
>  #include <linux/pci.h>
>  #include <linux/slab.h>
>  #include <linux/suspend.h>
> +#include <linux/platform_data/x86/intel_pmc_core.h>
>  
>  #include <asm/cpu_device_id.h>
>  #include <asm/intel-family.h>
> @@ -28,6 +29,8 @@
>  
>  #include "core.h"
>  
> +#define PMC_IPCS_PARAM_COUNT           7
> +
>  /* Maximum number of modes supported by platfoms that has low power mode capability */
>  const char *pmc_lpm_modes[] = {
>  	"S0i2.0",
> @@ -53,6 +56,63 @@ const struct pmc_bit_map msr_map[] = {
>  	{}
>  };
>  
> +int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
> +{
> +	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> +	union acpi_object params[PMC_IPCS_PARAM_COUNT] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +	};
> +	struct acpi_object_list arg_list = { PMC_IPCS_PARAM_COUNT, params };
> +	union acpi_object *obj;
> +	int status;
> +
> +	if (!ipc_cmd || !rbuf)
> +		return -EINVAL;
> +
> +	/*
> +	 * 0: IPC Command
> +	 * 1: IPC Sub Command
> +	 * 2: Size
> +	 * 3-6: Write Buffer for offset
> +	 */
> +	params[0].integer.value = ipc_cmd->cmd;
> +	params[1].integer.value = ipc_cmd->sub_cmd;
> +	params[2].integer.value = ipc_cmd->size;
> +	params[3].integer.value = ipc_cmd->wbuf[0];
> +	params[4].integer.value = ipc_cmd->wbuf[1];
> +	params[5].integer.value = ipc_cmd->wbuf[2];
> +	params[6].integer.value = ipc_cmd->wbuf[3];
> +
> +	status = acpi_evaluate_object(NULL, "\\IPCS", &arg_list, &buffer);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	obj = buffer.pointer;
> +	/* Check if the number of elements in package is 5 */
> +	if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count == 5) {
> +		const union acpi_object *objs = obj->package.elements;
> +
> +		if ((u8)objs[0].integer.value != 0)
> +			return -EINVAL;
> +
> +		rbuf[0] = objs[1].integer.value;
> +		rbuf[1] = objs[2].integer.value;
> +		rbuf[2] = objs[3].integer.value;
> +		rbuf[3] = objs[4].integer.value;
> +	} else {
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(intel_pmc_core_ipc);
> +
>  static inline u32 pmc_core_reg_read(struct pmc *pmc, int reg_offset)
>  {
>  	return readl(pmc->regbase + reg_offset);
> diff --git a/include/linux/platform_data/x86/intel_pmc_core.h b/include/linux/platform_data/x86/intel_pmc_core.h
> new file mode 100644
> index 000000000000..9bb3394fedcf
> --- /dev/null
> +++ b/include/linux/platform_data/x86/intel_pmc_core.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Intel Core SoC Power Management Controller Header File
> + *
> + * Copyright (c) 2023, Intel Corporation.
> + * All Rights Reserved.
> + *
> + * Authors: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> + *          David E. Box <david.e.box@linux.intel.com>
> + */
> +#ifndef INTEL_PMC_CORE_H
> +#define INTEL_PMC_CORE_H
> +
> +#define IPC_SOC_REGISTER_ACCESS			0xAA
> +#define IPC_SOC_SUB_CMD_READ			0x00
> +#define IPC_SOC_SUB_CMD_WRITE			0x01
> +
> +struct pmc_ipc_cmd {
> +	u32 cmd;
> +	u32 sub_cmd;
> +	u32 size;
> +	u32 wbuf[4];
> +};
> +
> +#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
> +/**
> + * intel_pmc_core_ipc() - PMC IPC Mailbox accessor
> + * @ipc_cmd:  struct pmc_ipc_cmd prepared with input to send
> + * @rbuf:     Allocated u32[4] array for returned IPC data
> + *
> + * Return: 0 on success. Non-zero on mailbox error
> + */
> +int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf);
> +#else
> +static inline int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
> +{
> +	return -ENODEV;
> +}
> +#endif /* CONFIG_INTEL_PMC_CORE */
> +
> +#endif /* INTEL_PMC_CORE_H */

Re: [PATCH net-next v2 3/5] net: phy: update in-band AN mode when changing interface by PHY driver

[Choong Yong Liang]

On 4/8/2023 5:02 pm, Russell King (Oracle) wrote:
> On Fri, Aug 04, 2023 at 04:45:25PM +0800, Choong Yong Liang wrote:
>> From: "Tan, Tee Min" <tee.min.tan@linux.intel.com>
>>
>> Add cur_link_an_mode into phy_device struct for PHY drivers to
>> communicate the in-band AN mode setting with phylink framework.
>>
>> As there is a mechanism in PHY drivers to switch the PHY interface
>> between SGMII and 2500BaseX according to link speed. In this case,
>> the in-band AN mode should be switching based on the PHY interface
>> as well, if the PHY interface has been changed/updated by PHY driver.
>>
>> For e.g., disable in-band AN in 2500BaseX mode, or enable in-band AN
>> back for SGMII mode (10/100/1000Mbps).
>>
>> Signed-off-by: Tan, Tee Min <tee.min.tan@linux.intel.com>
>> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
>> ---
>>   drivers/net/phy/marvell10g.c | 6 ++++++
>>   drivers/net/phy/phylink.c    | 4 ++++
>>   include/linux/phy.h          | 3 +++
>>   3 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
>> index d4bb90d76881..a9df19278618 100644
>> --- a/drivers/net/phy/marvell10g.c
>> +++ b/drivers/net/phy/marvell10g.c
>> @@ -30,6 +30,7 @@
>>   #include <linux/phy.h>
>>   #include <linux/sfp.h>
>>   #include <linux/netdevice.h>
>> +#include <linux/phylink.h>
>>   
>>   #define MV_PHY_ALASKA_NBT_QUIRK_MASK	0xfffffffe
>>   #define MV_PHY_ALASKA_NBT_QUIRK_REV	(MARVELL_PHY_ID_88X3310 | 0xa)
>> @@ -946,6 +947,9 @@ static void mv3310_update_interface(struct phy_device *phydev)
>>   	 * xaui / rxaui modes according to the speed.
>>   	 * Florian suggests setting phydev->interface to communicate this to the
>>   	 * MAC. Only do this if we are already in one of the above modes.
>> +	 * In-band Auto-negotiation is not supported in 2500BASE-X.
>> +	 * Setting phydev->cur_link_an_mode to communicate this to the
>> +	 * phylink framework.
>>   	 */
>>   	switch (phydev->speed) {
>>   	case SPEED_10000:
>> @@ -956,11 +960,13 @@ static void mv3310_update_interface(struct phy_device *phydev)
>>   		break;
>>   	case SPEED_2500:
>>   		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
>> +		phydev->cur_link_an_mode = MLO_AN_PHY;
>>   		break;
>>   	case SPEED_1000:
>>   	case SPEED_100:
>>   	case SPEED_10:
>>   		phydev->interface = PHY_INTERFACE_MODE_SGMII;
>> +		phydev->cur_link_an_mode = MLO_AN_INBAND;
>>   		break;
>>   	default:
>>   		break;
>> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
>> index 4f1c8bb199e9..f9cbb6d7e134 100644
>> --- a/drivers/net/phy/phylink.c
>> +++ b/drivers/net/phy/phylink.c
>> @@ -1720,6 +1720,8 @@ static void phylink_phy_change(struct phy_device *phydev, bool up)
>>   		pl->phy_state.pause |= MLO_PAUSE_RX;
>>   	pl->phy_state.interface = phydev->interface;
>>   	pl->phy_state.link = up;
>> +	pl->cur_link_an_mode = phydev->cur_link_an_mode;
>> +	pl->cfg_link_an_mode = phydev->cur_link_an_mode;
>>   	mutex_unlock(&pl->state_mutex);
>>   
>>   	phylink_run_resolve(pl);
>> @@ -1824,6 +1826,8 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
>>   	if (pl->config->mac_managed_pm)
>>   		phy->mac_managed_pm = true;
>>   
>> +	pl->phydev->cur_link_an_mode = pl->cur_link_an_mode;
> 
> I am really not happy with exposing phylink's AN mode into phylib.
> 
Hi Russell,

Thank you for the feedback.
After conducting further analysis on my end, it appears that this line 
"pl->phydev->cur_link_an_mode = pl->cur_link_an_mode;" is not necessary.
If we remove this line of code, would the implementation of this patch be 
acceptable to you?

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Choong Yong Liang]

On 4/8/2023 8:04 pm, Andrew Lunn wrote:
> On Fri, Aug 04, 2023 at 04:45:22PM +0800, Choong Yong Liang wrote:
>> Intel platforms’ integrated Gigabit Ethernet controllers support
>> 2.5Gbps mode statically using BIOS programming. In the current
>> implementation, the BIOS menu provides an option to select between
>> 10/100/1000Mbps and 2.5Gbps modes. Based on the selection, the BIOS
>> programs the Phase Lock Loop (PLL) registers. The BIOS also read the
>> TSN lane registers from Flexible I/O Adapter (FIA) block and provided
>> 10/100/1000Mbps/2.5Gbps information to the stmmac driver. But
>> auto-negotiation between 10/100/1000Mbps and 2.5Gbps is not allowed.
>> The new proposal is to support auto-negotiation between 10/100/1000Mbps
>> and 2.5Gbps . Auto-negotiation between 10, 100, 1000Mbps will use
>> in-band auto negotiation. Auto-negotiation between 10/100/1000Mbps and
>> 2.5Gbps will work as the following proposed flow, the stmmac driver reads
>> the PHY link status registers then identifies the negotiated speed.
>> Based on the speed stmmac driver will identify TSN lane registers from
>> FIA then send IPC command to the Power Management controller (PMC)
>> through PMC driver/API. PMC will act as a proxy to programs the
>> PLL registers.
> 
> Have you considered using out of band for all link modes? You might
> end up with a cleaner architecture, and not need any phylink/phylib
> hacks.
> 
> 	Andrew
Hi Andrew,

Thank you for your feedback.
I will study the feasibility of the out-of-band (OOB) approach.

Re: [PATCH net-next v2 1/5] platform/x86: intel_pmc_core: Add IPC mailbox accessor function and add SoC register access

[David E. Box]

Hi Hans,

On Mon, 2023-08-07 at 13:02 +0200, Hans de Goede wrote:
> > Hi David,
> > 
> > On 8/4/23 10:45, Choong Yong Liang wrote:
> > > > From: "David E. Box" <david.e.box@linux.intel.com>
> > > > 
> > > > - Exports intel_pmc_core_ipc() for host access to the PMC IPC mailbox
> > > > - Add support to use IPC command allows host to access SoC registers
> > > > through PMC firmware that are otherwise inaccessible to the host due to
> > > > security policies.
> > > > 
> > > > Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> > > > Signed-off-by: Chao Qin <chao.qin@intel.com>
> > > > Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> > 
> > The new exported intel_pmc_core_ipc() function does not seem to
> > depend on any existing PMC code.
> > 
> > IMHO it would be better to put this in a new .c file under
> > arch/x86/platform/intel/ this is where similar helpers like
> > the iosf_mbi functions also live.
> > 
> > This also avoids Kconfig complications. Currently the
> > drivers/platform/x86/intel/pmc/core.c code is only
> > build if CONFIG_X86_PLATFORM_DEVICES and
> > CONFIG_INTEL_PMC_CORE are both set. So if a driver
> > wants to make sure this is enabled by selecting them
> > then it needs to select both.

Yeah, makes sense. This is an old patch. Once upon a time the PMC driver was
going to use the IPC to access some registers but we were able to get them from
elsewhere. The patch was brought back for the TSN use case. But you're correct
that arch/x86/platform/intel makes more sense if the function is to be exported
now and doesn't require to PMC driver to discover the interface. We'll do that.

> > 
> > Talking about Kconfig:
> > 
> > #if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
> > int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf);
> > #else
> > static inline int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
> > {
> >         return -ENODEV;
> > }
> > #endif /* CONFIG_INTEL_PMC_CORE */
> > 
> > Notice that CONFIG_INTEL_PMC_CORE is a tristate, so pmc might be build as a
> > > module where as a consumer of intel_pmc_core_ipc() might end up builtin in
> > > which case this will not work without extra Kconfig protection. And if you
> > are > going to add extra Kconfig you might just as well select or depend on
> > > INTEL_PMC_CORE and drop the #if .

Sure. Thanks.

David

> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> > 
> > 
> > 
> > 
> > > > ---
> > > >  MAINTAINERS                                   |  1 +
> > > >  drivers/platform/x86/intel/pmc/core.c         | 60 +++++++++++++++++++
> > > >  .../linux/platform_data/x86/intel_pmc_core.h  | 41 +++++++++++++
> > > >  3 files changed, 102 insertions(+)
> > > >  create mode 100644 include/linux/platform_data/x86/intel_pmc_core.h
> > > > 
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 069e176d607a..8a034dee9da9 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -10648,6 +10648,7 @@ L:      platform-driver-x86@vger.kernel.org
> > > >  S:     Maintained
> > > >  F:     Documentation/ABI/testing/sysfs-platform-intel-pmc
> > > >  F:     drivers/platform/x86/intel/pmc/
> > > > +F:     linux/platform_data/x86/intel_pmc_core.h
> > > >  
> > > >  INTEL PMIC GPIO DRIVERS
> > > >  M:     Andy Shevchenko <andy@kernel.org>
> > > > diff --git a/drivers/platform/x86/intel/pmc/core.c > >
> > > > b/drivers/platform/x86/intel/pmc/core.c
> > > > index 5a36b3f77bc5..6fb1b0f453d8 100644
> > > > --- a/drivers/platform/x86/intel/pmc/core.c
> > > > +++ b/drivers/platform/x86/intel/pmc/core.c
> > > > @@ -20,6 +20,7 @@
> > > >  #include <linux/pci.h>
> > > >  #include <linux/slab.h>
> > > >  #include <linux/suspend.h>
> > > > +#include <linux/platform_data/x86/intel_pmc_core.h>
> > > >  
> > > >  #include <asm/cpu_device_id.h>
> > > >  #include <asm/intel-family.h>
> > > > @@ -28,6 +29,8 @@
> > > >  
> > > >  #include "core.h"
> > > >  
> > > > +#define PMC_IPCS_PARAM_COUNT           7
> > > > +
> > > >  /* Maximum number of modes supported by platfoms that has low power
> > > > mode > > capability */
> > > >  const char *pmc_lpm_modes[] = {
> > > >         "S0i2.0",
> > > > @@ -53,6 +56,63 @@ const struct pmc_bit_map msr_map[] = {
> > > >         {}
> > > >  };
> > > >  
> > > > +int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf)
> > > > +{
> > > > +       struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> > > > +       union acpi_object params[PMC_IPCS_PARAM_COUNT] = {
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +               {.type = ACPI_TYPE_INTEGER,},
> > > > +       };
> > > > +       struct acpi_object_list arg_list = { PMC_IPCS_PARAM_COUNT,
> > > > params };
> > > > +       union acpi_object *obj;
> > > > +       int status;
> > > > +
> > > > +       if (!ipc_cmd || !rbuf)
> > > > +               return -EINVAL;
> > > > +
> > > > +       /*
> > > > +        * 0: IPC Command
> > > > +        * 1: IPC Sub Command
> > > > +        * 2: Size
> > > > +        * 3-6: Write Buffer for offset
> > > > +        */
> > > > +       params[0].integer.value = ipc_cmd->cmd;
> > > > +       params[1].integer.value = ipc_cmd->sub_cmd;
> > > > +       params[2].integer.value = ipc_cmd->size;
> > > > +       params[3].integer.value = ipc_cmd->wbuf[0];
> > > > +       params[4].integer.value = ipc_cmd->wbuf[1];
> > > > +       params[5].integer.value = ipc_cmd->wbuf[2];
> > > > +       params[6].integer.value = ipc_cmd->wbuf[3];
> > > > +
> > > > +       status = acpi_evaluate_object(NULL, "\\IPCS", &arg_list,
> > > > &buffer);
> > > > +       if (ACPI_FAILURE(status))
> > > > +               return -ENODEV;
> > > > +
> > > > +       obj = buffer.pointer;
> > > > +       /* Check if the number of elements in package is 5 */
> > > > +       if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count
> > > > == > > 5) {
> > > > +               const union acpi_object *objs = obj->package.elements;
> > > > +
> > > > +               if ((u8)objs[0].integer.value != 0)
> > > > +                       return -EINVAL;
> > > > +
> > > > +               rbuf[0] = objs[1].integer.value;
> > > > +               rbuf[1] = objs[2].integer.value;
> > > > +               rbuf[2] = objs[3].integer.value;
> > > > +               rbuf[3] = objs[4].integer.value;
> > > > +       } else {
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(intel_pmc_core_ipc);
> > > > +
> > > >  static inline u32 pmc_core_reg_read(struct pmc *pmc, int reg_offset)
> > > >  {
> > > >         return readl(pmc->regbase + reg_offset);
> > > > diff --git a/include/linux/platform_data/x86/intel_pmc_core.h > >
> > > > b/include/linux/platform_data/x86/intel_pmc_core.h
> > > > new file mode 100644
> > > > index 000000000000..9bb3394fedcf
> > > > --- /dev/null
> > > > +++ b/include/linux/platform_data/x86/intel_pmc_core.h
> > > > @@ -0,0 +1,41 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +/*
> > > > + * Intel Core SoC Power Management Controller Header File
> > > > + *
> > > > + * Copyright (c) 2023, Intel Corporation.
> > > > + * All Rights Reserved.
> > > > + *
> > > > + * Authors: Choong Yong Liang <yong.liang.choong@linux.intel.com>
> > > > + *          David E. Box <david.e.box@linux.intel.com>
> > > > + */
> > > > +#ifndef INTEL_PMC_CORE_H
> > > > +#define INTEL_PMC_CORE_H
> > > > +
> > > > +#define IPC_SOC_REGISTER_ACCESS                        0xAA
> > > > +#define IPC_SOC_SUB_CMD_READ                   0x00
> > > > +#define IPC_SOC_SUB_CMD_WRITE                  0x01
> > > > +
> > > > +struct pmc_ipc_cmd {
> > > > +       u32 cmd;
> > > > +       u32 sub_cmd;
> > > > +       u32 size;
> > > > +       u32 wbuf[4];
> > > > +};
> > > > +
> > > > +#if IS_ENABLED(CONFIG_INTEL_PMC_CORE)
> > > > +/**
> > > > + * intel_pmc_core_ipc() - PMC IPC Mailbox accessor
> > > > + * @ipc_cmd:  struct pmc_ipc_cmd prepared with input to send
> > > > + * @rbuf:     Allocated u32[4] array for returned IPC data
> > > > + *
> > > > + * Return: 0 on success. Non-zero on mailbox error
> > > > + */
> > > > +int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 *rbuf);
> > > > +#else
> > > > +static inline int intel_pmc_core_ipc(struct pmc_ipc_cmd *ipc_cmd, u32 >
> > > > > *rbuf)
> > > > +{
> > > > +       return -ENODEV;
> > > > +}
> > > > +#endif /* CONFIG_INTEL_PMC_CORE */
> > > > +
> > > > +#endif /* INTEL_PMC_CORE_H */
> > 

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Choong Yong Liang]

On 4/8/2023 8:04 pm, Andrew Lunn wrote:
> On Fri, Aug 04, 2023 at 04:45:22PM +0800, Choong Yong Liang wrote:
>> Intel platforms’ integrated Gigabit Ethernet controllers support
>> 2.5Gbps mode statically using BIOS programming. In the current
>> implementation, the BIOS menu provides an option to select between
>> 10/100/1000Mbps and 2.5Gbps modes. Based on the selection, the BIOS
>> programs the Phase Lock Loop (PLL) registers. The BIOS also read the
>> TSN lane registers from Flexible I/O Adapter (FIA) block and provided
>> 10/100/1000Mbps/2.5Gbps information to the stmmac driver. But
>> auto-negotiation between 10/100/1000Mbps and 2.5Gbps is not allowed.
>> The new proposal is to support auto-negotiation between 10/100/1000Mbps
>> and 2.5Gbps . Auto-negotiation between 10, 100, 1000Mbps will use
>> in-band auto negotiation. Auto-negotiation between 10/100/1000Mbps and
>> 2.5Gbps will work as the following proposed flow, the stmmac driver reads
>> the PHY link status registers then identifies the negotiated speed.
>> Based on the speed stmmac driver will identify TSN lane registers from
>> FIA then send IPC command to the Power Management controller (PMC)
>> through PMC driver/API. PMC will act as a proxy to programs the
>> PLL registers.
> 
> Have you considered using out of band for all link modes? You might
> end up with a cleaner architecture, and not need any phylink/phylib
> hacks.
> 
> 	Andrew
Hi Andrew,

After conducting a comprehensive study, it seems that implementing 
out-of-band for all link modes might not be feasible. I may have missed 
some key aspects during my analysis.

Would you be open to sharing a high-level idea of how we could potentially 
make this feasible? Your insights would be greatly appreciated.

By the way, I've submitted a new design that not exposing phylink's AN mode 
into phylib. Please help review it to determine if it is acceptable.

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Andrew Lunn]

> Hi Andrew,
> 
> After conducting a comprehensive study, it seems that implementing
> out-of-band for all link modes might not be feasible. I may have missed some
> key aspects during my analysis.
> 
> Would you be open to sharing a high-level idea of how we could potentially
> make this feasible? Your insights would be greatly appreciated.

stmmac_mac_link_up() gets passed interface, speed and duplex. That
tells you what the PHY has negotiated. Is there anything else you need
to know?

   Andrew

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Russell King (Oracle)]

On Thu, Sep 21, 2023 at 08:25:05PM +0800, Choong Yong Liang wrote:
> 
> 
> On 4/8/2023 8:04 pm, Andrew Lunn wrote:
> > On Fri, Aug 04, 2023 at 04:45:22PM +0800, Choong Yong Liang wrote:
> > > Intel platforms’ integrated Gigabit Ethernet controllers support
> > > 2.5Gbps mode statically using BIOS programming. In the current
> > > implementation, the BIOS menu provides an option to select between
> > > 10/100/1000Mbps and 2.5Gbps modes. Based on the selection, the BIOS
> > > programs the Phase Lock Loop (PLL) registers. The BIOS also read the
> > > TSN lane registers from Flexible I/O Adapter (FIA) block and provided
> > > 10/100/1000Mbps/2.5Gbps information to the stmmac driver. But
> > > auto-negotiation between 10/100/1000Mbps and 2.5Gbps is not allowed.
> > > The new proposal is to support auto-negotiation between 10/100/1000Mbps
> > > and 2.5Gbps . Auto-negotiation between 10, 100, 1000Mbps will use
> > > in-band auto negotiation. Auto-negotiation between 10/100/1000Mbps and
> > > 2.5Gbps will work as the following proposed flow, the stmmac driver reads
> > > the PHY link status registers then identifies the negotiated speed.
> > > Based on the speed stmmac driver will identify TSN lane registers from
> > > FIA then send IPC command to the Power Management controller (PMC)
> > > through PMC driver/API. PMC will act as a proxy to programs the
> > > PLL registers.
> > 
> > Have you considered using out of band for all link modes? You might
> > end up with a cleaner architecture, and not need any phylink/phylib
> > hacks.
> > 
> > 	Andrew
> Hi Andrew,
> 
> After conducting a comprehensive study, it seems that implementing
> out-of-band for all link modes might not be feasible. I may have missed some
> key aspects during my analysis.

You need to provide details of why you think it's not feasible, because
you're making those reading your message have to guess.

We _do_ have cases where this is already supported. The DM7052 SFP
module for example has a BCM84881 PHY on board that has no in-band
support, so always has to use out-of-band. This module supports 10G,
5G, 2.5G, 1G, 100M and 10M speeds. It switches its interface between
10G, 2500base-X and SGMII mode. It's been supported in Linux for a
while with MAC/PCS that implement phylink _correctly_.

I wouldn't call stmmac a proper phylink implementation, especially
when it comes to switching between different interfaces.

My attempt at starting to clean up the stmmac code was thwarted by
niggly review comments (over whether %u or %d should be used to print
a _signed integer_ that stmmac stupidly implicitly casts to an unsigned
integer. That lead me to decide that stmmac was beyond being cleaned
up, so I junked the large patch set of improvements that I had - along
with multiple issues that I had found in the driver.

Someone else needs to sort stmmac out, and I suspect that may be a
pre-requisit for your changes so that stmmac operates _correctly_ with
phylink.

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

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Russell King (Oracle)]

On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote:
> > Hi Andrew,
> > 
> > After conducting a comprehensive study, it seems that implementing
> > out-of-band for all link modes might not be feasible. I may have missed some
> > key aspects during my analysis.
> > 
> > Would you be open to sharing a high-level idea of how we could potentially
> > make this feasible? Your insights would be greatly appreciated.
> 
> stmmac_mac_link_up() gets passed interface, speed and duplex. That
> tells you what the PHY has negotiated. Is there anything else you need
> to know?

The problem is... the stmmac driver is utter bollocks - that information
is *not* passed to the BSP. Instead, stmmac parse and store information
such as the PHY interface mode at initialisation time. BSPs also re-
parse and store e.g. the PHY interface mode at initialisation time.
The driver ignores what it gets from phylink.

The driver is basically utter crap. That's an area I _had_ patches to
clean up. I no longer do. stmmac is crap crap crap and will stay crap
until they become more receptive to patches to fix it, even if the
patches are not 100% to their liking but are in fact correct. Maybe
if I ever decide to touch that driver in the future. Which I doubt
given my recent experience.

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

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Andrew Lunn]

On Thu, Sep 21, 2023 at 03:12:19PM +0100, Russell King (Oracle) wrote:
> On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote:
> > > Hi Andrew,
> > > 
> > > After conducting a comprehensive study, it seems that implementing
> > > out-of-band for all link modes might not be feasible. I may have missed some
> > > key aspects during my analysis.
> > > 
> > > Would you be open to sharing a high-level idea of how we could potentially
> > > make this feasible? Your insights would be greatly appreciated.
> > 
> > stmmac_mac_link_up() gets passed interface, speed and duplex. That
> > tells you what the PHY has negotiated. Is there anything else you need
> > to know?
> 
> The problem is... the stmmac driver is utter bollocks - that information
> is *not* passed to the BSP. Instead, stmmac parse and store information
> such as the PHY interface mode at initialisation time. BSPs also re-
> parse and store e.g. the PHY interface mode at initialisation time.
> The driver ignores what it gets from phylink.
> 
> The driver is basically utter crap. That's an area I _had_ patches to
> clean up. I no longer do. stmmac is crap crap crap and will stay crap
> until they become more receptive to patches to fix it, even if the
> patches are not 100% to their liking but are in fact correct. Maybe
> if I ever decide to touch that driver in the future. Which I doubt
> given my recent experience.

Hi Russell

You pointed out the current proposal will break stuff. Do you see a
way forward for this patchset which does not first involve actually
cleaning up of this driver?

	Andrew

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Russell King (Oracle)]

On Thu, Sep 21, 2023 at 04:41:20PM +0200, Andrew Lunn wrote:
> On Thu, Sep 21, 2023 at 03:12:19PM +0100, Russell King (Oracle) wrote:
> > On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote:
> > > > Hi Andrew,
> > > > 
> > > > After conducting a comprehensive study, it seems that implementing
> > > > out-of-band for all link modes might not be feasible. I may have missed some
> > > > key aspects during my analysis.
> > > > 
> > > > Would you be open to sharing a high-level idea of how we could potentially
> > > > make this feasible? Your insights would be greatly appreciated.
> > > 
> > > stmmac_mac_link_up() gets passed interface, speed and duplex. That
> > > tells you what the PHY has negotiated. Is there anything else you need
> > > to know?
> > 
> > The problem is... the stmmac driver is utter bollocks - that information
> > is *not* passed to the BSP. Instead, stmmac parse and store information
> > such as the PHY interface mode at initialisation time. BSPs also re-
> > parse and store e.g. the PHY interface mode at initialisation time.
> > The driver ignores what it gets from phylink.
> > 
> > The driver is basically utter crap. That's an area I _had_ patches to
> > clean up. I no longer do. stmmac is crap crap crap and will stay crap
> > until they become more receptive to patches to fix it, even if the
> > patches are not 100% to their liking but are in fact correct. Maybe
> > if I ever decide to touch that driver in the future. Which I doubt
> > given my recent experience.
> 
> Hi Russell
> 
> You pointed out the current proposal will break stuff. Do you see a
> way forward for this patchset which does not first involve actually
> cleaning up of this driver?

As I said in one of my replies, it would really help if the author can
provide a table showing what is attempting to be achieved here. With
that, we should be able to work out exactly what is required, what
needs to change in stmmac, etc.

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

Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G

[Choong Yong Liang]

On 21/9/2023 10:55 pm, Russell King (Oracle) wrote:
> On Thu, Sep 21, 2023 at 04:41:20PM +0200, Andrew Lunn wrote:
>> On Thu, Sep 21, 2023 at 03:12:19PM +0100, Russell King (Oracle) wrote:
>>> On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> After conducting a comprehensive study, it seems that implementing
>>>>> out-of-band for all link modes might not be feasible. I may have missed some
>>>>> key aspects during my analysis.
>>>>>
>>>>> Would you be open to sharing a high-level idea of how we could potentially
>>>>> make this feasible? Your insights would be greatly appreciated.
>>>>
>>>> stmmac_mac_link_up() gets passed interface, speed and duplex. That
>>>> tells you what the PHY has negotiated. Is there anything else you need
>>>> to know?
>>>
>>> The problem is... the stmmac driver is utter bollocks - that information
>>> is *not* passed to the BSP. Instead, stmmac parse and store information
>>> such as the PHY interface mode at initialisation time. BSPs also re-
>>> parse and store e.g. the PHY interface mode at initialisation time.
>>> The driver ignores what it gets from phylink.
>>>
>>> The driver is basically utter crap. That's an area I _had_ patches to
>>> clean up. I no longer do. stmmac is crap crap crap and will stay crap
>>> until they become more receptive to patches to fix it, even if the
>>> patches are not 100% to their liking but are in fact correct. Maybe
>>> if I ever decide to touch that driver in the future. Which I doubt
>>> given my recent experience.
>>
>> Hi Russell
>>
>> You pointed out the current proposal will break stuff. Do you see a
>> way forward for this patchset which does not first involve actually
>> cleaning up of this driver?
> 
> As I said in one of my replies, it would really help if the author can
> provide a table showing what is attempting to be achieved here. With
> that, we should be able to work out exactly what is required, what
> needs to change in stmmac, etc.
> 

Thank you, Russell and Andrew for the comments.

What I'm trying to achieve here is to enable interface mode switching 
between 2500basex and SGMII interfaces for Intel platforms.

I did based on the DM7052 SFP module and BCM84881 PHY to make the necessary 
changes in the new version of my patch series.

In the new patch series, the 'allow_switch_interface' flag was introduced, 
based on the 'allow_switch_interface' flag, the interface mode is 
configured to PHY_INTERFACE_MODE_NA within the 'phylink_validate_phy' 
function. This setting allows all ethtool link modes that are supported and 
advertised will be published. Then interface mode switching occurs based on
the selection of different link modes.

During the interface mode switching, the code will go through the 
`phylink_major_config` function and based on the interface mode to select 
PCS and PCS negotiation mode to configure PCS. Then, the MAC driver will 
perform SerDes configuration according to the interface mode.

I did rewrite the description for the new patch series, hoping that it is 
clear to describe the whole intention of the changes.