[RFC,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

On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
> - 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.

Is this dynamic in some form?

On 10/23/20 1:45 PM, Russell King - ARM Linux admin wrote:
> On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
>> - 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.
> 
> Is this dynamic in some form?

There isn't any CAN SIC transceivers out there yet. I suspect there will be no
auto detection possible, so we would describe the type of the attached
transceiver via device tree.

In the future I can think of some devices that have a MUX and use the a classic
transceiver (CAN high-speed) for legacy deployments and CAN SIC transceivers if
connected to a "modern" CAN bus.

Someone (i.e. the user or the system integrator) has to configure the MUX to
select the correct transceiver.

Marc

On Fri, Oct 23, 2020 at 02:14:09PM +0200, Marc Kleine-Budde wrote:
> On 10/23/20 1:45 PM, Russell King - ARM Linux admin wrote:
> > On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
> >> - 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.
> > 
> > Is this dynamic in some form?
> 
> There isn't any CAN SIC transceivers out there yet. I suspect there will be no
> auto detection possible, so we would describe the type of the attached
> transceiver via device tree.
> 
> In the future I can think of some devices that have a MUX and use the a classic
> transceiver (CAN high-speed) for legacy deployments and CAN SIC transceivers if
> connected to a "modern" CAN bus.
> 
> Someone (i.e. the user or the system integrator) has to configure the MUX to
> select the correct transceiver.

Hmm. So it's static, and described in firmware. So, that brings me to
the obvious question: why use phylink for this rather than the phylib
APIs?

phylink isn't obsoleting phylib in any way, and phylib does support
the ability for the PHY to change its MAC side interface (if it didn't
then PHYs such as 88x3310 and similar wouldn't be usable.)

On 10/23/20 2:22 PM, Russell King - ARM Linux admin wrote:
> On Fri, Oct 23, 2020 at 02:14:09PM +0200, Marc Kleine-Budde wrote:
>> On 10/23/20 1:45 PM, Russell King - ARM Linux admin wrote:
>>> On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
>>>> - 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.
>>>
>>> Is this dynamic in some form?
>>
>> There isn't any CAN SIC transceivers out there yet. I suspect there will be no
>> auto detection possible, so we would describe the type of the attached
>> transceiver via device tree.
>>
>> In the future I can think of some devices that have a MUX and use the a classic
>> transceiver (CAN high-speed) for legacy deployments and CAN SIC transceivers if
>> connected to a "modern" CAN bus.
>>
>> Someone (i.e. the user or the system integrator) has to configure the MUX to
>> select the correct transceiver.
> 
> Hmm. So it's static, and described in firmware.

The use case where the system has a MUX (to route the signals to either one or
the other transceiver), the used transceiver would be selected by software.

It's static in that sense, as there is no hotplug of unknown devices, no-one
will swap the CAN-SPF+ module against a CAN-SIC-SFP+ module :)

> So, that brings me to
> the obvious question: why use phylink for this rather than the phylib
> APIs?

Oleksij is looking at code....

> phylink isn't obsoleting phylib in any way, and phylib does support
> the ability for the PHY to change its MAC side interface (if it didn't
> then PHYs such as 88x3310 and similar wouldn't be usable.)

regards,
Marc

On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
> This patch set is introducing PHY support for CAN.

The device tree binding needs documenting.

It might also help me get my head around the virtual MDIO bus and how
PHYs are added to it.

     Andrew