kernel/linux.git/drivers/base/regmap/regmap-spi.c, branch linux-7.0.y

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

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

regmap: spi: Fix potential off-by-one when calculating reserved size

2024-06-05T21:23:52+00:00

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 Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com Signed-off-by: Mark Brown

regmap: spi: Add missing MODULE_DESCRIPTION()

2024-04-10T21:45:53+00:00

The modpost script is not happy WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-spi.o because there is a missing module description. Add it to the module. Signed-off-by: Andy Shevchenko Link: https://msgid.link/r/20240410202912.1659275-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

regmap: spi: Reserve space for register address/padding

2022-08-18T14:02:05+00:00

Currently the max_raw_read and max_raw_write limits in regmap_spi struct do not take into account the additional size of the transmitted register address and padding. This may result in exceeding the maximum permitted SPI message size, which could cause undefined behaviour, e.g. data corruption. Fix regmap_get_spi_bus() to properly adjust the above mentioned limits by reserving space for the register address/padding as set in the regmap configuration. Fixes: f231ff38b7b2 ("regmap: spi: Set regmap max raw r/w from max_transfer_size") Signed-off-by: Cristian Ciocaltea Reviewed-by: Lucas Tanure Link: https://lore.kernel.org/r/20220818104851.429479-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown

regmap: spi: Set regmap max raw r/w from max_transfer_size

2021-10-23T18:55:03+00:00

Set regmap raw read/write from spi max_transfer_size so regmap_raw_read/write can split the access into chunks Signed-off-by: Lucas Tanure Reviewed-by: Charles Keepax [André: fix build warning] Signed-off-by: André Almeida Link: https://lore.kernel.org/r/20211021132721.13669-1-andrealmeid@collabora.com Signed-off-by: Mark Brown

regmap: add proper SPDX identifiers on files that did not have them.

2019-04-25T19:22:15+00:00

There were a few files in the regmap code that did not have SPDX identifiers on them, so fix that up. At the same time, remove the "free form" text that specified the license of the file, as that is impossible for any tool to properly parse. Also, as Mark loves // comment markers, convert all of the headers to be the same to make things look consistent :) Signed-off-by: Greg Kroah-Hartman Signed-off-by: Mark Brown

regmap: constify regmap_bus structures

2017-08-14T16:36:29+00:00

These regmap_bus structures are only passed as the second argument to __devm_regmap_init or __regmap_init, both of which are const, so the regmap_bus structures can be const too. Done with the help of Coccinelle. Signed-off-by: Julia Lawall Signed-off-by: Mark Brown

regmap: Move documentation to regmap.h

2015-08-11T16:21:44+00:00

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown

regmap: Use different lockdep class for each regmap init call

2015-08-07T13:50:59+00:00

Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown