From: Mark Brown <broonie@kernel.org>
To: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] regmap: Add a config option for making regmap debugfs writable
Date: Tue, 13 Oct 2015 21:07:00 +0100 [thread overview]
Message-ID: <20151013200700.GM14956@sirena.org.uk> (raw)
In-Reply-To: <CAOMFOmVp3j9o7UD+qDQOrQBcZr_4__HSxk98quctiu7jegrZHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
On Tue, Oct 13, 2015 at 11:33:13AM -0700, Anatol Pomozov wrote:
> On Tue, Oct 13, 2015 at 10:55 AM, Mark Brown <broonie@kernel.org> wrote:
> > This is deliberately not a Kconfig option because it is a terrible idea
> > to do this in production and making it either selectable or the default
> > is an invitation to abuse.
> What kind of abuse are you talking about?
Using it as a standard interface to control systems in production rather
than having appropriate support in the relevant driver.
> Having an easy way of modifying chip registers is extremely useful
> during bringup / driver development. And during device development
> phase I regularly have situations when I need to change a register to
> see if it fixes an issue. Sometimes I need to test it remotely when
> users located at another end of the Earth.
This is exactly the sort of use case this feature is intended for, and
is the sort of situation where a custom kernel is not going to be any
kind of practical problem.
> Current kernel source suggests I need to modify regmap-debugfs.c
> directly. But my kernel tree is shared by multiply products and some
> of the products in production already. I do not want to enable
> writable remap for production products. I would like to have a
> per-product compile-time configuration and .config serves exactly this
> purpose.
Feel free to make that modification in your local tree if you want it,
I'm not going to take it for upstream.
> > We want to place a barrier here so that
> > users know that this is something that they have taken a decision to
> > enable, not something that is in any way supported (this is also why we
> > taint the kernel when people do write).
> Honestly I am not convinced. Why to put obstacles on a feature that is
> very useful during development?
We don't want people complaining when someone misprograms their PMIC or
battery charger in a production system because a debug feature got left
on by mistake (both components that frequently use regmap and both
components that have the capacity to physically damage the system), or
have someone decide that the way to tune their system is to turn on this
option and bang on the hardware from userspace bypassing the driver.
It's really handy for debug but it's terrible for system robustness and
stability.
The whole point is that this is only intended to be used during
development while modifying the kernel, if you're able to do that it's
not a meningful obstacle.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-10-13 20:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 17:46 Anatol Pomozov
2015-10-13 17:55 ` Mark Brown
2015-10-13 18:33 ` Anatol Pomozov
2015-10-13 20:07 ` Mark Brown [this message]
2015-12-04 16:37 ` Pavel Machek
2015-12-05 16:49 ` Mark Brown
2015-10-13 20:00 ` kbuild test robot
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=20151013200700.GM14956@sirena.org.uk \
--to=broonie@kernel.org \
--cc=anatol.pomozov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®