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.


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