drivers: can: establish unified power management behaviour policy

[henrikbrixandersen]

Summary

Basic power management support was added to the first in-tree CAN controller driver with #96039 (and subsequent PRs #104080 and #104182).

As further additions of power management support to in-tree CAN controller drivers are being made (#100520 and #104218), now is suitable time to establish a policy for uniform behaviour across both CAN controller and CAN transceiver drivers.

The main goals of implementing power management support in CAN controllers, at least so far, are:

• Power saving.
• Remote wake-up on CAN activity.

Describe the solution you'd like

Initial Steps

• Review and merge drivers: can: tcan4x5x: various power management related changes #104182 to create a stable base for testing the current TCAN4x5x driver behaviour.
• Establish a test suite for the currently implemented power management behaviour. This test suite will serve as a baseline for future PM additions and potential changes in driver behaviour (tests: drivers: can: api: add power management test suite #104369)

Initial CAN Controller Driver Behaviour

The behaviour below was established in #96039 but is subject to change as power management support is added to more CAN controller drivers:

• The device is marked busy while started.
• The device is marked busy while RX filters are added (this is due to a limitation on the TCAN4x5x where RX filters and all other configuration are lost in sleep mode).
• The device is marked non-busy when stopped and no RX filters are added.
• CAN controller timing settings are lost on suspend.
• CAN controller mode settings are lost on suspend.

Unresolved Behaviour

• Is it common for CAN controllers to lose RX filter configuration in sleep mode? If not, the TCAN4x5x driver should be modified to restore the RX filters on resume and the test suite should be changed to verify that RX filters are preserved through suspend.
• Should CAN controller timing settings be restored on resume? Likely yes.
• Should CAN controller mode be restored on resume? Likely yes.
• Should calling a CAN controller driver API on a suspended CAN controller device automatically resume the device? If not, the call should fail. Currently, the behaviour of calling a CAN controller API on a suspended device is undefined.
• Client code currently has no way of being notified when a CAN controller is suspended. The enum can_state should be expanded with a CAN_STATE_SUSPENDED state and the state callback called upon suspension. Should there be a separate state representing PM_DEVICE_STATE_OFF?
• Remote wake-up configuration (i.e. wake-up on CAN activity) should adhere to the wakeup-source devicetree property and pm_device_wakeup_enable().
• CAN transceiver drivers (currently only one present in-tree) should handle PM on their own, but should suspending a CAN controller automatically suspend the associated transceiver? Likely yes.
• Should/can behaviour differ between PM_DEVICE_STATE_SUSPENDED and PM_DEVICE_STATE_OFF? Should the TCAN4x5x driver really be entering "stand-by mode" on PM_DEVICE_ACTION_SUSPEND and "sleep mode" on PM_DEVICE_ACTION_TURN_OFF?

Alternatives

No response

Additional Context

Feel free to comment on this issue and/or join the discussion thread on Discord: https://discord.com/channels/720317445772017664/1474400413951459511