Messages in this thread | | | From | Pali Rohár <> | Subject | Re: [PATCH 8/9] bq27x00: Add miscdevice for each battery with ioctl for reading registers | Date | Fri, 25 Nov 2011 23:48:39 +0100 |
| |
On Saturday 26 November 2011 02:04:48 Anton Vorontsov wrote: > On Fri, Nov 25, 2011 at 09:54:04PM +0100, Pali Rohár wrote: > > On Saturday 26 November 2011 00:46:26 Anton Vorontsov wrote: > > > On Fri, Nov 25, 2011 at 09:30:28PM +0100, Pali Rohár wrote: > > > [...] > > > > > > > This interface is not only for BME. Also some popular bq27200.sh > > > > script which print bq registers in human readable form needs > > > > this interface (with LD_PRELOAD library). > > > > > > > > Link for that shell script http://enivax.net/jk/n900/bq.tar > > > > > > That might be a good excuse to have the raw interface. Although, > > > as this is for debugging purposes only, the same effect can be > > > accomplished by unloading bq module and using i2c userspace > > > interface directly... I guess. > > > > Yes, unloading bq module and then starting script working. But I think > > that we could have some interface how to access directly to i2c when > > some i2c module for chip is loaded. > > This would be not safe as this might (in case of RW registers) > break kernel's driver behaviour (well, in bq case you only allow > reading, so not problem in this particular case). > > What would be more practical, is to allow I2C core to provide > userspace interface even for already bound I2C devices. > > That could be some kind of CONFIG_I2C_UNSAFE_DEBUG: when > selected I2C core would allow access to all I2C devices. But still, > the niche for such a feature is tiny, so I doubt that it is worth > doing at all. > > In any case, I just think that being able to access already bound > I2C devices from userspace might be a good thing for debugging, > but having such an interface per-driver is impractical. > > Thanks,
Yes, you are right that per-driver access is bad. So I will use this ioctl interface patch only in maemo specified kernels (eg. maemo kernel-power).
-- Pali Rohár pali.rohar@gmail.com[unhandled content-type:application/pgp-signature] | |