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,of returns
> > > The idea was that the kernel could not really do
> > > anything when a driver failed initialization, so why not getting rid
> > > to save a few bytes. The burden of determining whether it is acritical error
> > > during init is up to the driver. If there is a critical error, the driverinitialization.
> > > should assert (and setting driver_api to NULL).
> > >
> > > There are situations where there are non-critical erros during
> > > For example, the I2C driver, failure to set default configuration isnot
> > > critical. As long as the developer sets it later, the driver can stillfunction.
> > > However, with the above code, this non-critical error will causedriver_api
> > > to be NULL, which prevents its usage at all. The driver writershould know
> > > whether an error prevents the device from functioning at all. Soit should be
> > > up to driver writer to set driver_api to NULL. One can argue that anon-critical
> > > error should not return anything other than 0. But then it is notpassing on
> > > the information that there is a non-critical error (though thekernel does not
Not sure how the method in the RFC differentiates between critical
non-critical errors. Isn't the driver also *not* passing on thesomething to
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
correct such non-critical errors?Ramesh, in a production release, there should not be any non-critical
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
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...).
at device initialization (hence "production"). In a production
the null-returning can be used as a mechanism to signify a major
for example, a peripheral breaks down in the field. Notification then can
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