| Message ID | 20231126060732.31764-4-quic_luoj@quicinc.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | add qca8084 ethernet phy driver | expand |
> + /* There are two PCSs available for QCA8084, which support the > + * following interface modes. > + * > + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all > + * available 4 ports, which is for all link speeds. > + * > + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the > + * fourth port, which is only for the link speed 2500M same > + * as QCA8081. > + * > + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth > + * port, which is for the link speed 10M, 100M and 1000M same > + * as QCA8081. > + */ How are these 3 modes configured? I don't see any software configuration of this in these drivers. Can it only by configured by strapping? I think there should be some validation of the phydev->interface mode. Are ports 1-3 set to PHY_INTERFACE_MODE_10G_QXGMII? Is port 4 interface mode consistent with the strapping? Andrew
On 11/27/2023 1:31 AM, Andrew Lunn wrote: >> + /* There are two PCSs available for QCA8084, which support the >> + * following interface modes. >> + * >> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all >> + * available 4 ports, which is for all link speeds. >> + * >> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the >> + * fourth port, which is only for the link speed 2500M same >> + * as QCA8081. >> + * >> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth >> + * port, which is for the link speed 10M, 100M and 1000M same >> + * as QCA8081. >> + */ > > How are these 3 modes configured? I don't see any software > configuration of this in these drivers. Can it only by configured by > strapping? The interface mode is passed in the .config_init, which is configured by the PCS driver, the hardware register is located in the PCS, this driver will be pushed later. > > I think there should be some validation of the phydev->interface > mode. Are ports 1-3 set to PHY_INTERFACE_MODE_10G_QXGMII? Is port 4 > interface mode consistent with the strapping? > > Andrew All ports(1-4) can be PHY_INTERFACE_MODE_10G_QXGMII, if port4 is connected with PCS0, which will works on sgmii/2500basex mode, these configuration is controlled by register instead of boot strapping.
On Mon, Nov 27, 2023 at 02:21:46PM +0800, Jie Luo wrote: > > > On 11/27/2023 1:31 AM, Andrew Lunn wrote: > > > + /* There are two PCSs available for QCA8084, which support the > > > + * following interface modes. > > > + * > > > + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all > > > + * available 4 ports, which is for all link speeds. > > > + * > > > + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the > > > + * fourth port, which is only for the link speed 2500M same > > > + * as QCA8081. > > > + * > > > + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth > > > + * port, which is for the link speed 10M, 100M and 1000M same > > > + * as QCA8081. > > > + */ > > > > How are these 3 modes configured? I don't see any software > > configuration of this in these drivers. Can it only by configured by > > strapping? > > The interface mode is passed in the .config_init, which is configured > by the PCS driver, the hardware register is located in the PCS, this > driver will be pushed later. Is this the same as how the syqca807x works? Can the PCS driver be shared by these two drivers? What i don't like at the moment is that we have two driver developments going on at once for hardware which seems very similar, but no apparent cooperation? Andrew
On 11/27/2023 9:22 PM, Andrew Lunn wrote: > On Mon, Nov 27, 2023 at 02:21:46PM +0800, Jie Luo wrote: >> >> >> On 11/27/2023 1:31 AM, Andrew Lunn wrote: >>>> + /* There are two PCSs available for QCA8084, which support the >>>> + * following interface modes. >>>> + * >>>> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all >>>> + * available 4 ports, which is for all link speeds. >>>> + * >>>> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the >>>> + * fourth port, which is only for the link speed 2500M same >>>> + * as QCA8081. >>>> + * >>>> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth >>>> + * port, which is for the link speed 10M, 100M and 1000M same >>>> + * as QCA8081. >>>> + */ >>> >>> How are these 3 modes configured? I don't see any software >>> configuration of this in these drivers. Can it only by configured by >>> strapping? >> >> The interface mode is passed in the .config_init, which is configured >> by the PCS driver, the hardware register is located in the PCS, this >> driver will be pushed later. > > Is this the same as how the syqca807x works? Can the PCS driver be > shared by these two drivers? I am not sure syqca807x, would you point me the code path of this driver? > > What i don't like at the moment is that we have two driver > developments going on at once for hardware which seems very similar, > but no apparent cooperation? > > Andrew The PCS of qca8084 is the PHY PCS, which should be new PCS driver, in the previous chips, we don't have this kind of PHY PCS.
On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: > > > The interface mode is passed in the .config_init, which is configured > > > by the PCS driver, the hardware register is located in the PCS, this > > > driver will be pushed later. > > > > Is this the same as how the syqca807x works? Can the PCS driver be > > shared by these two drivers? > > I am not sure syqca807x, would you point me the code path of this driver? > > > > > What i don't like at the moment is that we have two driver > > developments going on at once for hardware which seems very similar, > > but no apparent cooperation? > > > > Andrew > > The PCS of qca8084 is the PHY PCS, which should be new PCS driver, > in the previous chips, we don't have this kind of PHY PCS. No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. +------------- | PHY MAC---PCS --- link --- PCS --- ... ^ | ^ | +--|---------- For this PCS | Not for this PCS
On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: > On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: >>>> The interface mode is passed in the .config_init, which is configured >>>> by the PCS driver, the hardware register is located in the PCS, this >>>> driver will be pushed later. >>> >>> Is this the same as how the syqca807x works? Can the PCS driver be >>> shared by these two drivers? >> >> I am not sure syqca807x, would you point me the code path of this driver? >> >>> >>> What i don't like at the moment is that we have two driver >>> developments going on at once for hardware which seems very similar, >>> but no apparent cooperation? >>> >>> Andrew >> >> The PCS of qca8084 is the PHY PCS, which should be new PCS driver, >> in the previous chips, we don't have this kind of PHY PCS. > > No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. > > +------------- > | PHY > MAC---PCS --- link --- PCS --- ... > ^ | ^ > | +--|---------- > For this PCS | > Not for this PCS > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device registers.
On Tue, Nov 28, 2023 at 05:50:41PM +0800, Jie Luo wrote: > > > On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: > > On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: > > > > > The interface mode is passed in the .config_init, which is configured > > > > > by the PCS driver, the hardware register is located in the PCS, this > > > > > driver will be pushed later. > > > > > > > > Is this the same as how the syqca807x works? Can the PCS driver be > > > > shared by these two drivers? > > > > > > I am not sure syqca807x, would you point me the code path of this driver? > > > > > > > > > > > What i don't like at the moment is that we have two driver > > > > developments going on at once for hardware which seems very similar, > > > > but no apparent cooperation? > > > > > > > > Andrew > > > > > > The PCS of qca8084 is the PHY PCS, which should be new PCS driver, > > > in the previous chips, we don't have this kind of PHY PCS. > > > > No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. > > > > +------------- > > | PHY > > MAC---PCS --- link --- PCS --- ... > > ^ | ^ > > | +--|---------- > > For this PCS | > > Not for this PCS > > > > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as > pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device > registers. Wrong. No they are not. Just because they are accessed via MDIO does not mean they are in the PHY. MDIO can be used for more than just the PHY, and is on a lot of platforms. LX2160A for example has many MDIO buses, and the PCSes (of which there are multiple inside the chip, and use pcs-lynx) are accessed through the MDIO bus specific to each port. They are not MMIO mapped. The same is true on stmmac platforms, where xpcs is used - xpcs is the _MAC_ side PCS. Sorry but you are wrong.
On 11/28/2023 6:35 PM, Russell King (Oracle) wrote: > On Tue, Nov 28, 2023 at 05:50:41PM +0800, Jie Luo wrote: >> >> >> On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: >>> On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: >>>>>> The interface mode is passed in the .config_init, which is configured >>>>>> by the PCS driver, the hardware register is located in the PCS, this >>>>>> driver will be pushed later. >>>>> >>>>> Is this the same as how the syqca807x works? Can the PCS driver be >>>>> shared by these two drivers? >>>> >>>> I am not sure syqca807x, would you point me the code path of this driver? >>>> >>>>> >>>>> What i don't like at the moment is that we have two driver >>>>> developments going on at once for hardware which seems very similar, >>>>> but no apparent cooperation? >>>>> >>>>> Andrew >>>> >>>> The PCS of qca8084 is the PHY PCS, which should be new PCS driver, >>>> in the previous chips, we don't have this kind of PHY PCS. >>> >>> No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. >>> >>> +------------- >>> | PHY >>> MAC---PCS --- link --- PCS --- ... >>> ^ | ^ >>> | +--|---------- >>> For this PCS | >>> Not for this PCS >>> >> >> The PCS drivers in drivers/net/pcs/ should be in PHY side, such as >> pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device >> registers. > > Wrong. No they are not. Just because they are accessed via MDIO does > not mean they are in the PHY. MDIO can be used for more than just the > PHY, and is on a lot of platforms. > > LX2160A for example has many MDIO buses, and the PCSes (of which there > are multiple inside the chip, and use pcs-lynx) are accessed through > the MDIO bus specific to each port. They are not MMIO mapped. > > The same is true on stmmac platforms, where xpcs is used - xpcs is the > _MAC_ side PCS. > > Sorry but you are wrong. > OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c looks like this PCS is located in PHY device from hardware perspective.
On Wed, Nov 29, 2023 at 06:34:16PM +0800, Jie Luo wrote: > > > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as > > > pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device > > > registers. > > > > Wrong. No they are not. Just because they are accessed via MDIO does > > not mean they are in the PHY. MDIO can be used for more than just the > > PHY, and is on a lot of platforms. > > > > LX2160A for example has many MDIO buses, and the PCSes (of which there > > are multiple inside the chip, and use pcs-lynx) are accessed through > > the MDIO bus specific to each port. They are not MMIO mapped. > > > > The same is true on stmmac platforms, where xpcs is used - xpcs is the > > _MAC_ side PCS. > > > > Sorry but you are wrong. > > > > OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c > looks like this PCS is located in PHY device from hardware perspective. In some ways, this contradiction has a potato-patato aspect to it. As Russell says, NXP devices do have internal SGMII/USXGMII/10GBASE-R ports which use pcs-lynx.c to access the registers of the PCS layer (which are on MDIO buses internal to the SoC). They could legally be called PHYs, because they have all the layers that 802.3 says a PHY should have: a PCS, a PMA and a PMD. But what phylib understands a phy_device to be is a more restricted definition than just "a PHY - any PHY". Originally, phylib considered a struct phy_device to be something (a discrete chip) that has pins and a phy_interface_t towards its host side, and pins + an ethtool_link_mode_bit_indices on its media side. Traditionally, the media side is exclusively copper (BASE-T, BASE-T1) or fiber (BASE-SX/LX). A struct phy_device was then also used with PHY_INTERFACE_MODE_INTERNAL to represent the built-in BASE-T PHYs that are embedded within certain small/medium business Ethernet switches. And then, more and more other similar embedded copper PHYs. The idea is that (1) a phy_device connects to a remote system, and (2) the phylib API does not have insight into the components of the PHY it controls: PCS, PMA, PMD. It's all just a monolithic struct phy_device. Because there are serial phy_interface_t modes where the MAC also need a PHY to even connect to the phylib PHY, a problem presented itself: phylib only has support for a single phy_device. So a new framework appeared: phylink, which uses the unmodified phylib layer for the external PHY, but models the MAC-side PHY using a different API. Later on, that API became the phylink_pcs. To muddy the waters, a phylink_pcs structure usually connects to another local component as described above, like a phylib PHY (on-board or on an SFP module). But it can also connect directly to a remote system (like a phy_device would). But the phylink_pcs is always integrated in silicon with the MAC, and the "media side" of it is a phy_interface_t type, not an ethtool_link_mode_bit_indices type. Having a separate phylink_pcs is what allows us to work around phylib's limitation of having a single phy_device. The reverse is also true: you can have a single phylink_pcs, and that belongs to the client MAC driver. The other layers (PMA/PMD) of the MAC-side PHY are modeled in the kernel as a struct phy (https://docs.kernel.org/driver-api/phy/index.html), and we have the phy_set_mode_ext() API for reconfiguring this layer to a different mode. Again, this is not applicable for phylib PHYs, which are monolithic. Given the above definitions, what NXP has and drives with pcs-lynx.c is not a struct phy_device, but a MAC-side PCS represented by a phylink_pcs. It absolutely does not matter that the register access method for the PCS is an internal MDIO bus. FWIW, the PMA/PMD layer is at drivers/phy/freescale/phy-fsl-lynx-28g.c. So, if put into the proper context, what Russell is saying is correct, but I think you need a bit of history to not get even more confused about why it is the way it is.
On 11/29/2023 8:04 PM, Vladimir Oltean wrote: > On Wed, Nov 29, 2023 at 06:34:16PM +0800, Jie Luo wrote: >>>> The PCS drivers in drivers/net/pcs/ should be in PHY side, such as >>>> pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device >>>> registers. >>> >>> Wrong. No they are not. Just because they are accessed via MDIO does >>> not mean they are in the PHY. MDIO can be used for more than just the >>> PHY, and is on a lot of platforms. >>> >>> LX2160A for example has many MDIO buses, and the PCSes (of which there >>> are multiple inside the chip, and use pcs-lynx) are accessed through >>> the MDIO bus specific to each port. They are not MMIO mapped. >>> >>> The same is true on stmmac platforms, where xpcs is used - xpcs is the >>> _MAC_ side PCS. >>> >>> Sorry but you are wrong. >>> >> >> OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c >> looks like this PCS is located in PHY device from hardware perspective. > > In some ways, this contradiction has a potato-patato aspect to it. > As Russell says, NXP devices do have internal SGMII/USXGMII/10GBASE-R > ports which use pcs-lynx.c to access the registers of the PCS layer > (which are on MDIO buses internal to the SoC). They could legally be > called PHYs, because they have all the layers that 802.3 says a PHY > should have: a PCS, a PMA and a PMD. > > But what phylib understands a phy_device to be is a more restricted > definition than just "a PHY - any PHY". Originally, phylib considered a > struct phy_device to be something (a discrete chip) that has pins and a > phy_interface_t towards its host side, and pins + an ethtool_link_mode_bit_indices > on its media side. > > Traditionally, the media side is exclusively copper (BASE-T, BASE-T1) or > fiber (BASE-SX/LX). > > A struct phy_device was then also used with PHY_INTERFACE_MODE_INTERNAL > to represent the built-in BASE-T PHYs that are embedded within certain > small/medium business Ethernet switches. And then, more and more other > similar embedded copper PHYs. > > The idea is that (1) a phy_device connects to a remote system, and > (2) the phylib API does not have insight into the components of the > PHY it controls: PCS, PMA, PMD. It's all just a monolithic struct phy_device. > > Because there are serial phy_interface_t modes where the MAC also need a > PHY to even connect to the phylib PHY, a problem presented itself: > phylib only has support for a single phy_device. So a new framework > appeared: phylink, which uses the unmodified phylib layer for the > external PHY, but models the MAC-side PHY using a different API. Later > on, that API became the phylink_pcs. > > To muddy the waters, a phylink_pcs structure usually connects to another > local component as described above, like a phylib PHY (on-board or on an > SFP module). But it can also connect directly to a remote system (like a > phy_device would). But the phylink_pcs is always integrated in silicon > with the MAC, and the "media side" of it is a phy_interface_t type, not > an ethtool_link_mode_bit_indices type. > > Having a separate phylink_pcs is what allows us to work around phylib's > limitation of having a single phy_device. The reverse is also true: you > can have a single phylink_pcs, and that belongs to the client MAC driver. > > The other layers (PMA/PMD) of the MAC-side PHY are modeled in the kernel > as a struct phy (https://docs.kernel.org/driver-api/phy/index.html), and > we have the phy_set_mode_ext() API for reconfiguring this layer to a > different mode. Again, this is not applicable for phylib PHYs, which are > monolithic. > > Given the above definitions, what NXP has and drives with pcs-lynx.c is > not a struct phy_device, but a MAC-side PCS represented by a phylink_pcs. > It absolutely does not matter that the register access method for the > PCS is an internal MDIO bus. FWIW, the PMA/PMD layer is at > drivers/phy/freescale/phy-fsl-lynx-28g.c. > > So, if put into the proper context, what Russell is saying is correct, > but I think you need a bit of history to not get even more confused > about why it is the way it is. Thanks Vladimir for the detail information, i just get this message, which is helpful to me.
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c index 37fb033e1c29..f376d794d170 100644 --- a/drivers/net/phy/at803x.c +++ b/drivers/net/phy/at803x.c @@ -176,6 +176,7 @@ #define AT8030_PHY_ID_MASK 0xffffffef #define QCA8081_PHY_ID 0x004dd101 +#define QCA8084_PHY_ID 0x004dd180 #define QCA8327_A_PHY_ID 0x004dd033 #define QCA8327_B_PHY_ID 0x004dd034 @@ -1760,6 +1761,9 @@ static bool qca808x_is_prefer_master(struct phy_device *phydev) static bool qca808x_has_fast_retrain_or_slave_seed(struct phy_device *phydev) { + if (phydev_id_compare(phydev, QCA8084_PHY_ID)) + return false; + return linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->supported); } @@ -1824,6 +1828,23 @@ static int qca808x_read_status(struct phy_device *phydev) return ret; if (phydev->link) { + /* There are two PCSs available for QCA8084, which support the + * following interface modes. + * + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all + * available 4 ports, which is for all link speeds. + * + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the + * fourth port, which is only for the link speed 2500M same + * as QCA8081. + * + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth + * port, which is for the link speed 10M, 100M and 1000M same + * as QCA8081. + */ + if (phydev->interface == PHY_INTERFACE_MODE_10G_QXGMII) + return 0; + if (phydev->speed == SPEED_2500) phydev->interface = PHY_INTERFACE_MODE_2500BASEX; else @@ -1958,6 +1979,14 @@ static int qca808x_cable_test_start(struct phy_device *phydev) phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807a, 0xc060); phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807e, 0xb060); + if (phydev_id_compare(phydev, QCA8084_PHY_ID)) { + /* Adjust the positive and negative pulse thereshold of CDT */ + phy_write_mmd(phydev, MDIO_MMD_PCS, 0x8075, 0xa060); + + /* Disable the near echo bypass */ + phy_modify_mmd(phydev, MDIO_MMD_PCS, 0x807f, BIT(15), 0); + } + return 0; } @@ -2227,6 +2256,26 @@ static struct phy_driver at803x_driver[] = { .cable_test_start = qca808x_cable_test_start, .cable_test_get_status = qca808x_cable_test_get_status, .link_change_notify = qca808x_link_change_notify, +}, { + /* Qualcomm QCA8084 */ + PHY_ID_MATCH_MODEL(QCA8084_PHY_ID), + .name = "Qualcomm QCA8084", + .flags = PHY_POLL_CABLE_TEST, + .probe = at803x_probe, + .config_intr = at803x_config_intr, + .handle_interrupt = at803x_handle_interrupt, + .get_tunable = at803x_get_tunable, + .set_tunable = at803x_set_tunable, + .set_wol = at803x_set_wol, + .get_wol = at803x_get_wol, + .get_features = qca808x_get_features, + .config_aneg = at803x_config_aneg, + .suspend = genphy_suspend, + .resume = genphy_resume, + .read_status = qca808x_read_status, + .soft_reset = qca808x_soft_reset, + .cable_test_start = qca808x_cable_test_start, + .cable_test_get_status = qca808x_cable_test_get_status, }, }; module_phy_driver(at803x_driver); @@ -2242,6 +2291,7 @@ static struct mdio_device_id __maybe_unused atheros_tbl[] = { { PHY_ID_MATCH_EXACT(QCA8327_B_PHY_ID) }, { PHY_ID_MATCH_EXACT(QCA9561_PHY_ID) }, { PHY_ID_MATCH_EXACT(QCA8081_PHY_ID) }, + { PHY_ID_MATCH_MODEL(QCA8084_PHY_ID) }, { } };
Add qca8084 PHY support, which is four-port PHY with maximum link capability 2.5G, the features of each port is almost same as QCA8081 and slave seed config is not needed. Three kind of interface modes supported by qca8084. PHY_INTERFACE_MODE_10G_QXGMII, PHY_INTERFACE_MODE_2500BASEX and PHY_INTERFACE_MODE_SGMII. The PCS(serdes) and clock are also needed to be configured to bringup qca8084 PHY, which will be added in the pcs driver. The additional CDT configurations used for qca8084. Signed-off-by: Luo Jie <quic_luoj@quicinc.com> --- drivers/net/phy/at803x.c | 50 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+)