mbox series

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

Message ID 20230921121946.3025771-1-yong.liang.choong@linux.intel.com (mailing list archive)
Headers show
Series TSN auto negotiation between 1G and 2.5G | expand

Message

Choong Yong Liang Sept. 21, 2023, 12:19 p.m. UTC
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: 
 - 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.

v2 -> v3:
 - Create `pmc_ipc.c` file for `intel_pmc_ipc()` function and 
 allocate the file in `arch/x86/platform/intel/` directory.
 - Update phylink's AN mode during phy interface change and 
 not exposing phylink's AN mode into phylib.

---

Choong Yong Liang (2):
  net: phy: update in-band AN mode when changing interface by PHY driver
  stmmac: intel: Add 1G/2.5G auto-negotiation support for ADL-N

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

Tan, Tee Min (2):
  net: pcs: xpcs: combine C37 SGMII AN and 2500BASEX for Intel mGbE
    controller
  net: stmmac: enable Intel mGbE 1G/2.5G auto-negotiation support

 MAINTAINERS                                   |   2 +
 arch/x86/Kconfig                              |   9 +
 arch/x86/platform/intel/Makefile              |   1 +
 arch/x86/platform/intel/pmc_ipc.c             |  75 +++++++
 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/phylink.c                     |  30 ++-
 include/linux/pcs/pcs-xpcs.h                  |   1 +
 .../linux/platform_data/x86/intel_pmc_ipc.h   |  34 ++++
 include/linux/stmmac.h                        |   1 +
 13 files changed, 493 insertions(+), 17 deletions(-)
 create mode 100644 arch/x86/platform/intel/pmc_ipc.c
 create mode 100644 include/linux/platform_data/x86/intel_pmc_ipc.h

Comments

Andrew Lunn Sept. 21, 2023, 1:14 p.m. UTC | #1
> 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.

I don't think you replied to my comment.

in-band is just an optimisation. It in theory allows you to avoid a
software path, the PHY driver talking to the MAC driver about the PHY
status. As an optimisation, it is optional. Linux has the software
path and the MAC driver you are using basically has it implemented.

Why use this odd mix of in-band and out of band? It seems the change
will be simpler if you just use the out of band method all the time
and ignore in-band.

	Andrew
Russell King (Oracle) Sept. 21, 2023, 2:09 p.m. UTC | #2
On Thu, Sep 21, 2023 at 03:14:59PM +0200, Andrew Lunn wrote:
> > 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.
> 
> I don't think you replied to my comment.
> 
> in-band is just an optimisation. It in theory allows you to avoid a
> software path, the PHY driver talking to the MAC driver about the PHY
> status. As an optimisation, it is optional. Linux has the software
> path and the MAC driver you are using basically has it implemented.

Sorry Andrew, I have to disagree. It isn't always optional - there are
PHYs out there where they won't pass data until the in-band exchange
has completed. If you try to operate out-of-band without the PHY being
told that is the case, and program the MAC/PCS end not to respond to
the in-band frames from the PHY, the PHY will report link up as normal
(since it reports the media side), but no data will flow because the
MAC facing side of the PHY hasn't completed.

The only exception are PHYs that default to in-band but have an inband
bypass mode also enabled to cover the case where the MAC/PCS doesn't
respond to the inband messages.
Choong Yong Liang Jan. 29, 2024, 1:13 p.m. UTC | #3
On 21/9/2023 10:09 pm, Russell King (Oracle) wrote:
> On Thu, Sep 21, 2023 at 03:14:59PM +0200, Andrew Lunn wrote:
>>> 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.
>>
>> I don't think you replied to my comment.
>>
>> in-band is just an optimisation. It in theory allows you to avoid a
>> software path, the PHY driver talking to the MAC driver about the PHY
>> status. As an optimisation, it is optional. Linux has the software
>> path and the MAC driver you are using basically has it implemented.
> 
> Sorry Andrew, I have to disagree. It isn't always optional - there are
> PHYs out there where they won't pass data until the in-band exchange
> has completed. If you try to operate out-of-band without the PHY being
> told that is the case, and program the MAC/PCS end not to respond to
> the in-band frames from the PHY, the PHY will report link up as normal
> (since it reports the media side), but no data will flow because the
> MAC facing side of the PHY hasn't completed.
> 
> The only exception are PHYs that default to in-band but have an inband
> bypass mode also enabled to cover the case where the MAC/PCS doesn't
> respond to the inband messages.
> 
Russell is correct, we did set out-of-band for PCS and configured MAC.
Due to the PHY not being completed, there will be no data flow through.