We'll need to call it from regmap-i2c.c, which can be built as module.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMark Brown <broonie@kernel.org>

Since we cannot make sure the 'val_count' will always be none zero
here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL
pointer dereference. This patch fixes this issue by adding check for
dev->NULL in all such places in regmap.c
Signed-off-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Recents commits for getting reg endianness causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianness only if dev
and dev->of_node exist.
Signed-off-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Split regmap_get_endian() in two functions, regmap_get_reg_endian() and
regmap_get_val_endian().

This allows to:
  - Get rid of the three switch()es on "type", incl. error handling in
    three "default" cases,
  - Get rid of the regmap_endian_type enum,
  - Get rid of the non-NULL check of "config" (regmap_init() already
    checks for that),
  - Get rid of the "endian" output parameters, and just return the
    regmap_endian enum value, as the functions can no longer fail.

This saves 21 lines of code (despite the still-present
one-comment-per-line over-documentation), and 30 bytes of code on ARM
V7.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

A previous over-zealous factorisation of code means that we only treat
registers as volatile if they are readable. For most devices this is fine
since normally most registers can be read and volatility implies
readability but for format_write() devices where there is no readback from
the hardware and we use volatility to mean simply uncacheability this means
that we end up treating all registers as cacheble.

A bigger refactoring of the code to clarify this is in order but as a fix
make a minimal change and only check readability when checking volatility
if there is no format_write() operation defined for the device.
Signed-off-by: NMark Brown <broonie@linaro.org>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Cc: stable@vger.kernel.org

Commit d647c199 ("regmap: add DT endianness binding support") had
some issues. Commit ba1b53fe ("regmap: Fix DT endianess parsing
logic") fixed the main problem. This patch fixes the other.

Specifically, restore the overall default of REGMAP_ENDIAN_BIG if none of
the config, DT, or the bus specify any endianness. Without this,
of_regmap_get_endian() could return REGMAP_ENDIAN_DEFAULT, which the
calling code can't handle. Since all busses do specify an endianness in
the current code, this makes no difference right now, but I saw no
justification in the patch description for removing this final default.

Also, clean up the code a bit:

* s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
  specific, even if the reason it was originally added was to add some
  DT-specific features.
* After potentially reading an endianess specification from DT, the code
  checks whether DT did specify an endianness, and if so, returns it. Move
  this test outside the whole switch statement so that if the
  REGMAP_ENDIAN_REG case ever modifies *endian, this check will pick that
  up. This partially reverts part of commit ba1b53fe ("regmap: Fix DT
  endianess parsing logic"), while maintaining the bug-fix that commit
  made to this code.
* Make the comments briefer, and only refer to the specific action taken
  at their location. This makes most of the comments independent of DT,
  and easier to follow.

Cc: Xiubo Li <Li.Xiubo@freescale.com>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Thierry Reding <treding@nvidia.com>
Fixes: d647c199 ("regmap: add DT endianness binding support")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Commit d647c199 ("regmap: add DT endianness binding support.")
added support to parse the device endianness from the device tree
but unfortunately the added logic doesn't have the same semantics
than the old code. This leads to a NULL dereference pointer error
when these properties are not provided by the Device Tree:

Unable to handle kernel NULL pointer dereference at virtual address 00000044
pgd = c0004000
[00000044] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc1-next-20140818ccu #671
task: ea412800 ti: ea484000 task.ti: ea484000
PC is at regmap_update_bits+0xc/0x5c

The problem is that platforms that rely on the default value now
gets different values due two related issues in the current code:

a) It only parses the endianness from DT for the regmap registers
   and not for the regmap values but it checks unconditionally in
   both cases if the resulting endiannes is REGMAP_ENDIAN_NATIVE.

b) REGMAP_ENDIAN_NATIVE is not even a valid DT property according
   to the regmap DT binding documentation so it shouldn't be set.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NMark Brown <broonie@linaro.org>

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: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NMark Brown <broonie@linaro.org>

Add a new function regmap_get_device to obtain the underlying struct
device from a regmap.
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

drivers/base/regmap/regmap.c: In function ‘_regmap_range_multi_paged_reg_write’:
drivers/base/regmap/regmap.c:1665: warning: ‘this_page’ may be used uninitialized in this function
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since we cannot make sure the 'len = pair_size * num_regs' will always
be none zero from the users, and then if 'num_regs' equals to zero by
mistake or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which
equals to ((void *)16).

So this patch fix this with just doing the 'len' zero check before calling
kzalloc().
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Some busses do not support sending/receiving multiple registers in one go.
Such kind of busses just unpack the registers that have been previously
packed by the regmap core or pack registers that will be later unpacked by
the core code.

Add reg_write and reg_read callbacks in order to optimize access through
this kind of busses.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Allow busses to request little endianness formatting and
parsing for 16- and 32-bit values. This will be useful to
support regmap-mmio.

For the following the scenarios using the regmap-mmio,
for example:

Index    CPU       Device     Endianess flag for values
----------------------------------------------------------
1        LE        LE         REGMAP_ENDIAN_DEFAULT/NATIVE
2        LE        BE         REGMAP_ENDIAN_BIG
3        BE        BE         REGMAP_ENDIAN_DEFAULT/NATIVE
4        BE        LE         REGMAP_ENDIAN_LITTLE

For one device driver, which will support all the cases above,
needs two boolean properties in DT node like: 'big-endian'
for case 2 and 'little-endian' for case 4, and for cases 1
and 3 they all will be absent.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

It need to add curly braces because the inner for "if" has
two statements.

coccicheck says:
 drivers/base/regmap/regmap.c:765:2-44:
code aligned with following code on line 766
Signed-off-by: NDaeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

regmap deploys the spinlock for the protection when set up in fast_io
mode.  This may lead to sleep-in-atomic by memory allocation with
GFP_KERNEL in regmap_bulk_write().  This patch fixes it by moving the
allocation out of the lock.

[Fix excessively large locked region -- broonie]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

With fast_io we use mutexes to lock the I/O operations so we would need
to do GFP_ATOMIC allocations if we wanted to do allocations inside the
lock as we do currently. Since it is unlikely that we will want to register
a patch outside of init where concurrency shouldn't be an issue move the
allocation of the patch data outside the lock.
Reported-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

This is the implementation of regmap_multi_reg_write()

There is a new capability 'can_multi_write' that device drivers
must set in order to use this multi reg write mode.

This replaces the first definition, which just defined the API.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

    In some cases, we need regmap's format parse_val function
to do be/le translation according to the bus configuration.
For example, snd_soc_bytes_put() uses regmap to write/read values,
and use cpu_to_be() directly to covert MASK into big endian. This
is a defect, and should use regmap's format function to do it according
to bus configuration.
Signed-off-by: NNenghua Cao <nhcao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since we now have an internal version of regmap_multi_reg_write use this
to apply the register patch.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Devices with more complex boot proceedures may occasionally apply the
register patch manual. regmap_multi_reg_write is a logical way to do so,
however the patch must be applied with cache bypass on, such that it
doesn't override any user settings. This patch adds a
regmap_multi_reg_write_bypassed function that applies a set of writes
with the bypass enabled.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

There should be no need for the writes supplied to this function to be
edited by it so mark them as const.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

   /drivers/base/regmap/regmap.c:717:6-33: WARNING:
Comparison to bool.

   More information about semantic patching is available at
http://coccinelle.lip6.fr/Signed-off-by: NNenghua Cao <nhcao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently, we check the registers in the patch are aligned to the
register stride everytime we sync the cache and the first time the patch
is written out is unchecked.

This patch checks the register patch when we first register it so the
first writes are no longer unchecked and then doesn't check on
subsequent syncs as the patch will be unchanged.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since sometimes the 'config' parameter has no use, it should be NULL.
And make the code simplifier.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Create special function regmap_attach_dev
which can be called separately out of regmap_init.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Check if regs are readable.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

regmap_bulk_write() should decay to performing individual writes
if we're using a "no-bus" regmap. Unfortunately, it returns an
error because there is no map->bus pointer. Fix it.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

regmap_bulk_read() should decay to performing individual reads if
we're using a "no-bus" regmap. Unfortunately, it returns an
error because there is no map->bus pointer. Fix it.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch give a warning when calling regmap_register_patch with
parameter num_regs <= 0.

When the num_regs parameter is zero and krealloc doesn't fail,
then the code would return an uninitialized value. However,
calling this function with num_regs == 0, would be a waste as it
essentially does nothing.
Signed-off-by: NCai Zhiyong <caizhiyong@huawei.com>
Reviewed-by: NGeyslan G. Bem <geyslan@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NCourtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

fix a trivial copy'n'paste error in the regmap kerneldoc, s/write/read/
for the regmap_read(), regmap_raw_read() and regmap_bulk_read() routines
Signed-off-by: NGerhard Sittig <gsi@denx.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Extend the interface for async I/O by allowing the value buffer to be
omitted and sending the value as part of the register buffer, minimising
the number of separate hardware operations required.
Signed-off-by: NMark Brown <broonie@linaro.org>

New API regmap_multi_reg_write() is defined that allows a set of reg,val
pairs to be written to a I2C client device as one block transfer from the
point of view of a single I2C master system.

A simple demonstration implementation is included that just splits the
block write request into a sequence of single register writes.

The implementation will be modified later to support those I2C clients
that implement the alternative non-standard MULTIWRITE block write mode
so to achieve a single I2C transfer that will be atomic even in multiple
I2C master systems.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NDavid Dajun Chen <david.chen@diasemi.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Try to speed up patch application a little using async I/O.
Signed-off-by: NMark Brown <broonie@linaro.org>

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>

Make it easier for drivers to include single register writes in
asynchronous sequences by providing async versions of the write
and update bits operations. The update bits operations are only
likely to be effective when used with devices that have caches
but this is common enough to be useful.
Signed-off-by: NMark Brown <broonie@linaro.org>

Rather than passing a flag around through the entire call stack store it
in the regmap struct and read it when required. This minimises the
visibility of the feature through the API, minimising the code updates
needed to use it more widely.
Signed-off-by: NMark Brown <broonie@linaro.org>

Since it is quite common for single register raw or async writes to be
generated by rbtree cache syncs or firmware downloads and essentially all
hardware will be faster with only a single transfer optimise this case by
copying single values into the internal scratch buffer before sending.
Signed-off-by: NMark Brown <broonie@linaro.org>