summaryrefslogtreecommitdiff
path: root/drivers/base/regmap
AgeCommit message (Collapse)AuthorFilesLines
2023-10-09regmap: fix NULL deref on lookupJohan Hovold1-1/+1
Not all regmaps have a name so make sure to check for that to avoid dereferencing a NULL pointer when dev_get_regmap() is used to lookup a named regmap. Fixes: e84861fec32d ("regmap: dev_get_regmap_match(): fix string comparison") Cc: stable@vger.kernel.org # 5.8 Cc: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20231006082104.16707-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-22regmap: rbtree: Fix wrong register marked as in-cache when creating new nodeRichard Fitzgerald1-1/+2
When regcache_rbtree_write() creates a new rbtree_node it was passing the wrong bit number to regcache_rbtree_set_register(). The bit number is the offset __in number of registers__, but in the case of creating a new block regcache_rbtree_write() was not dividing by the address stride to get the number of registers. Fix this by dividing by map->reg_stride. Compare with regcache_rbtree_read() where the bit is checked. This bug meant that the wrong register was marked as present. The register that was written to the cache could not be read from the cache because it was not marked as cached. But a nearby register could be marked as having a cached value even if it was never written to the cache. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node") Link: https://lore.kernel.org/r/20230922153711.28103-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-24regmap: Fix the type used for a bitmap pointerChristophe JAILLET1-1/+1
Bitmaps should be defined as 'unsigned long', not 'long'. Fix the type of 'cache_present' is the 'struct regcache_rbtree_node'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5600df5003d23da10efcfafbda97ca55776d0d29.1689960321.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-24regmap: Merge up fixes from mainlineMark Brown7-13/+17
There's several things here that will really help my CI.
2023-07-21regmap: Remove dynamic allocation warnings for rbtree and mapleMark Brown1-9/+0
Thanks to Dan and Guenter's very prompt updates of the rbtree and maple caches to support GPF_ATOMIC allocations and since the update shook out a bunch of users at least some of whom have been suitably careful about ensuring that the cache is prepoulated so there are no dynamic allocations after init let's revert the warnings. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230721-regmap-enable-kmalloc-v1-1-f78287e794d3@kernel.org
2023-07-21regmap: rbtree: Use alloc_flags for memory allocationsDan Carpenter1-5/+5
The kunit tests discovered a sleeping in atomic bug. The allocations in the regcache-rbtree code should use the map->alloc_flags instead of GFP_KERNEL. [ 5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 [ 5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch [ 5.006219] preempt_count: 1, expected: 0 [ 5.006414] 1 lock held by kunit_try_catch/117: [ 5.006590] #0: 833b9010 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c [ 5.007493] irq event stamp: 162 [ 5.007627] hardirqs last enabled at (161): [<80786738>] crng_make_state+0x1a0/0x294 [ 5.007871] hardirqs last disabled at (162): [<80c531ec>] _raw_spin_lock_irqsave+0x7c/0x80 [ 5.008119] softirqs last enabled at (0): [<801110ac>] copy_process+0x810/0x2138 [ 5.008356] softirqs last disabled at (0): [<00000000>] 0x0 [ 5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G N 6.4.4-rc3-g0e8d2fdfb188 #1 [ 5.009011] Hardware name: Generic DT based system [ 5.009277] unwind_backtrace from show_stack+0x18/0x1c [ 5.009497] show_stack from dump_stack_lvl+0x38/0x5c [ 5.009676] dump_stack_lvl from __might_resched+0x188/0x2d0 [ 5.009860] __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c [ 5.010061] __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8 [ 5.010254] kmalloc_trace from regcache_rbtree_write+0x26c/0x468 [ 5.010446] regcache_rbtree_write from _regmap_write+0x88/0x140 [ 5.010634] _regmap_write from regmap_write+0x44/0x68 [ 5.010803] regmap_write from basic_read_write+0x8c/0x270 [ 5.010980] basic_read_write from kunit_try_run_case+0x48/0xa0 Fixes: 28644c809f44 ("regmap: Add the rbtree cache support") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/all/ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net/ Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/58f12a07-5f4b-4a8f-ab84-0a42d1908cb9@moroto.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-20regmap: maple: Use alloc_flags for memory allocationsGuenter Roeck1-8/+8
REGCACHE_MAPLE needs to allocate memory for regmap operations. This results in lockdep splats if used with fast_io since fast_io uses spinlocks for locking. BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 167, name: kunit_try_catch preempt_count: 1, expected: 0 1 lock held by kunit_try_catch/167: #0: 838e9c10 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c irq event stamp: 146 hardirqs last enabled at (145): [<8078bfa8>] crng_make_state+0x1a0/0x294 hardirqs last disabled at (146): [<80c5f62c>] _raw_spin_lock_irqsave+0x7c/0x80 softirqs last enabled at (0): [<80110cc4>] copy_process+0x810/0x216c softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 PID: 167 Comm: kunit_try_catch Tainted: G N 6.5.0-rc1-00028-gc4be22597a36-dirty #6 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x38/0x5c dump_stack_lvl from __might_resched+0x188/0x2d0 __might_resched from __kmem_cache_alloc_node+0x1f4/0x258 __kmem_cache_alloc_node from __kmalloc+0x48/0x170 __kmalloc from regcache_maple_write+0x194/0x248 regcache_maple_write from _regmap_write+0x88/0x140 _regmap_write from regmap_write+0x44/0x68 regmap_write from basic_read_write+0x8c/0x27c basic_read_write from kunit_generic_run_threadfn_adapter+0x1c/0x28 kunit_generic_run_threadfn_adapter from kthread+0xf8/0x120 kthread from ret_from_fork+0x14/0x3c Exception stack(0x881a5fb0 to 0x881a5ff8) 5fa0: 00000000 00000000 00000000 00000000 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Use map->alloc_flags instead of GFP_KERNEL for memory allocations to fix the problem. Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230720172021.2617326-1-linux@roeck-us.net Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-20regmap: Reject fast_io regmap configurations with RBTREE and MAPLE cachesGuenter Roeck1-0/+9
REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Reject affected configurations. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230720032848.1306349-2-linux@roeck-us.net Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-20regmap: Disable locking for RBTREE and MAPLE unit testsGuenter Roeck1-0/+5
REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Disable locking for the associated unit tests to avoid lockdep splashes. Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Fixes: 2238959b6ad2 ("regmap: Add some basic kunit tests") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230720032848.1306349-1-linux@roeck-us.net Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-19regcache: Push async I/O request down into the rbtree cacheMark Brown2-3/+4
Currently the regcache core unconditionally enables async I/O for all cache types, causing problems for the maple tree cache which dynamically allocates the buffers used to write registers to the device since async requires the buffers to be kept around until the I/O has been completed. This use of async I/O is mainly for the rbtree cache which stores data in a format directly usable for regmap_raw_write(), though there is a special case for single register writes which would also have allowed it to be used with the flat cache. It is a bit of a landmine for other caches since it implicitly converts sync operations to async, and with modern hardware it is not clear that async I/O is actually a performance win as shown by the performance work David Jander did with SPI. In multi core systems the cost of managing concurrency ends up swamping the performance benefit and almost all modern systems are multi core. Address this by pushing the enablement of async I/O down into the rbtree cache where it is actively used, avoiding surprises for other cache implementations. Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com> Fixes: bfa0b38c1483 ("regmap: maple: Implement block sync for the maple tree cache") Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230719-regcache-async-rbtree-v1-1-b03d30cf1daf@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-18regmap: Provide test for regcache_reg_present()Mark Brown1-0/+40
Provide a KUnit test for the newly added API. Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230717-regmap-cache-check-v1-2-73ef688afae3@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-18regmap: Let users check if a register is cachedMark Brown1-0/+23
The HDA driver has a use case for checking if a register is cached which it bodges in awkwardly and unclearly. Provide an API which allows it to directly do what it's trying to do. Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230717-regmap-cache-check-v1-1-73ef688afae3@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17regmap: Account for register length in SMBus I/O limitsMark Brown1-4/+4
The SMBus I2C buses have limits on the size of transfers they can do but do not factor in the register length meaning we may try to do a transfer longer than our length limit, the core will not take care of this. Future changes will factor this out into the core but there are a number of users that assume current behaviour so let's just do something conservative here. This does not take account padding bits but practically speaking these are very rarely if ever used on I2C buses given that they generally run slowly enough to mean there's no issue. Cc: stable@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/20230712-regmap-max-transfer-v1-2-80e2aed22e83@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17regmap: Drop initial version of maximum transfer length fixesMark Brown2-5/+3
When problems were noticed with the register address not being taken into account when limiting raw transfers with I2C devices we fixed this in the core. Unfortunately it has subsequently been realised that a lot of buses were relying on the prior behaviour, partly due to unclear documentation not making it obvious what was intended in the core. This is all more involved to fix than is sensible for a fix commit so let's just drop the original fixes, a separate commit will fix the originally observed problem in an I2C specific way Fixes: 3981514180c9 ("regmap: Account for register length when chunking") Fixes: c8e796895e23 ("regmap: spi-avmm: Fix regmap_bus max_raw_write") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230712-regmap-max-transfer-v1-1-80e2aed22e83@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-13regmap: Provide user selectable option to enable regmapMark Brown1-1/+11
Since apparently enabling all the KUnit tests shouldn't enable any new subsystems it is hard to enable the regmap KUnit tests in normal KUnit testing scenarios that don't enable any drivers. Add a Kconfig option to help with this and include it in the KUnit all tests config. Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230712-regmap-kunit-enable-v1-1-13e296bd0204@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-12regmap-irq: Fix out-of-bounds access when allocating config buffersIsaac J. Manjarres1-1/+1
When allocating the 2D array for handling IRQ type registers in regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix with num_config_bases rows and num_config_regs columns. This is currently handled by allocating a buffer to hold a pointer for each row (i.e. num_config_bases). After that, the logic attempts to allocate the memory required to hold the register configuration for each row. However, instead of doing this allocation for each row (i.e. num_config_bases allocations), the logic erroneously does this allocation num_config_regs number of times. This scenario can lead to out-of-bounds accesses when num_config_regs is greater than num_config_bases. Fix this by updating the terminating condition of the loop that allocates the memory for holding the register configuration to allocate memory only for each row in the matrix. Amit Pundir reported a crash that was occurring on his db845c device due to memory corruption (see "Closes" tag for Amit's report). The KASAN report below helped narrow it down to this issue: [ 14.033877][ T1] ================================================================== [ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364 [ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1 [ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850 [ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8 [ 14.255669][ T1] The buggy address is located 0 bytes inside of [ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858) Fixes: faa87ce9196d ("regmap-irq: Introduce config registers for irq types") Reported-by: Amit Pundir <amit.pundir@linaro.org> Closes: https://lore.kernel.org/all/CAMi1Hd04mu6JojT3y6wyN2YeVkPR5R3qnkKJ8iR8if_YByCn4w@mail.gmail.com/ Tested-by: John Stultz <jstultz@google.com> Tested-by: Amit Pundir <amit.pundir@linaro.org> # tested on Dragonboard 845c Cc: stable@vger.kernel.org # v6.0+ Cc: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: "Isaac J. Manjarres" <isaacmanjarres@google.com> Link: https://lore.kernel.org/r/20230711193059.2480971-1-isaacmanjarres@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-10regmap: mmio: Remove unused 64-bit support codeAndy Shevchenko1-24/+0
regmap API does not support 64-bit data size, so there is no point to have it in regmap MMIO. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230622183613.58762-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-10regmap: cache: Revert "Add 64-bit mode support"Andy Shevchenko1-15/+0
There is no support for 64-bit data size in regmap, so there is no point to have it in regmap cache. This reverts commit 8b7663de6e2bfe3c40e1846e1c4625f33d138757. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230622183613.58762-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-10regmap: Revert "add 64-bit mode support" and Co.Andy Shevchenko1-122/+0
With unsigned int type we never ever can pass 64-bit value. Remove never properly worked code. Note, there are no users in kernel for this size of register offsets or data. This reverts commit afcc00b91f1865f6d0bbdb687dd642ce8a3c3c9e. Also revert other 64-bit code excerpts in the regmap implementation that had been induced by the false impression made by the above mentioned change that there is a support of that data size. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230622183613.58762-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-28Merge tag 'regmap-v6.5' of ↵Linus Torvalds10-259/+808
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap updates from Mark Brown: "Another busy release for regmap with the second half of the maple tree register cache implementation, there's some smaller optimisations that could be done but this should now be able to replace the rbtree cache for most devices. We also had a followup from Aidan MacDonald's refactoring of some of the regmap-irq interfaces, the conversion is complete so the old interfaces are removed. This means that even with the new features for the maple tree cache we'd have a nice negative diffstat were it not for the addition of a bunch more KUnit coverage. There's one GPIO patch in here, it was a dependency for a cleanup of an API in the regmap-irq code for which the gpio-104-dio-48e driver was the only user. Highlights: - The maple tree cache can now load in default values more efficiently, and is capabale of syncing multiple registers in a single write during cache sync - More KUnit coverage, including some coverage for raw I/O and a dummy RAM backed cache to support it - Removal of several old interfaces in regmap-irq now all users have been modernised" * tag 'regmap-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: (23 commits) regmap: Allow reads from write only registers with the flat cache regmap: Drop early readability check regmap: Check for register readability before checking cache during read regmap: Add test to make sure we don't sync to read only registers regmap: Add a test case for write only registers regmap: Add test that writes to write only registers are prevented regmap: Add debugfs file for forcing field writes regmap: Don't check for changes in regcache_set_val() regmap: maple: Implement block sync for the maple tree cache regmap: Provide basic KUnit coverage for the raw register I/O regmap: Provide a ram backed regmap with raw support regmap: Add missing cache_only checks regmap: regmap-irq: Move handle_post_irq to before pm_runtime_put regmap: Load register defaults in blocks rather than register by register regmap: mmio: Allow passing an empty config->reg_stride regmap-irq: Drop backward compatibility for inverted mask/unmask regmap-irq: Minor adjustments to .handle_mask_sync() regmap-irq: Remove support for not_fixed_stride regmap-irq: Remove type registers regmap-irq: Remove virtual registers ...
2023-06-20regmap: spi-avmm: Fix regmap_bus max_raw_writeRuss Weight1-1/+1
The max_raw_write member of the regmap_spi_avmm_bus structure is defined as: .max_raw_write = SPI_AVMM_VAL_SIZE * MAX_WRITE_CNT SPI_AVMM_VAL_SIZE == 4 and MAX_WRITE_CNT == 1 so this results in a maximum write transfer size of 4 bytes which provides only enough space to transfer the address of the target register. It provides no space for the value to be transferred. This bug became an issue (divide-by-zero in _regmap_raw_write()) after the following was accepted into mainline: commit 3981514180c9 ("regmap: Account for register length when chunking") Change max_raw_write to include space (4 additional bytes) for both the register address and value: .max_raw_write = SPI_AVMM_REG_SIZE + SPI_AVMM_VAL_SIZE * MAX_WRITE_CNT Fixes: 7f9fb67358a2 ("regmap: add Intel SPI Slave to AVMM Bus Bridge support") Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Link: https://lore.kernel.org/r/20230620202824.380313-1-russell.h.weight@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-19regmap: Allow reads from write only registers with the flat cacheMark Brown1-3/+12
The flat cache is intended for devices that need the lowest overhead so doesn't track any sparseness. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230617-regmap-kunit-read-writeonly-flat-v1-1-efd3ed66dec6@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-16regmap: Drop early readability checkMark Brown1-3/+3
We have some drivers that have a use case for cached write only registers, doing read/modify/writes on read only registers in order to work more easily with bitfields. Go back to trying the cache before we check if we can read from the device. Fixes: eab5abdeb79f0 ("regmap: Check for register readability before checking cache during read") Reported-by: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230615-regmap-drop-early-readability-v1-1-8135094362de@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regmap: Add KUnit tests for read/write checkingMark Brown1-0/+115
Merge series from Mark Brown <broonie@kernel.org>: Since Takashi found an issue with maple tree syncing registers it shouldn't do add some test cases that catch that case and some more potential issues, ideally we'd run through the combination of readability with all possible I/O calls but that's lifting for another day. We did find one issue with missing readability checks which will be fixed separately.
2023-06-14regmap: Check for register readability before checking cache during readMark Brown1-3/+3
Ensure that we don't return a spurious cache hit for unreadable registers (eg, with the flat cache which doesn't understand sparseness) by checking for readability before we do a cache lookup. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230613-b4-regmap-check-readability-before-cache-v1-1-b144c0b01ed9@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regmap: Add test to make sure we don't sync to read only registersMark Brown1-0/+42
Ensure that a read only value in the register cache does not result in a write during regcache_sync(). Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-3-2db337c52827@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regmap: Add a test case for write only registersMark Brown1-0/+32
Validate that attempts to read from write only registers fail and don't somehow trigger spurious hardware accesses. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-2-2db337c52827@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14regmap: Add test that writes to write only registers are preventedMark Brown1-0/+41
We should have error checking that verifies that writes to write only registers are suppressed, verify that this happens as it should. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-1-2db337c52827@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13regmap: Add debugfs file for forcing field writesWaqar Hameed3-1/+15
`_regmap_update_bits()` checks if the current register value differs from the new value, and only writes to the register if they differ. When testing hardware drivers, it might be desirable to always force a register write, for example when writing to a `regmap_field`. This enables and simplifies testing and verification of the hardware interaction. For example, when using a hardware mock/simulation model, one can then more easily verify that the driver makes the correct expected register writes during certain events. Add a bool variable `force_write_field` and a corresponding debugfs entry to enable this. Since this feature could interfere with driver operation, guard it with a macro. Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://lore.kernel.org/r/pnd1qifa7sj.fsf@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13regmap: regcache: Don't sync read-only registersTakashi Iwai1-0/+3
regcache_maple_sync() tries to sync all cached values no matter whether it's writable or not. OTOH, regache_sync_val() does care the wrtability and returns -EIO for a read-only register. This results in an error message like: snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2f0009. -5 and the sync loop is aborted incompletely. This patch adds the writable register check to regcache_sync_val() for addressing the bug above. Note that, although we may add the check in the caller side (regcache_maple_sync()), here we put in regcache_sync_val(), so that a similar case like this can be avoided in future. Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Link: https://lore.kernel.org/r/877cs7g6f1.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230613112240.3361-1-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-12regmap: Provide basic test coverage for raw I/OMark Brown4-1/+469
Merge series from Mark Brown <broonie@kernel.org>: Our existing coverage only deals with buses that provide single register read and write operations, extend it to cover raw buses using a similar approach with a RAM backed register map that the tests can inspect to check operations. This coverage could be more complete but provides a good start.
2023-06-12regmap: Don't check for changes in regcache_set_val()Mark Brown2-7/+3
The only user of regcache_set_val() ignores the return value so we may as well not bother checking if the value we are trying to set is the same as the value already stored. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regcache-set-val-no-ret-v1-1-9a6932760cf8@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-12regmap: maple: Implement block sync for the maple tree cacheMark Brown3-8/+80
For register maps where we can write multiple values in a single bus operation it is generally much faster to do so. Improve the performance of maple tree cache syncs on such devices by identifying blocks of adjacent registers that need to be written out and combining them into a single operation. Combining writes does mean that we need to allocate a scratch buffer and format the data into it but it is expected that for most cases where caches are in use the cost of I/O will be much greater than the cost of doing the allocation and format. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-regcache-maple-sync-raw-v1-1-8ddeb4e2b9ab@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-12regmap: Merge up v6.4-rc6Mark Brown4-6/+22
The fix for maple tree RCU locking on sync is a dependency for the block sync code for the maple tree.
2023-06-12regmap: Provide basic KUnit coverage for the raw register I/OMark Brown1-0/+327
Simple tests that cover basic raw I/O, plus basic coverage of cache sync since the caches generate bulk I/O with raw register maps. This could be more comprehensive but it is good for testing generic code. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230610-regcache-raw-kunit-v1-2-583112cd28ac@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-12regmap: Provide a ram backed regmap with raw supportMark Brown3-1/+142
Provide a simple, 16 bit only, RAM backed regmap which supports raw I/O for use in testing. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230610-regcache-raw-kunit-v1-1-583112cd28ac@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-01regmap: Add missing cache_only checksCharles Keepax1-10/+16
The current behaviour around cache_only is slightly inconsistent, most paths will only check cache_only if cache_bypass is false, and will return -EBUSY if a read attempts to go to the hardware whilst cache_only is true. However, a couple of paths will not check cache_only at all. The most notable of these being regmap_raw_read which will check cache_only in the case it processes the transaction one register at a time, but not in the case it handles them as a block. In the typical case a device has been put into cache_only whilst powered down this can cause physical reads to happen whilst the device is unavailable. Add a check in regmap_raw_read and move the check in regmap_noinc_read, adding a check for cache_bypass, such that all paths are covered and consistent. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230601101036.1499612-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-01regmap: regmap-irq: Move handle_post_irq to before pm_runtime_putCharles Keepax1-3/+3
Typically handle_post_irq is going to be used to manage some additional chip specific hardware operations required on each IRQ, these are very likely to want the chip to be resumed. For example the current in tree user max77620 uses this to toggle a global mask bit, which would obviously want the device resumed. It is worth noting this device does not specify the runtime_pm flag in regmap_irq_chip, so there is no actual issue. Move the callback to before the pm_runtime_put, so it will be called whilst the device is still resumed. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230601101036.1499612-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-24regmap: Load register defaults in blocks rather than register by registerMark Brown1-6/+52
Currently we use the normal single register write function to load the default values into the cache, resulting in a large number of reallocations when there are blocks of registers as we extend the memory region we are using to store the values. Instead scan through the list of defaults for blocks of adjacent registers and do a single allocation and insert for each such block. No functional change. We do not take advantage of the maple tree preallocation, this is purely at the regcache level. It is not clear to me yet if the maple tree level would help much here or if we'd have more overhead from overallocating and then freeing maple tree data. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230523-regcache-maple-load-defaults-v1-1-0c04336f005d@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-24regmap: maple: Drop the RCU read lock while syncing registersMark Brown1-1/+4
Unfortunately the maple tree requires us to explicitly lock it so we need to take the RCU read lock while iterating. When syncing this means that we end up trying to write out register values while holding the RCU read lock which triggers lockdep issues since that is an atomic context but most buses can't be used in atomic context. Pause the iteration and drop the lock for each register we check to avoid this. Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230523-regcache-maple-sync-lock-v1-1-530e4d68dfab@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-24regmap: sdw: check for invalid multi-register writes configSrinivas Kandagatla1-0/+4
SoundWire code as it is only supports Bulk register writes and it does not support multi-register writes. Any drivers that set can_multi_write and use regmap_multi_reg_write() will easily endup with programming the hardware incorrectly without any errors. So, add this check in bus code to be able to validate the drivers config. Fixes: 522272047dc6 ("regmap: sdw: Remove 8-bit value size restriction") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230523154747.5429-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-18regmap: Account for register length when chunkingJim Wylder1-2/+4
Currently, when regmap_raw_write() splits the data, it uses the max_raw_write value defined for the bus. For any bus that includes the target register address in the max_raw_write value, the chunked transmission will always exceed the maximum transmission length. To avoid this problem, subtract the length of the register and the padding from the maximum transmission. Signed-off-by: Jim Wylder <jwylder@google.com Link: https://lore.kernel.org/r/20230517152444.3690870-2-jwylder@google.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-12regmap-irq: Cleanups and remove unusedMark Brown1-175/+47
Merge series from Aidan MacDonald <aidanmacdonald.0x0@gmail.com>: This is a straightforward patch series, mostly just removing a bunch of old features that were only used by a handful of drivers. - 1/4 and 2/4 remove unused, deprecated functionality - 3/4 makes the behavior of .handle_mask_sync() a bit more consistent w.r.t. mask and unmask registers, to aid maintainability. - 4/4 removes now-unused "inverted mask/unmask" compatibility code.
2023-05-12regmap: mmio: Allow passing an empty config->reg_strideMaxime Chevallier1-1/+1
Regmap's stride is used for MMIO regmaps to check the correctness of reg_width. However, it's acceptable to pass an empty config->reg_stride, in that case the actual stride used is 1. There are valid cases now to pass an empty stride, when using down/upshifting of register address. In this case, the stride value loses its sense, so ignore the reg_width when the stride isn't set. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com Link: https://lore.kernel.org/r/20230511142735.316445-1-maxime.chevallier@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-12regmap-irq: Drop backward compatibility for inverted mask/unmaskAidan MacDonald1-33/+11
All users must now specify .mask_unmask_non_inverted = true to ensure they are using the expected semantics: 1s disable IRQs in the mask registers, and enable IRQs in the unmask registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230511091342.26604-5-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-12regmap-irq: Minor adjustments to .handle_mask_sync()Aidan MacDonald1-34/+31
If a .handle_mask_sync() callback is provided it supersedes all inbuilt handling of mask registers, and judging by the commit 69af4bcaa08d ("regmap-irq: Add handle_mask_sync() callback") it is intended to completely replace all default IRQ masking logic. The implementation has two minor inconsistencies, which can be fixed without breaking compatibility: (1) mask_base must be set to enable .handle_mask_sync(), even though mask_base is otherwise unused. This is easily fixed because mask_base is already optional. (2) Unmask registers aren't accounted for -- they are part of the default IRQ masking logic and are just a bit-inverted version of mask registers. It would be a bad idea to allow them to be used at the same time as .handle_mask_sync(), as the result would be confusing and unmaintainable, so make sure this can't happen. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230511091342.26604-4-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-12regmap-irq: Remove support for not_fixed_strideAidan MacDonald1-40/+3
No remaining users, use a custom .get_irq_reg() callback instead. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230511091342.26604-3-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-12regmap-irq: Remove type registersAidan MacDonald1-74/+8
No remaining users, these have been replaced by config registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230511091342.26604-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-11regmap-irq: Remove virtual registersAidan MacDonald1-48/+0
No remaining users, and it's been replaced by config registers. Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com Link: https://lore.kernel.org/r/20230509110100.3980123-3-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-08regmap: REGMAP_KUNIT should not select REGMAPGeert Uytterhoeven1-3/+10
Enabling a (modular) test should not silently enable additional kernel functionality, as that may increase the attack vector of a product. Fix this by: 1. making REGMAP visible if CONFIG_KUNIT_ALL_TESTS is enabled, 2. making REGMAP_KUNIT depend on REGMAP instead of selecting it. After this, one can safely enable CONFIG_KUNIT_ALL_TESTS=m to build modules for all appropriate tests for ones system, without pulling in extra unwanted functionality, while still allowing a tester to manually enable REGMAP and its test suite on a system where REGMAP is not enabled by default. Fixes: 2238959b6ad27040 ("regmap: Add some basic kunit tests") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org Link: https://lore.kernel.org/r/b0a5dbb17c1d5ea482e052e585ae83bb69c48806.1682516005.git.geert@linux-m68k.org Signed-off-by: Mark Brown <broonie@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-22 11:33:35 +0300