From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Enabling regulators form userspace
Date: Wed, 22 Apr 2015 13:56:44 -0700 [thread overview]
Message-ID: <20150422205644.GB29953@dtor-ws> (raw)
In-Reply-To: <20150422201112.GN22845@sirena.org.uk>
On Wed, Apr 22, 2015 at 09:11:12PM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2015 at 12:56:21PM -0700, Dmitry Torokhov wrote:
>
> Please keep the list in the Ccs unless there's a reason not to, other
> people could benefit from the discussion or even answer.
[ resending with LKML on CC ]
>
> > I am considering adding a debugs feature/attribute "enable" to allow
> > doing "regulatror_enable" and "regulator_disable" from userspace, how
> > do you feel about it?
>
> There's already a userspace consumer driver you can bind for test
> purposes which could be used here.
Thanks for the pointer, but I do not think this would work for this use
case, mainly because the controllers in question often impose timing
constraints on the supplies. I.e. while holding reset GPIO you turn on
vdd and then, after at least X msec, avdd, and then release reset GPIO.
> I guess ideally the I2C userspace
> interface would have code to do something like enumerate all supplies on
> the device and keep them enabled while the device is open from
> userspace, though that won't help things running as shell scripts which
> are probably a common case.
Same as above, the interactions are quite often a bit more complex to be
easily described generically, but is no problem to implement in a
userspace utility that is already product-specific.
>
> I'm not keen on having something in there as a standard feature, it's
> just this massive "abuse me" flag - there's not really much of a
> production use case for it but lots of "let's just hack around our buggy
> drivers" use case.
I would contend that the drivers are not necessarily buggy: we just do
not want to encumber the kernel driver with all the details about test
interface that is very much controller specific (i.e. we can't easily
generalize it for all permutations of Atmel/Cypress/Eantech/Stnaptics
etc controllers) and that is not going to be used during normal
operation. However it is very much a production issue as these test
utilities are used during factory runs to ensure quality of produced
hardware.
Thanks.
--
Dmitry
next parent reply other threads:[~2015-04-22 20:56 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 ` Dmitry Torokhov [this message]
2015-04-23 10:35 ` Enabling regulators form userspace Mark Brown
2015-04-23 16:08 ` Dmitry Torokhov
2015-04-23 16:52 ` Doug Anderson
2015-04-23 17:50 ` Mark Brown
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=20150422205644.GB29953@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--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