| Message ID | 1443699801-8888-1-git-send-email-jon@ringle.org |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: jon@ringle.org Date: Thu, 1 Oct 2015 07:43:20 -0400 > From: Jon Ringle <jringle@gridpoint.com> > > This commit allows installing a custom reg_update_bits function for cases where > the hardware provides a mechanism to set or clear register bits without a > read/modify/write cycle. Such is the case with the Microchip ENCX24J600. > > Signed-off-by: Jon Ringle <jringle@gridpoint.com> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 5 Oct 2015, David Miller wrote: > From: jon@ringle.org > Date: Thu, 1 Oct 2015 07:43:20 -0400 > > > From: Jon Ringle <jringle@gridpoint.com> > > > > This commit allows installing a custom reg_update_bits function for cases where > > the hardware provides a mechanism to set or clear register bits without a > > read/modify/write cycle. Such is the case with the Microchip ENCX24J600. > > > > Signed-off-by: Jon Ringle <jringle@gridpoint.com> > > Applied. Thanks David. However, I've sent a v3 patch, and also expecting feedback from Mark Brown on the regmap portion of it. -Jon -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jon Ringle <jon@ringle.org> Date: Mon, 5 Oct 2015 07:57:00 -0400 (EDT) > > > On Mon, 5 Oct 2015, David Miller wrote: > >> From: jon@ringle.org >> Date: Thu, 1 Oct 2015 07:43:20 -0400 >> >> > From: Jon Ringle <jringle@gridpoint.com> >> > >> > This commit allows installing a custom reg_update_bits function for cases where >> > the hardware provides a mechanism to set or clear register bits without a >> > read/modify/write cycle. Such is the case with the Microchip ENCX24J600. >> > >> > Signed-off-by: Jon Ringle <jringle@gridpoint.com> >> >> Applied. > > Thanks David. However, I've sent a v3 patch, and also expecting feedback > from Mark Brown on the regmap portion of it. Please send me relative changes from v2 to v3, thanks. Sorry about that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 05, 2015 at 06:16:09AM -0700, David Miller wrote: > >> Applied. > > Thanks David. However, I've sent a v3 patch, and also expecting feedback > > from Mark Brown on the regmap portion of it. > Please send me relative changes from v2 to v3, thanks. > Sorry about that. Ugh, this is a mess :( Can you please drop this patch instead?
From: Mark Brown <broonie@kernel.org> Date: Mon, 5 Oct 2015 15:25:31 +0100 > On Mon, Oct 05, 2015 at 06:16:09AM -0700, David Miller wrote: > >> >> Applied. > >> > Thanks David. However, I've sent a v3 patch, and also expecting feedback >> > from Mark Brown on the regmap portion of it. > >> Please send me relative changes from v2 to v3, thanks. > >> Sorry about that. > > Ugh, this is a mess :( Can you please drop this patch instead? I can't just "drop" changes. Once a commit hits my tree it is part of the permanent record. The easiest thing to do is to send a relative fix, and that's why I have asked for exactly that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 05, 2015 at 11:21:48PM -0700, David Miller wrote: > > Ugh, this is a mess :( Can you please drop this patch instead? > I can't just "drop" changes. Once a commit hits my tree it is part > of the permanent record. I was expecting a revert if you want to keep the branch fast forward only. > The easiest thing to do is to send a relative fix, and that's why > I have asked for exactly that. This isn't very good for reviewing the API change, and of course I'd also expect this change to be in the regmap tree so we can work on regmap without collisions, I obviously can't just merge in net-next. I was thinking about making some further changes on top of this and it *is* fiddling about in the core. Jon, please send me a patch against the regmap tree for review while we work out how to sort out this mess.
From: Mark Brown <broonie@kernel.org> Date: Tue, 6 Oct 2015 10:57:15 +0100 > I obviously can't just merge in net-next. People do this all the time, when needed. My history never changes, and the networking tree is one of the first trees pulled into linux-next, so this is always safe. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 06, 2015 at 06:22:08AM -0700, David Miller wrote: > Date: Tue, 6 Oct 2015 10:57:15 +0100 > > I obviously can't just merge in net-next. > People do this all the time, when needed. My history never changes, > and the networking tree is one of the first trees pulled into > linux-next, so this is always safe. Which would then make working with my tree annoying (I get net stuff showing up in my diffs and logs) and gets in the way for sending pull requests before Linus starts merging stuff which I tend to do.
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h index cc55788..4036d7a 100644 --- a/drivers/base/regmap/internal.h +++ b/drivers/base/regmap/internal.h @@ -98,6 +98,9 @@ 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); bool defer_caching; diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index afaf562..70387c9 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -619,6 +619,7 @@ struct regmap *__regmap_init(struct device *dev, goto skip_format_initialization; } else { map->reg_read = _regmap_bus_read; + map->reg_update_bits = bus->reg_update_bits; } reg_endian = regmap_get_reg_endian(bus, config); @@ -2509,6 +2510,30 @@ 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 (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; + + ret = regcache_write(map, reg, tmp); + if (ret != 0) + return ret; + if (map->cache_only) + map->cache_dirty = true; + } + return ret; + } + ret = _regmap_read(map, reg, &orig); if (ret != 0) return ret; diff --git a/include/linux/regmap.h b/include/linux/regmap.h index 8fc0bfd..4d3a3b1 100644 --- a/include/linux/regmap.h +++ b/include/linux/regmap.h @@ -296,6 +296,9 @@ typedef int (*regmap_hw_reg_read)(void *context, unsigned int reg, unsigned int *val); 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); typedef struct regmap_async *(*regmap_hw_async_alloc)(void); typedef void (*regmap_hw_free_context)(void *context); @@ -335,6 +338,7 @@ struct regmap_bus { regmap_hw_gather_write gather_write; regmap_hw_async_write async_write; regmap_hw_reg_write reg_write; + regmap_hw_reg_update_bits reg_update_bits; regmap_hw_read read; regmap_hw_reg_read reg_read; regmap_hw_free_context free_context;