[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YrNC3eHx7ARQy/Vd@sirena.org.uk>
Date: Wed, 22 Jun 2022 17:27:09 +0100
From: Mark Brown <broonie@...nel.org>
To: Dong Aisheng <dongas86@...il.com>
Cc: Aisheng Dong <aisheng.dong@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
Peng Fan <peng.fan@....com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>
Subject: Re: [PATCH RFC 1/2] regmap: add option to disable debugfs
On Thu, Jun 23, 2022 at 12:05:46AM +0800, Dong Aisheng wrote:
> On Wed, Jun 22, 2022 at 8:36 PM Mark Brown <broonie@...nel.org> wrote:
> > On Wed, Jun 22, 2022 at 06:12:49PM +0800, Dong Aisheng wrote:
> >
> > > NOTE: i didn't fix _regmap_write() as i.MX controls regmap write well in driver
> > > with power enabled first, so don't have issues in reality.
> > I can't tell what you think the problem is with _regmap_write()?
> Because from what I see, _regmap_write() seems still can write to HW
> register even with cache_only mode set theoretically.
Ah, I see - we don't enforce cache_only if bypass is enabled somehow,
but we will complain if you try to enable both at the same time so I'm
not sure that's an issue?
> > > - WARN_ON(map->cache_bypass && enable);
> > > +// WARN_ON(map->cache_bypass && enable);
> > What is the purpose of this change? Why would the combination of cache
> > only and bypass modes work be a good idea, and how should things behave
> > in that case?
> Because without this change, there will be a kernel dump caused by
> WARN_ON when drivers call regcache_cache_only(map, true) after power
> is off. There's no cache used in the imx blkctl driver. So map->cache_bypass
> is default to true.
cache_bypass is only going to be true if something enabled bypass, why
would a device that doesn't use a cache enable bypass? It does get
turned on transiently by things like patching but those only make sense
if the device can be accessed so caceh_only shouldn't be on then.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists