Merge series from "Sheetal ." <sheetal@nvidia.com>:
This series adds a reg_default_cb callback for REGCACHE_FLAT to provide
defaults for registers not listed in reg_defaults. Defaults are loaded
eagerly during regcache init and the callback can use writeable_reg to
filter valid addresses and avoid holes.
Since commit 632e04739c ("clk: rs9: Fix suspend/resume"), the
clk-renesas-pcie-9series driver produces the following print in
kernel log on boot:
"
clk-renesas-pcie-9series 8-0068: No cache defaults, reading back from HW
"
This is caused by the presence of .num_reg_defaults_raw in its struct
regmap_config, without a matching .reg_defaults_raw table of built-in
register default values.
This configuration is valid, and causes the regcache code to read the
default register settings from the hardware, which is a valid behavior
for this particular chip. In fact, this configuration is more common
than configuration with .reg_defaults_raw built-in register defaults.
Do not warn about the read of default values being read from hardware,
as that is too strong and seems unnecessary, turn the warning into a
debug print.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20260121234309.178391-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a flat-cache KUnit test that verifies reg_defaults are honored while
missing entries are populated via the reg_default_cb callback without
hardware reads. This exercises the new callback path added for
REGCACHE_FLAT defaults.
Test: ./tools/testing/kunit/kunit.py run regmap
Result:
======== reg_default_callback_populates_flat_cache ========
[PASSED] flat-default @0x0
[PASSED] flat-default fast I/O @0x0
[PASSED] flat-default @0x2001
==== [PASSED] reg_default_callback_populates_flat_cache ====
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-5-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit e062bdfdd6 ("regmap: warn users about uninitialized flat cache")
warns when REGCACHE_FLAT is used without full defaults. This causes
false positives on hardware where many registers reset to zero but are
not listed in reg_defaults, forcing drivers to maintain large tables
just to silence the warning.
Add a reg_default_cb() hook so drivers can supply defaults for registers
not present in reg_defaults when populating REGCACHE_FLAT. This keeps
the warning quiet for known zero-reset registers without bloating
tables. Provide a generic regmap_default_zero_cb() helper for drivers
that need zero defaults.
The hook is only used for REGCACHE_FLAT; the core does not
check readable/writeable access, so drivers must provide readable_reg/
writeable_reg callbacks and handle holes in the register map.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-3-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Invisible symbol REGMAP defaults to y when any of the REGMAP_* symbols
is enabled, effectively auto-enabling it when needed. However,
REGMAP_SLIMBUS is missing from the list.
Currently this does not cause any issues, as all symbols selecting
REGMAP_SLIMBUS also select REGMAP and/or REGMAP_IRQ. Add REGMAP_SLIMBUS
to the list for consistency, and to prevent any future issues.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://patch.msgid.link/47872f8f4cf613e9710963bf871c6ac7b2ce81e8.1768494166.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the address of the shared member '&map->spinlock_flags' was
passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race
condition where multiple contexts contending for the lock could overwrite
the shared flags variable, potentially corrupting the state for the
current lock owner.
Fix this by using a local stack variable 'flags' to store the IRQ state
temporarily.
Fixes: 8698b93647 ("regmap: Add hardware spinlock support")
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260109032633.8732-1-eleanor.lin@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regcache_maple_write() allocates a new block ('entry') to merge
adjacent ranges and then stores it with mas_store_gfp().
When mas_store_gfp() fails, the new 'entry' remains allocated and
is never freed, leaking memory.
Free 'entry' on the failure path; on success continue freeing the
replaced neighbor blocks ('lower', 'upper').
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Link: https://patch.msgid.link/20260105031820.260119-1-kaushlendra.kumar@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Subsystem:
- Add HDR transfer support
Drivers:
- dw: fix bus hang on Agilex5
- mipi-i3c-hci: Intel Nova Lake-S support, IOMMU support
- svc: HDR support
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEBqsFVZXh8s/0O5JiY6TcMGxwOjIFAmk2MWUACgkQY6TcMGxw
OjKkBQ/8C7lUVwuCThYHjD1tXamYiZ3iTE2TP3rcn6w6VdFrvZq0I/D3Z67ze0PR
kRwC9VRgV7qrOgu7niubRxUNkAsLkVvJBGGf3QKGaozqhGaqnhxoOIGZGVehG0GR
DuuR6eCkiIFyG1Z+8rBROkx2K84ne81SPsZ1/E9bB9GJXW1aALJ8PgAblu5VPecO
4YtqVRS8JOxTx5c0fnlpYo5xn3M0jMIhtAI9Z7AAGj0ZvoBaPplHjSM5L/YJCKss
KlGpuNMGCS25PsnujDmELn4QStIbMmCOYA6hiRvVk3iDf4zcG4f0Rem+Tr9jstUe
t8h8/s7maUs01i2rVBZtcanAY1iYbECiBYmRTHowDcJDj+6/BAz6cKNz7eDv7THl
tcPz4RotIAJOPTof9u9va0wt+LcFh6Y6SXVFEP3RYcFrgyjECFjJ+PL0TKIiJOyo
pRFgmyAU/qakmfcLEuWe95WJyl27d/pyg6WW4iuKDiVU8/um5M8RxlBCcBiLzmrM
j3XOAobE4KSpI/2deBxNdIpDNQyGTxNAyDobPQPU2nrQA0k/w8UmksQF/ZO+/RzM
5ZNfqSMhHO4j6GBIbo0iD+E2hO8l/7awMpiQZyhTrTrmFcBlVdbGttxlk+YYFKa7
7O3VILhoZZZppKIlLike6eOWFm+CiQ11zIGfHj7mnpAy5zggr3g=
=qQUB
-----END PGP SIGNATURE-----
Merge tag 'i3c/for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux
Pull i3c updates from Alexandre Belloni:
"HDR support has finally been added. mipi-i3c-hci has been reworked and
Intel Nova Lake-S support has been added.
Subsystem:
- Add HDR transfer support
Drivers:
- dw: fix bus hang on Agilex5
- mipi-i3c-hci: Intel Nova Lake-S support, IOMMU support
- svc: HDR support"
* tag 'i3c/for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux: (28 commits)
regmap: i3c: switch to use i3c_xfer from i3c_priv_xfer
net: mctp i3c: switch to use i3c_xfer from i3c_priv_xfer
hwmon: (lm75): switch to use i3c_xfer from i3c_priv_xfer
i3c: document i3c_xfers
i3c: fix I3C_SDR bit number
i3c: master: svc: Add basic HDR mode support
i3c: master: svc: Replace bool rnw with union for HDR support
i3c: Switch to use new i3c_xfer from i3c_priv_xfer
i3c: Add HDR API support
i3c: master: add WQ_PERCPU to alloc_workqueue users
i3c: master: Remove i3c_device_free_ibi from i3c_device_remove
i3c: mipi-i3c-hci-pci: Set d3cold_delay to 0 for Intel controllers
i3c: mipi-i3c-hci-pci: Add LTR support for Intel controllers
i3c: mipi-i3c-hci-pci: Add exit callback
i3c: mipi-i3c-hci-pci: Change callback parameter
i3c: mipi-i3c-hci-pci: Allocate a structure for mipi_i3c_hci_pci device information
i3c: mipi-i3c-hci-pci: Factor out intel_reset()
i3c: mipi-i3c-hci-pci: Factor out private registers ioremapping
i3c: mipi-i3c-hci-pci: Constify driver data
i3c: mipi-i3c-hci-pci: Use readl_poll_timeout()
...
Another small update for regmap, we have one new feature plus a little
bit of cleanup:
- Support for sparseness information in the flat cache, allowing users
that really need the performance properties it provides to benefit
from the interface and startup time improvements that sparsness provides
without needing to go all the way to a more fancy data structure.
- Cleanup work from Andy Shevchenko, refactoring the cache interface
in preparation for some future stuff he's working on.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmkt6/0ACgkQJNaLcl1U
h9A33gf/QC/O/zxVtpq31+CtC1k3ola0rWrLxOnQKywoUcBjJqX+FiFqL+MDS6Mw
RfXzX7SmzJup71/sg7GNQjRSL3jH3UmsAy4acbNhoCXwi0VaFibHfTqVKNQGK5um
uzsDP8Ue4zUyqym3jMKxs36iVYtt9/QcUjrubumisnB51csQKQ0tn7+2khUbN7D5
PEjUfR7WiGAGDf2AmCLueCYaV16uuzoxnlV9U4Mp5LYvzi5KKxZZAid9ppUCUcAt
uab8Y5Qo8uxBKJEue1vp4shfbxj69GoOdzOP8bYWNP2z6xcHXgK2ma/5y3eqK7L0
uA1SHqKW3QXY1VckI83QWrifR6r8mQ==
=TTeH
-----END PGP SIGNATURE-----
Merge tag 'regmap-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"Another small update for regmap, we have one new feature plus a little
bit of cleanup:
- Support for sparseness information in the flat cache, allowing
users that really need the performance properties it provides to
benefit from the interface and startup time improvements that
sparsness provides without needing to go all the way to a more
fancy data structure
- Cleanup work from Andy Shevchenko, refactoring the cache interface
in preparation for some future stuff he's working on"
* tag 'regmap-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: sdw-mbq: Reorder regmap_mbq_context struct for better packing
regmap: i3c: Use ARRAY_SIZE()
regcache: maple: Split ->populate() from ->init()
regcache: flat: Split ->populate() from ->init()
regcache: flat: Remove unneeded check and error message for -ENOMEM
regcache: rbtree: Split ->populate() from ->init()
regcache: Add ->populate() callback to separate from ->init()
regmap: warn users about uninitialized flat cache
regmap: add flat cache with sparse validity
Switch to use i3c_xfer instead of i3c_priv_xfer because framework will
update to support HDR mode. i3c_priv_xfer is now an alias of i3c_xfer.
Replace i3c_device_do_priv_xfers() with i3c_device_do_xfers(..., I3C_SDR)
to align with the new API.
Prepare for removal of i3c_priv_xfer and i3c_device_do_priv_xfers().
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20251028-lm75-v1-3-9bf88989c49c@nxp.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Merge series from Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>:
This patchset has 4 fixes and some enhancements to the Elite DSP driver
support.
Fixes includes
- setting correct flags for expected behaviour of appl_ptr
- fix closing of copp instances
- fix buffer alignment.
- fix state checks before closing asm stream
Enhancements include:
- adding q6asm_get_hw_pointer and ack callback support
- simplify code via __free(kfree) mechanism.
- use spinlock guards
- few cleanups discovered during doing above 2.
There is another set of updates comming soon, which will add support
for early memory mapping and few more modules support in audioreach.
Use ARRAY_SIZE() instead of hard coded numbers to show the intention
and make code robust against potential changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251103180946.604127-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a convention in the kernel to avoid error messages
in the cases of -ENOMEM errors. Besides that, the idea behind
using struct_size() and other macros from overflow.h is
to saturate the size that the following allocation call will
definitely fail, hence the check and the error messaging added
in regcache_flat_init() are redundant. Remove them.
Acked-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Split ->populate() implementation from ->init() code.
This decoupling will help for the further changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the future changes we would like to change the flow of the cache handling.
Add ->populate() callback in order to prepare for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251031080540.3970776-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The standard flat cache did not contain any validity info, so the cache
was always considered to be entirely valid. Multiple mechanisms exist to
initialize the cache on regmap init (defaults, raw defaults, HW init),
but not all drivers are using one of these. As a result, their
implementation might currently depend on the zero-initialized cache or
contain other workarounds.
When reading an uninitialized value from the flat cache, warn the user,
but maintain the current behavior. This will allow developers to switch
to a sparse (flat) cache independently.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Link: https://patch.msgid.link/20251029081248.52607-3-sander@svanheule.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The flat regcache will always assume the data in the cache is valid.
Since the cache is preferred over hardware access, this may shadow the
actual state of the device.
Add a new containing cache structure with the flat data table and a
bitmap indicating cache validity. REGCACHE_FLAT will still behave as
before, as the validity is ignored.
Define new cache type REGCACHE_FLAT_S: a flat cache with sparse
validity. The sparse validity is used to determine if a hardware access
should occur to initialize the cache on the fly, vs. at regmap init for
REGCACHE_FLAT. Contrary to REGCACHE_FLAT, this allows us to implement
regcache_ops.drop.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Link: https://patch.msgid.link/20251029081248.52607-2-sander@svanheule.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the code assumes that the device that registered the
MBQ register map is the actual SoundWire slave device. This works
fine for all current users, however future SDCA devices will
likely be implemented with the SoundWire slave as a parent device
and separate child drivers with regmaps for each audio Function.
Update the regmap_init_sdw_mbq_cfg macro to allow these two
to be specified separately.
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20251020155512.353774-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4e65bda827 ("ASoC: wcd934x: fix error handling in
wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.
That commit breaks audio playback, for instance, on sdm845 Thundercomm
Dragonboard 845c board:
Unable to handle kernel paging request at virtual address ffff8000847cbad4
...
CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT
Hardware name: Thundercomm Dragonboard 845c (DT)
...
Call trace:
slim_xfer_msg+0x24/0x1ac [slimbus] (P)
slim_read+0x48/0x74 [slimbus]
regmap_slimbus_read+0x18/0x24 [regmap_slimbus]
_regmap_raw_read+0xe8/0x174
_regmap_bus_read+0x44/0x80
_regmap_read+0x60/0xd8
_regmap_update_bits+0xf4/0x140
_regmap_select_page+0xa8/0x124
_regmap_raw_write_impl+0x3b8/0x65c
_regmap_bus_raw_write+0x60/0x80
_regmap_write+0x58/0xc0
regmap_write+0x4c/0x80
wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]
snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]
__soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]
dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]
dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]
snd_pcm_hw_params+0x124/0x464 [snd_pcm]
snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]
snd_pcm_ioctl+0x34/0x4c [snd_pcm]
__arm64_sys_ioctl+0xac/0x104
invoke_syscall+0x48/0x104
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x34/0xec
el0t_64_sync_handler+0xa0/0xf0
el0t_64_sync+0x198/0x19c
The __devm_regmap_init_slimbus() started to be used instead of
__regmap_init_slimbus() after the commit mentioned above and turns out
the incorrect bus_context pointer (3rd argument) was used in
__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal
to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or
the first user of devm_regmap_init_slimbus() but we should fix it till
the point where __devm_regmap_init_slimbus() was introduced therefore
two "Fixes" tags.
While at this, also correct the same argument in __regmap_init_slimbus().
Fixes: 4e65bda827 ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()")
Fixes: 7d6f7fb053 ("regmap: add SLIMbus support")
Cc: stable@vger.kernel.org
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Ma Ke <make24@iscas.ac.cn>
Cc: Steev Klimaszewski <steev@kali.org>
Cc: Srinivas Kandagatla <srini@kernel.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20251022201013.1740211-1-alexey.klimov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the 'ret' variable from unsigned int to int to store negative error
codes or zero returned by regmap_field_read() and regmap_read(), and change
'-1' to 'negative errno' in the comments.
Storing the negative error codes in unsigned type, doesn't cause an issue
at runtime but it's ugly as pants. Additionally, assigning negative error
codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
flag is enabled.
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Message-ID: <20250828150702.193288-1-rongqianfeng@vivo.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There were already several commits to add module descriptions to regmap
modules. But this one was still missing:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-mmio.o
Signed-off-by: Luis Henriques <luis@igalia.com>
Link: https://patch.msgid.link/20250728150829.11890-1-luis@igalia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These patches fix a lockdep issue Russell King reported with nested
regmap-irqs (unusual since regmap is generally for devices on slow buses
so devices don't get nested), plus add a missing mutex free which I
noticed while implementing a fix for that issue.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmiV7wUACgkQJNaLcl1U
h9DgbAf+O3VBljLbtjoJGP25dWZcmFNkVyDu6Bq2rFeIrDKxhZT3048MraxFw1if
uo+YeAuOAziDFMPqBhUvtbNIeFDg1rSzqOGhQ4NdAFHQjN8ZcwxrVzp/hXJiFMTf
jAhonhUWOeerxtu5ThT12060FwX/pD/M+aV2Q6zLI44pUXw/WH7J90B0CAi76ok4
9V1NWybkCh8BUX98ePuqlut/p+1Iq8PixpoxaOdLLd3OxoRy++fjhvNjaSo65NGR
C9L6Rmv46ter4LCkfHlYz+VEDQg6ahdCexSNknzncH6OV9ZYV0/SVysqrlpqOALz
CUbOeXIQ9nV9PwOeQqKGgaqbxbfxhg==
=G3M7
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v6.17-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"These patches fix a lockdep issue Russell King reported with nested
regmap-irqs (unusual since regmap is generally for devices on slow
buses so devices don't get nested), plus add a missing mutex free
which I noticed while implementing a fix for that issue"
* tag 'regmap-fix-v6.17-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: irq: Avoid lockdep warnings with nested regmap-irq chips
regmap: irq: Free the regmap-irq mutex
While handling interrupts through regmap-irq we use a mutex to protect the
updates we are caching while genirq runs in atomic context. Russell King
reported that while running on the nVidia Jetson Xavier NX this generates
lockdep warnings since that platform has a regmap-irq for the max77686 RTC
which is a child of a max77620 which also uses regmap-irq.
[ 46.723127] rtcwake/3984 is trying to acquire lock:
[ 46.723235] ffff0000813b2c68 (&d->lock){+.+.}-{4:4}, at: regmap_irq_lock+0x18/0x24
[ 46.723452]
but task is already holding lock:
[ 46.723556] ffff00008504dc68 (&d->lock){+.+.}-{4:4}, at: regmap_irq_lock+0x18/0x24
This happens because by default lockdep uses a single lockdep class for all
mutexes initialised from a single mutex_init() call and is unable to tell
that two distinct mutex are being taken and verify that the ordering of
operations is safe. This should be a very rare situation since normally
anything using regmap-irq will be a leaf interrupt controller due to being
on a slow bus like I2C.
We can avoid these warnings by providing the lockdep key for the regmap-irq
explicitly, allocating one for each chip so that lockdep can distinguish
between them.
Thanks to Russell for the report and analysis.
Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250731-regmap-irq-nesting-v1-2-98b4d1bf20f0@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
We do not currently free the mutex allocated by regmap-irq, do so.
Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250731-regmap-irq-nesting-v1-1-98b4d1bf20f0@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
A very quiet release for regmap this time, just two cleanup patches and
one almost cleanup patch which saves individual MMIO regmaps flagging
themselves as having fast I/O.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmiHZLAACgkQJNaLcl1U
h9B/wwgAgBT89u9tOn21YaAz+wFIT5e8Ri/Id15lJHiabLJNhZtlbwajgXU8Rtl6
weTCCylI1jDkKX9rGXIKE3wz31rGD19saZjLEaZqPDgKTq6dkXByGKdFa31cJ+hs
FGPBUOGuOMJCMlKm1leLQbPj9mYX1hGQA6bD0uZHfjhnP+eX8FlqgmQ2/Ssk9Nwm
V816pTgr14z2mbfMZRFC/UjXVFDWQy9JGRFvWcb1y9S3ZNVZ+kelu5oTyaNgtfkx
+rCjPrPEvoYLnYHSTXsclXegRi71RYOF7Hoc2c3Tlen5vIL0+cY5kqLlA0b3MrT3
0NDg2O/49PyQlbYLfB0cq0eE3/nFvg==
=1gmK
-----END PGP SIGNATURE-----
Merge tag 'regmap-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"A very quiet release for regmap this time, just two cleanup patches
and one almost cleanup patch which saves individual MMIO regmaps
flagging themselves as having fast I/O"
* tag 'regmap-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Annotate that MMIO implies fast IO
regmap: get rid of redundant debugfs_file_{get,put}()
regmap: kunit: Constify regmap_range_cfg array
pointless in ->read()/->write() of file_operations used only via
debugfs_create_file()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Link: https://patch.msgid.link/20250702211602.GC3406663@ZenIV
Signed-off-by: Mark Brown <broonie@kernel.org>
When __regmap_init() is called from __regmap_init_i2c() and
__regmap_init_spi() (and their devm versions), the bus argument
obtained from regmap_get_i2c_bus() and regmap_get_spi_bus(), may be
allocated using kmemdup() to support quirks. In those cases, the
bus->free_on_exit field is set to true.
However, inside __regmap_init(), buf is not freed on any error path.
This could lead to a memory leak of regmap_bus when __regmap_init()
fails. Fix that by freeing bus on error path when free_on_exit is set.
Fixes: ea030ca688 ("regmap-i2c: Set regmap max raw r/w from quirks")
Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
Link: https://patch.msgid.link/20250626172823.18725-1-abdun.nihaal@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some GPIO chips allow to rise an IRQ on GPIO level changes but do not
provide an IRQ status for each separate line: only the current gpio
level can be retrieved.
Add support for these chips, emulating IRQ status by comparing GPIO
levels with the levels during the previous interrupt.
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use enable_irq_wake() and disable_irq_wake() instead of
calling low-level irq_set_irq_wake() with a parameter.
No functional changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250521135538.1086717-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If either REGMAP_IRQ or REGMAP_MDIO are set then REGMAP is also set.
This then enables the selecting of IRQ_DOMAIN or MDIO_BUS from REGMAP
based on the above two symbols respectively. This makes it very easy
to end up with "circular dependencies".
Instead select the IRQ_DOMAIN or MDIO_BUS from the symbols that make
use of them. This is almost equivalent to before but makes it less
likely to end up with false circular dependency detections.
Signed-off-by: Andrew Davis <afd@ti.com>
Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Closes: https://lore.kernel.org/r/bfe991fa-f54c-4d58-b2e0-34c4e4eb48f4@linaro.org/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250516141722.13772-1-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Only a couple of small patches this release, one refactoring struct
regmap to pack it more efficiently and another which makes our way of
setting all bits consistent in the regmap-irq code.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmfl0I4ACgkQJNaLcl1U
h9Ddlgf/bwUrSlIstkLQi3JqIT6rlfhtE34WyDlaI9fmDwzoUn3tS9HQt2Yxbyqz
e+V+HrhsQrGUTrcyHMYywo70b/Ed+R2ck2S8IUV2+RVJ1rEcCUTjr14iyPo8YRrE
4fJClRxqiPmsDhyNaW3/3gaoKczwaWJym9bJrGLunvy2bm//c2yBq2ZetzZYYady
qZnPhrT+jsDvcTPS8MLo6u/zdx1hFOKdKzj0+xlzmSgoXwIaU79s+VglOgVpa8Qf
AilGHXiNy1QvbbaBJwm2UJEQSuyPaV2/ID3ydtGzgDuoSOOESxS+lrlv0oybDZ09
PQ4QD/qX/86XRDRb9gqZECwIndoQ8w==
=G7Ap
-----END PGP SIGNATURE-----
Merge tag 'regmap-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap updates from Mark Brown:
"Only a couple of small patches this release, one refactoring struct
regmap to pack it more efficiently and another which makes our way of
setting all bits consistent in the regmap-irq code"
* tag 'regmap-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: irq: Use one way of setting all bits in the register
regmap: Reorder 'struct regmap'
The defaults array in regcache must be sorted into ascending register
address order, because binary search is used to locate values in
the array. Add a helper to sort the register defaults array which
can be useful for systems that dynamically create a defaults array
based on external information.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250217140159.2288784-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently there are two ways of how we represent all bits set, i.e.
UINT_MAX and GENMASK(31, 0). Use the former as the single way of
doing that, which is crystal clear on how we fill the unsigned int
value.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250206191644.1132869-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On a x86_64, with configured with allmodconfig, pahole states that the
regmap structure is:
/* size: 1048, cachelines: 17, members: 78 */
/* sum members: 1006, holes: 9, sum holes: 35 */
/* padding: 7 */
/* member types with holes: 2, total: 2 */
/* last cacheline: 24 bytes */
So, when such a struct is allocated, 2048 bytes are allocated, with most of
this space being wasted.
Move a few bools so that the size is reduced to 1024.
After this change, pahole gives:
/* size: 1024, cachelines: 16, members: 78 */
/* sum members: 1006, holes: 6, sum holes: 18 */
/* member types with holes: 2, total: 2 */
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/f01f900d15633d5cda5f27763723acb307c0d22f.1737725820.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
The current SDCA MBQ (Multi-Byte Quantities) register map only
supports 16-bit types, add support for more sizes and then update
the rt722 driver to use the new support. We also add support for
the deferring feature of MBQs to allow hardware to indicate it is
not currently ready to service a read/write.
Afraid I don't have hardware to test the rt722 change so it is
only build tested, but I thought it good to include a change to
demonstrate the new features in use.
The SDCA specification allows for controls to be deferred. In the case
of a deferred control the device will return COMMAND_IGNORED to the
8-bit operation that would cause the value to commit. Which is the
final 8-bits on a write, or the first 8-bits on a read. In the case of
receiving a defer, the regmap will poll the SDCA function busy bit,
after which the transaction will be retried, returning an error if the
function busy does not clear within a chip specific timeout. Since
this is common SDCA functionality which is the 99% use-case for MBQs
it makes sense to incorporate this functionality into the register
map. If no MBQ configuration is specified, the behaviour will default
to the existing behaviour.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
SoundWire MBQ register maps typically contain a variety of register
sizes, which doesn't map ideally to the regmap abstraction which
expects register maps to have a consistent size. Currently the MBQ
register map only allows 16-bit registers to be defined, however
this leads to complex CODEC driver implementations with an 8-bit
register map and a 16-bit MBQ, every control will then have a custom
get and put handler that allows them to access different register
maps. Further more 32-bit MBQ quantities are not currently supported.
Add support for additional MBQ sizes and to avoid the complexity
of multiple register maps treat the val_size as a maximum size for
the register map. Within the regmap use an ancillary callback to
determine how many bytes to actually read/write to the hardware for
a specific register. In the case that no callback is defined the
behaviour defaults back to the existing behaviour of a fixed size
register map.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark the list of registers passed into regmap_multi_reg_read() as a
pointer to const. This allows the caller to define the register list
as const data.
This requires making the same change to _regmap_bulk_read(), which is
called by regmap_multi_reg_read().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241211133558.884669-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Two patches move the code to use BITS_TO_BYTES(), while the last
one otpimizes the code generation on x86 (32- and 64-bit on different
compilers).
Use krealloc_array() to replace krealloc() with multiplication.
krealloc_array() has multiply overflow check, which will be safer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241121123439.4180167-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use kmalloc_array() to replace kmalloc() with multiplication.
kmalloc_array() has multiply overflow check, which will be safer.
In once case change kcalloc() as we don't need to clear the memory
since it's all being reinitialised just immediately after that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241121123433.4180133-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On x86 the compiler (gcc (Debian 14.2.0-8) 14.2.0) may generate
a better code if it sees division and modulo goes together.
Function old new delta
__regmap_init 3740 3732 -8
Total: Before=31159, After=31151, chg -0.03%
clang (Debian clang version 18.1.8) on x86_64 still shows better code
Function old new delta
__regmap_init 3582 3579 -3
Total: Before=39854, After=39851, chg -0.01%
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241121105838.4073659-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown