drivers: can: shell: use shell_fprintf_normal instead of shell_fprintf

[ndrs-pst]

Due to the introduction of shell_xxx_impl wrapper functions in PR #75340 and rename to shell_fprintf_xxx in PR #77192 we can minimize caller overhead by eliminating direct color parameter passing.

[henrikbrixandersen]

It seems wrong to call the _impl function directly. This is just a simple test, the overhead of calling the non-impl function does not matter.

What is the motivation for changing this?

[ndrs-pst]

If the condition is to avoid calling _impl functions (due to the naming convention),
one alternative could be to rename the following functions:

• shell_info_impl to shell_fprintf_info
• shell_print_impl to shell_fprintf_normal
• shell_warn_impl to shell_fprintf_warn
• shell_error_impl to shell_fprintf_error

---

The short variants shell_info, shell_print, shell_warn, and shell_error
concatenate "\n" internally, which makes them unsuitable for cases where a newline is not desired.
If we were to remove the newline concatenation, it could affect a wide range of functions across the codebase (the "widetree" effect).

---

The motivation for this change stems from the discussion in PR #74652, which led to PR #75340.
So, it's not specific to can_shell.c initially, but I submitted this PR to gather feedback from other areas as well. 😅

[henrikbrixandersen]

If the condition is to avoid calling _impl functions (due to the naming convention),
one alternative could be to rename the following functions:

shell_info_impl to shell_fprintf_info
shell_print_impl to shell_fprintf_normal
shell_warn_impl to shell_fprintf_warn
shell_error_impl to shell_fprintf_error

I think that would make for a better naming convention. In Zephyr, *_impl are usually associated with system call implementation functions, which should never be called directly.

[ndrs-pst]

I think that would make for a better naming convention. In Zephyr, *_impl are usually associated with system call implementation functions, which should never be called directly.

Thank you for your feedback. I may propose a revision to the naming convention in a separate PR and will update this PR accordingly afterward. WDYT?

[henrikbrixandersen]

I may propose a revision to the naming convention in a separate PR and will update this PR accordingly afterward. WDYT?

Sounds good. Thanks!

[henrikbrixandersen]

Please rebase.

[ndrs-pst]

Addressed it. 👍