Re: [lm-sensors] [PATCH] lsm303dlh: Adding Accelerometer and Magnetometer support

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jonathan Cameron
Date: Wednesday, December 1, 2010 - 4:28 am

On 12/01/10 05:14, Chethan Krishna N wrote:
For this review I'm ignoring the debate on where this goes.
Obviously, further review will be needed after that is cleared up.

Also I'll be concentrating for now on my favourite area: interfaces.
(I review from the end so most comments are in the magnetometer driver).

My main gripes are:
* Lots of magic numbers.  They lead to a completely non generalizable
interface and so aren't an option in mainline except in the rare cases
where you can really argue no other device is likely to have similar
controls.
* Lots of naming that I haven't seen elsewhere.  There are magnetometers
and accelerometers in tree. Take a look at how they do this stuff.
Few other comments on things I happened to notice whilst passing by.

Code itself is mostly pretty cleaner so should take long to cleanup
one you've found a home.

Have run out of time so haven't done much review of accelerometer side.
Sorry but what is there may be helpful to you in the meantime and most
of the magnetometer comments look like they apply to the accelerometer.
As an aside, how similar is the accelerometer part to those currently
supported by the lis3* driver already in the tree?

Jonathan


Those names really aren't that clear. I'd just call them lsm303dlh_accelerometer
and lsm303dlh_magnetometer (or accel and magnet would do).

Jumping a long way... Loose this test.
Why is this in the middle of code setting up the value of data?  It's confusing
to read so move it to one end of the other.
Again, does the device guarantee one 'scan' of data is read. If not
they are different values and hence need separate attributes.
Also, what is data?  Name doesn't tell us anything.
Units? Permissible values?
Magic numbers
So how does interrupt control differ from interrupt configure?
Both look like black magic to me.
What is this?
This smacks of more magic numbers. Undocumented so I have no idea
what they even do. Unless I'm missing something there is no way
this is going into mainline.
Needs documenting.  I've proposed a set (to limited response) of
suggestions on how to name sensor interrupt control attributes.
We are using that set in IIO but are still open to changes if
you want to reopen that discussion.
Why assign it to NULL? 
Guessing this is a motion detector... Dmitry, happy with this in input?
Definitely pull the input code out into a function even if you leave it
in this file. It'll make things rather easier to read.
roll into line above.
roll into the first line of function.
Odd spacing.
Looks (at very brief glance) like you could just move the definition
of set_mode then you wouldn't need this.

It's going to tget assigned the next line so don't bother doing it here.
That goes an rather short distance. Lose the check.
That's a whole lot of error. I'd use a debug macro so it's not there unless
someone is having problems.
Looks suspiciously like a magic number. Could be wrong...
Is there a reason to do this in two goes?
Do the mutex unlock then check the error condition to save yourself a couple of lines of code.
Not sure I've seen that colon syntax anywhere else in kernel.
Unless the happens often I'd be inclined to not bother with thie error
message. Or moving it into a debugging macro so it gets compiled out if
no one cares.
Why does it need to be a gpio?  Can't see any code that isn't just using
gpio_to_irq on the gpio. Hence just pass the irq number in to start with.
This is looking suspicously like another set of magic numbers....
So you set ddata->mode to garabage before handling the error?
It might not matter in this case, but it's pretty uggly from
a review point of view.
This isn't clear. Gain of what?  In IIO we have a nice clear
convention for this. There may be others elsewhere in kernel.
Ah, looking at the function you have 3 separate values. Given
these apply to different channels and are constant I don't think
you can claim they are a single value. Hence under sysfs they need
to be 3 separate attributes.  Is this a gain userspace applies or
one that is occuring inside the device?  Or even one set by platform
data (in which case why does userspace what to know?)

For reference in IIO, if these are applied before the data hits userspace
they would be:
magn_x_calibscale
magn_y_calibscale
magn_z_calibscale

and if they are to be applied in usersapce
magn_x_scale
magn_y_scale
magn_z_scale
 

data... Values of what? Fine here where you have a separate device
for a magnetometer, but it doesn't generalize.  Take the big imu's in
IIO. We have parts which truely integrate gyros, accels and magnetometers.
Hence I'd suggest
magn_xyz if the part is such that you can argue that one always obtains a
set captured at the 'same' time. If not, then they aren't a single element
and so under sysfs rules need to be 3 attributes.  Personally I'd advocate
having them as separate attributes as you have the input route to handle
'scans' of the channels for anyone who cares.
Magic numbers?  Please don't this.  Firstly it doesn't seem to
be documented so even if there was no alternative it would need
that.  Secondly, nice simple strings are much clearer. Obviously
you will need to match this interface against similar ones elsewhere
in the kernel.  Attributes like this mean that no userspace code can
ever cover more than one part and the userspace code writers have
to have the datasheet in their hand to know what they need to write.
We have had a few discussions about this in IIO and eventually concluded
it's a lot easier to handle this as a scale parameter than as a range.
This is partly because we allow all computation of scaling etc to be done
in userspace and partly because range gets tricky to specify for any device
that say goes form -1V to +5V.

Also, what are the units of this? Without datasheet trawling it's not obviousl
Check against other devices in tree.
No need to set it to NULL. kzalloc will do that anyway
if it fails...
To be honest... Who cares what the version number is? Or is going to
look in the kernel logs if they do...
See comment below on ripping this stuff out to a separate file and doing
the ifdefs in the header.
Isn't that a bit vague for naming?  (one for Dmitry and the input guys).
Don't think you want that leading space in the string.
I'd roll the previous two lines together. 

struct lsm303dlh_m_data *ddata = dev_get_drvdata(dev)l
is cleaner than doing it in two lines.
same as previous one.
There are a lot of thes input related ifdefs. 
The prefered option if remotely sensible is to do these
in a header. You then have a separate source file with
implementations that is only compiled in if this option
is enabled and stubs in the header for when it isn't.
Why?

return lsm303dlh_m_restore(ddata);

 will do just fine. (and lose the int ret; above as well)
Why?
Personally I prefer kernel doc for structures like this,
but that's down to whether the maintainer who takes it
cares.
accelerometer

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH] lsm303dlh: Adding Accelerometer and Magnetometer s ..., Chethan Krishna N, (Tue Nov 30, 10:14 pm)
Re: [lm-sensors] [PATCH] lsm303dlh: Adding Accelerometer a ..., Jonathan Cameron, (Wed Dec 1, 4:28 am)