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