This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
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>
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()
...
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.
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>
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>
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>
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
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>
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'
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>
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).
