[QUESTION] How to support partial networking

[QUESTION] How to support partial networking

[Francesco Valla]

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

Re: [QUESTION] How to support partial networking

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]

Hey Francesco,

On 14.01.2026 22:26:39, Francesco Valla wrote:
> 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.

> 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.

> 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

> 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.

regards,
Marc

-- 
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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]