fix(Other): Fix Wrap_MXC_CAN_Init signature

[trupples]

Description

Fixes a bug introduced by #1306, which added a Zephyr wrapper for MXC_CAN_Init, whose signature differs between the MAX32662 and MAX32690.

The previous implementation declared Wrap_MXC_CAN_Init as void and discarded the return value of the underlying MXC_CAN_Init calls. This is incompatible with the can_max32 driver which does error checking and expects an int return value.

While this is a "breaking" change, no code currently depends on this wrapper, because its signature is invalid and could not be properly used in the can_max32 driver.

How did this happen?

This is entirely my fault, as I was rushing to get some zephyr can_max32 changes in, on the last Friday before the winter holiday break. (I am now well aware of how stupid that is...)

While working on this wrapper, I used the following forks: trupples/msdk, trupples/hal_adi. I did catch this error and fixed it in hal_adi, but didn't push the same changes to msdk.

At that point, trupples/hal_adi had the correct implementation (int return), but trupples/msdk did not (void return).

I was able to build and test an application using the driver, because in zephyr I only referenced my hal_adi repo. In PR #1306 I claimed the wrapper is correct and tested, and the PR got accepted, but with the wrong code. The wrong code was then automatically copied to analogdevicesinc/hal_adi.

NB: should have listened to shouldideploy.today

Validation

A minimal example to test this on both MAX32662 and MAX32690 can be found at trupples/max32-can-validate. It unfortunately requires some fiddling around to get the WIP driver from innersource. Most importantly, the entire process is automated by validate.sh, which:

1. Clones hal_adi (develop branch), msdk (the branch in this PR)
2. Uses zephyr-hal.sh to properly copy files to hal_adi
3. Prepares the west workspace
4. Overwrites hal_adi with modified variant (this is the step I'm most doubtful of, because it intentionally bypasses west update to more easily apply the changes)
5. Builds example for MAX32690 and MAX32662

Usage:

cd /path/to/west_workspace
git clone https://github.com/trupples/max32-can-validate/ validate
cd validate
./validate.sh

I have successfully run this, and I am quite confident that I am not wasting your time with a second bad PR, but I'd like a sanity check.

Checklist Before Requesting Review

• PR Title follows correct guidelines.
• Description of changes and all other relevant information.
• (Optional) Link any related GitHub issues using a keyword
• (Optional) Provide info on any relevant functional testing/validation. For API changes or significant features, this is not optional.

[sihyung-maxim]

No worries, thanks for catching this. Just an unfortunate consequence that we don't have workflows to check for everything.

[sihyung-maxim]

Interesting that the Build_Examples workflow is having trouble with your fork. I'm in the process updating this workflow at the moment, but merging this PR because the Zephyr files are not relevant with the Build_Examples workflow.