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 _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
