linux.git/drivers/base/regmap, branch master Linux kernel source tree regmap: sdw-mbq: don't call an unset readable_reg callback 2026-08-12T17:08:48+00:00 Andrey Golovko andrey.golovko@gmail.com 2026-08-11T19:14:35+00:00 00268f9452d2a0d660aa9c1bb0ca07a994af6a4f regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit by calling ctx->readable_reg(), which is a straight copy of config->readable_reg. That callback is optional: regmap_readable() treats a NULL ->readable_reg as "every register is readable", and drivers rely on that. es9356 and tac5xx2-sdw both build an MBQ regmap without one. Since commit ca1b11b36d82 ("regmap: sdw-mbq: Allow defers on undeferrable controls") the poll runs on every -ENODATA, not only for Controls the driver marked deferrable, so any of those devices answering COMMAND_IGNORED takes the kernel through a NULL function pointer. Treat a missing callback the way the rest of regmap does and poll. Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260811184500.5312-1-andrey.golovko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit
by calling ctx->readable_reg(), which is a straight copy of
config->readable_reg. That callback is optional: regmap_readable() treats
a NULL ->readable_reg as "every register is readable", and drivers rely on
that. es9356 and tac5xx2-sdw both build an MBQ regmap without one.

Since commit ca1b11b36d82 ("regmap: sdw-mbq: Allow defers on undeferrable
controls") the poll runs on every -ENODATA, not only for Controls the
driver marked deferrable, so any of those devices answering
COMMAND_IGNORED takes the kernel through a NULL function pointer.

Treat a missing callback the way the rest of regmap does and poll.

Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls")
Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260811184500.5312-1-andrey.golovko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: sdw-mbq: Fix swap of timeout and retry times 2026-08-11T15:37:59+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2026-08-11T13:18:16+00:00 ae7fd6ff4c6713270d2efe6db87a4a58ccb7cc61 When polling Function Busy using read_poll_timeout() the total timeout and retry delay arguments are swapped. This leads to only a single retry being processed, it seems the existing users typically do succeed before the first retry. Swap the arguments over to ensure the correct polling time. Reported-by: Ville Saarinen <wiza@saarinenkoti.fi> Link: https://lore.kernel.org/linux-sound/ansTPGgVNoDJlA5r@opensource.cirrus.com/T/#m680731a2f307f1f5176b27ed5aa560ddc94e5d62 Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260811131816.332082-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> 
When polling Function Busy using read_poll_timeout() the total timeout
and retry delay arguments are swapped. This leads to only a single retry
being processed, it seems the existing users typically do succeed before
the first retry.

Swap the arguments over to ensure the correct polling time.

Reported-by: Ville Saarinen <wiza@saarinenkoti.fi>
Link: https://lore.kernel.org/linux-sound/ansTPGgVNoDJlA5r@opensource.cirrus.com/T/#m680731a2f307f1f5176b27ed5aa560ddc94e5d62
Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260811131816.332082-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regcache: Sort the local copy of an unsorted reg_defaults array 2026-08-06T12:01:39+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2026-08-05T13:22:50+00:00 4b05ccb17f92268384d483221a577fccfc291c7a regcache_lookup_reg() bsearch()es the reg_defaults array, which requires it to be sorted by ascending register address. Entries following a descending step are never found, so regcache_reg_needs_sync() reports that they need a sync and they are written to the device on every regcache_sync() even when they were never touched. Detect the misordering while reg_defaults is validated against the register stride and sort the local copy. The check needs no new loop and sort() only runs for the affected drivers, which are also warned about. Note that sort() is not stable, so for arrays with duplicated register addresses it remains unspecified which entry is found. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260805132250.2637-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
regcache_lookup_reg() bsearch()es the reg_defaults array, which requires
it to be sorted by ascending register address.  Entries following a
descending step are never found, so regcache_reg_needs_sync() reports
that they need a sync and they are written to the device on every
regcache_sync() even when they were never touched.

Detect the misordering while reg_defaults is validated against the
register stride and sort the local copy.  The check needs no new loop
and sort() only runs for the affected drivers, which are also warned
about.

Note that sort() is not stable, so for arrays with duplicated register
addresses it remains unspecified which entry is found.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260805132250.2637-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regcache: Use a consistent sort for defaults table 2026-08-06T11:59:47+00:00 Mark Brown broonie@kernel.org 2026-08-05T17:51:00+00:00 9ed3d974a26644ad57b3d4d067e279188b2038b6 When we look up registers in the defaults table we use a binary search, and we have a regcache_sort_defaults() API to help drivers that constuct their defaults tables on the fly. Unfortunately the lookup and the sort don't use the same comparison function, and to make matters worse the comparison function used during lookups is written for signed register numbers rather than the unsigned ones we actually have so can produce suprising results when some of the addresses have the top bit set. Standardise on the more explicitly coded function to ensure consistent results. Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260805-regmap-regcache-sort-v1-1-162186aad8b9@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
When we look up registers in the defaults table we use a binary search,
and we have a regcache_sort_defaults() API to help drivers that constuct
their defaults tables on the fly.  Unfortunately the lookup and the sort
don't use the same comparison function, and to make matters worse the
comparison function used during lookups is written for signed register
numbers rather than the unsigned ones we actually have so can produce
suprising results when some of the addresses have the top bit set.

Standardise on the more explicitly coded function to ensure consistent
results.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260805-regmap-regcache-sort-v1-1-162186aad8b9@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'regmap-fix-v7.2-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap 2026-06-26T17:47:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-26T17:47:26+00:00 fa956617b89c0669c651bf4f301ded8e9b20c6db Pull regmap fix from Mark Brown: "Ensure that we don't overwrite the error code when cleaning up a failed cache initialisation, helping people debug issues if they do arise" * tag 'regmap-fix-v7.2-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regcache: Do not overwrite error code when finalizing cache after error 
Pull regmap fix from Mark Brown:
 "Ensure that we don't overwrite the error code when cleaning up a
  failed cache initialisation, helping people debug issues if they
  do arise"

* tag 'regmap-fix-v7.2-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regcache: Do not overwrite error code when finalizing cache after error
regcache: Do not overwrite error code when finalizing cache after error 2026-06-16T13:13:48+00:00 Francesco Lavra flavra@baylibre.com 2026-06-16T11:44:29+00:00 9108f7fa493b4c88cbc09503e0c164244456bad5 During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed. Fixes: 94a3a95f0315 ("regcache: Add ->populate() callback to separate from ->init()") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Link: https://patch.msgid.link/20260616114429.1852456-1-flavra@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> 
During regcache initialization, if an error occurs in the
cache_ops->populate callback, and if cache operations include an exit
callback, the error code from populate() is overwritten with the return
value from exit(). This hides the error condition from the caller of
regcache_init(), and can cause NULL pointer dereferences when the regcache
is later accessed.

Fixes: 94a3a95f0315 ("regcache: Add ->populate() callback to separate from ->init()")
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Link: https://patch.msgid.link/20260616114429.1852456-1-flavra@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'regmap-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap 2026-06-16T02:18:30+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-06-16T02:18:30+00:00 aaee7820e2f7370034c4fd74eb36588eaae65966 Pull regmap update from Mark Brown: "This time around we just have a single fix for a sparse warning" * tag 'regmap-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16 
Pull regmap update from Mark Brown:
 "This time around we just have a single fix for a sparse warning"

* tag 'regmap-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16
regmap: reject volatile update_bits() in cache-only mode 2026-05-28T14:15:46+00:00 bui duc phuc phucduc.bui@gmail.com 2026-05-28T05:32:04+00:00 006c66d1d52f1905e6ccfb615cf27235e4e6e745 Prevent _regmap_update_bits() from accessing hardware when the register map is in cache-only mode. Unlike regmap_raw_read() and _regmap_read(), the volatile _regmap_update_bits() fast path bypasses the cache_only check. This can result in unexpected hardware accesses while the device is suspended. Return -EBUSY to ensure behavior is consistent with other cache-only access paths. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260528053204.46783-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Prevent _regmap_update_bits() from accessing hardware when the register
map is in cache-only mode.

Unlike regmap_raw_read() and _regmap_read(), the volatile
_regmap_update_bits() fast path bypasses the cache_only check. This can
result in unexpected hardware accesses while the device is suspended.

Return -EBUSY to ensure behavior is consistent with other cache-only
access paths.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260528053204.46783-1-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16 2026-05-21T08:47:39+00:00 Nishanth Sampath Kumar nissampa@cisco.com 2026-05-20T15:11:09+00:00 34808ac8ddafc3e2c2a59e84eaab0a410e7a0fdc i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16() returns __le16 (a sparse-restricted endian type), causing: drivers/base/regmap/regmap-i2c.c:340: sparse: incorrect type in argument 3 (different base types) expected unsigned short [usertype] value got restricted __le16 [usertype] SMBus already defines byte ordering internally, so cpu_to_le16() is wrong here. Replace it with a plain (u16) cast. Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/ Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com> Signed-off-by: Mark Brown <broonie@kernel.org> 
i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16()
returns __le16 (a sparse-restricted endian type), causing:

  drivers/base/regmap/regmap-i2c.c:340: sparse: incorrect type in
  argument 3 (different base types)
    expected unsigned short [usertype] value
    got restricted __le16 [usertype]

SMBus already defines byte ordering internally, so cpu_to_le16() is
wrong here. Replace it with a plain (u16) cast.

Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/
Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: sdw-mbq: Fix spelling mistake "undeferable" -> "undeferrable" 2026-04-26T21:48:16+00:00 Colin Ian King colin.i.king@gmail.com 2026-04-24T11:24:25+00:00 4b7774eeab8d66c22f02f5c120602df154a87e12 There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260424112425.32129-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
There is a spelling mistake in a dev_warn message. Fix it.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://patch.msgid.link/20260424112425.32129-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>