Re: [lm-sensors] [PATCH v2] lis3: Fix Oops with NULL platform data

[Jonathan Cameron]

On 09/24/10 16:22, Éric Piel wrote:
> Op 24-09-10 16:30, Jean Delvare schreef:
>> Well, as long as the driver lives in drivers/hwmon and the hwmon
>> subsystem is maintained, it seems fair to consider the driver
>> maintained.
>>
>> That being said, I indeed would like all non-hwmon drivers to go away
>> from drivers/hwmon. Originally we were waiting for iio to settle first,
>> but apparently this is taking forever. The 4 drivers I would like to
>> kick are: ams, hdaps, lis3lv02d and applesmc. They are primarily
>> accelerometer device drivers. Not sure where to put them,
>> drivers/accel(erometer), drivers/misc, drivers/misc/accel(erometer),
>> drivers/input/accel(erometer)... Opinions welcome.
> As maintainer of the lis3lv02d driver, I'd completely support the move too.
> 
> IMHO, an accelerometer is just another input device (usually with 2 or 3
> axes),
That is not actually all that true in general. There are an awful lot of parts
that aren't even vaguely designed for 'human' input.
In some restricted cases I'm happy to agree though and that definitely includes
3 axis sensors with input specific features like those your driver covers.

> so moving them to drivers/input/accel would make sense.
Propose a move on linux-input and see what the response is.  Currently
they are going in drivers/input/misc, but that is probably just because there
aren't enough of them yet to justify their own directory.

Dmitry is taking them slowly (mainly I think because he wants the interfaces to
be more pinned down).   The adxl34x driver is already there, Hemanth's
cma3000 is close (either dropping some knobs in sysfs or working out
naming that everyone interested can agree on).  I would imagine the awkward
bits will be things like freefall detectors that no one can reasonably argue
are a conventional form of 'human' input.

As an aside, we are trying to work out a unified interface between IIO and
input for some elements and a userspace bridge where that doesn't make sense.
There are ongoing (if rather quiet) discussions on this on linux-input / lkml.
http://lkml.org/lkml/2010/9/21/167 I would certainly welcome any comments / 
suggestions anyone would like to make.  The intent here is to pin down the
naming conventions as independently as possible of the actual subsystem handling
the device, but to keep them general enough as to be able to cover a wide range
of different sensors.
 
Cheers,

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/