* [PATCH v1 1/4] regmap: Switch to use kmemdup_array()
2026-11-10 9:36 [PATCH v1 0/4] regmap: a small set of cleanups Andy Shevchenko
@ 2026-11-10 9:36 ` Andy Shevchenko
2026-11-10 9:37 ` [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs Andy Shevchenko
` (3 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2026-11-10 9:36 UTC (permalink / raw)
To: Mark Brown, linux-kernel, driver-core
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Johan Hovold, Andy Shevchenko
Let the kmemdup_array() take care about multiplication and possible
overflows.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/base/regmap/regmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index bc4e53ce8ecc..e327850ecc97 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2595,9 +2595,9 @@ static int _regmap_multi_reg_write(struct regmap *map,
*/
range = _regmap_range_lookup(map, reg);
if (range || regs[i].delay_us) {
- size_t len = sizeof(struct reg_sequence)*num_regs;
- struct reg_sequence *base = kmemdup(regs, len,
- GFP_KERNEL);
+ struct reg_sequence *base;
+
+ base = kmemdup_array(regs, num_regs, sizeof(*regs), GFP_KERNEL);
if (!base)
return -ENOMEM;
ret = _regmap_range_multi_paged_reg_write(map, base,
--
2.50.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs
2026-11-10 9:36 [PATCH v1 0/4] regmap: a small set of cleanups Andy Shevchenko
2026-11-10 9:36 ` [PATCH v1 1/4] regmap: Switch to use kmemdup_array() Andy Shevchenko
@ 2026-11-10 9:37 ` Andy Shevchenko
2026-11-10 10:19 ` Peng Fan
2026-11-11 18:49 ` Mark Brown
2026-11-10 9:37 ` [PATCH v1 3/4] regmap: Defer assignments to the later in some cases Andy Shevchenko
` (2 subsequent siblings)
4 siblings, 2 replies; 11+ messages in thread
From: Andy Shevchenko @ 2026-11-10 9:37 UTC (permalink / raw)
To: Mark Brown, linux-kernel, driver-core
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Johan Hovold, Andy Shevchenko
devm_regmap_field_free() was introduced in 2013 and was never ever used.
devm_regmap_field_bulk_free() was introduced in 2020 and the same story.
Drop never used APIs.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/base/regmap/regmap.c | 36 ------------------------------------
include/linux/regmap.h | 3 ---
2 files changed, 39 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index e327850ecc97..0617a957559b 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1330,42 +1330,6 @@ void regmap_field_bulk_free(struct regmap_field *field)
}
EXPORT_SYMBOL_GPL(regmap_field_bulk_free);
-/**
- * devm_regmap_field_bulk_free() - Free a bulk register field allocated using
- * devm_regmap_field_bulk_alloc.
- *
- * @dev: Device that will be interacted with
- * @field: regmap field which should be freed.
- *
- * Free register field allocated using devm_regmap_field_bulk_alloc(). Usually
- * drivers need not call this function, as the memory allocated via devm
- * will be freed as per device-driver life-cycle.
- */
-void devm_regmap_field_bulk_free(struct device *dev,
- struct regmap_field *field)
-{
- devm_kfree(dev, field);
-}
-EXPORT_SYMBOL_GPL(devm_regmap_field_bulk_free);
-
-/**
- * devm_regmap_field_free() - Free a register field allocated using
- * devm_regmap_field_alloc.
- *
- * @dev: Device that will be interacted with
- * @field: regmap field which should be freed.
- *
- * Free register field allocated using devm_regmap_field_alloc(). Usually
- * drivers need not call this function, as the memory allocated via devm
- * will be freed as per device-driver life-cyle.
- */
-void devm_regmap_field_free(struct device *dev,
- struct regmap_field *field)
-{
- devm_kfree(dev, field);
-}
-EXPORT_SYMBOL_GPL(devm_regmap_field_free);
-
/**
* regmap_field_alloc() - Allocate and initialise a register field.
*
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 8f3034881f8a..e4f8f462fbab 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -1488,7 +1488,6 @@ DEFINE_FREE(regmap_field, struct regmap_field *, if (_T) regmap_field_free(_T))
struct regmap_field *devm_regmap_field_alloc(struct device *dev,
struct regmap *regmap, struct reg_field reg_field);
-void devm_regmap_field_free(struct device *dev, struct regmap_field *field);
int regmap_field_bulk_alloc(struct regmap *regmap,
struct regmap_field **rm_field,
@@ -1499,8 +1498,6 @@ int devm_regmap_field_bulk_alloc(struct device *dev, struct regmap *regmap,
struct regmap_field **field,
const struct reg_field *reg_field,
int num_fields);
-void devm_regmap_field_bulk_free(struct device *dev,
- struct regmap_field *field);
int regmap_field_read(struct regmap_field *field, unsigned int *val);
int regmap_field_update_bits_base(struct regmap_field *field,
--
2.50.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs
2026-11-10 9:37 ` [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs Andy Shevchenko
@ 2026-11-10 10:19 ` Peng Fan
2026-11-11 18:49 ` Mark Brown
1 sibling, 0 replies; 11+ messages in thread
From: Peng Fan @ 2026-11-10 10:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Brown, linux-kernel, driver-core, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Johan Hovold
On Tue, Nov 10, 2026 at 10:37:00AM +0100, Andy Shevchenko wrote:
>devm_regmap_field_free() was introduced in 2013 and was never ever used.
>devm_regmap_field_bulk_free() was introduced in 2020 and the same story.
>
>Drop never used APIs.
>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs
2026-11-10 9:37 ` [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs Andy Shevchenko
2026-11-10 10:19 ` Peng Fan
@ 2026-11-11 18:49 ` Mark Brown
2026-11-12 6:56 ` Andy Shevchenko
1 sibling, 1 reply; 11+ messages in thread
From: Mark Brown @ 2026-11-11 18:49 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Brown, linux-kernel, driver-core, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Johan Hovold
> devm_regmap_field_free() was introduced in 2013 and was never ever used.
> devm_regmap_field_bulk_free() was introduced in 2020 and the same story.
>
> Drop never used APIs.
I tend to think that if we have allocation functions we should have
matching release functions, this avoids cross tree annoyances and bugs
due to people using inappropriate release functions which actually
exist rather than adding the ones they should use.
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs
2026-11-11 18:49 ` Mark Brown
@ 2026-11-12 6:56 ` Andy Shevchenko
0 siblings, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2026-11-12 6:56 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, driver-core, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Johan Hovold
On Wed, Nov 11, 2026 at 06:49:02PM +0000, Mark Brown wrote:
> > devm_regmap_field_free() was introduced in 2013 and was never ever used.
> > devm_regmap_field_bulk_free() was introduced in 2020 and the same story.
> >
> > Drop never used APIs.
>
> I tend to think that if we have allocation functions we should have
> matching release functions, this avoids cross tree annoyances and bugs
> due to people using inappropriate release functions which actually
> exist rather than adding the ones they should use.
In general yes, but for devm_*() it makes not much sense as proven by dozens
of dropped "release/free" type of devm_*() calls in the past. Also as commit
message says for more than 10 years nobody used it even once. What does make
you think there eventually be at least a single user?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v1 3/4] regmap: Defer assignments to the later in some cases
2026-11-10 9:36 [PATCH v1 0/4] regmap: a small set of cleanups Andy Shevchenko
2026-11-10 9:36 ` [PATCH v1 1/4] regmap: Switch to use kmemdup_array() Andy Shevchenko
2026-11-10 9:37 ` [PATCH v1 2/4] regmap: Drop never used devm_regmap_*_free() APIs Andy Shevchenko
@ 2026-11-10 9:37 ` Andy Shevchenko
2026-11-10 10:20 ` Peng Fan
2026-11-10 9:37 ` [PATCH v1 4/4] regmap: Drop duplicate ret assignment Andy Shevchenko
2026-11-11 18:52 ` (subset) [PATCH v1 0/4] regmap: a small set of cleanups Mark Brown
4 siblings, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2026-11-10 9:37 UTC (permalink / raw)
To: Mark Brown, linux-kernel, driver-core
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Johan Hovold, Andy Shevchenko
In some cases the assignments at the top of the certain functions
belong to smaller subset of the functionality and may be located
too far from their actual users. Defer them to the later.
This makes code robust against potential changes that may lead to
the corruption of the respected values.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/base/regmap/regmap.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 0617a957559b..1855b5fc76da 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -681,12 +681,14 @@ struct regmap *__regmap_init(struct device *dev,
const char *lock_name)
{
struct regmap *map;
- int ret = -EINVAL;
enum regmap_endian reg_endian, val_endian;
int i, j;
+ int ret;
- if (!config)
+ if (!config) {
+ ret = -EINVAL;
goto err;
+ }
map = kzalloc_obj(*map);
if (map == NULL) {
@@ -1604,8 +1606,7 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg,
{
struct regmap_range_node *range;
unsigned long flags;
- void *work_val = map->work_buf + map->format.reg_bytes +
- map->format.pad_bytes;
+ void *work_val;
void *buf;
int ret = -ENOTSUPP;
size_t len;
@@ -1688,6 +1689,7 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg,
* buffer to write. Since register syncs often generate raw
* writes of single registers optimise that case.
*/
+ work_val = map->work_buf + map->format.reg_bytes + map->format.pad_bytes;
if (val != work_val && val_len == map->format.val_bytes) {
memcpy(work_val, val, map->format.val_bytes);
val = work_val;
@@ -2291,8 +2293,8 @@ EXPORT_SYMBOL_GPL(regmap_fields_update_bits_base);
int regmap_bulk_write(struct regmap *map, unsigned int reg, const void *val,
size_t val_count)
{
- int ret = 0, i;
size_t val_bytes = map->format.val_bytes;
+ int ret, i;
if (!IS_ALIGNED(reg, map->reg_stride))
return -EINVAL;
@@ -2302,6 +2304,8 @@ int regmap_bulk_write(struct regmap *map, unsigned int reg, const void *val,
* single write operations.
*/
if (!map->write || !map->format.parse_inplace) {
+ ret = 0; /* Later error paths rely on this */
+
guard(regmap)(map);
for (i = 0; i < val_count; i++) {
@@ -2739,12 +2743,12 @@ static int _regmap_bus_read(void *context, unsigned int reg,
{
int ret;
struct regmap *map = context;
- void *work_val = map->work_buf + map->format.reg_bytes +
- map->format.pad_bytes;
+ void *work_val;
if (!map->format.parse_val)
return -EINVAL;
+ work_val = map->work_buf + map->format.reg_bytes + map->format.pad_bytes;
ret = _regmap_raw_read(map, reg, work_val, map->format.val_bytes, false);
if (ret == 0)
*val = map->format.parse_val(work_val);
--
2.50.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v1 3/4] regmap: Defer assignments to the later in some cases
2026-11-10 9:37 ` [PATCH v1 3/4] regmap: Defer assignments to the later in some cases Andy Shevchenko
@ 2026-11-10 10:20 ` Peng Fan
0 siblings, 0 replies; 11+ messages in thread
From: Peng Fan @ 2026-11-10 10:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Brown, linux-kernel, driver-core, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Johan Hovold
On Tue, Nov 10, 2026 at 10:37:01AM +0100, Andy Shevchenko wrote:
>In some cases the assignments at the top of the certain functions
>belong to smaller subset of the functionality and may be located
>too far from their actual users. Defer them to the later.
>
>This makes code robust against potential changes that may lead to
>the corruption of the respected values.
>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v1 4/4] regmap: Drop duplicate ret assignment
2026-11-10 9:36 [PATCH v1 0/4] regmap: a small set of cleanups Andy Shevchenko
` (2 preceding siblings ...)
2026-11-10 9:37 ` [PATCH v1 3/4] regmap: Defer assignments to the later in some cases Andy Shevchenko
@ 2026-11-10 9:37 ` Andy Shevchenko
2026-11-10 10:22 ` Peng Fan
2026-11-11 18:52 ` (subset) [PATCH v1 0/4] regmap: a small set of cleanups Mark Brown
4 siblings, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2026-11-10 9:37 UTC (permalink / raw)
To: Mark Brown, linux-kernel, driver-core
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Johan Hovold, Andy Shevchenko
In a one case the ret is assigned at the top of a certain function and
gets reassigned in all cases after that, making the initial assignment
useless. Drop that assignment.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/base/regmap/regmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 1855b5fc76da..b729226e9e3d 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1608,8 +1608,8 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg,
unsigned long flags;
void *work_val;
void *buf;
- int ret = -ENOTSUPP;
size_t len;
+ int ret;
int i;
/* Check for unwritable or noinc registers in range
--
2.50.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v1 4/4] regmap: Drop duplicate ret assignment
2026-11-10 9:37 ` [PATCH v1 4/4] regmap: Drop duplicate ret assignment Andy Shevchenko
@ 2026-11-10 10:22 ` Peng Fan
0 siblings, 0 replies; 11+ messages in thread
From: Peng Fan @ 2026-11-10 10:22 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Brown, linux-kernel, driver-core, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Johan Hovold
On Tue, Nov 10, 2026 at 10:37:02AM +0100, Andy Shevchenko wrote:
>In a one case the ret is assigned at the top of a certain function and
>gets reassigned in all cases after that, making the initial assignment
>useless. Drop that assignment.
>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (subset) [PATCH v1 0/4] regmap: a small set of cleanups
2026-11-10 9:36 [PATCH v1 0/4] regmap: a small set of cleanups Andy Shevchenko
` (3 preceding siblings ...)
2026-11-10 9:37 ` [PATCH v1 4/4] regmap: Drop duplicate ret assignment Andy Shevchenko
@ 2026-11-11 18:52 ` Mark Brown
4 siblings, 0 replies; 11+ messages in thread
From: Mark Brown @ 2026-11-11 18:52 UTC (permalink / raw)
To: linux-kernel, driver-core, Andy Shevchenko
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Johan Hovold
On Tue, 10 Nov 2026 10:36:58 +0100, Andy Shevchenko wrote:
> regmap: a small set of cleanups
>
> This is a mini-series of a small set of ad-hoc cleanups.
> Read individual patches to get the idea.
>
> Andy Shevchenko (4):
> regmap: Switch to use kmemdup_array()
> regmap: Drop never used devm_regmap_*_free() APIs
> regmap: Defer assignments to the later in some cases
> regmap: Drop duplicate ret assignment
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-7.5
Thanks!
[1/4] regmap: Switch to use kmemdup_array()
https://git.kernel.org/broonie/regmap/c/ed8939e50466
[3/4] regmap: Defer assignments to the later in some cases
https://git.kernel.org/broonie/regmap/c/ac5fd39a1718
[4/4] regmap: Drop duplicate ret assignment
https://git.kernel.org/broonie/regmap/c/64db965e43d4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread