Re: regcache_sync() errors for read-only registers cache

[Takashi Iwai]

At Tue, 3 Mar 2015 09:09:29 +0000,
Mark Brown wrote:
> 
> On Mon, Mar 02, 2015 at 08:15:23PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > Please don't bury patches in the middle of mails, that just means that
> > > if the patch is useful it's painful to apply.
> 
> > The --scissors option of git am is your friend.
> 
> That's still pain.

But it's still better than sending two mails even if you don't know
whether it's the right patch.  It's even not tag as an RFC.  The patch
was there just as a reference.

> > > Your patch seems fine but
> > > can you please resend in a directly applyable format unless something in
> > > the below indicates against that...
> 
> > Hm, so do you think that my patch is the best way to fix?  I wasn't
> > sure about it, that's why I wrote in that style.
> 
> Well, it's either that or adding the values read back from the chip to
> the defaults.

For fixing the single rw, it's easy in either way (although the latter
sounds bad from the performance POV).  But what about the block rw?

> > > > Also, _regmap_write() itself calls again regmap_writeable(), so it's
> > > > superfluous.  Alternatively, we may check -EIO from _regmap_write()
> > > > and treat as a special case not to show the error.  Or, add a
> > > > parameter to skip regmap_writeable() call.
> 
> > > I'm sorry but I can't parse the above - what is "it" in this context?
> 
> > regmap_wrietable() call in _regmap_write().
> 
> It's superfluous with respect to what?  Still a bit confused, sorry.

regmap_writeable() is called twice in that code path with my patch.
First before calling _regmap_write() and again in _regmap_write().
The second call is superfluous in this code path although it's needed
for other paths.

regmap_writeable() isn't usually that heavy, but it's still
suboptimal.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/