Skip to contentSkip to conversation

regmap: allow to define reg_update_bits for no bus configuration

PATCH RESEND In review Ansuel Smith 2 participants 4 messages Nov 11, 2021

Subsystems (2)

v1 of 2 In review Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH RESEND 1/1 regmap: allow to define reg_update_bits for no bus configuration

Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a special function in regmap_config for reg_update_bits as we do with the bus config and append it to the regmap_volatile logic in _regmap_update_bits.

---
 drivers/base/regmap/regmap.c | 3 ++-
 include/linux/regmap.h       | 7 +++++++
 2 files changed, 9 insertions(+), 1 deletion(-)
drivers/base/regmap/regmap.c +2 -1
index 21a0c2562ec0..d6fcb45194b0 100644
@@ -876,6 +876,7 @@ struct regmap *__regmap_init(struct device *dev,
 	if (!bus) {
 		map->reg_read  = config->reg_read;
 		map->reg_write = config->reg_write;
+		map->reg_update_bits = config->reg_update_bits;
 
 		map->defer_caching = false;
 		goto skip_format_initialization;
@@ -3064,7 +3065,7 @@ static int _regmap_update_bits(struct regmap *map, unsigned int reg,
 	if (change)
 		*change = false;
 
-	if (regmap_volatile(map, reg) && map->reg_update_bits) {
+	if ((regmap_volatile(map, reg) || !map->bus) && map->reg_update_bits) {
 		ret = map->reg_update_bits(map->bus_context, reg, mask, val);
 		if (ret == 0 && change)
 			*change = true;
include/linux/regmap.h +7 -0
index e3c9a25a853a..22652e5fbc38 100644
@@ -290,6 +290,11 @@ typedef void (*regmap_unlock)(void *);
  *		  read operation on a bus such as SPI, I2C, etc. Most of the
  *		  devices do not need this.
  * @reg_write:	  Same as above for writing.
+ * @reg_update_bits: Optional callback that if filled will be used to perform
+ *		     all the update_bits(rmw) operation. Should only be provided
+ *		     if the function require special handling with lock and reg
+ *		     handling and the operation cannot be represented as a simple
+ *		     update_bits operation on a bus such as SPI, I2C, etc.
  * @fast_io:	  Register IO is fast. Use a spinlock instead of a mutex
  *	     	  to perform locking. This field is ignored if custom lock/unlock
  *	     	  functions are used (see fields lock/unlock of struct regmap_config).
@@ -372,6 +377,8 @@ struct regmap_config {
 
 	int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
 	int (*reg_write)(void *context, unsigned int reg, unsigned int val);
+	int (*reg_update_bits)(void *context, unsigned int reg,
+			       unsigned int mask, unsigned int val);
 
 	bool fast_io;
 
Signature · 1 line
2.32.0
maintainer
#1 lore raw
Quoted 3 lines · Ansuel Smith

Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations.

Please allow a reasonable time for review and remember that it's the merge window right now so no new patches are being applied.

#2 lore raw
Quoted 7 lines · Mark Brown
Quoted 3 lines · Ansuel Smith

Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations.

Please allow a reasonable time for review and remember that it's the merge window right now so no new patches are being applied.

I'm so sorry. I had some problem last time with sending v2 that got rejected automatically by patchwork and I thought it was the same for this. Again sorry.

Signature · 1 line
	Ansuel
maintainer
#3 lore raw
Quoted 8 lines · Ansuel Smith
Quoted 2 lines · Mark Brown

Please allow a reasonable time for review and remember that it's the merge window right now so no new patches are being applied.

I'm so sorry. I had some problem last time with sending v2 that got rejected automatically by patchwork and I thought it was the same for this. Again sorry.

The patchwork instance for LKML is now read only (at some point it might even get converted to just point at the threads in lore automatically IIRC) - nothing new is being added.