kernel/drivers/base/regmap/regmap-i2c.c, branch linux-5.1.y

regmap-i2c: Off by one in regmap_i2c_smbus_i2c_read/write()

2018-02-08T15:36:35Z

The commit message says that we are allowed to read and write up to 32 bytes but the code only allows us to write 31 bytes. In other words, the ">=" should be changed to ">". But this is already checked in regmap_raw_read()/write() so we can just remove the if statemetents. Fixes: 29332534e2b6 ("regmap-i2c: Add smbus i2c block support") Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown

regmap-i2c: Use i2c block command only if register value width is 8 bit

2016-06-22T12:50:51Z

Chips with 16-bit registers don't usually work well with I2C block commands. For example, neither the LM75 datasheet nor the TMP102 datasheet mentions block command support, and in fact it does not work for any of those chips. Also, it is not clear how the block command would handle 16-bit SMBus operations in the fist place, since the data format associated with those commands is either little endian or big endian, which requires some kind of conversion to or from host byte order. Only use i2c block commands if both register and value width is 8 bit. Signed-off-by: Guenter Roeck Signed-off-by: Mark Brown

Merge remote-tracking branches 'regmap/topic/lockdep' and 'regmap/topic/seq-delay' into regmap-next

2015-09-04T16:22:10Z

regmap-i2c: Add smbus i2c block support

2015-08-30T09:19:23Z

This allows to read/write up to 32 bytes of data and is to be prefered if supported before the register read/write smbus support. Signed-off-by: Markus Pargmann Signed-off-by: Mark Brown

regmap: Move documentation to regmap.h

2015-08-11T16:21:44Z

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown

regmap: Use different lockdep class for each regmap init call

2015-08-07T13:50:59Z

Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown

regmap: Fix i2c word access when using SMBus access functions

2015-02-04T20:48:13Z

SMBus access functions assume that 16-bit values are formatted as little endian numbers. The direct i2c access functions in regmap, however, assume that 16-bit values are formatted as big endian numbers. As a result, the current code returns different values if an i2c chip's 16-bit registers are accessed through i2c access functions vs. SMBus access functions. Use regmap_smbus_read_word_swapped and regmap_smbus_write_word_swapped for 16-bit SMBus accesses if a chip is configured as REGMAP_ENDIAN_BIG. If the chip is configured as REGMAP_ENDIAN_LITTLE, keep using regmap_smbus_write_word_data and regmap_smbus_read_word_data. Otherwise reject registration if the controller does not support direct i2c accesses. Signed-off-by: Guenter Roeck Signed-off-by: Mark Brown

regmap: add DT endianness binding support.

2014-08-16T21:56:23Z

For many drivers which will support rich endianness of Devices need define DT properties by itself with the binding support. The endianness using regmap: Index Device Properties if needs bytes-swap, or just ignore it ------------------------------------------------------------- 1 BE 'big-endian' 2 LE 'little-endian' The properties include all the register values and the buffers. And these properties are very usful for the MMIO devices: Such as: a memory-mapped device, on one SoC is in BE mode, while in another SoC will be in LE mode, and the CPU will always in LE mode. For the first case, we must use cpu_to_be32/be32_to_cpu for 32-bit registers accessing, so the 'big-endian' property is needed. For the second case, we can just ignore the bytes-swap functions like cpu_to_le32/le32_to_cpu, so the 'little-endian' property could be abscent. And vice versa... Signed-off-by: Xiubo Li Signed-off-by: Mark Brown

regmap: i2c: fallback to SMBus if the adapter does not support standard I2C

2014-04-22T11:57:28Z

Some I2C adapters are only compatible with the SMBus protocol and do not support standard I2C transfers. Fallback to SMBus transfers if we encounter such kind of adapters. The transfer type is chosen according to the val_bits field in the regmap config. Signed-off-by: Boris BREZILLON Signed-off-by: Mark Brown

drivers/base: delete non-required instances of include

2014-02-14T22:31:37Z

None of these files are actually using any __init type directives and hence don't need to include . Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Cc: Len Brown Signed-off-by: Paul Gortmaker Acked-by: Pavel Machek Acked-by: Rafael J. Wysocki Acked-by: Mark Brown Signed-off-by: Greg Kroah-Hartman