How to support partial networking
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
Marc Kleine-Budde
maintainerHey 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 |