linux-kernel - [RFC PATCH v1 0/6] add initial CAN PHY support

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: <20201023105626.6534-1-o.rempel@pengutronix.de>
Date:   Fri, 23 Oct 2020 12:56:20 +0200
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>,
        David Jander <david@...tonic.nl>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Russell King <linux@...linux.org.uk>, mkl@...gutronix.de,
        Marek Vasut <marex@...x.de>, linux-can@...r.kernel.org
Subject: [RFC PATCH v1 0/6] add initial CAN PHY support

This patch set is introducing PHY support for CAN.

Why it is needed?
- A usual CAN PHY has an enable or silent mode pin. This pin needs to be
  pulled into the correct direction, so that the CAN controller can
  access the CAN network. So far this has been "hacked" into the
  CAN controller driver, by enabling/disabling regulators. Better use
  proper PHY drivers instead.
- Bit rate limits. There are different types of CAN PHYs not all support
  all bit rates. Further the upper limit of CAN FD PHYs is not given by
  the standard by by the PHY itself. Use the PHY link framework to
  validate bit rate limits.
- The upcoming CAN SIC and CAN SIC XL PHYs use a different interface to
  the CAN controller. This means the controller needs to know which type
  of PHY is attached to configure the interface in the correct mode. Use
  PHY link for that, too.
- Another topic is cable testing/diagnostics. Unfortunately this is not
  standardized in CAN, but there are several boards that implement CAN
  cable testing in some way or another. Use PHY framework as an
  abstraction.
- The class of CAN low-speed PHYs has enhanced error detection
  capabilities, compared to normal (CAN high-speed and CAN FD) PHYs.
  Use PHY framework to implement CAN low-speed PHY drivers.

Oleksij Rempel (6):
  net: phy: add CAN PHY Virtual Bus
  net: phy: add a driver for generic CAN PHYs
  net: phy: add CAN interface mode
  net: add CAN specific link modes
  can: flexcan: add phylink support
  can: flexcan: add ethtool support

 drivers/net/can/Kconfig       |   2 +
 drivers/net/can/flexcan.c     | 244 +++++++++++++++++++++++++++++++++-
 drivers/net/phy/Kconfig       |  14 ++
 drivers/net/phy/Makefile      |   2 +
 drivers/net/phy/can_phy_bus.c | 196 +++++++++++++++++++++++++++
 drivers/net/phy/can_phy_drv.c | 236 ++++++++++++++++++++++++++++++++
 drivers/net/phy/phy-core.c    |   2 +-
 drivers/net/phy/phy.c         |   2 +
 include/linux/can/phy.h       |  21 +++
 include/linux/phy.h           |   3 +
 include/uapi/linux/ethtool.h  |   9 ++
 net/ethtool/common.c          |   7 +
 net/ethtool/linkmodes.c       |   7 +
 13 files changed, 743 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/phy/can_phy_bus.c
 create mode 100644 drivers/net/phy/can_phy_drv.c
 create mode 100644 include/linux/can/phy.h

-- 
2.28.0