Re: [PATCH 8/9] bq27x00: Add miscdevice for each battery with ioctlfor reading registers

[Anton Vorontsov]

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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/