Re: [PATCH v2 0/7] regmap: cleanups for regcache and regmap init paths

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Mark,

On Tue, Oct 06, 2026 at 06:08:33PM +0200, Mark Brown wrote:
>On Fri, 02 Oct 2026 21:11:16 +0800, Peng Fan (OSS) wrote:
>> regmap: cleanups for regcache and regmap init paths
>> 
>> Following up the previous regmap guard lock patchset [1].
>> 
>> [1] https://lore.kernel.org/all/179062150526.139547.3870545428656485907.b4-ty@b4/#r
>> 
>> This is the 2nd batch to do more cleanup.
>> 
>> [...]
>
>Applied to
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-7.4

Thanks for picking up this series.

Sashiko report a minor issue that I should not use scoped_guard inside
a function has goto.

Actually it is not an bug. The goto logic and the scoped area are not mixed,
but anyway I just posted out v3 to address the issue:
https://lore.kernel.org/all/20261007-regmap-lock-2nd-v3-0-0e590c4125be@nxp.com/

If you would keep v2, I could post a incremental patch to address the
Sashiko's findings. Or you may pick v3.

Thanks
Peng

>
>Thanks!
>
>[1/7] regcache: extract locked helpers to replace open-coded lock/unlock pairs
>      https://git.kernel.org/broonie/regmap/c/81556a7aec22
>[2/7] regcache: extract __regcache_sync() to deduplicate sync dispatch
>      https://git.kernel.org/broonie/regmap/c/7ca8aa98e2ba
>[3/7] regcache: simplify control flow and reduce nesting
>      https://git.kernel.org/broonie/regmap/c/4e1b5ccf1eab
>[4/7] regmap: use krealloc_array() in regmap_register_patch()
>      https://git.kernel.org/broonie/regmap/c/8a889c83e478
>[5/7] regmap: fix potential double-free of map->reg_defaults on cache reinit
>      https://git.kernel.org/broonie/regmap/c/ca685a42b0fd
>[6/7] regmap: debugfs: Use __free(kfree) in regmap_name_read_file()
>      https://git.kernel.org/broonie/regmap/c/d64967dee82b
>[7/7] regmap: debugfs: Use guard to simplify code
>      https://git.kernel.org/broonie/regmap/c/a93de1d65c6b
>
>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
>
>
>