public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Houcheng Lin <houcheng@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Stephen Gallimore <stephen.gallimore@st.com>,
	Srinivas KANDAGATLA <srinivas.kandagatla@st.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	sre@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Vikas Sajjan <vikas.sajjan@samsung.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
Date: Mon, 11 Aug 2014 19:33:56 +0200	[thread overview]
Message-ID: <20140811173356.GN15297@lukather> (raw)
In-Reply-To: <1407507789.3354.20.camel@paszta.hi.pengutronix.de>

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

On Fri, Aug 08, 2014 at 04:23:09PM +0200, Philipp Zabel wrote:
> Am Dienstag, den 08.07.2014, 11:38 +0200 schrieb Linus Walleij:
> > On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote:
> > >> On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin <houcheng@gmail.com> wrote:
> > >>
> > >> > The Problem
> > >> > -----------
> > >> > The reset signal on a hardware board is send either:
> > >> >     - during machine initialization
> > >> >     - during bus master's initialization
> > >>
> > >> I just thought about this a bit, since there isn't already a generic GPIO
> > >> reset driver, just call this drivers/reset/reset-gpio.c and make the
> > >> ability to deferral just a configuration detail of the GPIO reset driver.
> > >
> > > Philipp has been working on one for quite some time. See
> > > http://www.spinics.net/lists/arm-kernel/msg321927.html
> > >
> > > However, it seems to progress slowly, and we don't seem to be able to
> > > reach a consensus here.
> 
> Mostly because Maxime and I seem to have a completely different opinion
> and nobody else argued one way or the other.

Yep, mostly because I don't see how a generic approach can work.

The existing reset-gpios property only provide the gpio to use, but
some informations are encoded in the driver, such as the reset
duration, or a reset sequence if any.

How do you plan on giving that information to your generic driver?

The only solution I can think of would be to add an extra property
that your code would parse. But then, you break the existing DT
bindings.

And if we're going to break those bindings, at least do it in a way
consistent with reset bindings.

Plus, your approach doesn't cover the weird corner cases such as:
  - reset-gpio
  - wlf,reset-gpios
  - phy-reset-gpios
  - snps,reset-gpio
  - the drivers that need several gpio and expect the reset one as a
    positional argument.
  - etc.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

  reply	other threads:[~2014-08-11 17:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 13:37 [RFC PATCH v3] reset: Add a defer reset object to send board specific reset Houcheng Lin
2014-06-20  9:35 ` Maxime Ripard
2014-07-07 12:38 ` Linus Walleij
2014-07-08  7:52 ` Linus Walleij
2014-07-08  8:05   ` Maxime Ripard
2014-07-08  9:38     ` Linus Walleij
2014-08-08 14:23       ` Philipp Zabel
2014-08-11 17:33         ` Maxime Ripard [this message]
2014-08-14  9:36           ` Philipp Zabel
2014-08-14 10:47             ` Maxime Ripard

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=20140811173356.GN15297@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=dbaryshkov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=gnurou@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=houcheng@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    --cc=srinivas.kandagatla@st.com \
    --cc=stephen.gallimore@st.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vikas.sajjan@samsung.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