>-----Original Message----- >From: Guenter Roeck [mailto:guenter.roeck@xxxxxxxxxxxx] >Sent: Monday, October 25, 2010 7:48 AM >To: Jonathan Cameron >Cc: Mike Frysinger; linux-iio@xxxxxxxxxxxxxxx; >device-drivers-devel@xxxxxxxxxxxxxxxxxxxx; Zhang, Sonic >Subject: Re: [PATCH 12/14] staging: iio: adc: new driver for >ADT7408 temperature sensors > >On Sun, Oct 24, 2010 at 06:53:44PM -0400, Jonathan Cameron wrote: >> On 10/23/10 21:29, Mike Frysinger wrote: >> > From: Sonic Zhang <sonic.zhang@xxxxxxxxxx> >> Here we enter new territory. This device is already supported in >> hwmon. Do we have a usecase that is not covered by that driver? >> >> If this is only for hardware monitoring by Guenter (cc'd) >can perhaps >> advise on how to support everything you have here... >> > >device_id and manufactory_id (shouldn't that be >manufacturer_id ?) don't provide much value since they are (or >could be) already part of the device name. > >"capability" reflects a raw register value. I would be opposed >to any attribute like that, since it does not mean anything >beyond the driver for that specific chip. >The data it provides might make sense in the driver >documentation, but what is anyone supposed to do with the >returned hex value ? That kind of ABI really does not make any >sense. If the reported values are really valuable enough to be >reported, a real abi (eg tempX_accuracy and tempX_resolution) >would be much better. With the raw register value, the driver gives application develop full flexibility to control the device. Is it possible to define a unifiied ABI for all different ADCs in IIO framework? May IIO should document a policy on ABI difinition. > >For "power-save" (or "power-down" ?) and "full" mode I am not >sure why suspend/resume isn't used instead. Is that some new >upcoming ABI ? > I think the user may want to disable specific AD sensors while still keeping system running. Sonic -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
