On 15/02/16 15:02, Mark Brown wrote: > On Sun, Feb 14, 2016 at 06:40:15PM +0100, Lars-Peter Clausen wrote: >> On 02/14/2016 04:02 PM, Jonathan Cameron wrote: > >>> I'm lost here. Why should changing the storage of the register cache result >>> in different behaviour other than in efficiency of access to cached values? > >> And if there is really a difference this should probably be addressed at the >> regmap level. > > You'd need to make regcache-flat keep track of which cache values are > valid either during init (in which case it'd have to read every other > register at that time) or at runtime (which would mean extra operations > in a fast path). Flat really is special here, there's no reason to use > it over a rbtree other than being very sensitive about performance. > > Please also be aware that if you CC me on an iio patch series there's a > good chance I'll just delete it without reading it, for some reason I > keep on getting copied on lots of them which have no relevance to me > that I'm able to identify. > Hmm. Not the best documented 'non intuitive case' ever, but fair enough. Glad you did pick this one up Mark! So Matt, the reason those two elements are dropped from being volatile is that they never were, but because we were using a flat cache it wasn't getting the original values? If so fair enough I suppose, but please confirm that I've understood this correctly + I'll probably expand the patch description somewhat to make it clearer why the original was wrong. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
