linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: p.zabel@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] reset: Add generic GPIO reset driver.
Date: Tue, 11 Feb 2014 18:36:49 +0100	[thread overview]
Message-ID: <1392140209.6943.49.camel@pizza.hi.pengutronix.de> (raw)
In-Reply-To: <CANh8QzwERe-zxCaAd4QujZJ4zcZ7SchK+w8u52fvJj0s5tx2nA@mail.gmail.com>

Hi Martin,

Am Dienstag, den 11.02.2014, 10:34 +0100 schrieb Fuzzey, Martin:
[...]
> >> 2) Allow hardware on discoverable busses to be rest via a GPIO line
> >> without driver modifications.
> >>
> >> Examples of the second use case include:
> >> * SDIO wifi modules
> >> * USB hub chips with a reset line
> >
> > Now this is interesting. But if you export it to userspace anyway, why
> > not use the existing gpio sysfs API?
> >
> 
> In the normal case of reset on boot the userspace interface isn't needed.
> Setting the "auto" dt property will make the kernel do the reset by
> itself during
> early boot. This is the standard use case.
> 
> The userspace interface is to let applications deal with special cases.
> It is also simpler for userspace than manlually toggling the GPIO line
> and keeps the configuration (active high / low, delay) centralised in
> the DT and consistent between the automatic on boot reset and the
> manually triggered reset.
>
> > I think a proper solution should handle this in the kernel. For SDIO
> > wifi modules you usually have a powerdown line that can be implemented
> > as an rfkill switch.
> >
> 
> I think this is too specific. It's not just for SDIO wifi. We also
> have the problem
> of a USB hub needing to be reset.
> 
> Also even for the SDIO wifi case rfkill doesn't ssem the right
> abstraction to say "reset me"
> (particularly when firmware fails to load on warm boot if you don't).

so long as you need to take devices out of reset before they can be
discovered, maybe the corresponding host controller would be the right
place to put the reset.

regards
Philipp

      reply	other threads:[~2014-02-11 17:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 12:54 [PATCH] reset: Add generic GPIO reset driver Martin Fuzzey
2014-02-10 13:16 ` Philipp Zabel
2014-02-11  9:34   ` Fuzzey, Martin
2014-02-11 17:36     ` Philipp Zabel [this message]

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=1392140209.6943.49.camel@pizza.hi.pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).