Lockdep gives a false positive splat as it can't distinguish the lock
which is taken by different IRQ descriptors from different IRQ chips
that are organized in a way of a hierarchy:
======================================================
WARNING: possible circular locking dependency detected
6.12.0-rc5-next-20241101-00148-g9fabf8160b53 #562 Tainted: G W
------------------------------------------------------
modprobe/141 is trying to acquire lock:
ffff899446947868 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}, at: regmap_update_bits_base+0x33/0x90
but task is already holding lock:
ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790
which lock already depends on the new lock.
-> #3 (&d->lock){+.+.}-{4:4}:
-> #2 (&desc->request_mutex){+.+.}-{4:4}:
-> #1 (ipclock){+.+.}-{4:4}:
-> #0 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}:
Chain exists of:
intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock --> &desc->request_mutex --> &d->lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&d->lock);
lock(&desc->request_mutex);
lock(&d->lock);
lock(intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock);
*** DEADLOCK ***
3 locks held by modprobe/141:
#0: ffff8994419368f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xf6/0x250
#1: ffff89944690b250 (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0x1a2/0x790
#2: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790
Set a lockdep class when we map the IRQ so that it doesn't warn about
a lockdep bug that doesn't exist.
Fixes: 4af8be67fd ("regmap: Convert regmap_irq to use irq_domain")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241101165553.4055617-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In some cases when using the maple tree register cache, the lockdep
validator might complain about invalid deadlocks:
[7.131886] Possible interrupt unsafe locking scenario:
[7.131890] CPU0 CPU1
[7.131893] ---- ----
[7.131896] lock(&mt->ma_lock);
[7.131904] local_irq_disable();
[7.131907] lock(rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock);
[7.131916] lock(&mt->ma_lock);
[7.131925] <Interrupt>
[7.131928] lock(rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock);
[7.131936]
*** DEADLOCK ***
[7.131939] no locks held by swapper/0/0.
[7.131944]
the shortest dependencies between 2nd lock and 1st lock:
[7.131950] -> (&mt->ma_lock){+.+.}-{2:2} {
[7.131966] HARDIRQ-ON-W at:
[7.131973] lock_acquire+0x200/0x330
[7.131986] _raw_spin_lock+0x50/0x70
[7.131998] regcache_maple_write+0x68/0xe0
[7.132010] regcache_write+0x6c/0x90
[7.132019] _regmap_read+0x19c/0x1d0
[7.132029] _regmap_update_bits+0xc0/0x148
[7.132038] regmap_update_bits_base+0x6c/0xa8
[7.132048] rk8xx_probe+0x22c/0x3d8
[7.132057] rk8xx_spi_probe+0x74/0x88
[7.132065] spi_probe+0xa8/0xe0
[...]
[7.132675] }
[7.132678] ... key at: [<ffff800082943c20>] __key.0+0x0/0x10
[7.132691] ... acquired at:
[7.132695] _raw_spin_lock+0x50/0x70
[7.132704] regcache_maple_write+0x68/0xe0
[7.132714] regcache_write+0x6c/0x90
[7.132724] _regmap_read+0x19c/0x1d0
[7.132732] _regmap_update_bits+0xc0/0x148
[7.132741] regmap_field_update_bits_base+0x74/0xb8
[7.132751] vop2_plane_atomic_update+0x480/0x14d8 [rockchipdrm]
[7.132820] drm_atomic_helper_commit_planes+0x1a0/0x320 [drm_kms_helper]
[...]
[7.135112] -> (rockchip_drm_vop2:3114:(&vop2_regmap_config)->lock){-...}-{2:2} {
[7.135130] IN-HARDIRQ-W at:
[7.135136] lock_acquire+0x200/0x330
[7.135147] _raw_spin_lock_irqsave+0x6c/0x98
[7.135157] regmap_lock_spinlock+0x20/0x40
[7.135166] regmap_read+0x44/0x90
[7.135175] vop2_isr+0x90/0x290 [rockchipdrm]
[7.135225] __handle_irq_event_percpu+0x124/0x2d0
In the example above, the validator seems to get the scope of
dependencies wrong, since the regmap instance used in rk8xx-spi driver
has nothing to do with the instance from vop2.
Improve validation by sharing the regmap's lockdep class with the maple
tree's internal lock, while also providing a subclass for the latter.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20241031-regmap-maple-lockdep-fix-v2-1-06a3710f3623@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
Since 0 can look a lot like a NULL pointer when used in a cache some clever
data structures might potentially introduce bugs specific to handling it.
Add some explicit testing of storing 0 as a value in a sparse cache, at the
minute there are no issues and this will stop any appearing in the future.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20240924-regcache-zero-value-v1-1-8a1224214b52@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
By default regmap uses a mutex to protect the regmap but we also support
other kinds of locking, including spinlocks, which can have an impact
especially around allocations. Ensure that we are covering the spinlock
case by running tests configured using fast I/O, this causes the core to
use a spinlock instead of a mutex. Running every single test would be
redundant but cover most of them.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20240901-regmap-test-fast-io-v1-1-aad83a871bcc@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit fd4ebc07b4 ("regmap: Hold the regmap lock when allocating and
freeing the cache") introduced a locking around the allocating and
freeing a regmap cache, so adjust the memory allocation flags to the ones
given in the regmap configuration instead of the hardcoded GFP_KERNEL.
This fixes the "BUG: sleeping function called from invalid context"
introduced by the mentioned commit.
Fixes: fd4ebc07b4 ("regmap: Hold the regmap lock when allocating and freeing the cache")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20240828122834.3778031-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When multiple IRQ domains are created from the same device-tree node they
will get the same name based on the device-tree path. This will cause a
naming collision in debugFS when IRQ domain specific entries are created.
The regmap-IRQ creates per instance IRQ domains. This will lead to a
domain name conflict when a device which provides more than one
interrupt line uses the regmap-IRQ.
Add support for specifying an IRQ domain name suffix when creating a
regmap-IRQ controller.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/776bc4996969e5081bcf61b9bdb5517e537147a3.1723120028.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regmap fix from Mark Brown:
"Arnd sent a workaround for a false positive warning which was showing
up with GCC 14.1"
* tag 'regmap-fix-v6.11-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: maple: work around gcc-14.1 false-positive warning
With gcc-14.1, there is a false-postive -Wuninitialized warning in
regcache_maple_drop:
drivers/base/regmap/regcache-maple.c: In function 'regcache_maple_drop':
drivers/base/regmap/regcache-maple.c:113:23: error: 'lower_index' is used uninitialized [-Werror=uninitialized]
113 | unsigned long lower_index, lower_last;
| ^~~~~~~~~~~
drivers/base/regmap/regcache-maple.c:113:36: error: 'lower_last' is used uninitialized [-Werror=uninitialized]
113 | unsigned long lower_index, lower_last;
| ^~~~~~~~~~
I've created a reduced test case to see if this needs to be reported
as a gcc, but it appears that the gcc-14.x branch already has a change
that turns this into a more sensible -Wmaybe-uninitialized warning, so
I ended up not reporting it so far.
The reduced test case also produces a warning for gcc-13 and gcc-12
but I don't see that with the version in the kernel.
Link: https://godbolt.org/z/oKbohKqd3
Link: https://lore.kernel.org/all/CAMuHMdWj=FLmkazPbYKPevDrcym2_HDb_U7Mb9YE9ovrP0jJfA@mail.gmail.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20240719104030.1382465-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull spi updates from Mark Brown:
"There's some quite exciting core work in this release, we've got the
beginnings of support for hardware initiated transfers which is itself
independently useful for optimising fast paths in existing drivers.
We also have a rework of the DMA mapping which allows finer grained
decisions about DMA mapping messages and also helps remove some bodges
that we'd had.
Otherwise it's a fairly quiet release, a few new drivers and features
for existing drivers, together with various cleanups and DT binding
conversions.
One regmap SPI fix made it's way in here too which I should probably
have sent as a regmap fix instead.
Summary:
- Support for pre-optimising messages, reducing the overhead for
messages that are repeatedly used (eg, reading the interrupt status
from a device). This will also be used for hardware initiated
transfers in future.
- A reworking of how DMA mapping is done, introducing a new helper
and allowing the DMA mapping decision to be done per transfer
instead of per message.
- Support for Atmel SAMA7D64, Freescale LX2160A DSPI and WCH CH341A"
* tag 'spi-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (72 commits)
spi: dt-bindings: at91: Add sama7d65 compatible string
spi: add ch341a usb2spi driver
spi: dt-bindings: fsl-dspi: add compatible string 'fsl,lx2160a-dspi'
spi: dt-bindings: fsl-dspi: add dmas and dma-names properties
spi: spi: Remove unnecessary ‘0’ values from status
spi: spi: Remove unnecessary ‘0’ values from rc
spi: xcomm: fix coding style
spi: xcomm: remove i2c_set_clientdata()
spi: xcomm: make use of devm_spi_alloc_host()
spi: xcomm: add gpiochip support
spi: dt-bindings: snps,dw-apb-ssi.yaml: update compatible property
spi: dt-bindings: fsl-dspi: Convert to yaml format
spi: fsl-dspi: use common proptery 'spi-cs-setup(hold)-delay-ns'
spi: axi-spi-engine: remove platform_set_drvdata()
spi: spi-fsl-lpspi: Pass pm_ptr()
spi: spi-imx: Pass pm_ptr()
spi: spi-fsl-lpspi: Switch to SYSTEM_SLEEP_PM_OPS()
spi: spi-imx: Switch to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
spi: add EXPORT_SYMBOL_GPL(devm_spi_optimize_message)
spi: add devm_spi_optimize_message() helper
...
Merge series from Guenter Roeck <linux@roeck-us.net>:
regmap_multi_reg_read() is similar to regmap_bilk_read() but reads from
an array of non-sequential registers. It is helpful if multiple non-
sequential registers need to be read in a single operation which would
otherwise have to be mutex protected.
The name of the new function was chosen to match the existing function
regmap_multi_reg_write().
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-ac97.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-ram.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-raw-ram.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-slimbus.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-spmi.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-w1.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-sccb.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-spi-avmm.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20240603-md-base-regmap-v1-1-ff7a2e5f990f@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Replace open coded kmemdup_array(), which does an additional
overflow check.
While at it, fix one minor issue in regcache.c.
If we ever meet a hardware that uses weird register bits and padding,
we may end up in off-by-one error since x/8 + y/8 might not be equal
to (x + y)/8 in some cases.
bits pad x/8+y/8 (x+y)/8
4..7 0..3 0 0 // x + y from 4 up to 7
4..7 4..7 0 1 // x + y from 8 up to 11
4..7 8..11 1 1 // x + y from 12 up to 15
8..15 0..7 1 1 // x + y from 8 up to 15
8..15 8..15 2 2 // x + y from 16 up to 23
Fix this by using (x+y)/8.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- Use kunit_kcalloc() to allocate the defaults table so that it will be
freed when the test case ends.
- kfree() the buf and *data buffers on the error paths.
- Use kunit_add_action_or_reset() instead of kunit_add_action() so that
if it fails it will call regmap_exit().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240411103724.54063-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, when an adapter defines a max_write_len quirk,
the data will be chunked into data sizes equal to the
max_write_len quirk value. But the payload will be increased by
the size of the register address before transmission. The
resulting value always ends up larger than the limit set
by the quirk.
Avoid this error by setting regmap's max_write to the quirk's
max_write_len minus the number of bytes for the register and
padding. This allows the chunking to work correctly for this
limited case without impacting other use-cases.
Signed-off-by: Jim Wylder <jwylder@google.com>
Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regmap fix from Mark Brown:
"Guenter ran with memory sanitisers and found an issue in the new KUnit
tests that Richard added where an assumption in older test code was
exposed, this was fixed quickly by Richard"
* tag 'regmap-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: kunit: Fix array overflow in stride() test
With the rework of how the __string() handles dynamic strings where it
saves off the source string in field in the helper structure[1], the
assignment of that value to the trace event field is stored in the helper
value and does not need to be passed in again.
This means that with:
__string(field, mystring)
Which use to be assigned with __assign_str(field, mystring), no longer
needs the second parameter and it is unused. With this, __assign_str()
will now only get a single parameter.
There's over 700 users of __assign_str() and because coccinelle does not
handle the TRACE_EVENT() macro I ended up using the following sed script:
git grep -l __assign_str | while read a ; do
sed -e 's/\(__assign_str([^,]*[^ ,]\) *,[^;]*/\1)/' $a > /tmp/test-file;
mv /tmp/test-file $a;
done
I then searched for __assign_str() that did not end with ';' as those
were multi line assignments that the sed script above would fail to catch.
Note, the same updates will need to be done for:
__assign_str_len()
__assign_rel_str()
__assign_rel_str_len()
I tested this with both an allmodconfig and an allyesconfig (build only for both).
[1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/
Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Christian König <christian.koenig@amd.com> for the amdgpu parts.
Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> #for
Acked-by: Rafael J. Wysocki <rafael@kernel.org> # for thermal
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Darrick J. Wong <djwong@kernel.org> # xfs
Tested-by: Guenter Roeck <linux@roeck-us.net>
Force the max_register of the test regmap to be one register longer
than the number of test registers, to prevent an array overflow in
the test loop.
The test defines num_reg_defaults = 6. With 6 registers and
stride == 2 the valid register addresses would be 0, 2, 4, 6, 8, 10.
However the loop checks attempting to access the odd address, so on
the final register it accesses address 11, and it writes entry [11]
of the read/written arrays.
Originally this worked because the max_register of the regmap was
hardcoded to be BLOCK_TEST_SIZE (== 12).
commit 710915743d ("regmap: kunit: Run sparse cache tests at non-zero
register addresses")
introduced the ability to start the test address range from any address,
which means adjusting the max_register. If max_register was not forced,
it was calculated either from num_reg_defaults or BLOCK_TEST_SIZE. This
correctly calculated that with num_reg_defaults == 6 and stride == 2 the
final valid address is 10. So the read/written arrays are allocated to
contain entries [0..10]. When stride attempted to access [11] it was
overflowing the array.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 710915743d ("regmap: kunit: Run sparse cache tests at non-zero register addresses")
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://msgid.link/r/20240517144703.1200995-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
This series adds some more test cases, mainly for testing:
commit eaa03486d9 ("regmap: maple: Fix uninitialized symbol 'ret' warnings")
commit 00bb549d7d ("regmap: maple: Fix cache corruption in regcache_maple_drop()")
And the pending patch ("regmap: Add regmap_read_bypassed()")
There are also a few small improvements to the KUnit implementation.
Add a test case for dropping only some cache blocks and leaving others
unchanged.
The regmap is divided into 8 register ranges, and only 4 of these are
written with values. This creates 4 non-contiguous ranges of registers
with cached values.
One whole range is then dropped, and part of another range. A cache
sync is then performed to check that the correct registers were written,
and the correct values were written to these registers.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240408144600.230848-11-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend the testing of cache-sync.
- cache_sync() renamed cache_sync_marked_dirty() for clarity of
what conditions it is testing.
- cache_sync_defaults() renamed cache_sync_defaults_marked_dirty()
for clarity. Added code to write the register back to its default
value to check that a dirty sync doesn't write out the default value.
- Added cache_sync_after_cache_only(). Tests syncing the cache without
calling regcache_mark_dirty(). A register written while in cache-only
should be written out by regcache_sync().
- Added cache_sync_default_after_cache_only. This is similar to
cache_sync_after_cache_only(), but the register is changed to its
default value while in cache-only. Because regcache_mark_dirty() was
NOT called, regacache_sync() should write out the register.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240408144600.230848-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend the testing of cache-drop.
- Added cache_drop_all_and_sync_marked_dirty(). If all registers are
dropped from the cache a regcache_mark_dirty() followed by
regcache_sync() should not write anything because the cache is empty.
- Added cache_drop_all_and_sync_no_defaults(). This is similar to
cache_drop_all_and_sync_marked_dirty() except that regcache_mark_dirty()
is NOT called. All registers were dropped so regcache_sync() should not
write anything.
- Added cache_drop_all_and_sync_has_defaults(). This is the same as
cache_drop_all_and_sync_no_defaults() except that the regmap has a
table of default values.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240408144600.230848-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the tests parameterized by real_cache_types_list[] to test at some
register addresses that are not 0.
The cache_range_window_reg() test has hardcoded address assumptions that
are not present in any other tests using real_cache_types_list[] table. So
it has been given a separate parameter table, real_cache_types_only_list[],
that preserves the original parameterization.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240408144600.230848-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Run the cache_drop() and cache_present() tests at blocks of addresses
that don't start at zero.
This adds a from_reg parameter to struct regmap_test_param. This is
used to set the base address of the register defaults created by
gen_regmap().
Extra entries are added to sparse_cache_types_list[] to test at non-zero
from_reg values. The cache_drop() and cache_present() tests are updated
to test at the given offset.
The aim here is to add test cases to cache_drop() for the bug fixed by
commit 00bb549d7d ("regmap: maple: Fix cache corruption in
regcache_maple_drop()")
But the same parameter table is used by the cache_present() test so
let's also update that to use from_reg.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240408144600.230848-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
