netdev - [PATCH net-next 0/6] net: Introduce Ethernet Inband Extensions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220519135647.465653-1-maxime.chevallier@bootlin.com>
Date:   Thu, 19 May 2022 15:56:41 +0200
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     davem@...emloft.net, Rob Herring <robh+dt@...nel.org>
Cc:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, thomas.petazzoni@...tlin.com,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org,
        Richard Cochran <richardcochran@...il.com>,
        Horatiu.Vultur@...rochip.com, Allan.Nielsen@...rochip.com,
        UNGLinuxDriver@...rochip.com
Subject: [PATCH net-next 0/6] net: Introduce Ethernet Inband Extensions

Hello everyone,

This series introduces support for Ethernet in-band extensions, a
mechanism proposed by Cisco as part of the USXGMII spec.

The idea is to leverage the 7 bytes preamble to convey meaningful data,
in what's called an "extension".

This series adds the QUSGMII mode, which is a quad variant of the
USXGMII standard, and adds its support in the lan966x driver. In
QUSGMII, extensions can be used.

The only extension support thus far is the PCH mode, a way to convey
part of a timestamp into the ethernet preamble. That's a pretty
straightfoward extension, documented in the Cisco spec. Other extensions
can exist, each being identified by a 2 bits code in the preamble,
parsed by the hardware.

We therefore need an API to synchronise which mode is supported by a
given PHY, then a way to enable it in the PHY, from the MAC's control.

This is done through a new phy_driver callback, .inband_ext_config(),
that the MAC driver will call to ask a PHY driver to enable a given
extension.

The PCH mode that is added in this series is used to offload a bit
the MDIO bus when doing PHY-side timestamping, by conveying the nanoseconds
part of the timestamp into the preamble. The MAC driver then extracts
the timestamp (using lan966x's IFH mechanism), puts the nanosecond part
in the SKB. The RX deferred timestamping then asks the PHY for the rest
of the timestamp.

Other modes exists, such as Microchip's MCH mode, but this series only
include PCH since it's simple enough and keeps the code reviewable.

Thanks,

Maxime

Maxime Chevallier (6):
  net: phy: Introduce QUSGMII PHY mode
  dt-bindings: net: ethernet-controller: add QUSGMII mode
  net: lan966x: Add QUSGMII support for lan966x
  net: phy: Add support for inband extensions
  net: lan966x: Allow using PCH extension for PTP
  net: phy: micrel: Add QUSGMII support and PCH extension

 .../bindings/net/ethernet-controller.yaml     |   1 +
 Documentation/networking/phy.rst              |   9 ++
 .../ethernet/microchip/lan966x/lan966x_main.c |  14 +--
 .../ethernet/microchip/lan966x/lan966x_main.h |   6 ++
 .../microchip/lan966x/lan966x_phylink.c       |   9 +-
 .../ethernet/microchip/lan966x/lan966x_port.c |  33 ++++--
 .../ethernet/microchip/lan966x/lan966x_ptp.c  |  93 +++++++++++++++-
 .../ethernet/microchip/lan966x/lan966x_regs.h |  72 +++++++++++++
 drivers/net/phy/micrel.c                      | 102 ++++++++++++++++--
 drivers/net/phy/phy.c                         |  68 ++++++++++++
 drivers/net/phy/phylink.c                     |   3 +
 include/linux/phy.h                           |  28 ++++-
 12 files changed, 413 insertions(+), 25 deletions(-)

-- 
2.36.1