* Accelerometer drivers in drivers/hwmon @ 2010-09-25 11:23 ` Jean Delvare 0 siblings, 0 replies; 6+ messages in thread From: Jean Delvare @ 2010-09-25 11:23 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, LM Sensors, Takashi Iwai, Jonathan Cameron Hi Dmitry, I would like to kick the following 5 drivers out of drivers/hwmon: ams, hdaps, hp_accel, lis3lv02d and applesmc. These are primarily accelerometer devices, so the drivers do not belong to hwmon. ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. They are pure accelerometer drivers as far as I can see. Would you take them in drivers/input/misc? applesmc is more complex, it's a multifunction device. Maybe it would better go to drivers/macintosh, where the other thermal management drivers for mac machines live. If you don't want hdaps and hp_accel, they might also fit under drivers/platform/x86. There are quite a few laptop-specific drivers living there already. If nobody wants these drivers, drivers/misc is yet another option. I'm open to suggestions. Virtually anything which moves these drivers outside of drivers/hwmon will make me happy. Thanks, -- Jean Delvare ^ permalink raw reply [flat|nested] 6+ messages in thread
* [lm-sensors] Accelerometer drivers in drivers/hwmon @ 2010-09-25 11:23 ` Jean Delvare 0 siblings, 0 replies; 6+ messages in thread From: Jean Delvare @ 2010-09-25 11:23 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, LM Sensors, Takashi Iwai, Jonathan Cameron Hi Dmitry, I would like to kick the following 5 drivers out of drivers/hwmon: ams, hdaps, hp_accel, lis3lv02d and applesmc. These are primarily accelerometer devices, so the drivers do not belong to hwmon. ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. They are pure accelerometer drivers as far as I can see. Would you take them in drivers/input/misc? applesmc is more complex, it's a multifunction device. Maybe it would better go to drivers/macintosh, where the other thermal management drivers for mac machines live. If you don't want hdaps and hp_accel, they might also fit under drivers/platform/x86. There are quite a few laptop-specific drivers living there already. If nobody wants these drivers, drivers/misc is yet another option. I'm open to suggestions. Virtually anything which moves these drivers outside of drivers/hwmon will make me happy. Thanks, -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Accelerometer drivers in drivers/hwmon 2010-09-25 11:23 ` [lm-sensors] " Jean Delvare @ 2010-10-04 18:03 ` Dmitry Torokhov -1 siblings, 0 replies; 6+ messages in thread From: Dmitry Torokhov @ 2010-10-04 18:03 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-input, LM Sensors, Takashi Iwai, Jonathan Cameron Hi Jean, On Sat, Sep 25, 2010 at 01:23:30PM +0200, Jean Delvare wrote: > Hi Dmitry, > > I would like to kick the following 5 drivers out of drivers/hwmon: ams, > hdaps, hp_accel, lis3lv02d and applesmc. These are primarily > accelerometer devices, so the drivers do not belong to hwmon. > > ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. > They are pure accelerometer drivers as far as I can see. Would you take > them in drivers/input/misc? > > applesmc is more complex, it's a multifunction device. Maybe it would > better go to drivers/macintosh, where the other thermal management > drivers for mac machines live. > > If you don't want hdaps and hp_accel, they might also fit under > drivers/platform/x86. There are quite a few laptop-specific drivers > living there already. > > If nobody wants these drivers, drivers/misc is yet another option. I'm > open to suggestions. Virtually anything which moves these drivers > outside of drivers/hwmon will make me happy. > I looked over the drivers and none of them (with possible exception of lis3lv02d) are pure input devices either. I think the best course of action would be to move ams, applesmc, hdaps and hp_accel into drivers/*/platform (I'd say drivers/x86/platform except that I think apple one might not be x86 only). lis3lv02d could ether go into drivers/misc or stay where it is for the time being, pending resolution on overall IIO/Input/accelerometers decision. I'd take it in input/misc but accelerometer guys need to decide on common sysfs layout for such devices. -- Dmitry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lm-sensors] Accelerometer drivers in drivers/hwmon @ 2010-10-04 18:03 ` Dmitry Torokhov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Torokhov @ 2010-10-04 18:03 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-input, LM Sensors, Takashi Iwai, Jonathan Cameron Hi Jean, On Sat, Sep 25, 2010 at 01:23:30PM +0200, Jean Delvare wrote: > Hi Dmitry, > > I would like to kick the following 5 drivers out of drivers/hwmon: ams, > hdaps, hp_accel, lis3lv02d and applesmc. These are primarily > accelerometer devices, so the drivers do not belong to hwmon. > > ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. > They are pure accelerometer drivers as far as I can see. Would you take > them in drivers/input/misc? > > applesmc is more complex, it's a multifunction device. Maybe it would > better go to drivers/macintosh, where the other thermal management > drivers for mac machines live. > > If you don't want hdaps and hp_accel, they might also fit under > drivers/platform/x86. There are quite a few laptop-specific drivers > living there already. > > If nobody wants these drivers, drivers/misc is yet another option. I'm > open to suggestions. Virtually anything which moves these drivers > outside of drivers/hwmon will make me happy. > I looked over the drivers and none of them (with possible exception of lis3lv02d) are pure input devices either. I think the best course of action would be to move ams, applesmc, hdaps and hp_accel into drivers/*/platform (I'd say drivers/x86/platform except that I think apple one might not be x86 only). lis3lv02d could ether go into drivers/misc or stay where it is for the time being, pending resolution on overall IIO/Input/accelerometers decision. I'd take it in input/misc but accelerometer guys need to decide on common sysfs layout for such devices. -- Dmitry _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Accelerometer drivers in drivers/hwmon 2010-10-04 18:03 ` [lm-sensors] " Dmitry Torokhov @ 2010-10-05 10:16 ` Jonathan Cameron -1 siblings, 0 replies; 6+ messages in thread From: Jonathan Cameron @ 2010-10-05 10:16 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jean Delvare, linux-input, LM Sensors, Takashi Iwai, linux-iio@vger.kernel.org, Eric Piel, Frank Seidel Hi all, I've cc'd a few more relevant people and linux-iio as the below attribute discussion may result in minor changes there. > Hi Jean, > > On Sat, Sep 25, 2010 at 01:23:30PM +0200, Jean Delvare wrote: >> Hi Dmitry, >> >> I would like to kick the following 5 drivers out of drivers/hwmon: ams, >> hdaps, hp_accel, lis3lv02d and applesmc. These are primarily >> accelerometer devices, so the drivers do not belong to hwmon. >> >> ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. >> They are pure accelerometer drivers as far as I can see. Would you take >> them in drivers/input/misc? >> >> applesmc is more complex, it's a multifunction device. Maybe it would >> better go to drivers/macintosh, where the other thermal management >> drivers for mac machines live. >> >> If you don't want hdaps and hp_accel, they might also fit under >> drivers/platform/x86. There are quite a few laptop-specific drivers >> living there already. >> >> If nobody wants these drivers, drivers/misc is yet another option. I'm >> open to suggestions. Virtually anything which moves these drivers >> outside of drivers/hwmon will make me happy. >> > > I looked over the drivers and none of them (with possible exception of > lis3lv02d) are pure input devices either. I think the best course of > action would be to move ams, applesmc, hdaps and hp_accel into > drivers/*/platform (I'd say drivers/x86/platform except that I think > apple one might not be x86 only). > > lis3lv02d could ether go into drivers/misc or stay where it is for the > time being, pending resolution on overall IIO/Input/accelerometers > decision. I'd take it in input/misc but accelerometer guys need to > decide on common sysfs layout for such devices. Actually not so much a problem for that driver seeing as it provides very few sysfs interfaces... Lets take a quick look at what is there and see if we can resolve this question nice and quickly. selftest - device specific so consistency doesn't matter - and it's a perfectly good name anyway! position - (I suspect this is a somewhat misleading name) I could be wrong but I doubt anyone is using this interface for cases where they care if they get a consistent set of readings, I'd advocate splitting that one up into three separate attributes. Whilst a single attribute is just fine if you know exactly what the device you are using is, it really doesn't generalize well to devices that aren't 3d accelerometers or have addition sensor types. We can quite happily maintain the 'position' interface as well though for compatibility reasons. I'd just add, accel_x_input, accel_y_input and accel_z_input. rate - here we have a subtle and largerly irrelevant difference. IIO uses sampling_frequency but rate is just as valid. We just came from a more data capture terminology whereas I guess rate is more common when considering data streams? If I'm playing devil's advocate I guess rate might imply a data rate and hence people might interpret it as being in bytes per second. Then again I'm sure sampling_frequency can also be misinterpreted! This is a large complex driver which is definitely in input in a sense (even if it is located elsewhere in the tree). Until someone is using one of these parts in a circumstance where they need the other bits of IIO it doesn't to my mind make sense to do a complete rewrite. There are a lot of bells and whistles in here that we would need to support that aren't even vaguely of interest for things other than input usage. These are very much input oriented devices (supporting things like 'click' detection. Hence I'd encourage you to pick this one up for input. The misc option is fine with me as well. Jonathan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lm-sensors] Accelerometer drivers in drivers/hwmon @ 2010-10-05 10:16 ` Jonathan Cameron 0 siblings, 0 replies; 6+ messages in thread From: Jonathan Cameron @ 2010-10-05 10:16 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jean Delvare, linux-input, LM Sensors, Takashi Iwai, linux-iio@vger.kernel.org, Eric Piel, Frank Seidel Hi all, I've cc'd a few more relevant people and linux-iio as the below attribute discussion may result in minor changes there. > Hi Jean, > > On Sat, Sep 25, 2010 at 01:23:30PM +0200, Jean Delvare wrote: >> Hi Dmitry, >> >> I would like to kick the following 5 drivers out of drivers/hwmon: ams, >> hdaps, hp_accel, lis3lv02d and applesmc. These are primarily >> accelerometer devices, so the drivers do not belong to hwmon. >> >> ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device. >> They are pure accelerometer drivers as far as I can see. Would you take >> them in drivers/input/misc? >> >> applesmc is more complex, it's a multifunction device. Maybe it would >> better go to drivers/macintosh, where the other thermal management >> drivers for mac machines live. >> >> If you don't want hdaps and hp_accel, they might also fit under >> drivers/platform/x86. There are quite a few laptop-specific drivers >> living there already. >> >> If nobody wants these drivers, drivers/misc is yet another option. I'm >> open to suggestions. Virtually anything which moves these drivers >> outside of drivers/hwmon will make me happy. >> > > I looked over the drivers and none of them (with possible exception of > lis3lv02d) are pure input devices either. I think the best course of > action would be to move ams, applesmc, hdaps and hp_accel into > drivers/*/platform (I'd say drivers/x86/platform except that I think > apple one might not be x86 only). > > lis3lv02d could ether go into drivers/misc or stay where it is for the > time being, pending resolution on overall IIO/Input/accelerometers > decision. I'd take it in input/misc but accelerometer guys need to > decide on common sysfs layout for such devices. Actually not so much a problem for that driver seeing as it provides very few sysfs interfaces... Lets take a quick look at what is there and see if we can resolve this question nice and quickly. selftest - device specific so consistency doesn't matter - and it's a perfectly good name anyway! position - (I suspect this is a somewhat misleading name) I could be wrong but I doubt anyone is using this interface for cases where they care if they get a consistent set of readings, I'd advocate splitting that one up into three separate attributes. Whilst a single attribute is just fine if you know exactly what the device you are using is, it really doesn't generalize well to devices that aren't 3d accelerometers or have addition sensor types. We can quite happily maintain the 'position' interface as well though for compatibility reasons. I'd just add, accel_x_input, accel_y_input and accel_z_input. rate - here we have a subtle and largerly irrelevant difference. IIO uses sampling_frequency but rate is just as valid. We just came from a more data capture terminology whereas I guess rate is more common when considering data streams? If I'm playing devil's advocate I guess rate might imply a data rate and hence people might interpret it as being in bytes per second. Then again I'm sure sampling_frequency can also be misinterpreted! This is a large complex driver which is definitely in input in a sense (even if it is located elsewhere in the tree). Until someone is using one of these parts in a circumstance where they need the other bits of IIO it doesn't to my mind make sense to do a complete rewrite. There are a lot of bells and whistles in here that we would need to support that aren't even vaguely of interest for things other than input usage. These are very much input oriented devices (supporting things like 'click' detection. Hence I'd encourage you to pick this one up for input. The misc option is fine with me as well. Jonathan _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-05 10:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-25 11:23 Accelerometer drivers in drivers/hwmon Jean Delvare 2010-09-25 11:23 ` [lm-sensors] " Jean Delvare 2010-10-04 18:03 ` Dmitry Torokhov 2010-10-04 18:03 ` [lm-sensors] " Dmitry Torokhov 2010-10-05 10:16 ` Jonathan Cameron 2010-10-05 10:16 ` [lm-sensors] " Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.