diff mbox series

[v6,3/6] net: phy: at803x: add QCA8084 ethernet phy support

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

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/codegen success Generated files up to date
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1115 this patch: 1115
netdev/cc_maintainers success CCed 7 of 7 maintainers
netdev/build_clang success Errors and warnings before: 1142 this patch: 1142
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 1142 this patch: 1142
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 86 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Jie Luo Nov. 26, 2023, 6:07 a.m. UTC
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(+)

Comments

Andrew Lunn Nov. 26, 2023, 5:31 p.m. UTC | #1
> +		/* 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
Jie Luo Nov. 27, 2023, 6:21 a.m. UTC | #2
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.
Andrew Lunn Nov. 27, 2023, 1:22 p.m. UTC | #3
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
Jie Luo Nov. 28, 2023, 7:16 a.m. UTC | #4
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.
Russell King (Oracle) Nov. 28, 2023, 9 a.m. UTC | #5
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
Jie Luo Nov. 28, 2023, 9:50 a.m. UTC | #6
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.
Russell King (Oracle) Nov. 28, 2023, 10:35 a.m. UTC | #7
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.
Jie Luo Nov. 29, 2023, 10:34 a.m. UTC | #8
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.
Vladimir Oltean Nov. 29, 2023, 12:04 p.m. UTC | #9
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.
Jie Luo Dec. 1, 2023, 8:05 a.m. UTC | #10
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 mbox series

Patch

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) },
 	{ }
 };