drivers: CAN: Abstract blocking send call

[alexanderwachter]

This commit moves the semaphore for a blocking call from
the driver implementation to the stack of the caller.
It reduces the complexity of the drivers and saves some RAM.

Fixes #22379

[zephyrbot]

All checks passed.

checkpatch (informational only, not a failure)

-:321: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or return
#321: FILE: include/drivers/can.h:368:
+		return api->send(dev, msg, timeout, callback_isr, callback_arg);
+	} else {

- total: 0 errors, 1 warnings, 288 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: Ignored message types: AVOID_EXTERNS BRACES CONFIG_EXPERIMENTAL CONST_STRUCT DATE_TIME FILE_PATH_CHANGES MINMAX NETWORKING_BLOCK_COMMENT_STYLE PRINTK_WITHOUT_KERN_LEVEL SPLIT_STRING VOLATILE

NOTE: If any of the errors are false positives, please report
      them to the maintainers.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[henrikbrixandersen]

This change will introduce an overhead of initialising a semaphore on each can_send() call without any callback defined. I am not sure it is worth it.

It also seem very unlike any other API implementation in Zephyr?

[karstenkoenig]

Yea I am sort of ambivalent about it. Not sure how much of a trade-off the memory saved vs the calling overhead it is.
In terms of driver complexity I think it isn't a big improvement, we all had the same approach and it's not so hard to follow either.

[alexanderwachter]

This change will introduce an overhead of initialising a semaphore on each can_send() call without any callback defined. I am not sure it is worth it.

The overhead of initializing is not that much. The blocking send call is used rarely, and in the current implementation, we need to maintain a sem for every mailbox just in case we will need it.

In terms of driver complexity I think it isn't a big improvement, we all had the same approach and it's not so hard to follow either.

The complexity raised with the timeout patch :-)
I really don't like #19707 in its current state.

[karstenkoenig]

Ah gotcha. What would be your plan then, use that can_common_isr_callback_handler() for failing sends with timeouts?

[alexanderwachter]

Updated #19707 on top of this PR. Looks better now!