[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1510010826450.21737@jring-w510-7m3g.gridpoint.com>
Date: Thu, 1 Oct 2015 08:29:19 -0400 (EDT)
From: Jon Ringle <jon@...gle.org>
To: Mark Brown <broonie@...nel.org>
cc: jon@...gle.org, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits
function
On Thu, 1 Oct 2015, Mark Brown wrote:
> On Thu, Oct 01, 2015 at 02:33:06AM -0400, jon@...gle.org wrote:
>
> > @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, unsigned int reg,
> > int ret;
> > unsigned int tmp, orig;
> >
> > + if (map->reg_update_bits)
> > + return map->reg_update_bits(map->bus_context, reg, mask, val,
> > + change, force_write);
> > +
> > ret = _regmap_read(map, reg, &orig);
> > if (ret != 0)
> > return ret;
>
> This completely bypasses and therefore breaks the cache infrastructure.
>
Hi Mark,
Right after sending the v2 patch, I realized that calling the
custom reg_update_bits would only be applicable for registers that are
marked as volatile. Would the following solution be acceptable (it would
also simplify the regmap_update_bits in the encx24j600 driver):
if (regmap_volatile(map, reg) && map->reg_update_bits) {
return map->reg_update_bits(map->bus_context, reg, mask,
val, change, force_write);
The cache state should not matter for volatile registers, right?
-Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists