> This debate is what I wanted to have. The new Melexis sensor will be > using it and since I think some others might also be using it in > future I would rather put it to i2c. It is more i2c command than > sensor specific so I think it fits into i2c. There is no thing as 'I2C command'. There are just I2C messages combined into a transfer. I think you mix SMBus and I2C terminology here. > Another gain is that when number of functions each device does increase, as > well as ram/rom addressing read commands with longer than 8-bit register read > commands will be needed. Especially since most sensors have digital design of > i2c interface (not software) which means native access to registers is required, > therefor 8bit read addressing (smbus) might not be suitable. Adding a function to i2c-core will grow the kernel for everyone. So, it really has to be justified. So, here is the deal: If you can send a series which fixes existing drivers to use your new function and it shows that it really saves code, we can add it. Otherwise "thinking it might be useful in the future" is too vague for me in this case. > I can fix the function name, but in core this is a master read command. What "core" are you referring to? You set up a write and a read message, no?
Attachment:
signature.asc
Description: Digital signature
