On Fri, Oct 30, 2015 at 09:39:05AM +0900, Mark Brown wrote:

On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote:

quoted

However, you have regmap in the driver core already. Mark, is it
possible to have regmap API also allow doing raw underlying protocol
transfer so that consumers could issue command requests without needing
to know if they need to do it over i2c or spi or whatever. Or we need a
notion of command registers in regmap...

I don't think it's a good idea to break the encapsulation of the regmap
and export the raw I/O functionality directly, there seem to be more bad
ways of using that than good.  The driver must at some point know what
bus it is dealing with and be able to manage this itself.

I don't know what "command registers" are.

With this device, if the MSB of the first byte of the transaction is 1 then
a convertor command is encoded in that byte instead of a register address.

So here is my plan:
- Add a function pointer for tsc2005_cmd in the struct tsc2005
- Put the spi and i2c tsc2005_cmd versions in their respective drivers
- Pass the cmd functions to the core via tsc200x_probe

Any objections?
Other review suggestions before I code the revision?
Am I doing too much with a single patch?