From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Enabling regulators form userspace
Date: Thu, 23 Apr 2015 18:50:00 +0100 [thread overview]
Message-ID: <20150423175000.GX22845@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=WaoecKbNZrH98AiJLZ3WuEiqGn2=02NqYrR5PXx1DjWg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]
On Thu, Apr 23, 2015 at 09:52:40AM -0700, Doug Anderson wrote:
> Personally, I have been annoyed several times by the lack of an easy
> way to control regulators from userspace. While doing development of
> regulator code it is very handy to be able to change the voltages from
> userspace so I can probe them with a scope. I have a terribly hacky /
> wrong CL <https://chromium-review.googlesource.com/#/c/214475/> that I
> actually wrote for this. Note that userspace consumers were a bit
> cumbersome for this purpose.
There's a test consumer in mainline for precisely this purpose, I used
to use it a lot when I was doing bringup of regulator drivers on
evaluation boards - look at virtual.c (which is separate to the
userspace consumer in that it throws usability to the wind, though some
trivial shell scripts fix that).
> I wonder whether we could achieve "safety" and "don't abuse" problems
> by doing something like:
> 1. Put the interface in "debugfs", not sysfs. Hopefully folks know
> that userspace isn't supposed to rely on debugfs. ...though perhaps
> userspace in the factory (test tools) are OK to use it as long as they
> understand that it is fragile (API may change) and dangerous (could
> shoot yourself in the foot).
I'm not optimistic about this achieving the desired results, we export
too much stuff through debugfs that's useful in production so all it
really does is give us a bit more ability to say "I told you so".
> 2. Require a config option to enable it with suitable warnings in the
> KConfig option.
> 3. Force the user to write a "y" into a file named
> "i_know_this_is_unsafe", or something of the sort. Writing this could
> write a suitable warning to the kernel log saying "If you let the
> magic smoke out, don't blame me".
I don't think either of those accomplishes anything meaningful, it's not
like we've got a good track record on getting people to pay attention to
warnings or do transitions. With echoing into a file I'd just expect to
see patches turning off the warning because of course everyone thinks
that their own use case is totally sensible, reasonable and well thought
through (and some of them actually are).
Like I say I think if we're delegating this to userspace we should
actively choose to do so, not just throw everything over the wall.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-04-23 17:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAKdAkRSE+A4Y1mBedCvyy3vL3=+PuGuYXBF7Q0gob-P3ZU8FTg@mail.gmail.com>
[not found] ` <20150422201112.GN22845@sirena.org.uk>
2015-04-22 20:56 ` Enabling regulators form userspace Dmitry Torokhov
2015-04-23 10:35 ` Mark Brown
2015-04-23 16:08 ` Dmitry Torokhov
2015-04-23 16:52 ` Doug Anderson
2015-04-23 17:50 ` Mark Brown [this message]
2015-04-23 17:13 ` Mark Brown
2015-04-23 18:19 ` Dmitry Torokhov
2015-04-23 19:09 ` 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=20150423175000.GX22845@sirena.org.uk \
--to=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@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