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