When regmap_bulk_write() is called with the map->use_single_rw flag set
an immediate mutex deadlock happens because regmap_raw_write() is called
after obtaining the mutex and regmap_raw_write() itself then tries to
obtain the mutex as well.

It is obvious that no one other than myself tried it with a real device.
I did, but only for the purposes of an experiment and demonstration.

But even if this situation will never ever happen with a real device, it
is a bug and therefore should be fixed.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

With devices which have a dense and small register map but placed at a large
offset the global cache_present bitmap imposes a huge memory overhead. Making
the cache_present per rbtree node avoids the issue and easily reduces the memory
footprint by a factor of ten. For devices with a more sparse map or without a
large base register offset the memory usage might increase slightly by a few
bytes, but not significantly. E.g. for a device which has ~50 registers at
offset 0x4000 the memory footprint of the register cache goes down form 2496
bytes to 175 bytes.

Moving the bitmap to a per node basis means that the handling of the bitmap is
now cache implementation specific and can no longer be managed by the core. The
regcache_sync_block() function is extended by a additional parameter so that the
cache implementation can tell the core which registers in the block are set and
which are not. The parameter is optional and if NULL the core assumes that all
registers are set. The rbtree cache also needs to implement its own drop
callback instead of relying on the core to handle this.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Support for reducing the number of nodes and memory consumption of the rbtree
cache by allowing for small unused holes in the node's register cache block was
initially added in commit 0c7ed856 ("regmap: Cut down on the average # of nodes
in the rbtree cache"). But the commit had problems and so its effect was
reverted again in commit 4e67fb5f ("regmap: rbtree: Fix overlapping rbnodes.").
This patch brings the feature back of reducing the average number of nodes,
which will speedup node look-up, while at the same time also reducing the memory
usage of the rbtree cache. This patch takes a slightly different approach than
the original patch though. It modifies the adjacent node look-up to not only
consider nodes that are just one to the left or the right of the register but
any node that falls in a certain range around the register. The range is
calculated based on how much memory it would take to allocate a new node
compared to how much memory it takes adding a set of unused registers to an
existing node. E.g. if a node takes up 24 bytes and each register in a block
uses 1 byte the range will be from the register address - 24 to the register
address + 24. If we find a node that falls within this range it is cheaper or as
expensive to add the register to the existing node and have a couple of unused
registers in the node's cache compared to allocating a new node.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

A register which is adjacent to a node will either be left to the first
register or right to the last register. It will not be within the node's range,
so there is no point in checking for each register cached by the node whether
the new register is next to it. It is sufficient to check whether the register
comes before the first register or after the last register of the node.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The regmap_debugfs_get_dump_start() function maps from a file offset to the
register that can be found at that position in the file. This is done using a
look-up table. Commit d6814a7d ("regmap: debugfs: Suppress cache for partial
register files") added a check to bypass the look-up table for partial register
files, since the offsets in that table are only correct for the full register
file. The check incorrectly uses the file offset instead of the register base
address and returns it. This will cause the file offset to be interpreted as a
register address which will result in a incorrect output from the registers file
for all reads except at position 0.

The issue can easily be reproduced by doing small reads the registers file, e.g.
`dd if=registers bs=10 count=5`.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

There are a couple of calculations, which convert between register addresses and
block indices, in regcache_rbtree_sync() and regcache_rbtree_node_alloc() which
assume that reg_stride is 1. This will break the rb cache for configurations
which do not use a reg_stride of 1.

Also rename 'base' in regcache_rbtree_sync() to 'start' to avoid confusion with
'base_reg'.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Avoid overlapping register regions by making the initial blklen of a new
node 1. If a register write occurs to a yet uncached register, that is
lower than but near an existing node's base_reg, a new node is created
and it's blklen is set to an arbitrary value (sizeof(*rbnode)). That may
cause this node to overlap with another node. Those nodes should be merged,
but this merge doesn't happen yet, so this patch at least makes the initial
blklen small enough to avoid hitting the wrong node, which may otherwise
lead to severe breakage.
Signed-off-by: NDavid Jander <david@protonic.nl>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

It may be useful to register multiple patches with regmap, for example
one that depends on the device revision and one that depends on the system
configuration. Add support for doing this, appending any new patches to
the existing patches.
Signed-off-by: NMark Brown <broonie@linaro.org>

The regmap_writeable() check should not be done in
regcache_write() because this prevents read-only
registers to be cached. After a read on a read-only
register its value will not be stored in the cache
and the next time someone will try to read it the
value will be read from the bus instead of the
cache.

Instead the regmap_writeable() check should be done
in _regmap_write() to prevent callers from writing
to read-only registers.
Signed-off-by: NIonut Nicu <ioan.nicu.ext@nsn.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

In the initial case when no reg_defaults values are
provided and no register value was added to the cache
yet, the cache_present bitmap is NULL. If this function
is invoked for any register it should return false
(i.e. the register is not cached) instead of true.
Signed-off-by: NIonut Nicu <ioan.nicu.ext@nsn.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

I see no reason why a virtual range shouldn't be allowed to cover its
own data window if the page selection register is in the same place
on every page.
For chips which use paged access for all of their registers, but only
when connected via I2C, and which can access the whole register space
directly when connected via SPI, this allows to avoid acrobatics with
the register ranges by simply mapping the I2C ranges over the data
window beginning at 0x0, and then using linear access for the SPI
variant.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

regcache_sync_block_raw_flush() expects the address of the register after last
register that needs to be synced as its parameter. But the last call to
regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address
of the last register in the block. This effectively always skips over the last
register in a block, even if it needs to be synced. In order to fix it increase
the address by one register.

The issue was introduced in commit 75a5f89f ("regmap: cache: Write consecutive
registers in a single block write").

Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The usage of strict_strto*() is not preferred, because
strict_strto*() is obsolete. Thus, kstrto*() should be
used.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In case the hardware interrupt mask register does not prevent the chip level
irq from being asserted by the corresponding interrupt status bit, already
set interrupt bits should to be cleared once after masking them during
initialization. Add a flag to let drivers enable this behavior.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Fix the following sparse warnings:

drivers/base/regmap/regmap.c:305:13: warning: context imbalance in 'regmap_lock_spinlock' - wrong count at exit
drivers/base/regmap/regmap.c:314:13: warning: context imbalance in 'regmap_unlock_spinlock' - unexpected unlock
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Commit f8bd822c ("regmap: cache: Factor out block sync") made
regcache_rbtree_sync() call regmap_async_complete(), which in turn does
not check for map->bus before dereferencing it.

This causes a NULL pointer dereference on bus-less maps.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Cc: stable@vger.kernel.org [v3.10 only]
Signed-off-by: NMark Brown <broonie@linaro.org>

The cache is based on the full register map so confuses things if used
for a partial map.
Reported-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

It is common to access regmap registers at bit level, using
regmap_update_bits or regmap_read functions, however the end user has to
take care of a mask or shifting. This becomes overhead when such use
cases are high. Having a common function to do this is much convenient
and less error prone.

The idea of regmap_field is simple, regmap_field gives a logical
structure to bits of the regmap register, and the driver can use this
logical entity without the knowledge of the bit positions and masks all
over the code. This way code looks much neat and it need not handle the
masks, shifts every time it access the those entities.

With this new regmap_field_read/write apis the end user can setup a
regmap field using regmap_field_init and use the return regmap_field to
read write the register field without worrying about the masks or
shifts.

Also this apis will be useful for drivers which are based on regmaps,
like some clocks or pinctrls which can work on the regmap_fields
directly without having to worry about bit positions.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently all register maps with a cache need to provide a volatile
callback since the default is to assume all registers are volatile.
This is not sensible if we have a cache so change the default to be
fully cached if a cache is provided.
Signed-off-by: NMark Brown <broonie@linaro.org>

This can be used for cache types for which syncing values one by one is
equally efficient as syncing a range, such as the flat cache.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

A node starting before the minimum register is no reason to reject it,
since its end could be in range. The check for the end already exists
two lines lower, so we can just remove the incorrect check.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

regmap-mmio uses a spinlock with spin_lock() and spin_unlock() for locking.
To be able to use the regmap API from different contexts (atomic vs non-atomic),
without the risk of race conditions, we need to use spin_lock_irqsave() and
spin_lock_irqrestore() instead. A new field, the spinlock_flags field, is added
to regmap struct to store the flags between regmap_{,un}lock_spinlock(). The
spinlock_flags field itself is also protected by the spinlock.

Thanks to Stephen Warren for the suggestion of this particular solution.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The parameter passed to the regmap lock/unlock callbacks needs to be
map->lock_arg, regcache passes just map. This works fine in the case that no
custom locking callbacks are used since in this case map->lock_arg equals map,
but will break when custom locking callbacks are used. The issue was introduced
in commit 0d4529c5("regmap: make lock/unlock functions customizable") and is
fixed by this patch.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The parameter passed to the regmap lock/unlock callbacks needs to be
map->lock_arg, regcache passes just map. This works fine in the case that no
custom locking callbacks are used, since in this case map->lock_arg equals map,
but will break when custom locking callbacks are used. The issue was introduced
in commit 0d4529c5 ("regmap: make lock/unlock functions customizable") and is
fixed by this patch.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

regmap_debugfs_get_dump_start should return the offset of the register
it should start reading from, However in the current code at one point
the code does not return correct register offset.

With this patch all the returns from this function takes reg_stride in
to consideration to return correct offset.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

A register write to hardware is reasonably unlikely to cause locking
dependency issues, the reason we're tainting is that unexpected changes
in the hardware configuration may confuse drivers.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If range information has been provided then when we allocate a rbnode
within a range allocate the entire range. The goal is to minimise the
number of reallocations done when combining or extending blocks. At
present only readability and yes_ranges are taken into account, this is
expected to cover most cases efficiently.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for being slightly smarter about how we allocate memory
factor out the node allocation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Allow drivers to use an access table as part of their implementation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Allow drivers to discard parts of the register cache, for example if part
of the hardware has been reset.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

_regmap_raw_write() contains code to call regcache_write() to write
values to the cache. That code calls memcpy() to copy the value data to
the start of the work_buf. However, at least when _regmap_raw_write() is
called from _regmap_bus_raw_write(), the value data is in the work_buf,
and this memcpy() operation may over-write part of that value data,
depending on the value of reg_bytes + pad_bytes. At least when using
reg_bytes==1 and pad_bytes==0, corruption of the value data does occur.

To solve this, remove the memcpy() operation, and modify the subsequent
.parse_val() call to parse the original value buffer directly.

At least in the case of 8-bit register address and 16-bit values, and
writes of single registers at a time, this memcpy-then-parse combination
used to cancel each-other out; for a work-buffer containing xx 89 03,
the memcpy changed it to 89 03 03, and the parse_val changed it back to
89 89 03, thus leaving the value uncorrupted. This appears completely
accidental though. Since commit 8a819ff8 "regmap: core: Split out in
place value parsing", .parse_val only returns the parsed value, and does
not modify the buffer, and hence does not (accidentally) undo the
corruption caused by memcpy(). This caused bogus values to get written
to HW, thus preventing e.g. audio playback on systems with a WM8903
CODEC. This patch fixes that.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This reverts commit bc8ce4 (regmap: don't corrupt work buffer in
_regmap_raw_write()) since it turns out that it can cause issues when
taken in isolation from the other changes in -next that lead to its
discovery.  On the basis that nobody noticed the problems for quite some
time without that subsequent work let's drop it from v3.9.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Fix format specifier in dev_dbg and suppress the following warning

drivers/base/regmap/regcache.c: In function
‘regcache_sync_block_raw_flush’:
drivers/base/regmap/regcache.c:593:2: warning: format ‘%d’ expects
argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat]
Signed-off-by: NStratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

regcache_sync_block_raw is used only in this file. Hence make it static.
Silences the following warning:
drivers/base/regmap/regcache.c:608:5: warning:
symbol 'regcache_sync_block_raw' was not declared. Should it be static?
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

When syncing blocks of data using raw writes combine the writes into a
single block write, saving us bus overhead for setup, addressing and
teardown.

Currently the block write is done unconditionally as it is expected that
hardware which has a register format which can support raw writes will
support auto incrementing writes, this decision may need to be revised in
future.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>

For code clarity after implementing block writes split out the raw and
non-raw I/O sync implementations.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>

The idea of holding blocks of registers in device format is shared between
at least rbtree and lzo cache formats so split out the loop that does the
sync from the rbtree code so optimisations on it can be reused.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>

The idea of maintaining a bitmap of present registers is something that
can usefully be used by other cache types that maintain blocks of cached
registers so move the code out of the rbtree cache and into the generic
regcache code.

Refactor the interface slightly as we go to wrap the set bit and enlarge
bitmap operations (since we never do one without the other) and make it
more robust for reads of uncached registers by bounds checking before we
look at the bitmap.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>

Let's only write once...
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>