The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Doug Anderson <dianders@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Enabling regulators form userspace
Date: Thu, 23 Apr 2015 11:35:45 +0100	[thread overview]
Message-ID: <20150423103545.GS22845@sirena.org.uk> (raw)
In-Reply-To: <20150422205644.GB29953@dtor-ws>

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On Wed, Apr 22, 2015 at 01:56:44PM -0700, Dmitry Torokhov wrote:
> On Wed, Apr 22, 2015 at 09:11:12PM +0100, Mark Brown wrote:

> > 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.

This really sounds like you should be writing a device driver here, even
if it's just a little module you write separately to the actual device
driver used in real systems.

> > 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.

It's not about the quality of an individual driver, it's about the
potential for misuse - making the kernel interfaces such that it's easy
to do the right thing and hard to do the wrong thing.  Having the
ability to just bang on this stuff from userspace seems like it's
encouraging problematic behaviour.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-04-23 10:36 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 [this message]
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=20150423103545.GS22845@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