From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755331AbbCCJXF (ORCPT ); Tue, 3 Mar 2015 04:23:05 -0500 Received: from cantor2.suse.de ([195.135.220.15]:49698 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754966AbbCCJXC (ORCPT ); Tue, 3 Mar 2015 04:23:02 -0500 Date: Tue, 03 Mar 2015 10:22:59 +0100 Message-ID: From: Takashi Iwai To: Mark Brown Cc: linux-kernel@vger.kernel.org Subject: Re: regcache_sync() errors for read-only registers cache In-Reply-To: <20150303090929.GG21293@sirena.org.uk> References: <20150302182418.GD21293@sirena.org.uk> <20150303090929.GG21293@sirena.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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