There are some functions that were missed by commit d77e7456 ("regmap:
Add bulk read/write callbacks into regmap_config") when support to define
bulk read/write callbacks in regmap_config was introduced.

The regmap_bulk_write() and regmap_noinc_write() functions weren't changed
to use the added map->write instead of the map->bus->write handler.

Also, the regmap_can_raw_write() was not modified to take map->write into
account. So will only return true if a bus with a .write callback is set.

Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config")
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20220616073435.1988219-4-javierm@redhat.comSigned-off-by: NMark Brown <broonie@kernel.org>

Before adding support to define bulk read/write callbacks in regmap_config
by the commit d77e7456 ("regmap: Add bulk read/write callbacks into
regmap_config"), the regmap_noinc_read() function returned an errno early
a map->bus->read callback wasn't set.

But that commit dropped the check and now a call to _regmap_raw_read() is
attempted even when bulk read operations are not supported. That function
checks for map->read anyways but there's no point to continue if the read
can't succeed.

Also is a fragile assumption to make so is better to make it fail earlier.

Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config")
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20220616073435.1988219-3-javierm@redhat.comSigned-off-by: NMark Brown <broonie@kernel.org>

Support for drivers to define bulk read/write callbacks in regmap_config
was introduced by the commit d77e7456 ("regmap: Add bulk read/write
callbacks into regmap_config"), but this commit wrongly dropped a check
in regmap_bulk_read() to determine whether bulk reads can be done or not.

Before that commit, it was checked if map->bus was set. Now has to check
if a map->read callback has been set.

Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config")
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20220616073435.1988219-2-javierm@redhat.comSigned-off-by: NMark Brown <broonie@kernel.org>

The map->bus can be NULL here, add the missing NULL pointer check.

Fixes: d77e7456 ("regmap: Add bulk read/write callbacks into regmap_config")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Mark Brown <broonie@kernel.org>
To: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20220509003035.225272-1-marex@denx.deSigned-off-by: NMark Brown <broonie@kernel.org>

Currently the regmap_config structure only allows the user to implement
single element register read/write using .reg_read/.reg_write callbacks.
The regmap_bus already implements bulk counterparts of both, and is being
misused as a workaround for the missing bulk read/write callbacks in
regmap_config by a couple of drivers. To stop this misuse, add the bulk
read/write callbacks to regmap_config and call them from the regmap core
code.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
To: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/r/20220430025145.640305-1-marex@denx.deSigned-off-by: NMark Brown <broonie@kernel.org>

There's an inconsistency that arises when a register set can be accessed
internally via MMIO, or externally via SPI. The VSC7514 chip allows both
modes of operation. When internally accessed, the system utilizes __iomem,
devm_ioremap_resource, and devm_regmap_init_mmio.

For SPI it isn't possible to utilize memory-mapped IO. To properly operate,
the resource base must be added to the register before every operation.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Link: https://lore.kernel.org/r/20220313224524.399947-3-colin.foster@in-advantage.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add an additional reg_downshift to be applied to register addresses before
any register accesses. An example of a device that uses this is a VSC7514
chip, which require each register address to be downshifted by two if the
access is performed over a SPI bus.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Link: https://lore.kernel.org/r/20220313224524.399947-2-colin.foster@in-advantage.comSigned-off-by: NMark Brown <broonie@kernel.org>

Since commit cffa4b21 ("regmap: debugfs: Fix a memory leak when
calling regmap_attach_dev"), the following debugfs error is seen
on i.MX boards:

debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!

In the attempt to fix the memory leak, the above commit added a NULL check
for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL
and then the new name is allocated via kasprintf().

For the second debugfs entry, map->debugfs_name() is no longer NULL, so
it will keep using the old entry name and the duplicate name error is seen.

Quoting Mark Brown:

"That means that if the device gets freed we'll end up with the old debugfs
file hanging around pointing at nothing.
...
To be more explicit this means we need a call to regmap_debugfs_exit()
which will clean up all the existing debugfs stuff before we loose
references to it."

Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix
the problem.

Tested on i.MX6Q and i.MX6SX boards.

Fixes: cffa4b21 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NFabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some device requires a special handling for reg_update_bits and can't use
the normal regmap read write logic. An example is when locking is
handled by the device and rmw operations requires to do atomic operations.
Allow to declare a dedicated function in regmap_config for
reg_update_bits in no bus configuration.
Signed-off-by: NAnsuel Smith <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some drivers might access regmap in a context where a raw spinlock is
held. An example is drivers/irqchip/irq-ls-extirq.c, which calls
regmap_update_bits() from struct irq_chip :: irq_set_type, which is a
method called by __irq_set_trigger() under the desc->lock raw spin lock.

Since desc->lock is a raw spin lock and the regmap internal lock for
mmio is a plain spinlock (which can become sleepable on RT), this is an
invalid locking scheme and we get a splat stating that this is a
"[ BUG: Invalid wait context ]".

It seems reasonable for regmap to have an option use a raw spinlock too,
so add that in the config such that drivers can request it.
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210825205041.927788-2-vladimir.oltean@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

The reg_fields array fed to {devm_}regmap_field_bulk_alloc is currently
not const, which is not correct on semantics (the functions shouldn't
change reg_field contents) and prevents pre-defined const reg_field
array to be used.

As the implementation of this function doesn't change the content of it,
just add const to its prototype.
Signed-off-by: NIcenowy Zheng <icenowy@sipeed.com>
Link: https://lore.kernel.org/r/20210802063741.76301-1-icenowy@sipeed.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix checkpatch warnings:
    WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: NJinchao Wang <wjc@cdjrlc.com>
Link: https://lore.kernel.org/r/20210628171907.63646-1-wjc@cdjrlc.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch fixes the offset of register error log
by using regmap_get_offset().
Signed-off-by: NJeongtae Park <jeongtae.park@gmail.com>
Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds support for 7 bits register, 17 bits value type register
formating. This is used, for example, by the Analog Devices
ADMV1013/ADMV1014.
Signed-off-by: NAntoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: NAndrei Drimbarean <andrei.drimbarean@analog.com>
Message-Id: <20210526085223.14896-1-antoniu.miclaus@analog.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set regmap raw read/write from i2c quirks max read/write
so regmap_raw_read/write can split the access into chunks
Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210512135222.223203-1-tanureal@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

_regmap_write can trigger a _regmap_select_page, which will call
another _regmap_write that will be executed first, but the log shows
the inverse order

Also, keep consistency with _regmap_read which only logs in case of
success
Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20201112150217.459844-1-tanureal@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Usage of regmap_field_alloc becomes much overhead when number of fields
exceed more than 3.
QCOM LPASS driver has extensively converted to use regmap_fields.

Using new bulk api to allocate fields makes it much more cleaner code to read!
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: NSrinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

While not destroying mutexes doesn't lead to memory leaks, it's still
the correct thing to do for mutex debugging accounting.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200928120614.23172-1-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

Many error paths in __regmap_init rely on ret being pre-initialised to
-EINVAL, add an extra initialisation in after the new call to
regmap_set_name.

Fixes: 94cc89eb ("regmap: debugfs: Fix handling of name string for debugfs init delays")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200918152212.22200-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Non-incrementing writes can fail if register + length crosses page
border. However for non-incrementing writes we should not check for page
border crossing. Fix this by passing additional flag to _regmap_raw_write
and passing length to _regmap_select_page basing on the flag.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: cdf6b11d ("regmap: Add regmap_noinc_write API")
Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Non-incrementing reads can fail if register + length crosses page
border. However for non-incrementing reads we should not check for page
border crossing. Fix this by passing additional flag to _regmap_raw_read
and passing length to _regmap_select_page basing on the flag.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 74fe7b55 ("regmap: Add regmap_noinc_read API")
Link: https://lore.kernel.org/r/20200917153405.3139200-1-dmitry.baryshkov@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Fixes: 94cc89eb ("regmap: debugfs: Fix handling of name string for debugfs init delays")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200918112002.15216-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

In regmap_debugfs_init the initialisation of the debugfs is delayed
if the root node isn't ready yet. Most callers of regmap_debugfs_init
pass the name from the regmap_config, which is considered temporary
ie. may be unallocated after the regmap_init call returns. This leads
to a potential use after free, where config->name has been freed by
the time it is used in regmap_debugfs_initcall.

This situation can be seen on Zynq, where the architecture init_irq
callback registers a syscon device, using a local variable for the
regmap_config. As init_irq is very early in the platform bring up the
regmap debugfs root isn't ready yet. Although this doesn't crash it
does result in the debugfs entry not having the correct name.

Regmap already sets map->name from config->name on the regmap_init
path and the fact that a separate field is used to pass the name
to regmap_debugfs_init appears to be an artifact of the debugfs
name being added before the map name. As such this patch updates
regmap_debugfs_init to use map->name, which is already duplicated from
the config avoiding the issue.

This does however leave two lose ends, both regmap_attach_dev and
regmap_reinit_cache can be called after a regmap is registered and
would have had the effect of applying a new name to the debugfs
entries. In both of these cases it was chosen to update the map
name. In the case of regmap_attach_dev there are 3 users that
currently use this function to update the name, thus doing so avoids
changes for those users and it seems reasonable that attaching
a device would want to set the name of the map. In the case of
regmap_reinit_cache the primary use-case appears to be devices that
need some register access to identify the device (for example devices
in the same family) and then update the cache to match the exact
hardware. Whilst no users do currently update the name here, given the
use-case it seemed reasonable the name might want to be updated once
the device is better identified.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Devices such as the AD5628 require 32 bits of data divided in 12 bits
for dummy, command and address, and 20 for data and dummy. Eg:

XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX

Where X is dont care, C is command, A is address and D is data bits.

Which would requierd the following regmap_config:

static const struct regmap_config config_dac = {
	.reg_bits = 12,
	.val_bits = 20,
	.max_register = 0xff,
};
Signed-off-by: NRicardo Ribalda <ribalda@kernel.org>
Link: https://lore.kernel.org/r/20200917114727.1120373-1-ribalda@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Regmap can't sleep if spinlock is used for the locking protection.
This patch fixes regression caused by a previous commit that switched
regmap to use fsleep() and this broke Amlogic S922X platform.

This patch adds new configuration option for regmap users, allowing to
specify whether regmap operations can sleep and assuming that sleep is
allowed if mutex is used for the regmap locking protection.
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Fixes: 2b32d2f7 ("regmap: Use flexible sleep")
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200902141843.6591-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The multi-reg write function uses udelay(), which is a busy-loop based
delaying function that is not suitable for a long delays. Hence let's
replace the udelay() with fsleep(), which is flexible sleep function that
selects best delay function based on the delay-time.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200830185356.5365-3-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Make regmap firmware node type agnostic by switching it to use fwnode.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200708161232.17914-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

This function is used by dev_get_regmap() to retrieve a regmap for the
specified device. If the device has more than one regmap, the name parameter
can be used to specify one.

The code here uses a pointer comparison to check for equal strings. This
however will probably always fail, as the regmap->name is allocated via
kstrdup_const() from the regmap's config->name.

Fix this by using strcmp() instead.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

When a register patch is registered the reg_sequence is copied but the
memory allocated is never freed. Add a kfree in regmap_exit to clean it
up.

Fixes: 22f0d90a ("regmap: Support register patch sets")
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200617152129.19655-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

There are two spaces between arguments in regmap_fields_update_bits_base()
so remove one.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200615072507.11303-1-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

The kerneldoc comment for regmap_test_bits() says that it returns -1 on
regmap_read() failure. This is not true - it will propagate the error
code returned by regmap_read(). Fix it.

Fixes: aa2ff9db ("regmap: provide helpers for simple bit operations")
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200607093421.22209-1-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

In many instances regmap_update_bits() is used for simple bit setting
and clearing. In these cases the last argument is redundant and we can
hide it with a static inline function.

This adds three new helpers for simple bit operations: set_bits,
clear_bits and test_bits (the last one defined as a regular function).
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The assembly and disassembly of data to be sent to or received from
a device invoke functions regmap_format_XX() and regmap_parse_XX()
that extract or insert data items from or into a buffer, using
assignments. In some cases the functions are called with a buffer
pointer with an odd address. On architectures with strict alignment
requirements this can result in a kernel crash. The assignments
have been replaced by functions that take alignment into account.
Signed-off-by: NJens Thoms Toerring <jt@toerring.de>
Link: https://lore.kernel.org/r/20200531095300.GA27570@toerring.deSigned-off-by: NMark Brown <broonie@kernel.org>

In many instances regmap_update_bits() is used for simple bit setting
and clearing. In these cases the last argument is redundant and we can
hide it with a static inline function.

This adds three new helpers for simple bit operations: set_bits,
clear_bits and test_bits (the last one defined as a regular function).
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

Add reg_update_bits() support in case some platforms use a special method
to update bits of registers.
Signed-off-by: NBaolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/df32fd0529957d1e7e26ba1465723f16cfbe92c8.1586757922.git.baolin.wang7@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

When checking if a register block is writable we must ensure that the
block does not start with or contain a non incrementing register.

Fixes: 8b9f9d4d ("regmap: verify if register is writeable before writing operations")
Signed-off-by: NBen Whitten <ben.whitten@gmail.com>
Link: https://lore.kernel.org/r/20200118205625.14532-1-ben.whitten@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

On buses like SlimBus and SoundWire which does not support
gather_writes yet in regmap, A bulk write on paged register
would be silently ignored after programming page.
This is because local variable 'ret' value in regmap_raw_write_impl()
gets reset to 0 once page register is written successfully and the
code below checks for 'ret' value to be -ENOTSUPP before linearising
the write buffer to send to bus->write().

Fix this by resetting the 'ret' value to -ENOTSUPP in cases where
gather_writes() is not supported or single register write is
not possible.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There were a few files in the regmap code that did not have SPDX
identifiers on them, so fix that up.  At the same time, remove the "free
form" text that specified the license of the file, as that is impossible
for any tool to properly parse.

Also, as Mark loves // comment markers, convert all of the headers to be
the same to make things look consistent :)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

regmap provides a couple of ways to validate the register range used.
a) maxim allowed register, b) writable/readable register tables,
c) callback function that can be provided by the driver to validate
a register. regmap framework should verify if registers
are writeable before every write operation. However this doesn't
seems to happen in every situation.

The method `_regmap_raw_write_impl` is only using the `writeable_reg`
callback to verify if register is writeable, ignoring the other two.
This can lead to undefined behaviour since this allows to write to
registers that could be declared un-writeable by using any other
option.

Change `_regmap_raw_write_impl` to use the `regmap_writeable` method
to verify if registers are writable before the write operation.
Signed-off-by: NNandor Han <nandor.han@vaisala.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Move the checking of the LOG_DEVICE into a function to reduce the
number of #ifdefs and  ensure more of the code gets compiled/checked,
and make it easier to change this for internal debugging purposes
(such as checking >1 device).
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>