drivers: can: mcux: flexcan: add dynamic memory allocation for MB

[william-tang914]

This change replaces static memory allocation for FlexCAN message buffers with dynamic allocation using a per-instance heap. The motivation is to support FlexCAN instances with varying message buffer counts and CAN FD configurations.
For CAN FD instances, message buffer count is adjusted based on 64-byte payload size (7 buffers per RAM block vs 32 for 8-byte payload).

Key changes:

• Add CAN_MCUX_FLEXCAN_HEAP_SIZE Kconfig option (default 2048 bytes) to configure heap size for message buffer allocation
• Replace compile-time MCUX_FLEXCAN_MAX_MB/RX/TX macros with runtime calculation in mcux_flexcan_get_mb_config()
• Add dynamic allocation of rx_allocs, tx_allocs, rx_cbs, and tx_cbs arrays using k_heap during driver initialization
• Update all array bounds checks and loop limits to use runtime values stored in driver data structure
• Remove Kconfig symbol CAN_MAX_MB beacuse such information is added to device tree.
• Remove range limitation in Kconfig symbol CAN_MAX_FILTER because such validation is added in mcux_flexcan_get_mb_config()

Fixes #92798

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.2% Duplication on New Code

See analysis details on SonarQube Cloud

[henrikbrixandersen]

Dynamic allocation is not the solution here. This can be derived at build timer per instance (as is done in other drivers as well, see e.g.

zephyr/include/zephyr/drivers/can/can_mcan.h

Line 1216 in 3cf7b20

#define CAN_MCAN_DT_CALLBACKS_DEFINE(node_id, _name) \

).

On a side note, I do have a plan for a Zephyr-native FlexCAN driver, but the more workarounds and #ifdefs that are added, the more I realise that the NXP HAL hides way too many differences in the IP implementations covered under the market name "FlexCAN", which are very, very difficult to capture in a single driver.

[PetervdPerk-NXP]

Dynamic allocation is not the solution here. This can be derived at build timer per instance (as is done in other drivers as well, see e.g.

Indeed we've got tiny MCX parts with little flash/ram with FlexCAN support, rather avoid using dynamic memory for something as as simple as CAN in an RTOS.

On a side note, I do have a plan for a Zephyr-native FlexCAN driver, but the more workarounds and #ifdefs that are added, the more I realise that the NXP HAL hides way too many differences in the IP implementations covered under the market name "FlexCAN", which are very, very difficult to capture in a single driver.

About your driver, @henrikbrixandersen do you already have something in place? I was planning to create my own HAL-less FlexCAN driver, but I put that on hold when I heard you were working on one as well.

If so, would it be something to do developement in the open? Opening a branch somewhere to work on that?

Regarding different IP implementation, I would just focus on i.MXRT10XX and later (S32K, IMX9 seem to be quite similar). And then utilize the Zephyr compatible string to override the driver for these newer parts. RXFIFO isn't that interesting to implement because typically not all instances on a single chip (typically only primary) have that feature.

[william-tang914]

Hi @henrikbrixandersen , following your advice, I create another draft PR.
#99483