linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
@ 2015-10-05 13:29 jon
  2015-10-05 13:29 ` [PATCH 2/2] net: encx24j600: Simplified regmap_encx24j600_reg_update_bits() jon
  2015-10-05 14:57 ` [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile Mark Brown
  0 siblings, 2 replies; 10+ messages in thread
From: jon @ 2015-10-05 13:29 UTC (permalink / raw)
  To: broonie, gregkh, linux-kernel, netdev; +Cc: Jon Ringle

From: Jon Ringle <jringle@gridpoint.com>

The only time that it makes sense to call a custom provided reg_update_bits
function, is the register being updated is one that has volatile bits.
Otherwise, the normal read/modify/write cycle (where the read is likely to
be free from the cache) will do just fine. This should keep the reg cache
intact, since volatile registers won't get cached anyway.

Signed-off-by: Jon Ringle <jringle@gridpoint.com>
---

This patch is being submitted because
"[PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function"
was applied to net-next prematurely (there was a v3 patch out for review).

This is a diff between the v2 and v3.

Thanks,

Jon

 drivers/base/regmap/internal.h |  3 +--
 drivers/base/regmap/regmap.c   | 48 +++++++++++++-----------------------------
 include/linux/regmap.h         |  3 +--
 3 files changed, 17 insertions(+), 37 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 4036d7a..628ad7a 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -99,8 +99,7 @@ struct regmap {
 	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 *change, bool force_write);
+			       unsigned int mask, unsigned int val);
 
 	bool defer_caching;
 
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 70387c9..8cd155a 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2510,44 +2510,26 @@ static int _regmap_update_bits(struct regmap *map, unsigned int reg,
 	int ret;
 	unsigned int tmp, orig;
 
-	if (map->reg_update_bits) {
-		ret = map->reg_update_bits(map->bus_context, reg, mask, val,
-					   change, force_write);
+	if (change)
+		*change = false;
+
+	if (regmap_volatile(map, reg) && map->reg_update_bits) {
+		ret = map->reg_update_bits(map->bus_context, reg, mask, val);
+		if (ret == 0 && change)
+			*change = true;
+	} else {
+		ret = _regmap_read(map, reg, &orig);
 		if (ret != 0)
 			return ret;
 
-		/* Fix up the cache by read/modify/write */
-		if (!map->cache_bypass && !map->defer_caching) {
-			ret = regcache_read(map, reg, &orig);
-			if (ret != 0)
-				return ret;
+		tmp = orig & ~mask;
+		tmp |= val & mask;
 
-			tmp = orig & ~mask;
-			tmp |= val & mask;
-
-			ret = regcache_write(map, reg, tmp);
-			if (ret != 0)
-				return ret;
-			if (map->cache_only)
-				map->cache_dirty = true;
+		if (force_write || (tmp != orig)) {
+			ret = _regmap_write(map, reg, tmp);
+			if (ret == 0 && change)
+				*change = true;
 		}
-		return ret;
-	}
-
-	ret = _regmap_read(map, reg, &orig);
-	if (ret != 0)
-		return ret;
-
-	tmp = orig & ~mask;
-	tmp |= val & mask;
-
-	if (force_write || (tmp != orig)) {
-		ret = _regmap_write(map, reg, tmp);
-		if (change)
-			*change = true;
-	} else {
-		if (change)
-			*change = false;
 	}
 
 	return ret;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 4d3a3b1..b49d413 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -297,8 +297,7 @@ typedef int (*regmap_hw_reg_read)(void *context, unsigned int reg,
 typedef int (*regmap_hw_reg_write)(void *context, unsigned int reg,
 				   unsigned int val);
 typedef int (*regmap_hw_reg_update_bits)(void *context, unsigned int reg,
-					 unsigned int mask, unsigned int val,
-					 bool *change, bool force_write);
+					 unsigned int mask, unsigned int val);
 typedef struct regmap_async *(*regmap_hw_async_alloc)(void);
 typedef void (*regmap_hw_free_context)(void *context);
 
-- 
2.4.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 2/2] net: encx24j600: Simplified regmap_encx24j600_reg_update_bits()
  2015-10-05 13:29 [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile jon
@ 2015-10-05 13:29 ` jon
  2015-10-05 14:57 ` [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile Mark Brown
  1 sibling, 0 replies; 10+ messages in thread
From: jon @ 2015-10-05 13:29 UTC (permalink / raw)
  To: broonie, gregkh, linux-kernel, netdev; +Cc: Jon Ringle

From: Jon Ringle <jringle@gridpoint.com>

The changes to _regmap_update_bits() to call a custom reg_update_bits()
function simplify the function signature and also don't need to deal with
registers that can't individual bit updates via the hardware. The normal
flow of _regmap_update_bits() will take care of doing read/modify/write
cycle for any register not marked as volatile.

Signed-off-by: Jon Ringle <jringle@gridpoint.com>
---

This patch is being submitted because
"[PATCH net-next v3 2/2] net: Microchip encx24j600 driver"
was applied to net-next prematurely (there was a v3 patch out for review).

This is a diff between the v2 and v3.

Thanks,

Jon

 drivers/net/ethernet/microchip/encx24j600-regmap.c | 56 ++++------------------
 1 file changed, 9 insertions(+), 47 deletions(-)

diff --git a/drivers/net/ethernet/microchip/encx24j600-regmap.c b/drivers/net/ethernet/microchip/encx24j600-regmap.c
index f1d74e3..f3bb905 100644
--- a/drivers/net/ethernet/microchip/encx24j600-regmap.c
+++ b/drivers/net/ethernet/microchip/encx24j600-regmap.c
@@ -191,8 +191,7 @@ static int regmap_encx24j600_sfr_clr_bits(struct encx24j600_context *ctx,
 
 static int regmap_encx24j600_reg_update_bits(void *context, unsigned int reg,
 					     unsigned int mask,
-					     unsigned int val, bool *change,
-					     bool force_write)
+					     unsigned int val)
 {
 	struct encx24j600_context *ctx = context;
 
@@ -200,61 +199,24 @@ static int regmap_encx24j600_reg_update_bits(void *context, unsigned int reg,
 	unsigned int set_mask = mask & val;
 	unsigned int clr_mask = mask & ~val;
 
-	if (change)
-		*change = false;
-
-	if ((reg >= 0x40 && reg < 0x6c) || reg >= 0x80) {
-		/* Must do read/modify/write cycles for
-		 * MAC/MII regs or Unbanked SFR regs
-		 */
-		u16 tmp, orig;
-
-		ret = regmap_encx24j600_sfr_read(context, reg, (u8 *)&orig,
-						 sizeof(orig));
-		if (ret != 0)
-			return ret;
-
-		tmp = orig & ~mask;
-		tmp |= val & mask;
-
-		if (force_write || (tmp != orig)) {
-			ret = regmap_encx24j600_sfr_write(context, reg,
-							  (u8 *)&tmp,
-							  sizeof(tmp));
-			if (change)
-				*change = true;
-		} else if (change) {
-			*change = false;
-		}
-
-		return ret;
-	}
+	if ((reg >= 0x40 && reg < 0x6c) || reg >= 0x80)
+		return -EINVAL;
 
-	if (set_mask & 0xff) {
+	if (set_mask & 0xff)
 		ret = regmap_encx24j600_sfr_set_bits(ctx, reg, set_mask);
-		if (ret == 0 && change)
-			*change = true;
-	}
+
 	set_mask = (set_mask & 0xff00) >> 8;
 
-	if ((set_mask & 0xff) && (ret == 0)) {
+	if ((set_mask & 0xff) && (ret == 0))
 		ret = regmap_encx24j600_sfr_set_bits(ctx, reg + 1, set_mask);
-		if (ret == 0 && change)
-			*change = true;
-	}
 
-	if ((clr_mask & 0xff) && (ret == 0)) {
+	if ((clr_mask & 0xff) && (ret == 0))
 		ret = regmap_encx24j600_sfr_clr_bits(ctx, reg, clr_mask);
-		if (ret == 0 && change)
-			*change = true;
-	}
+
 	clr_mask = (clr_mask & 0xff00) >> 8;
 
-	if ((clr_mask & 0xff) && (ret == 0)) {
+	if ((clr_mask & 0xff) && (ret == 0))
 		ret = regmap_encx24j600_sfr_clr_bits(ctx, reg + 1, clr_mask);
-		if (ret == 0 && change)
-			*change = true;
-	}
 
 	return ret;
 }
-- 
2.4.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-05 13:29 [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile jon
  2015-10-05 13:29 ` [PATCH 2/2] net: encx24j600: Simplified regmap_encx24j600_reg_update_bits() jon
@ 2015-10-05 14:57 ` Mark Brown
  2015-10-06  6:29   ` David Miller
  1 sibling, 1 reply; 10+ messages in thread
From: Mark Brown @ 2015-10-05 14:57 UTC (permalink / raw)
  To: jon; +Cc: gregkh, linux-kernel, netdev, Jon Ringle

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Mon, Oct 05, 2015 at 09:29:31AM -0400, jon@ringle.org wrote:
> From: Jon Ringle <jringle@gridpoint.com>
> 
> The only time that it makes sense to call a custom provided reg_update_bits
> function, is the register being updated is one that has volatile bits.
> Otherwise, the normal read/modify/write cycle (where the read is likely to
> be free from the cache) will do just fine. This should keep the reg cache
> intact, since volatile registers won't get cached anyway.

Dave, to be clear please do *not* apply this patch at least for the time
being - I've not reviewed it or the one from Thursday that you applied
this morning.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-05 14:57 ` [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile Mark Brown
@ 2015-10-06  6:29   ` David Miller
  2015-10-06 10:13     ` Mark Brown
  0 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2015-10-06  6:29 UTC (permalink / raw)
  To: broonie; +Cc: jon, gregkh, linux-kernel, netdev, jringle

From: Mark Brown <broonie@kernel.org>
Date: Mon, 5 Oct 2015 15:57:22 +0100

> On Mon, Oct 05, 2015 at 09:29:31AM -0400, jon@ringle.org wrote:
>> From: Jon Ringle <jringle@gridpoint.com>
>> 
>> The only time that it makes sense to call a custom provided reg_update_bits
>> function, is the register being updated is one that has volatile bits.
>> Otherwise, the normal read/modify/write cycle (where the read is likely to
>> be free from the cache) will do just fine. This should keep the reg cache
>> intact, since volatile registers won't get cached anyway.
> 
> Dave, to be clear please do *not* apply this patch at least for the time
> being - I've not reviewed it or the one from Thursday that you applied
> this morning.

It's applied, it's pushed out to my tree, and therefore this will need to
be fixed up with a relative patch of some sort.

What you don't seem to understand is that my GIT tree is never rebased
or mangled because many people depend upon it.  So once a patch is
applied, that commit lives on forever.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06  6:29   ` David Miller
@ 2015-10-06 10:13     ` Mark Brown
  2015-10-06 12:50       ` Jon Ringle
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Brown @ 2015-10-06 10:13 UTC (permalink / raw)
  To: David Miller; +Cc: jon, gregkh, linux-kernel, netdev, jringle

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote:
> From: Mark Brown <broonie@kernel.org>

> > Dave, to be clear please do *not* apply this patch at least for the time
> > being - I've not reviewed it or the one from Thursday that you applied
> > this morning.

> It's applied, it's pushed out to my tree, and therefore this will need to
> be fixed up with a relative patch of some sort.

This appears to be an incremental change, not the initial commit which
you already applied.  I'm asking you to stop applying changes to regmap
which have not been reviewed.

> What you don't seem to understand is that my GIT tree is never rebased
> or mangled because many people depend upon it.  So once a patch is
> applied, that commit lives on forever.

I'm not *so* concerned if the patch lives in history, I'm concerned with
having something I can sensibly review and ideally getting the code into
my tree.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06 10:13     ` Mark Brown
@ 2015-10-06 12:50       ` Jon Ringle
  2015-10-06 13:25         ` David Miller
                           ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Jon Ringle @ 2015-10-06 12:50 UTC (permalink / raw)
  To: Mark Brown; +Cc: David Miller, jon, gregkh, linux-kernel, netdev, jringle


> On Oct 6, 2015, at 6:13 AM, Mark Brown <broonie@kernel.org> wrote:
> 
>> On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote:
>> From: Mark Brown <broonie@kernel.org>
> 
>>> Dave, to be clear please do *not* apply this patch at least for the time
>>> being - I've not reviewed it or the one from Thursday that you applied
>>> this morning.
> 
>> It's applied, it's pushed out to my tree, and therefore this will need to
>> be fixed up with a relative patch of some sort.
> 
> This appears to be an incremental change, not the initial commit which
> you already applied.  I'm asking you to stop applying changes to regmap
> which have not been reviewed.
> 
>> What you don't seem to understand is that my GIT tree is never rebased
>> or mangled because many people depend upon it.  So once a patch is
>> applied, that commit lives on forever.
> 
> I'm not *so* concerned if the patch lives in history, I'm concerned with
> having something I can sensibly review and ideally getting the code into
> my tree.

I would suggest the following course of action:

1) David, revert the following from net-next:
$ git revert 9886ce2b9d4e5a8bb3d78d0f7eff3c0f1ed58d67
$ git revert 04fbfce7a222327b97ca165294ef19f0faa45960
$ git revert 7741c373cf3ea1f5383fa97fb7a640a429d3dd7c

2) Mark, please use the patch titled "[PATCH net-next v3 1/2] regmap:
Allow installing custom". It will apply cleanly to the regmap for-next
branch
3) Once Mark has accepted this patch into the regmap tree, I will make
any adjustments needed to the net-next patch.
4) David should then merge the regmap for-next branch into net-next
5) I will submit a new patch to net-next for the encx24j600 driver
that should build against the regmap changes

Sound like a good plan?

-Jon

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06 12:50       ` Jon Ringle
@ 2015-10-06 13:25         ` David Miller
  2015-10-06 14:31           ` Mark Brown
  2015-10-06 13:26         ` David Miller
  2015-10-06 13:37         ` Mark Brown
  2 siblings, 1 reply; 10+ messages in thread
From: David Miller @ 2015-10-06 13:25 UTC (permalink / raw)
  To: jonringle; +Cc: broonie, jon, gregkh, linux-kernel, netdev, jringle

From: Jon Ringle <jonringle@gmail.com>
Date: Tue, 6 Oct 2015 08:50:43 -0400

> 4) David should then merge the regmap for-next branch into net-next

Nope, this doesn't work at all.

It is my tree which people depend upon, not the other way around.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06 12:50       ` Jon Ringle
  2015-10-06 13:25         ` David Miller
@ 2015-10-06 13:26         ` David Miller
  2015-10-06 13:37         ` Mark Brown
  2 siblings, 0 replies; 10+ messages in thread
From: David Miller @ 2015-10-06 13:26 UTC (permalink / raw)
  To: jonringle; +Cc: broonie, jon, gregkh, linux-kernel, netdev, jringle

From: Jon Ringle <jonringle@gmail.com>
Date: Tue, 6 Oct 2015 08:50:43 -0400

> 1) David, revert the following from net-next:
> $ git revert 9886ce2b9d4e5a8bb3d78d0f7eff3c0f1ed58d67
> $ git revert 04fbfce7a222327b97ca165294ef19f0faa45960
> $ git revert 7741c373cf3ea1f5383fa97fb7a640a429d3dd7c

Applied, thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06 12:50       ` Jon Ringle
  2015-10-06 13:25         ` David Miller
  2015-10-06 13:26         ` David Miller
@ 2015-10-06 13:37         ` Mark Brown
  2 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2015-10-06 13:37 UTC (permalink / raw)
  To: Jon Ringle; +Cc: David Miller, jon, gregkh, linux-kernel, netdev, jringle

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Tue, Oct 06, 2015 at 08:50:43AM -0400, Jon Ringle wrote:

> 4) David should then merge the regmap for-next branch into net-next

What I generally do (and what's best practice in general for cross tree
work) is apply patches on topic branches and then create a signed tag
for anything that's being merged into another tree.  That both means
we've got a signed tag for the chain of trust in the code and means that
only the specific dependency gets pulled into other trees rather than
everything that's queued.  Minimising what's pulled in makes pull
requests look cleaner and avoids noise from in development code
appearing in other trees (eg, any bugs in other code that's not quite
ready won't get merged).

In my specific trees nobody should ever merge my for-FOO branches,
they're rebuilt frequently - the topic branches are fast forward only
and intended for that (though like I say a signed tag is best).  Linus
complains about keeping the for-FOO branches fast forward
only.

> 5) I will submit a new patch to net-next for the encx24j600 driver
> that should build against the regmap changes

> Sound like a good plan?

Makes sense to me modulo the signed tag thing above.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
  2015-10-06 13:25         ` David Miller
@ 2015-10-06 14:31           ` Mark Brown
  0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2015-10-06 14:31 UTC (permalink / raw)
  To: David Miller; +Cc: jonringle, jon, gregkh, linux-kernel, netdev, jringle

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Tue, Oct 06, 2015 at 06:25:08AM -0700, David Miller wrote:

> > 4) David should then merge the regmap for-next branch into net-next

> Nope, this doesn't work at all.

> It is my tree which people depend upon, not the other way around.

Yes, it does work - this is the way we normally handle cross tree
issues.  There is nothing about pulling code from other trees into your
tree which will stop other people depending on your tree, obviously
anything you merge in needs to stay fast forward only and ideally not
make any resulting pull requests look terrible but that's really the
only restriction.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-10-06 14:32 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-05 13:29 [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile jon
2015-10-05 13:29 ` [PATCH 2/2] net: encx24j600: Simplified regmap_encx24j600_reg_update_bits() jon
2015-10-05 14:57 ` [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile Mark Brown
2015-10-06  6:29   ` David Miller
2015-10-06 10:13     ` Mark Brown
2015-10-06 12:50       ` Jon Ringle
2015-10-06 13:25         ` David Miller
2015-10-06 14:31           ` Mark Brown
2015-10-06 13:26         ` David Miller
2015-10-06 13:37         ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).