mbox series

[net-next,v2,0/5] Add PCS support for Qualcomm IPQ9574 SoC

Message ID 20241204-ipq_pcs_rc1-v2-0-26155f5364a1@quicinc.com
Headers show
Series Add PCS support for Qualcomm IPQ9574 SoC | expand

Message

Lei Wei Dec. 4, 2024, 2:43 p.m. UTC
The 'UNIPHY' PCS block in the Qualcomm IPQ9574 SoC provides Ethernet
PCS and SerDes functions. It supports 1Gbps mode PCS and 10-Gigabit
mode PCS (XPCS) functions, and supports various interface modes for
the connectivity between the Ethernet MAC and the external PHYs/Switch.
There are three UNIPHY (PCS) instances in IPQ9574, supporting the six
Ethernet ports.

This patch series adds base driver support for initializing the PCS,
and PCS phylink ops for managing the PCS modes/states. Support for
SGMII/QSGMII (PCS) and USXGMII (XPCS) modes is being added initially.

The Ethernet driver which handles the MAC operations will create the
PCS instances and phylink for the MAC, by utilizing the API exported
by this driver.

While support is being added initially for IPQ9574, the driver is
expected to be easily extendable later for other SoCs in the IPQ
family such as IPQ5332.

Signed-off-by: Lei Wei <quic_leiwei@quicinc.com>
---
Changes in v2:
- dtbindings updates
  a.) Rename dt-binding header file to match binding file name.
  b.) Drop unused labels and the redundant examples.
  c.) Rename "mii_rx"/"mii_tx" clock names to "rx"/"tx".
- Rename "PCS_QCOM_IPQ" with specific name "PCS_QCOM_IPQ9574" in
  Kconfig.
- Remove interface mode check for the PCS lock.
- Use Cisco SGMII AN mode as default SGMII/QSGMII AN mode.
- Instantiate MII PCS instances in probe and export "ipq_pcs_get" and
  "ipq_pcs_put" APIs.
- Move MII RX and TX clock enable and disable to "pcs_enable" and
  "pcs_disable" methods.
- Change "dev_dbg" to "dev_dbg_ratelimited" in "pcs_get_state" method.
- Link to v1: https://lore.kernel.org/r/20241101-ipq_pcs_rc1-v1-0-fdef575620cf@quicinc.com

---
Lei Wei (5):
      dt-bindings: net: pcs: Add Ethernet PCS for Qualcomm IPQ9574 SoC
      net: pcs: Add PCS driver for Qualcomm IPQ9574 SoC
      net: pcs: qcom-ipq9574: Add PCS instantiation and phylink operations
      net: pcs: qcom-ipq9574: Add USXGMII interface mode support
      MAINTAINERS: Add maintainer for Qualcomm IPQ9574 PCS driver

 .../bindings/net/pcs/qcom,ipq9574-pcs.yaml         | 190 +++++
 MAINTAINERS                                        |   9 +
 drivers/net/pcs/Kconfig                            |   9 +
 drivers/net/pcs/Makefile                           |   1 +
 drivers/net/pcs/pcs-qcom-ipq9574.c                 | 884 +++++++++++++++++++++
 include/dt-bindings/net/qcom,ipq9574-pcs.h         |  15 +
 include/linux/pcs/pcs-qcom-ipq9574.h               |  16 +
 7 files changed, 1124 insertions(+)
---
base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc
change-id: 20241101-ipq_pcs_rc1-26ae183c9c63

Best regards,

Comments

Lei Wei Dec. 6, 2024, 4:20 p.m. UTC | #1
On 12/4/2024 11:38 PM, Russell King (Oracle) wrote:
> On Wed, Dec 04, 2024 at 10:43:56PM +0800, Lei Wei wrote:
>> +static int ipq_pcs_link_up_config_usxgmii(struct ipq_pcs *qpcs, int speed)
>> +{
> ...
>> +	/* USXGMII only support full duplex mode */
>> +	val |= XPCS_DUPLEX_FULL;
> 
> Again... this restriction needs to be implemented in .pcs_validate() by
> knocking out the half-duplex link modes when using USXGMII mode.
> 
> .pcs_validate() needs to be implemented whenever the PCS has
> restrictions beyond what is standard for the PHY interface mode.
> 

Currently, it seems there is no phylink_validate() call in 
phylink_resolve(), to validate the resolved duplex/speed which is 
notified by phydev when the PHY is linked up. So I am thinking to add 
this duplex check in this link_up op, and return an appropriate error in 
case of half-duplex. (Kindly correct me if I am wrong).

> Thanks.
>
Russell King (Oracle) Dec. 6, 2024, 4:31 p.m. UTC | #2
On Sat, Dec 07, 2024 at 12:20:57AM +0800, Lei Wei wrote:
> On 12/4/2024 11:38 PM, Russell King (Oracle) wrote:
> > On Wed, Dec 04, 2024 at 10:43:56PM +0800, Lei Wei wrote:
> > > +static int ipq_pcs_link_up_config_usxgmii(struct ipq_pcs *qpcs, int speed)
> > > +{
> > ...
> > > +	/* USXGMII only support full duplex mode */
> > > +	val |= XPCS_DUPLEX_FULL;
> > 
> > Again... this restriction needs to be implemented in .pcs_validate() by
> > knocking out the half-duplex link modes when using USXGMII mode.
> > 
> > .pcs_validate() needs to be implemented whenever the PCS has
> > restrictions beyond what is standard for the PHY interface mode.
> > 
> 
> Currently, it seems there is no phylink_validate() call in
> phylink_resolve(), to validate the resolved duplex/speed which is notified
> by phydev when the PHY is linked up. So I am thinking to add this duplex
> check in this link_up op, and return an appropriate error in case of
> half-duplex. (Kindly correct me if I am wrong).

Doing validation at that point is way too late.

We don't want the PHY e.g. even advertising a half-duplex link mode if
the system as a whole can not support half-duplex modes. If the system
can't support half-duplex, then trying to trap it out at resolve time
would be way too late - the media has already negotiated a half-duplex
link, and that's that.

Instead, phylink takes the approach of restricting the media
advertisement according to the properties of the system, thereby
preventing invalid configurations _way_ before we get to autoneg
completion and calling phylink_resolve().