Skip to contentSkip to conversation

How to support partial networking

QUESTION Francesco Valla 2 participants 2 messages Jan 14 – Jan 15 CAN network drivers

lore
Share & tools
lore
#0 lore raw

Hello linux-can,

I am starting to develop a driver for the TJA1465 SIC CAN transceiver from NXP [0], which among other things supports partial networking, and I was wondering whether it has already been discussed or not how to support such a feature.

For those not familiar, partial networking is an automotive-oriented feature that allows to wake-up selectively through CAN traffic some ECUs while leaving others in a quiescent state. This can be used for example for periodic maintenance tasks, diagnostics or updates. It is typically implemented inside a trasceiver, which is always powered and stores in a volatile memory a list of CAN IDs (plus masks, much like the SocketCAN filtering works) that shall lead to the wake-up of the ECU.

In the context of the Linux kernel, this can be probably be implemented in a number of ways:

- as a device-specifc capability (accessible e.g. through sysfs)
- at phy level
- in the generic CAN subsystem
- ?

I did not find a previous discussion neither in the mailing list nor in public presentations, but maybe some discussion already took place privately or I missed something.

Any idea or preference? If not, I'll try to come up with a proposal and submit an RFC.

[0] https://www.nxp.com/products/TJA1465

Thank you in advance!

Regards,
Francesco

#1 lore raw

Hey Francesco,

Quoted 4 lines · Francesco Valla

I am starting to develop a driver for the TJA1465 SIC CAN transceiver from NXP [0], which among other things supports partial networking, and I was wondering whether it has already been discussed or not how to support such a feature.

Not yet.

Quoted 4 lines

For those not familiar, partial networking is an automotive-oriented feature that allows to wake-up selectively through CAN traffic some ECUs while leaving others in a quiescent state. This can be used for example for periodic maintenance tasks, diagnostics or updates.

The ethtool interface provides an interface to configure wake-on-lan settings, see the man page of ethtool:

| wol p|u|m|b|a|g|s|f|d...
|        Sets Wake-on-LAN options. Not all devices support this. The
|        argument to this option is a string of characters specifying
|        which options to enable.
|        p   Wake on PHY activity
|        u   Wake on unicast messages
|        m   Wake on multicast messages
|        b   Wake on broadcast messages
|        a   Wake on ARP
|        g   Wake on MagicPacket™
|        s   Enable SecureOn™ password for MagicPacket™
|        f   Wake on filter(s)
|        d   Disable (wake on nothing).  This option clears all previous options.
Quoted 4 lines

It is typically
implemented inside a trasceiver, which is always powered and stores in a volatile memory a list of CAN IDs (plus masks, much like the SocketCAN filtering works) that shall lead to the wake-up of the ECU.

Commit 04d5826b074e ("can: m_can: Map WoL to device_set_wakeup_enable") extended the m_can driver for WOL support in. In that use case the m_can IP core itself is powered and wakes up the system on CAN traffic. The driver uses the "Wake on PHY activity" for this.

From your description I think "Wake on filter(s)" would fit for your use case. ethtool also provides the interface to configure filters and use them for Wake-on-LAN. However the filter interface only supports Ethernet and/or IP related filters yet.

A basic CAN transceiver driver is located in
"drivers/phy/phy-can-transceiver.c"

The TJA1465 PHY driver would be an SPI client driver that implements the struct phy provider, similar to "phy-can-transceiver.c".

The ethtool callbacks end up in the CAN driver, but we don't have an interface to the PHY to configure CAN PHY specific settings. I think you can extended the union phy_configure_opts for this:

| /**
|  * union phy_configure_opts - Opaque generic phy configuration
|  *
|  * @mipi_dphy:	Configuration set applicable for phys supporting
|  *		the MIPI_DPHY phy mode.
|  * @dp:		Configuration set applicable for phys supporting
|  *		the DisplayPort protocol.
|  * @lvds:	Configuration set applicable for phys supporting
|  *		the LVDS phy mode.
|  * @hdmi:	Configuration set applicable for phys supporting
|  *		the HDMI phy mode.
|  */
| union phy_configure_opts {
| 	struct phy_configure_opts_mipi_dphy	mipi_dphy;
| 	struct phy_configure_opts_dp		dp;
| 	struct phy_configure_opts_lvds		lvds;
| 	struct phy_configure_opts_hdmi		hdmi;
| };

Let's add a "struct phy_configure_opts_can" here.

What do we need to configure?
- bitrate (CAN-CC only?)
- enable/disable WoL
- set filters

Quoted 8 lines

In the context of the Linux kernel, this can be probably be implemented in a number of ways:

- as a device-specifc capability (accessible e.g. through sysfs)
- at phy level
- in the generic CAN subsystem
- ?

Quoted 6 lines

I did not find a previous discussion neither in the mailing list nor in public presentations, but maybe some discussion already took place privately or I missed something.

Any idea or preference? If not, I'll try to come up with a proposal and submit an RFC.

regards,
Marc

Signature · 4 lines
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |