_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>

The last register block, which falls into the specified range, is not handled
correctly. The formula which calculates the number of register which should be
synced is inverse (and off by one). E.g. if all registers in that block should
be synced only one is synced, and if only one should be synced all (but one) are
synced. To calculate the number of registers that need to be synced we need to
subtract the number of the first register in the block from the max register
number and add one. This patch updates the code accordingly.

The issue was introduced in commit ac8d91c8 ("regmap: Supply ranges to the sync
operations").
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

In the rbtree code we are exposing statistics relating to the
number of nodes/registers of the rbtree cache for each of the
devices.  Ensure that `map->debugfs' has been initialized before
we attempt to initialize the debugfs entry for the rbtree cache.
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put(_sync) in such case.

Signed-off-by Liu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NLi Fei <fei.li@intel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some mmio devices have a dedicated interface clock that needs
to be enabled to access their registers. This patch optionally
enables a clock before accessing registers in the regmap_bus
callbacks.

I added (devm_)regmap_init_mmio_clk variants of the init
functions that have an added clk_id string parameter. This
is passed to clk_get to request the clock from the clk
framework.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation to support the regmap debugfs ranges functionality
factor this code out to a separate function.  We'll need to ensure
that the value has been correctly calculated from two separate places
in the code.
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Optimize this so that we can better guess where to start scanning
from.  We know the length of the register field format, therefore
given the file pointer position align to the nearest register
field and scan from there onwards.  We round down in this calculation
and we let the rest of the code figure out where to start scanning
from.
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We are keeping track of the maximum register as well, this will make
things easier for us in sharing this code with the code implementing
the register ranges functionality.  It also simplifies a bit the
calculations when looking for the relevant block:offset from within
the cache.
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

At the moment, if the length of the register field format is
N bytes, we can only get anything meaningful back to userspace
by providing a buffer that is N + 2 bytes large.  Fix this
so we that we only need to provide a buffer of N bytes.
Signed-off-by: NDimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

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

This fixes below build error when CONFIG_REGMAP=y && CONFIG_REGMAP_SPI=m

ERROR: "regmap_async_complete_cb" [drivers/base/regmap/regmap-spi.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This fixes:

drivers/base/regmap/regmap.c: In function 'regmap_async_complete_cb':
drivers/base/regmap/regmap.c:1656:3: error: 'TASK_NORMAL' undeclared (first use in this function)
drivers/base/regmap/regmap.c:1656:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/base/regmap/regmap.c: In function 'regmap_async_complete':
drivers/base/regmap/regmap.c:1688:2: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function)
drivers/base/regmap/regmap.c:1688:2: error: implicit declaration of function 'schedule'

An alternative might be to adjust linux/wait.h to include linux/sched.h,
but since that hasn't been done before, I assume we're consciously
avoiding doing that.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

Some use cases like firmware download can transfer a lot of data in quick
succession. With high speed buses these use cases can benefit from having
multiple transfers scheduled at once since this allows the bus to minimise
the delay between transfers.

Support this by adding regmap_raw_write_async(), allowing raw transfers to
be scheduled, and regmap_async_complete() to wait for them to finish.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This commit adds provision for "no-bus" usage of the regmap API. In
this configuration user can provide API with two callbacks 'reg_read'
and 'reg_write' which are to be called when reads and writes to one of
device's registers is performed. This is useful for devices that
expose registers but whose register access sequence does not fit the 'bus'
abstraction.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Gcc warns about the case where regmap_read_debugfs tries to walk an
empty map->debugfs_off_cache list, which would results in uninitialized
variable getting returned, if we hadn't checked the same condition
just before that.

After an originally suggested inferior patch from Arnd Bergmann,
this is the solution that Russell King came up with, sidestepping
the problem by merging the error case for an empty list with the
normal path.

Without this patch, building mxs_defconfig results in:

drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
Reported-by: NVincent Stehle <v-stehle@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NNestor Ovroy <novroy@riseup.net>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We don't want to bomb out early if we failed to get the cache any more,
just soldier on instead and we won't get confused and always return the
first block.

Reported-by: Philipp Zabel <p.zabel@pengutronix.de
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register write function.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register read function.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Since regmap already has support for formatting 24 bit wide values, so adding
support for 24 bit wide registers is pretty much straight forward.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

This should never happen in the real world.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Rather than trying to soldier on with a partially allocated cache just
throw the cache away and pretend we don't have one in case we can get a
full cache next time around.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Check for the block we were asked to start from, not the position we're
in.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Return the start of the last block we tried to read rather than a position,
and also make sure we update the byte position while we're at it.  Without
this reads that go into nonexistant areas get confused.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Support devices which have an enable rather than mask register for wake
sources.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This wasn't implemented but happened to work on test systems due to lack
of wake mask inversion support.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If the interrupt status registers are a single block of registers and the
chip supports bulk reads then do a single bulk read rather than pay the
extra I/O cost. This restores the original behaviour which was lost when
support for register striding was added.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for adding back support for block reads.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

While for I2C and SPI devices the overhead of using rbtree for devices with
only one block of registers is negligible the same isn't always going to
be true for MMIO devices where the I/O costs are very much lower. Cater
for these devices by adding a simple flat array type for them where the
lookups are simple array accesses, taking us right back to the original
ASoC cache implementation.

Thanks to Magnus Damm for the discussion which prompted this.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

regmap-irq framework is used vastly by mfd drivers and some of
devices like TPS65910, TPS80036 do not support the wake base
register to enable wake.

Currently wake in regmap-irq only supported if client driver
passes the wake base register.

As the regmap-irq is mostly used by mfd devices and it is require
to have wake support from these devices in most of use cases,
enabling wake support by default in regmap-irq.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Avoid doing a linear scan of the entire register map for each read() of
the debugfs register dump by recording the offsets where valid registers
exist when we first read the registers file. This assumes the set of
valid registers never changes, if this is not the case invalidation of
the cache will be required.

This could be further improved for large blocks of contiguous registers
by calculating the register we will read from within the block - currently
we do a linear scan of the block. An rbtree may also be worthwhile.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for doing things a bit more quickly than a linear scan
factor out the initial seek from the debugfs register dump.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If count is less than the size of a register then we may hit integer
wraparound when trying to move backwards to check if we're still in
the buffer. Instead move the position forwards to check if it's still
in the buffer, we are unlikely to be able to allocate a buffer
sufficiently big to overflow here.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

No point in calculating them every time.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Many of the regmap enabled drivers implementing one or more of the
readable, writeable, volatile and precious methods use the same code
pattern:

	return ((reg >= X && reg <= Y) || (reg >= W && reg <= Z) || ...)

Switch to a data driven approach, using tables to describe
readable/writeable/volatile and precious registers ranges instead.
The table based check can still be overridden by passing the usual function
pointers via struct regmap_config.
Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This seems to be the most common way of reporting register numbers, it's
certainly what we do for trace.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>