linux-kernel - Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140811173356.GN15297@lukather>
Date:	Mon, 11 Aug 2014 19:33:56 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Houcheng Lin <houcheng@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Stephen Gallimore <stephen.gallimore@...com>,
	Srinivas KANDAGATLA <srinivas.kandagatla@...com>,
	Ulf Hansson <ulf.hansson@...aro.org>, sre@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Vikas Sajjan <vikas.sajjan@...sung.com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v3] reset: Add a defer reset object to send board
 specific reset

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@...e-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@...il.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

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)