kernel/linux.git/drivers/base/regmap, branch v6.1.124

regmap: Use correct format specifier for logging range errors

2025-01-02T09:30:52+00:00

[ Upstream commit 3f1aa0c533d9dd8a835caf9a6824449c463ee7e2 ] The register addresses are unsigned ints so we should use %u not %d to log them. Signed-off-by: Mark Brown Link: https://patch.msgid.link/20241127-regmap-test-high-addr-v1-1-74a48a9e0dc5@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regmap: detach regmap from dev on regmap_exit

2024-12-14T18:54:36+00:00

commit 3061e170381af96d1e66799d34264e6414d428a7 upstream. At the end of __regmap_init(), if dev is not NULL, regmap_attach_dev() is called, which adds a devres reference to the regmap, to be able to retrieve a dev's regmap by name using dev_get_regmap(). When calling regmap_exit, the opposite does not happen, and the reference is kept until the dev is detached. Add a regmap_detach_dev() function and call it in regmap_exit() to make sure that the devres reference is not kept. Cc: stable@vger.kernel.org Fixes: 72b39f6f2b5a ("regmap: Implement dev_get_regmap()") Signed-off-by: Cosmin Tanislav Rule: add Link: https://lore.kernel.org/stable/20241128130554.362486-1-demonsingur%40gmail.com Link: https://patch.msgid.link/20241128131625.363835-1-demonsingur@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regmap: irq: Set lockdep class for hierarchical IRQ domains

2024-12-14T18:53:23+00:00

[ Upstream commit 953e549471cabc9d4980f1da2e9fa79f4c23da06 ] Lockdep gives a false positive splat as it can't distinguish the lock which is taken by different IRQ descriptors from different IRQ chips that are organized in a way of a hierarchy: ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc5-next-20241101-00148-g9fabf8160b53 #562 Tainted: G W ------------------------------------------------------ modprobe/141 is trying to acquire lock: ffff899446947868 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}, at: regmap_update_bits_base+0x33/0x90 but task is already holding lock: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 which lock already depends on the new lock. -> #3 (&d->lock){+.+.}-{4:4}: -> #2 (&desc->request_mutex){+.+.}-{4:4}: -> #1 (ipclock){+.+.}-{4:4}: -> #0 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}: Chain exists of: intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock --> &desc->request_mutex --> &d->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&d->lock); lock(&desc->request_mutex); lock(&d->lock); lock(intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock); *** DEADLOCK *** 3 locks held by modprobe/141: #0: ffff8994419368f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xf6/0x250 #1: ffff89944690b250 (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0x1a2/0x790 #2: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 Set a lockdep class when we map the IRQ so that it doesn't warn about a lockdep bug that doesn't exist. Fixes: 4af8be67fd99 ("regmap: Convert regmap_irq to use irq_domain") Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20241101165553.4055617-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

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

2024-09-08T05:53:10+00:00

[ Upstream commit d4ea1d504d2701ba04412f98dc00d45a104c52ab ] 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 Signed-off-by: Sasha Levin

regmap-i2c: Subtract reg size from max_write

2024-07-11T10:47:17+00:00

[ Upstream commit 611b7eb19d0a305d4de00280e4a71a1b15c507fc ] Currently, when an adapter defines a max_write_len quirk, the data will be chunked into data sizes equal to the max_write_len quirk value. But the payload will be increased by the size of the register address before transmission. The resulting value always ends up larger than the limit set by the quirk. Avoid this error by setting regmap's max_write to the quirk's max_write_len minus the number of bytes for the register and padding. This allows the chunking to work correctly for this limited case without impacting other use-cases. Signed-off-by: Jim Wylder Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regmap: fix bogus error on regcache_sync success

2023-12-13T17:39:20+00:00

commit fea88064445a59584460f7f67d102b6e5fc1ca1d upstream. Since commit 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") opening pcm512x based soundcards fail with EINVAL and dmesg shows sync cache and pm_runtime_get errors: [ 228.794676] pcm512x 1-004c: Failed to sync cache: -22 [ 228.794740] pcm512x 1-004c: ASoC: error at snd_soc_pcm_component_pm_runtime_get on pcm512x.1-004c: -22 This is caused by the cache check result leaking out into the regcache_sync return value. Fix this by making the check local-only, as the comment above the regcache_read call states a non-zero return value means there's nothing to do so the return value should not be altered. Fixes: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") Cc: stable@vger.kernel.org Signed-off-by: Matthias Reichl Link: https://lore.kernel.org/r/20231203222216.96547-1-hias@horus.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regmap: Ensure range selector registers are updated after cache sync

2023-11-28T17:07:09+00:00

commit 0ec7731655de196bc1e4af99e495b38778109d22 upstream. When we sync the register cache we do so with the cache bypassed in order to avoid overhead from writing the synced values back into the cache. If the regmap has ranges and the selector register for those ranges is in a register which is cached this has the unfortunate side effect of meaning that the physical and cached copies of the selector register can be out of sync after a cache sync. The cache will have whatever the selector was when the sync started and the hardware will have the selector for the register that was synced last. Fix this by rewriting all cached selector registers after every sync, ensuring that the hardware and cache have the same content. This will result in extra writes that wouldn't otherwise be needed but is simple so hopefully robust. We don't read from the hardware since not all devices have physical read support. Given that nobody noticed this until now it is likely that we are rarely if ever hitting this case. Reported-by: Hector Martin Cc: stable@vger.kernel.org Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded82770d@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regmap: prevent noinc writes from clobbering cache

2023-11-20T10:52:15+00:00

[ Upstream commit 984a4afdc87a1fc226fd657b1cd8255c13d3fc1a ] Currently, noinc writes are cached as if they were standard incrementing writes, overwriting unrelated register values in the cache. Instead, we want to cache the last value written to the register, as is done in the accelerated noinc handler (regmap_noinc_readwrite). Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API") Signed-off-by: Ben Wolsieffer Link: https://lore.kernel.org/r/20231101142926.2722603-2-ben.wolsieffer@hefring.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regmap: debugfs: Fix a erroneous check after snprintf()

2023-11-20T10:51:55+00:00

[ Upstream commit d3601857e14de6369f00ae19564f1d817d175d19 ] This error handling looks really strange. Check if the string has been truncated instead. Fixes: f0c2319f9f19 ("regmap: Expose the driver name in debugfs") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/8595de2462c490561f70020a6d11f4d6b652b468.1693857825.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regmap: fix NULL deref on lookup

2023-10-25T10:03:04+00:00

commit c6df843348d6b71ea986266c12831cb60c2cf325 upstream. Not all regmaps have a name so make sure to check for that to avoid dereferencing a NULL pointer when dev_get_regmap() is used to lookup a named regmap. Fixes: e84861fec32d ("regmap: dev_get_regmap_match(): fix string comparison") Cc: stable@vger.kernel.org # 5.8 Cc: Marc Kleine-Budde Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20231006082104.16707-1-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman