From: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: patches@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] regmap: make REGCACHE_NONE maps return error on regcache_sync
Date: Mon, 8 Jun 2015 15:16:41 +0100 [thread overview]
Message-ID: <20150608141641.GA9236@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20150508103454.GA13160@opensource.wolfsonmicro.com>
On Fri, May 08, 2015 at 11:34:54AM +0100, Nariman Poushin wrote:
> On Fri, May 08, 2015 at 11:20:19AM +0100, Mark Brown wrote:
> > On Fri, May 08, 2015 at 10:55:37AM +0100, Nariman Poushin wrote:
> > > Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
> > > ---
> > > regcache currently causes a BUG_ON if cache_sync/sync_region is
> > > called on a map with cache_type REGCACHE_NONE. This is not
> > > consistent with the behaviour of regcache_read/write which
> > > currently just return -ENOSYS and only throws a BUG_ON if
> > > the cache_type is something that _should_ have cache ops,
> > > but doesn't. Sure your device might not work, it but doesn't
> > > seem right to panic the kernel. The other option I suppose
> > > is to change it to a WARN_ON.
> >
> > Please submit patches in the format covered in SubmittingPatches, the
> > changelog goes before the signoff.
> >
>
> Will do, apologies.
>
> > The reason this is so loud is that while it's reasonable that generic
> > code could end up triggering a write it's difficult to see any way in
> > which a sync could be triggered on a device without a cache without it
> > being an obvious bug. Since people frequently don't bother checking
> > return codes loud log messages are our only real way of reporting this,
> > given where syncs tend to happen it's not likely to happen in an obscure
> > code path that won't get seen.
>
> Fair enough, that makes sense.
In light of this:
https://lkml.org/lkml/2015/6/7/193
Would it be prudent to now make these WARN_ON? It seems like it's not
worth taking the kernel down in the case where you are trying to sync to
a non-existent cache for a peripheral. Of course it could be that the
particular write _not_ going in to the cache is catastrophic for some
other reason, but it still seems a bit severe and given the discussion
above not the intended usage for BUG_ON. It doesn't feel like this
satisfies the test:
"The *ONLY* acceptable reason for a BUG_ON() is if the machine is dead
anyway because of some major internal corruption."
Anyway, just a thought. Not sure if this constitutes a "content-less
bump", I just read something that I thought may change our previous
assumptions, if it does, apologies.
Thanks
Nariman
>
> Thanks
> Nariman
> _______________________________________________
> patches mailing list
> patches@opensource.wolfsonmicro.com
> http://opensource.wolfsonmicro.com/cgi-bin/mailman/listinfo/patches
next prev parent reply other threads:[~2015-06-08 14:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 9:55 [RFC][PATCH] regmap: make REGCACHE_NONE maps return error on regcache_sync Nariman Poushin
2015-05-08 10:20 ` Mark Brown
2015-05-08 10:34 ` Nariman Poushin
2015-06-08 14:16 ` Nariman Poushin [this message]
2015-06-08 17:24 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150608141641.GA9236@opensource.wolfsonmicro.com \
--to=nariman@opensource.wolfsonmicro.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.