kernel/linux.git/drivers/base/regmap/internal.h, branch v5.9.2

regmap: fix page selection for noinc writes

2020-09-21T19:58:02+00:00

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: Dmitry Baryshkov Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API") Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown

regmap: debugfs: Fix handling of name string for debugfs init delays

2020-09-17T17:54:20+00:00

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: Charles Keepax Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown

regmap: add proper SPDX identifiers on files that did not have them.

2019-04-25T19:22:15+00:00

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: Greg Kroah-Hartman Signed-off-by: Mark Brown

Merge remote-tracking branches 'regmap/topic/noinc' and 'regmap/topic/single-rw' into regmap-next

2018-10-21T11:07:26+00:00

regmap: Add regmap_noinc_write API

2018-10-19T11:51:19+00:00

The regmap API had a noinc_read function added for instances where devices supported returning data from an internal FIFO in a single read. This commit adds the noinc_write variant to allow writing to a non incrementing register, this is used in devices such as the sx1301 for loading firmware. Signed-off-by: Ben Whitten Signed-off-by: Mark Brown

regmap: fix comment for regmap.use_single_write

2018-09-07T12:03:51+00:00

Signed-off-by: David Frey Signed-off-by: Mark Brown

regmap: Add regmap_noinc_read API

2018-08-09T10:00:15+00:00

The regmap API usually assumes that bulk read operations will read a range of registers but some I2C/SPI devices have certain registers for which a such a read operation will return data from an internal FIFO instead. Add an explicit API to support bulk read without range semantics. Some linux drivers use regmap_bulk_read or regmap_raw_read for such registers, for example mpu6050 or bmi150 from IIO. This only happens to work because when caching is disabled a single regmap read op will map to a single bus read op (as desired). This breaks if caching is enabled and reg+1 happens to be a cacheable register. Without regmap support refactoring a driver to enable regmap caching requires separate I2C and SPI paths. This is exactly what regmap is supposed to help avoid. Suggested-by: Jonathan Cameron Signed-off-by: Crestez Dan Leonard Signed-off-by: Stefan Popa Signed-off-by: Mark Brown

regmap: Disable debugfs when locking is disabled

2017-12-13T16:22:31+00:00

The recently added support for disabling the regmap internal locking left debugfs enabled for devices with the locking disabled. This is a problem since debugfs allows userspace to do things like initiate reads from the hardware which will use the scratch buffers protected by the regmap locking so could cause data corruption. For safety address this by just disabling debugfs for these devices. That is overly conservative since some of the debugfs files just read internal data structures but it's much simpler to implmement and less likely to lead to problems with tooling that works with debugfs. Reported-by: Lars-Peter Clausen Signed-off-by: Mark Brown

regmap: Add hardware spinlock support

2017-11-01T10:06:29+00:00

On some platforms, when reading or writing some special registers through regmap, we should acquire one hardware spinlock to synchronize between the multiple subsystems. Thus this patch adds the hardware spinlock support for regmap. Signed-off-by: Baolin Wang Signed-off-by: Mark Brown

Merge remote-tracking branches 'regmap/topic/core' and 'regmap/topic/debugfs' into regmap-next

2016-10-04T03:17:12+00:00