linux/drivers/base/regmap, branch v6.17

Merge tag 'regmap-fix-v6.17-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2025-08-09T05:40:28Z

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

regmap: irq: Avoid lockdep warnings with nested regmap-irq chips

2025-08-01T12:37:07Z

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) Tested-by: Russell King (Oracle) Reviewed-by: Russell King (Oracle) Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250731-regmap-irq-nesting-v1-2-98b4d1bf20f0@kernel.org Signed-off-by: Mark Brown

regmap: irq: Free the regmap-irq mutex

2025-08-01T12:37:06Z

We do not currently free the mutex allocated by regmap-irq, do so. Tested-by: Russell King (Oracle) Reviewed-by: Russell King (Oracle) Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250731-regmap-irq-nesting-v1-1-98b4d1bf20f0@kernel.org Signed-off-by: Mark Brown

Merge tag 'regmap-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2025-07-29T05:38:15Z

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

regmap: get rid of redundant debugfs_file_{get,put}()

2025-07-04T12:18:13Z

pointless in ->read()/->write() of file_operations used only via debugfs_create_file() Signed-off-by: Al Viro Link: https://patch.msgid.link/20250702211602.GC3406663@ZenIV Signed-off-by: Mark Brown

regmap: fix potential memory leak of regmap_bus

2025-06-29T21:10:36Z

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: ea030ca68819 ("regmap-i2c: Set regmap max raw r/w from quirks") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20250626172823.18725-1-abdun.nihaal@gmail.com Signed-off-by: Mark Brown

regmap: kunit: Constify regmap_range_cfg array

2025-06-08T22:35:03Z

Static 'struct regmap_range_cfg' array is not modified so can be changed to const for more safety. Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250528194501.567366-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown

regmap: irq: Add support for chips without separate IRQ status

2025-05-22T12:11:50Z

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 Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20250522-mdb-max7360-support-v9-5-74fc03517e41@bootlin.com Signed-off-by: Mark Brown

regmap-irq: Use dedicated interrupt wake setters

2025-05-21T15:04:11Z

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 Link: https://patch.msgid.link/20250521135538.1086717-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

regmap: Move selecting for REGMAP_MDIO and REGMAP_IRQ

2025-05-20T09:25:08Z

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 Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/r/bfe991fa-f54c-4d58-b2e0-34c4e4eb48f4@linaro.org/ Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250516141722.13772-1-afd@ti.com Signed-off-by: Mark Brown