can : move bytes2dlc/dlc2bytes to common header file

[xucheng5]

only keep can_bytes2dlc & can_dlc2bytes

Note: Please adhere to Contributing Guidelines.

Summary

Update this section with information on why change is necessary,
what it exactly does and how, if new feature shows up, provide
references (dependencies, similar problems and solutions), etc.

Impact

Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it mentions keeping can_bytes2dlc and can_dlc2bytes, it lacks crucial information.

Specifically, it's missing:

• Clear Explanation of the Change: The summary doesn't explain why only these two functions are being kept. What is being removed? What problem does this solve? What's the motivation?
• Detailed Impact Assessment: The impact section is completely empty. This needs to be filled out describing the effects on users, build, hardware, documentation, security, and compatibility. Removing code almost certainly has some impact.
• Testing Information: The testing section is also empty. What platforms were used for testing? What were the results? "Works as intended" is not sufficient; concrete examples of tests and their outcomes are needed. The logs sections are empty.

To make this PR acceptable, the author needs to:

1. Explain the "why" behind the change. Provide a clear and concise explanation of the reason for removing the other functions. What problem did they cause? What are the benefits of removing them?
2. Complete the Impact Assessment. Consider all aspects listed in the template (users, build, hardware, docs, security, compatibility) and explain how this change affects each. Even if the answer is "NO", it should be stated explicitly.
3. Provide detailed testing information. List the build host(s) and target(s) used for verification. Include the actual testing logs from before and after the change to demonstrate the effect of the modification.

Only then will the PR meet the NuttX requirements.

[raiden00pl]

why not put common code in a separate header like include/nuttx/can_cmn.h. We shouldn't couple CAN chardev headers with SocketCAN headers. These are two separate implementations

[xucheng5]

why not put common code in a separate header like include/nuttx/can_cmn.h. We shouldn't couple CAN chardev headers with SocketCAN headers. These are two separate implementations

'include nuttx/can_cmn.h' is ok

[acassis]

@xucheng5 I think it should be flexible enough to let some less common usage scenarios: i.e.: it could be possible to use the internal CAN peripheral from a MCU with SocketCAN and an external MCP2515 with CAN char dev. Using global variables shared by both will introduce issues to this case of use. I think your modifications are fine, but we need to test these usage case to confirm everything still working fine.

[xucheng5]

@xucheng5 I think it should be flexible enough to let some less common usage scenarios: i.e.: it could be possible to use the internal CAN peripheral from a MCU with SocketCAN and an external MCP2515 with CAN char dev. Using global variables shared by both will introduce issues to this case of use. I think your modifications are fine, but we need to test these usage case to confirm everything still working fine.

The conversion of DLC into byte length/ byte length into DLC does not care about socketcan or character-can, which is the processing of CAN protocol.