Re: [RFC] Device: device_get_binding() returns NULL if device fails initialization


Thomas, Ramesh
 

On Tue, Apr 12, 2016 at 10:27:20, Leung, Daniel wrote:
On Tue, Apr 12, 2016 at 09:07:00AM +0200, Tomasz Bursztyka wrote:
Hi Ramesh,

> > > The idea was that the kernel could not really do
> > > anything when a driver failed initialization, so why not getting rid
of returns
> > > to save a few bytes. The burden of determining whether it is a
critical error
> > > during init is up to the driver. If there is a critical error, the driver
> > > should assert (and setting driver_api to NULL).
> > >
> > > There are situations where there are non-critical erros during
initialization.
> > > For example, the I2C driver, failure to set default configuration is
not
> > > critical. As long as the developer sets it later, the driver can still
function.
> > > However, with the above code, this non-critical error will cause
driver_api
> > > to be NULL, which prevents its usage at all. The driver writer
should know
> > > whether an error prevents the device from functioning at all. So
it should be
> > > up to driver writer to set driver_api to NULL. One can argue that a
non-critical
> > > error should not return anything other than 0. But then it is not
passing on
> > > the information that there is a non-critical error (though the
kernel does not

Not sure how the method in the RFC differentiates between critical
and
non-critical errors. Isn't the driver also *not* passing on the
non-critical error status to the app by not setting device_api = NULL in
those cases? Then how will the app know that it needs to do
something to
correct such non-critical errors?

If this is merely a way to indicate that the driver is in an unusable
error state, then how is it different from critical error? - which is
not expected to happen in production releases.

The idea is to let the driver decide whether it is still functioning or
not.
Unusable state is a critical error to me.
A non critical error, means it is still ok to work, thus the driver API
will be set.
If the driver stops at non-critical error and do not set the API, it's not
really a non-critical error then.
(or it's a bug)

I don't see much trouble with that. Up to drivers to decide

And anyway, in 99.9% of the drivers: there will be critical errors only I
guess (unable to get
a device binding, to configure some register...).

Tomasz
Ramesh, in a production release, there should not be any non-critical
errors
at device initialization (hence "production"). In a production
environment,
the null-returning can be used as a mechanism to signify a major
problem,
for example, a peripheral breaks down in the field. Notification then can
be
made to replace the faulty hardware, if so desired.
I see. So the method in the RFC is to assist in diagnosis or notification of critical
errors.



----------
Daniel Leung

Join devel@lists.zephyrproject.org to automatically receive all group messages.