mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: pHilipp Zabel <philipp.zabel@gmail.com>
Cc: Roger Quadros <quadros.roger@gmail.com>,
	lrg@slimlogic.co.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regulator: Add GPIO enable control to fixed voltage regulator driver
Date: Fri, 31 Jul 2009 14:34:37 +0100	[thread overview]
Message-ID: <20090731133437.GF17091@sirena.org.uk> (raw)
In-Reply-To: <74d0deb30907310625u128ea22cu6fecca53c4a23d40@mail.gmail.com>

On Fri, Jul 31, 2009 at 03:25:36PM +0200, pHilipp Zabel wrote:
> On Fri, Jul 31, 2009 at 3:10 PM, Mark
> Brown<broonie@opensource.wolfsonmicro.com> wrote:

> > This isn't needed, just use an invalid GPIO value (zero or less).

> Negative only, actually. Zero itself is a valid GPIO number (which is
> a bit unfortunate because if you forget to initialize .gpio, it will
> default to GPIO #0).

> If you drop .use_gpio_control, use gpio_is_valid(data->gpio) for this check:

Feh, better print a warning for GPIO 0 for at least a kernel release.
Fortunately we've got no mainline users of fixed voltage regulators.

> > Same comment as above with regard to the error message. ?It would be
> > nice to have the default state passed in as platform data if you can't
> > read it back to help avoid bouncing supplies at startup. ?IIRC
> > gpio_get_value() will generally take a good stab at giving the current
> > state no matter if the GPIO is input our output but I'd need to check.

> I think this is not clearly defined in the GPIO API document, so it
> could be architecture dependent.

It's not particularly; having checked gpiolib just passes this straight
through to the underlying driver.  Since they'd have to go out of their
way to do something unconstructive it should be safe to do the read and
we can worry about problem cases if they crop up.

> > If you mark the comments with /** they'll get picked up by kerneldoc.

> Maybe following the style in Documentation/kernel-doc-nano-HOWTO.txt
> would be worthwhile, then.

Indeed.

  reply	other threads:[~2009-07-31 13:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31 12:55 Roger Quadros
2009-07-31 13:10 ` Mark Brown
2009-07-31 13:25   ` pHilipp Zabel
2009-07-31 13:34     ` Mark Brown [this message]
2009-07-31 13:43       ` Roger Quadros
2009-07-31 13:50         ` Mark Brown
     [not found]           ` <b90c0690907310713w5c8b7fe3l4253f03f78f06491@mail.gmail.com>
     [not found]             ` <20090731141547.GA6505@rakim.wolfsonmicro.main>
2009-07-31 14:22               ` Roger Quadros
2009-07-31 14:34                 ` Roger Quadros

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=20090731133437.GF17091@sirena.org.uk \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=philipp.zabel@gmail.com \
    --cc=quadros.roger@gmail.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 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®