linux/drivers/base/regmap, branch v4.8

Merge tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2016-09-23T18:50:49Z

Pull regmap fix from Mark Brown: "A fix for an issue with double locking that was introduced earlier this release. I'd missed in review that we were already in a locked region when trying to drop part of the cache" * tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: fix deadlock on _regmap_raw_write() error path

regmap: fix deadlock on _regmap_raw_write() error path

2016-09-22T10:24:22Z

Commit 815806e39bf6 ("regmap: drop cache if the bus transfer error") added a call to regcache_drop_region() to error path in _regmap_raw_write(). However that path runs with regmap lock taken, and regcache_drop_region() tries to re-take it, causing a deadlock. Fix that by calling map->cache_ops->drop() directly. Signed-off-by: Nikita Yushchenko Signed-off-by: Mark Brown

Merge remote-tracking branch 'regmap/fix/rbtree' into regmap-linus

2016-09-03T11:10:09Z

regmap: drop cache if the bus transfer error

2016-08-18T10:09:12Z

regmap_write ->_regmap_raw_write -->regcache_write first and than use map->bus->write to wirte i2c or spi But if the i2c or spi transfer failed, But the cache is updated, So if I use regmap_read will get the cache data which is not the real register value. Signed-off-by: Elaine Zhang Signed-off-by: Mark Brown

regmap: rbtree: Avoid overlapping nodes

2016-08-04T15:55:26Z

When searching for a suitable node that should be used for inserting a new register, which does not fall within the range of any existing node, we not only looks for nodes which are directly adjacent to the new register, but for nodes within a certain proximity. This is done to avoid creating lots of small nodes with just a few registers spacing in between, which would increase memory usage as well as tree traversal time. This means there might be multiple node candidates which fall within the proximity range of the new register. If we choose the first node we encounter, under certain register insertion patterns it is possible to end up with overlapping ranges. This will break order in the rbtree and can cause the cached register value to become corrupted. E.g. take the simplified example where the proximity range is 2 and the register insertion sequence is 1, 4, 2, 3, 5. * Insert of register 1 creates a new node, this is the root of the rbtree * Insert of register 4 creates a new node, which is inserted to the right of the root. * Insert of register 2 gets inserted to the first node * Insert of register 3 gets inserted to the first node * Insert of register 5 also gets inserted into the first node since this is the first node encountered and it is within the proximity range. Now there are two overlapping nodes. To avoid this always choose the node that is closest to the new register. This will ensure that nodes will not overlap. The tree traversal is still done as a binary search, we just don't stop at the first node found. So the complexity of the algorithm stays within the same order. Ideally if a new register is in the range of two adjacent blocks those blocks should be merged, but that is a much more invasive change and left for later. The issue was initially introduced in commit 472fdec7380c ("regmap: rbtree: Reduce number of nodes, take 2"), but became much more exposed by commit 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") which changed the order in which nodes are looked-up. Fixes: 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown

regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw

2016-07-29T22:02:19Z

In 3245d460 (regmap: cache: Fall back to register by register read for cache defaults) non-readable registers are skipped when initializing reg_defaults, but are still included in num_reg_defaults. So there can be uninitialized entries at the end of reg_defaults, which can cause problems when the register cache initializes from the full array. Fixed it by excluding non-readable registers from the count as well. Signed-off-by: Maarten ter Huurne Signed-off-by: Mark Brown

Merge remote-tracking branches 'regmap/topic/bulk', 'regmap/topic/i2c', 'regmap/topic/iopoll', 'regmap/topic/irq' and 'regmap/topic/maintainers' into regmap-next

2016-07-15T12:44:47Z

regmap: Support bulk writes for devices without raw formatting

2016-06-29T18:48:00Z

When doing a bulk writes from a device which lacks raw I/O support we fall back to doing register at a time reads but we still use the raw formatters in order to render the data into the word size used by the device (since bulk reads still operate on the device word size rather than unsigned ints). This means that devices without raw formatting such as those that provide reg_read() are not supported. Provide handling for them by copying the values read into native endian values of the appropriate size. This complements commit d5b98eb12420 ("regmap: Support bulk reads for devices without raw formatting"). Signed-off-by: Chen-Yu Tsai 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

regmap: irq: Add support to call client specific pre/post interrupt service

2016-06-02T23:41:15Z

Regmap irq implements the generic interrupt service routine which is common for most of devices. Some devices, like MAX77620, MAX20024 needs the special handling before and after servicing the interrupt as generic. For the example, MAX77620 programming guidelines for interrupt servicing says: 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting GLBLM. 2. Read IRQTOP and service the interrupt accordingly. 3. Once all interrupts has been checked and serviced, the interrupt service routine un-masks the hardware interrupt line by clearing GLBLM. The step (2) is implemented in regmap irq as generic routine. For step (1) and (3), add callbacks from regmap irq to client driver to handle chip specific configurations. Signed-off-by: Laxman Dewangan Signed-off-by: Mark Brown