linux-stable.git/drivers/base/regmap, branch linux-6.10.y Linux kernel stable tree regmap: maple: work around gcc-14.1 false-positive warning 2024-09-12T09:13:03+00:00 Arnd Bergmann arnd@arndb.de 2024-07-19T10:40:24+00:00 66a490d7c5dd7935038147e2aa0913feeb5aeab3 [ Upstream commit 542440fd7b30983cae23e32bd22f69a076ec7ef4 ] With gcc-14.1, there is a false-postive -Wuninitialized warning in regcache_maple_drop: drivers/base/regmap/regcache-maple.c: In function 'regcache_maple_drop': drivers/base/regmap/regcache-maple.c:113:23: error: 'lower_index' is used uninitialized [-Werror=uninitialized] 113 | unsigned long lower_index, lower_last; | ^~~~~~~~~~~ drivers/base/regmap/regcache-maple.c:113:36: error: 'lower_last' is used uninitialized [-Werror=uninitialized] 113 | unsigned long lower_index, lower_last; | ^~~~~~~~~~ I've created a reduced test case to see if this needs to be reported as a gcc, but it appears that the gcc-14.x branch already has a change that turns this into a more sensible -Wmaybe-uninitialized warning, so I ended up not reporting it so far. The reduced test case also produces a warning for gcc-13 and gcc-12 but I don't see that with the version in the kernel. Link: https://godbolt.org/z/oKbohKqd3 Link: https://lore.kernel.org/all/CAMuHMdWj=FLmkazPbYKPevDrcym2_HDb_U7Mb9YE9ovrP0jJfA@mail.gmail.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20240719104030.1382465-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 542440fd7b30983cae23e32bd22f69a076ec7ef4 ]

With gcc-14.1, there is a false-postive -Wuninitialized warning in
regcache_maple_drop:

drivers/base/regmap/regcache-maple.c: In function 'regcache_maple_drop':
drivers/base/regmap/regcache-maple.c:113:23: error: 'lower_index' is used uninitialized [-Werror=uninitialized]
  113 |         unsigned long lower_index, lower_last;
      |                       ^~~~~~~~~~~
drivers/base/regmap/regcache-maple.c:113:36: error: 'lower_last' is used uninitialized [-Werror=uninitialized]
  113 |         unsigned long lower_index, lower_last;
      |                                    ^~~~~~~~~~

I've created a reduced test case to see if this needs to be reported
as a gcc, but it appears that the gcc-14.x branch already has a change
that turns this into a more sensible -Wmaybe-uninitialized warning, so
I ended up not reporting it so far.

The reduced test case also produces a warning for gcc-13 and gcc-12
but I don't see that with the version in the kernel.

Link: https://godbolt.org/z/oKbohKqd3
Link: https://lore.kernel.org/all/CAMuHMdWj=FLmkazPbYKPevDrcym2_HDb_U7Mb9YE9ovrP0jJfA@mail.gmail.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20240719104030.1382465-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regmap: spi: Fix potential off-by-one when calculating reserved size 2024-09-08T05:56:35+00:00 Andy Shevchenko andy.shevchenko@gmail.com 2024-06-05T20:53:15+00:00 61e5929d10b81817176c38d0d49752b7933ff6b5 [ 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 <andy.shevchenko@gmail.com> Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <andy.shevchenko@gmail.com>
Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regmap: kunit: Fix memory leaks in gen_regmap() and gen_raw_regmap() 2024-08-14T13:34:05+00:00 Richard Fitzgerald rf@opensource.cirrus.com 2024-04-11T10:37:24+00:00 9a3f1490f9b2b7b4d484d032dd0f13296ad59e08 [ Upstream commit c3820641da87442251e0c00b6874ef1022da8f58 ] - Use kunit_kcalloc() to allocate the defaults table so that it will be freed when the test case ends. - kfree() the buf and *data buffers on the error paths. - Use kunit_add_action_or_reset() instead of kunit_add_action() so that if it fails it will call regmap_exit(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://msgid.link/r/20240411103724.54063-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c3820641da87442251e0c00b6874ef1022da8f58 ]

- Use kunit_kcalloc() to allocate the defaults table so that it will be
  freed when the test case ends.
- kfree() the buf and *data buffers on the error paths.
- Use kunit_add_action_or_reset() instead of kunit_add_action() so that
  if it fails it will call regmap_exit().

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240411103724.54063-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regmap-i2c: Subtract reg size from max_write 2024-05-27T00:30:33+00:00 Jim Wylder jwylder@google.com 2024-05-23T21:14:36+00:00 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 <jwylder@google.com> Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com Signed-off-by: Mark Brown <broonie@kernel.org> 
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 <jwylder@google.com>
Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'regmap-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap 2024-05-23T20:38:31+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-05-23T20:38:31+00:00 09f8f2c4ca4263b40f766238a92ef9c5f93ea5a5 Pull regmap fix from Mark Brown: "Guenter ran with memory sanitisers and found an issue in the new KUnit tests that Richard added where an assumption in older test code was exposed, this was fixed quickly by Richard" * tag 'regmap-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: kunit: Fix array overflow in stride() test 
Pull regmap fix from Mark Brown:
 "Guenter ran with memory sanitisers and found an issue in the new KUnit
  tests that Richard added where an assumption in older test code was
  exposed, this was fixed quickly by Richard"

* tag 'regmap-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: kunit: Fix array overflow in stride() test
tracing/treewide: Remove second parameter of __assign_str() 2024-05-23T00:14:47+00:00 Steven Rostedt (Google) rostedt@goodmis.org 2024-05-16T17:34:54+00:00 2c92ca849fcc6ee7d0c358e9959abc9f58661aea With the rework of how the __string() handles dynamic strings where it saves off the source string in field in the helper structure[1], the assignment of that value to the trace event field is stored in the helper value and does not need to be passed in again. This means that with: __string(field, mystring) Which use to be assigned with __assign_str(field, mystring), no longer needs the second parameter and it is unused. With this, __assign_str() will now only get a single parameter. There's over 700 users of __assign_str() and because coccinelle does not handle the TRACE_EVENT() macro I ended up using the following sed script: git grep -l __assign_str | while read a ; do sed -e 's/\(__assign_str([^,]*[^ ,]\) *,[^;]*/\1)/' $a > /tmp/test-file; mv /tmp/test-file $a; done I then searched for __assign_str() that did not end with ';' as those were multi line assignments that the sed script above would fail to catch. Note, the same updates will need to be done for: __assign_str_len() __assign_rel_str() __assign_rel_str_len() I tested this with both an allmodconfig and an allyesconfig (build only for both). [1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/ Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Christian König <christian.koenig@amd.com> for the amdgpu parts. Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> #for Acked-by: Rafael J. Wysocki <rafael@kernel.org> # for thermal Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Darrick J. Wong <djwong@kernel.org> # xfs Tested-by: Guenter Roeck <linux@roeck-us.net> 
With the rework of how the __string() handles dynamic strings where it
saves off the source string in field in the helper structure[1], the
assignment of that value to the trace event field is stored in the helper
value and does not need to be passed in again.

This means that with:

  __string(field, mystring)

Which use to be assigned with __assign_str(field, mystring), no longer
needs the second parameter and it is unused. With this, __assign_str()
will now only get a single parameter.

There's over 700 users of __assign_str() and because coccinelle does not
handle the TRACE_EVENT() macro I ended up using the following sed script:

  git grep -l __assign_str | while read a ; do
      sed -e 's/\(__assign_str([^,]*[^ ,]\) *,[^;]*/\1)/' $a > /tmp/test-file;
      mv /tmp/test-file $a;
  done

I then searched for __assign_str() that did not end with ';' as those
were multi line assignments that the sed script above would fail to catch.

Note, the same updates will need to be done for:

  __assign_str_len()
  __assign_rel_str()
  __assign_rel_str_len()

I tested this with both an allmodconfig and an allyesconfig (build only for both).

[1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/

Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home

Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Christian König <christian.koenig@amd.com> for the amdgpu parts.
Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> #for
Acked-by: Rafael J. Wysocki <rafael@kernel.org> # for thermal
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>	# xfs
Tested-by: Guenter Roeck <linux@roeck-us.net>
regmap: kunit: Fix array overflow in stride() test 2024-05-17T17:23:12+00:00 Richard Fitzgerald rf@opensource.cirrus.com 2024-05-17T14:47:03+00:00 7ba822189e6060a8a2833b721d430f833bf0db43 Force the max_register of the test regmap to be one register longer than the number of test registers, to prevent an array overflow in the test loop. The test defines num_reg_defaults = 6. With 6 registers and stride == 2 the valid register addresses would be 0, 2, 4, 6, 8, 10. However the loop checks attempting to access the odd address, so on the final register it accesses address 11, and it writes entry [11] of the read/written arrays. Originally this worked because the max_register of the regmap was hardcoded to be BLOCK_TEST_SIZE (== 12). commit 710915743d53 ("regmap: kunit: Run sparse cache tests at non-zero register addresses") introduced the ability to start the test address range from any address, which means adjusting the max_register. If max_register was not forced, it was calculated either from num_reg_defaults or BLOCK_TEST_SIZE. This correctly calculated that with num_reg_defaults == 6 and stride == 2 the final valid address is 10. So the read/written arrays are allocated to contain entries [0..10]. When stride attempted to access [11] it was overflowing the array. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 710915743d53 ("regmap: kunit: Run sparse cache tests at non-zero register addresses") Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://msgid.link/r/20240517144703.1200995-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Force the max_register of the test regmap to be one register longer
than the number of test registers, to prevent an array overflow in
the test loop.

The test defines num_reg_defaults = 6. With 6 registers and
stride == 2 the valid register addresses would be 0, 2, 4, 6, 8, 10.
However the loop checks attempting to access the odd address, so on
the final register it accesses address 11, and it writes entry [11]
of the read/written arrays.

Originally this worked because the max_register of the regmap was
hardcoded to be BLOCK_TEST_SIZE (== 12).

commit 710915743d53 ("regmap: kunit: Run sparse cache tests at non-zero
register addresses")
introduced the ability to start the test address range from any address,
which means adjusting the max_register. If max_register was not forced,
it was calculated either from num_reg_defaults or BLOCK_TEST_SIZE. This
correctly calculated that with num_reg_defaults == 6 and stride == 2 the
final valid address is 10. So the read/written arrays are allocated to
contain entries [0..10]. When stride attempted to access [11] it was
overflowing the array.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 710915743d53 ("regmap: kunit: Run sparse cache tests at non-zero register addresses")
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://msgid.link/r/20240517144703.1200995-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: kunit: Fix an NULL vs IS_ERR() check 2024-04-15T10:54:57+00:00 Dan Carpenter dan.carpenter@linaro.org 2024-04-15T10:34:54+00:00 991b5e2aad870828669ca105f424ef1b2534f820 The kunit_device_register() function returns error pointers, not NULL. Passing an error pointer to get_device() will lead to an Oops. Also get_device() returns the same device you passed to it. Fix it! ;) Fixes: 7b7982f14315 ("regmap: kunit: Create a struct device for the regmap") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/b32e80cf-b385-40cd-b8ec-77ec73e07530@moroto.mountain Signed-off-by: Mark Brown <broonie@kernel.org> 
The kunit_device_register() function returns error pointers, not NULL.
Passing an error pointer to get_device() will lead to an Oops.  Also
get_device() returns the same device you passed to it.  Fix it!  ;)

Fixes: 7b7982f14315 ("regmap: kunit: Create a struct device for the regmap")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/b32e80cf-b385-40cd-b8ec-77ec73e07530@moroto.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: spi: Add missing MODULE_DESCRIPTION() 2024-04-10T21:45:53+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2024-04-10T20:27:53+00:00 135cec6ba82ebffc0275c5228b4c4bf279fbf6f5 The modpost script is not happy WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-spi.o because there is a missing module description. Add it to the module. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://msgid.link/r/20240410202912.1659275-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The modpost script is not happy

  WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/base/regmap/regmap-spi.o

because there is a missing module description.

Add it to the module.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240410202912.1659275-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap: Drop capitalisation in MODULE_DESCRIPTION() 2024-04-10T21:45:52+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2024-04-10T20:27:52+00:00 c1ffff88750a697483eabb052004a937631720b6 'Regmap' should be spelled as 'regmap'. Update that. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://msgid.link/r/20240410202912.1659275-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
'Regmap' should be spelled as 'regmap'. Update that.

Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240410202912.1659275-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>