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>

If a regmap has "fast_io" set then its lock function uses a spinlock.
That doesn't work so well with the functions:
* regmap_cache_only_write_file()
* regmap_cache_bypass_write_file()

Both of the above functions have the pattern:
1. Lock the regmap.
2. Call:
   debugfs_write_file_bool()
     copy_from_user()
       __might_fault()
         __might_sleep()

Let's reorder things a bit so that we do all of our sleepable
functions before we grab the lock.

Fixes: d3dc5430 ("regmap: debugfs: Allow writes to cache state settings")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200715164611.1.I35b3533e8a80efde0cec1cc70f71e1e74b2fa0da@changeidSigned-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>

CONFIG_REGMAP is not selected when no other serial bus is supported.
It's largely academic since CONFIG_I2C is usually selected e.g. by
DRM, but still this can break randconfig so let's be explicit.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200707202628.113142-1-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Convert the argument to the newer fwnode_handle instead a device tree
node. Fortunately, there are no users for now. So this is an easy
change.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200706175353.16404-2-michael@walle.ccSigned-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>

This allows to access data with 16-bit width of registers
via i2c SMBus block functions.

The multi-command sequence of the reading function is not safe
and may read the wrong data from other address if other commands
are sent in-between the SMBus commands in the read function.

Read performance:
   32768 bytes (33 kB, 32 KiB) copied, 11.4869 s, 2.9 kB/s
Write performance(with 1-byte page):
   32768 bytes (33 kB, 32 KiB) copied, 129.591 s, 0.3 kB/s

The implementation is inspired by below commit
https://patchwork.ozlabs.org/patch/545292/

v2: add more descriptions about the issue that maybe introduced
    by this commit
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Link: https://lore.kernel.org/r/20200424123358.144850-1-acelan.kao@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add a new function regmap_add_irq_chip_np() with its corresponding
devm_regmap_add_irq_chip_np() variant. Sometimes one want to register
the IRQ domain on a different device node that the one of the regmap
node. For example when using a MFD where there are different interrupt
controllers and particularly for the generic regmap gpio_chip/irq_chip
driver. In this case it is not desireable to have the IRQ domain on
the parent node.
Signed-off-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200402203656.27047-5-michael@walle.ccSigned-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 executing the following command, we met kernel dump.
dmesg -c > /dev/null; cd /sys;
for i in `ls /sys/kernel/debug/regmap/* -d`; do
	echo "Checking regmap in $i";
	cat $i/registers;
done && grep -ri "0x02d0" *;

It is because the count value is too big, and kmalloc fails. So add an
upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.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>

regmap_bus structures are not changed anywhere. Mark them const.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/85e4141348db00ecf1f2bc5c2ff6ba3de75e8ff4.1578134920.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Both init functions have a stray "return NULL" at the end which is never
reached so drop them.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191119125837.47619-1-mika.westerberg@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some error paths in regmap_irq_thread put the pm_runtime others do not,
there is no reason to leave the pm_runtime enabled in some cases so
update those paths to also put the pm_runtime.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190812092409.21593-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

The existing code has a mixed select/depend usage which makes no sense.

config SOUNDWIRE_BUS
       tristate
       select REGMAP_SOUNDWIRE

config REGMAP_SOUNDWIRE
        tristate
        depends on SOUNDWIRE_BUS

Let's remove one layer of Kconfig definitions and align with the
solutions used by all other serial links.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190718230215.18675-1-pierre-louis.bossart@linux.intel.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

The debugfs core will warn if a file or directory can not be created, so
there's no need to duplicate the warning, nor really do anything else.

Cc: Mark Brown <broonie@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190731132923.GA13829@kroah.comSigned-off-by: NMark Brown <broonie@kernel.org>

REGMAP_SCCB is selected by ov772x and ov9650 drivers,
but CONFIG_REGMAP may not, so building will fails:

rivers/media/i2c/ov772x.c: In function ov772x_probe:
drivers/media/i2c/ov772x.c:1360:22: error: variable ov772x_regmap_config has initializer but incomplete type
  static const struct regmap_config ov772x_regmap_config = {
                      ^~~~~~~~~~~~~
drivers/media/i2c/ov772x.c:1361:4: error: const struct regmap_config has no member named reg_bits
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: 5bbf3221 ("media: ov772x: use SCCB regmap")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190704093553.49904-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-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>

Add basic support for i3c bus.
This is a simple implementation that only give support
for SDR Read and Write commands.
Signed-off-by: NVitor Soares <vitor.soares@synopsys.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

As detected by kmemleak running on i.MX6ULL board:

nreferenced object 0xd8366600 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937370 (age 933.220s)
  hex dump (first 32 bytes):
    64 75 6d 6d 79 2d 69 6f 6d 75 78 63 2d 67 70 72  dummy-iomuxc-gpr
    40 32 30 65 34 30 30 30 00 e3 f3 ab fe d1 1b dd  @20e4000........
  backtrace:
    [<b0402aec>] kasprintf+0x2c/0x54
    [<a6fbad2c>] regmap_debugfs_init+0x7c/0x31c
    [<9c8d91fa>] __regmap_init+0xb5c/0xcf4
    [<5b1c3d2a>] of_syscon_register+0x164/0x2c4
    [<596a5d80>] syscon_node_to_regmap+0x64/0x90
    [<49bd597b>] imx6ul_init_machine+0x34/0xa0
    [<250a4dac>] customize_machine+0x1c/0x30
    [<2d19fdaf>] do_one_initcall+0x7c/0x398
    [<e6084469>] kernel_init_freeable+0x328/0x448
    [<168c9101>] kernel_init+0x8/0x114
    [<913268aa>] ret_from_fork+0x14/0x20
    [<ce7b131a>] 0x0

Root cause is that map->debugfs_name is allocated using kasprintf
and then the pointer is lost by assigning it other memory address.
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NDaniel Baluta <daniel.baluta@nxp.com>
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>

Checking for value of type default value just after allocating will
always be zero and the type register default values will never be read,
so fix this!

Without this patch setting irq type will be silently ignored.
Patch "regmap: regmap-irq: Remove default irq type setting from core"
did remove the default mask but it forgot to remove the check before
reading the default type register.

Fixes: 84267d1b ("regmap: regmap-irq: Remove default irq type setting from core")
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Improve the speed of the loop jumping to the next
available register
Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NLucas Tanure <tanureal@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On one hand commit 28644c80 ("regmap: Add the rbtree cache support")
added 'regcache_rbtree_node' as packed structure, while on the other hand
commit e977145a ("[RBTREE] Add explicit alignment to sizeof(long)
for struct rb_node.") declared struct 'rb_node' as aligned.

Solve the ambiguity of placing aligned structure in a packed one by
removing the packed attribute from struct. This seems to be the behavior
of gcc anyway.

This removes the following warning (W=1):

  drivers/base/regmap/regcache-rbtree.c:36:1: warning: alignment 1 of 'struct regcache_rbtree_node' is less than 4 [-Wpacked-not-aligned]

Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NMathieu Malaterre <malat@debian.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is bunch of devices with multiple logical blocks which
can generate interrupts. It's not a rare case that the interrupt
reason registers are arranged so that there is own status/ack/mask
register for each logical block. In some devices there is also a
'main interrupt register(s)' which can indicate what sub blocks
have interrupts pending.

When such a device is connected via slow bus like i2c the main
part of interrupt handling latency can be caused by bus accesses.
On systems where it is expected that only one (or few) sub blocks
have active interrupts we can reduce the latency by only reading
the main register and those sub registers which have active
interrupts. Support this with regmap-irq for simple cases where
main register does not require acking or masking.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

If client have not provided the mask base register then do not
write into the mask register.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NJinyoung Park <jinyoungp@nvidia.com>
Signed-off-by: NVenkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: NMark Zhang <markz@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Do not return error if irq-type setting is requested for
controlloer which does not support this. This is how
regmap-irq has previously handled the undupported type
settings and existing drivers seem to be upset if failure
is now reported.

Fixes: 1c2928e3 ("regmap: regmap-irq/gpio-max77620: add level-irq support")
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some interrupt controllers whose interrupts are acked on read will set
the status bits for masked interrupts without changing the state of
the IRQ line.

Some chips have an additional "feature" where if those set bits are
not cleared before unmasking their respective interrupts, the IRQ
line will change the state and we'll interpret this as an interrupt
although it actually fired when it was masked.

Add a new field to the irq chip struct that tells the regmap irq chip
code to always clear the status registers before actually changing the
irq mask values.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add level active IRQ support to regmap-irq irqchip. Change breaks
existing regmap-irq type setting. Convert the existing drivers which
use regmap-irq with trigger type setting (gpio-max77620) to work
with this new approach. So we do not magically support level-active
IRQs on gpio-max77620 - but add support to the regmap-irq for chips
which support them =)

We do not support distinguishing situation where HW supports rising
and falling edge detection but not both. Separating this would require
inventing yet another flags for IRQ types.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: NMark Brown <broonie@kernel.org>