Re: [RFC v2] lis3lv02d: avoid divide by zero due to unchecked register read

[Christian Lamparter <chunkeey@googlemail.com>]

On Tuesday 17 May 2011 23:46:00 Éric Piel wrote:
> Op 16-05-11 23:36, Christian Lamparter schreef:
> > On Monday 16 May 2011 13:16:46 Éric Piel wrote:
> >> Op 16-05-11 00:46, Christian Lamparter schreef:
> >>>  From my POV, it looks like the hardware is not working as expected
> >>> and returns a bogus data rate. The driver doesn't check the result
> >>> and directly uses it as some sort of divisor in some places:
> >>>
> >>> msleep(lis3->pwron_delay / lis3lv02d_get_odr());
> >>>
> >>> Under this circumstances, this could very well cause the
> >>> "divide by zero" exception from above.
> >>>
> >> However, I'd fix it a bit differently: let lis3lv02d_get_odr() return
> >> the raw data, and create a special function
> >> lis3lv02d_get_pwron_delay_ms() which does the "lis3->pwron_delay /
> >> lis3lv02d_get_odr()" with special handling for 0 (returning a large
> >> value and also sending a printk_once() ).
> > Do you know how "volatile" this data rate is? If it never changes
> > [at least it doesn't here?] then why not read it once in init_device
> > and store it in the device context?
> It is not normally changing, normally it is set just at init/unsuspend 
> (where the bios can also interfere sometimes) and when the user changes 
> it.
Uh, "bios can also interfere"... this sounds very bad. At least for
my x41t the bios doesn't care about hdaps once the OS is running.

> So definitely within the same function it's not going to suddenly 
> change.
a SMM can happen at any time and if a faulty BIOS [likely, since I got
a new laptop] is what caused the crash, I wouldn't bet on "const within
a function context".

> We could avoid calculating/checking it twice in 
> lis3lv02d_selftest(). Care to do a third version with this little clean up?
I have my doubts, but ok if you say so... Just one thing: need to do some Q&A
on the code above, I haven't tested it extensively yet.

Regards,
	Chr