Revision tags: v6.6.26, v6.6.25, v6.6.24 |
|
#
fce7a547 |
| 29-Mar-2024 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
regmap: maple: Fix uninitialized symbol 'ret' warnings
[ Upstream commit eaa03486d932572dfd1c5f64f9dfebe572ad88c0 ]
Fix warnings reported by smatch by initializing local 'ret' variable to 0.
drive
regmap: maple: Fix uninitialized symbol 'ret' warnings
[ Upstream commit eaa03486d932572dfd1c5f64f9dfebe572ad88c0 ]
Fix warnings reported by smatch by initializing local 'ret' variable to 0.
drivers/base/regmap/regcache-maple.c:186 regcache_maple_drop() error: uninitialized symbol 'ret'. drivers/base/regmap/regcache-maple.c:290 regcache_maple_sync() error: uninitialized symbol 'ret'.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Link: https://lore.kernel.org/r/20240329144630.1965159-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
3af6c5ac |
| 27-Mar-2024 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
regmap: maple: Fix cache corruption in regcache_maple_drop()
[ Upstream commit 00bb549d7d63a21532e76e4a334d7807a54d9f31 ]
When keeping the upper end of a cache block entry, the entry[] array must b
regmap: maple: Fix cache corruption in regcache_maple_drop()
[ Upstream commit 00bb549d7d63a21532e76e4a334d7807a54d9f31 ]
When keeping the upper end of a cache block entry, the entry[] array must be indexed by the offset from the base register of the block, i.e. max - mas.index.
The code was indexing entry[] by only the register address, leading to an out-of-bounds access that copied some part of the kernel memory over the cache contents.
This bug was not detected by the regmap KUnit test because it only tests with a block of registers starting at 0, so mas.index == 0.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Link: https://msgid.link/r/20240327114406.976986-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40 |
|
#
b0393e1f |
| 20-Jul-2023 |
Guenter Roeck <linux@roeck-us.net> |
regmap: maple: Use alloc_flags for memory allocations
REGCACHE_MAPLE needs to allocate memory for regmap operations. This results in lockdep splats if used with fast_io since fast_io uses spinlocks
regmap: maple: Use alloc_flags for memory allocations
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>
show more ...
|
Revision tags: v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
bfa0b38c |
| 11-Jun-2023 |
Mark Brown <broonie@kernel.org> |
regmap: maple: Implement block sync for the maple tree cache
For register maps where we can write multiple values in a single bus operation it is generally much faster to do so. Improve the performa
regmap: maple: Implement block sync for the maple tree cache
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>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30 |
|
#
3a48d212 |
| 23-May-2023 |
Mark Brown <broonie@kernel.org> |
regmap: Load register defaults in blocks rather than register by register
Currently we use the normal single register write function to load the default values into the cache, resulting in a large n
regmap: Load register defaults in blocks rather than register by register
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>
show more ...
|
#
0cc65780 |
| 23-May-2023 |
Mark Brown <broonie@kernel.org> |
regmap: maple: Drop the RCU read lock while syncing registers
Unfortunately the maple tree requires us to explicitly lock it so we need to take the RCU read lock while iterating. When syncing this m
regmap: maple: Drop the RCU read lock while syncing registers
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>
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
fac79bad |
| 04-Apr-2023 |
Mark Brown <broonie@kernel.org> |
regmap: Use mas_walk() instead of mas_find()
Liam recommends using mas_walk() instead of mas_find() for our use case so let's do that, it avoids some minor overhead associated with being able to res
regmap: Use mas_walk() instead of mas_find()
Liam recommends using mas_walk() instead of mas_find() for our use case so let's do that, it avoids some minor overhead associated with being able to restart the operation which we don't need since we do a simple search.
Suggested-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230403-regmap-maple-walk-fine-v2-1-c07371c8a867@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
451941ac |
| 03-Apr-2023 |
Mark Brown <broonie@kernel.org> |
regmap: Fix double unlock in the maple cache
Doing the dance to drop the maple tree's internal spinlock means we need multiple exit paths in our error handling.
Reported-by: Liam R. Howlett <Liam.H
regmap: Fix double unlock in the maple cache
Doing the dance to drop the maple tree's internal spinlock means we need multiple exit paths in our error handling.
Reported-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230403-regmap-maple-unlock-v1-1-89998991b16c@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.22 |
|
#
f033c26d |
| 29-Mar-2023 |
Mark Brown <broonie@kernel.org> |
regmap: Add maple tree based register cache
The current state of the art for sparse register maps is the rbtree cache. This works well for most applications but isn't always ideal for sparser regis
regmap: Add maple tree based register cache
The current state of the art for sparse register maps is the rbtree cache. This works well for most applications but isn't always ideal for sparser register maps since the rbtree can get deep, requiring a lot of walking. Fortunately the kernel has a data structure intended to address this very problem, the maple tree. Provide an initial implementation of a register cache based on the maple tree to start taking advantage of it.
The entries stored in the maple tree are arrays of register values, with the maple tree keys holding the register addresses. We store data in host native format rather than device native format as we do for rbtree, this will be a benefit for devices where we don't marshal data within regmap and simplifies the code but will result in additional CPU overhead when syncing the cache on devices where we do marshal data in regmap.
This should work well for a lot of devices, though there's some additional areas that could be looked at such as caching the last accessed entry like we do for rbtree and trying to minimise the maple tree level locking. We should also use bulk writes rather than single register writes when resyncing the cache where possible, even if we don't store in device native format.
Very small register maps may continue to to better with rbtree longer term.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230325-regcache-maple-v3-2-23e271f93dc7@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|