Messages in this thread | | | Date | Sat, 26 Nov 2011 02:04:48 +0400 | From | Anton Vorontsov <> | Subject | Re: [PATCH 8/9] bq27x00: Add miscdevice for each battery with ioctl for reading registers |
| |
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,
-- Anton Vorontsov Email: cbouatmailru@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |