Video: more input validation and parameter decoding

[josuah]

Summary

With #90415, video APIs got improved to perform extra input validation with either __ASSERT_NO_MSG() or return -EINVAL;.

There is no complete plan for how to process the input between the application and the drivers.

Describe the solution you'd like

Reduce boilerplate in drivers by moving everything done for each and every driver to the APIs or maybe extra front-end code on top.

Split the input validation concern away from the drivers to making sure all drivers apply the same checks.

Alternatives

Define guidelines for what input has to be validated at the level of the drivers and applications.

Additional Context

• video: common: prevent divide-by-zero in video_closest_frmival_stepwi… #91893 (comment)

[josuah]

• Common driver code can be factorized into helper functions.
• Then every driver will likely want to call the same helper functions.
• Then these helper functions can be automatically called as part of the API wrappers.
• These API wrappers end-up becoming more like a front-end, which can be refactored into subsystem/video at some point, to keep the low-level API wrappers just like GDB syscall wrappers.
• Ultimately, these API wrappers need to actually be turned into Zephyr syscalls: Video: syscall support #93025

Does that make sense?

[josuah]

It seems like just an ASSERT() works during development but it is not input validation, which might require return -EINVAL;.

For instance, drivers returning an error which a protocol returns as an error message to the host, rather than crashing the firmware. If users are expected to route user input directly to video APIs, better make sure to defend against anything known to be out of bound, so that drivers only have to do input validation that cannot be guessed.

At the same time, this is an opportunity to document how to implement each driver API and specify the amount of validation done on behalf of drivers.