On Thu, May 17, 2018 at 09:12:49AM +0200, Jorge Ramirez-Ortiz wrote: > On 05/13/2018 04:22 AM, Mark Brown wrote:
> > > So I dont see where/how your recommendation fits; maybe you could clarify > > > a > > > bit more please? > > As I've been saying if you explicitly need a write to happen don't use > > regmap_update_bits(), do something that guarantees you'll get a write > > like regmap_write() or regmap_write_bits(). > I do understand your point but Mark, that interface you mention sits above > the user request (as a client the user does not call regmap_update_bits or > regmap_write_bits or regmap_write(): none of those functions mean anything > to the foo_regmap definition below - that is why we have an interface). ... > and all this request means is that it expects foo_volatile_regs to be taken > into consideration when accessing the reg_write callback: so whoever is > calling the interface reg_write (be it regmap_update_bits or > regmap_write_bits or whoever it is, I dont know) must make sure the volatile > request applies. Right, but your code can expect a lot of things and not have them happen if they're not good expectations - that's explicitly not what we've been meaning by volatile registers (they're just registers that can't be cached). I mean, you mentioned that you were doing this for an ALSA control and since ALSA reports noop updates to userspace it'd be entirely reasonable for an implementation change there were to suppress the write before it gets to regmap (this is the sort of thing I was thinking of when I said I was suspicious of what you're doing there, this doesn't sound like a normal ALSA control). I get what you're saying, it just doesn't feel like this is the right place to solve whatever your end use case is, it feels like it's going to be fragile one way or another and end up adding more complexity - having a hand coded ALSA control for this feels more secure at that level never mind anything that's going on in regmap.
Description: PGP signature