drivers: can: CAN interfaces are brought up with default bitrate at boot, causing error frames if bus bitrate differs #45304
Description
Describe the bug
Currently, the CAN drivers start with a default bitrate (or timing) specified using devicetree and start the CAN controller in their respective init() functions.
This is fine for CAN nodes using only one fixed bitrate, but if the bitrate is set by the user (e.g. via a DIP-switch or other HMI which is very common), the CAN driver will still initialise with the default timing/bitrate at boot and use this until the application has determined the requested bitrate/timing and set it using can_set_bitrate()/can_set_timing().
During this period, the CAN node will potentially destroy valid CAN frames on the CAN bus (which is using the soon-to-be-set-by-the-application bitrate) by sending error frames.
Expected behavior
The CAN controller drivers should not automatically start the CAN controller at boot time, but instead provide an API for the application to start/stop the CAN controller.
Impact
Interruptions to the ongoing CAN bus traffic when a Zephyr-based CAN node connected to the bus is (re-)booted.
Additional context
The Linux kernel CAN drivers require all configuration (bitrate/timing, mode, etc.) to take place before bringing the CAN interface "up". Reconfiguration requires bringing the CAN interface "down" first.