For some reason, the signature of functions passed to the
DEVICE_INIT() <init_fn> parameter has a return type of 'int', but
the return value is never checked within
_sys_device_do_config_level(). Some init functions do return an
error code, such as the ARC init code and the bluetooth init
routines, but that just gets ignored.

Question: should we have init functions of return type 'void' then
? That would shave a few bytes in every init function if we don't
have to return a value.

We generally try to operate under the assumption that failures will
not occur. That being said, we do have some instances where we do
check for errors, and some of these are considered fatal.

My take on it is that for Zephyr a failed device initialization
should be considered a fatal event. My expectation is that the
Zephyr user will only be enabling relevant (and important) devices
to their project. If one of these devices should fail, then that is
a serious system error and _NanoFatalErrorHandler() should be
invoked.

If this train of thought holds up to scrutiny, and if the aim is to
save a few bytes then I would think that it would be better to have
the device initialization routines return a failure code and have
_sys_device_do_config_level() check for it and invoke the fatal
error handler upon the detection of failure. Otherwise we duplicate
the overhead of calling the fatal error handler in each device
initialization routine.

Drivers' initialization routines can use __ASSERT() if they want to
catch an error in a debug build.

I have not received any other feedback w.r.t. this: silence implies
consent ? :)