All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Date: Mon, 15 Jul 2013 21:35:52 -0600	[thread overview]
Message-ID: <51E4BF98.8030604@wwwdotorg.org> (raw)
In-Reply-To: <20130716015038.GD28375@S2101-09.ap.freescale.net>

On 07/15/2013 07:50 PM, Shawn Guo wrote:
> Hi Philipp,
> 
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>> This driver implements a reset controller device that toggle a gpio
>> connected to a reset pin of a peripheral IC. The delay between assertion
>> and de-assertion of the reset signal can be configured via device tree.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>> Reviewed-by: Stephen Warren <swarren@nvidia.com>
> 
> I see this patch is very useful, as GPIOs are widely used to reset
> components/devices on board.  But I do not find the patch in v3.11-rc1.
> What's your plan about it?
> 
> Also, I'm wondering if we should register the driver a little bit
> early.  Please see the following patch.  If it makes sense to you,
> I can send the patch to you, or you can just quash it into yours.
> 
> Shawn
> 
> ---8<--------
> 
> From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
> From: Shawn Guo <shawn.guo@linaro.org>
> Date: Sun, 14 Jul 2013 20:41:00 +0800
> Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
>  arch_initcall
> 
> It's a little bit late to register gpio-reset driver at module_init
> time, because gpio-reset provides reset control via gpio for other
> devices which are mostly probed at module_init time too.  And it
> becomes even worse, when the gpio comes from IO expander on I2C bus,
> e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> bus driver which is generally ready at subsys_initcall time.  Let's
> register gpio-reset driver in arch_initcall() to have it ready early
> enough.

There's no need for the reset driver to be registered before its users;
the users of the reset GPIO will simply have their probe deferred until
the reset controller is available, and then everything will work out
just fine.

> The defer probe mechanism is not used here, because a reset controller
> driver should be reasonably registered early than other devices.  More
> importantly, defer probe doe not help in some nasty cases, e.g. the
> gpio-pca953x device itself needs a reset from gpio-reset driver to start
> working.

That should work fine with deferred probe.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>,
	Fabio Estevam
	<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	Mike Turquette
	<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>,
	Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
	Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Date: Mon, 15 Jul 2013 21:35:52 -0600	[thread overview]
Message-ID: <51E4BF98.8030604@wwwdotorg.org> (raw)
In-Reply-To: <20130716015038.GD28375-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>

On 07/15/2013 07:50 PM, Shawn Guo wrote:
> Hi Philipp,
> 
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>> This driver implements a reset controller device that toggle a gpio
>> connected to a reset pin of a peripheral IC. The delay between assertion
>> and de-assertion of the reset signal can be configured via device tree.
>>
>> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Reviewed-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> I see this patch is very useful, as GPIOs are widely used to reset
> components/devices on board.  But I do not find the patch in v3.11-rc1.
> What's your plan about it?
> 
> Also, I'm wondering if we should register the driver a little bit
> early.  Please see the following patch.  If it makes sense to you,
> I can send the patch to you, or you can just quash it into yours.
> 
> Shawn
> 
> ---8<--------
> 
> From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
> From: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Sun, 14 Jul 2013 20:41:00 +0800
> Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
>  arch_initcall
> 
> It's a little bit late to register gpio-reset driver at module_init
> time, because gpio-reset provides reset control via gpio for other
> devices which are mostly probed at module_init time too.  And it
> becomes even worse, when the gpio comes from IO expander on I2C bus,
> e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> bus driver which is generally ready at subsys_initcall time.  Let's
> register gpio-reset driver in arch_initcall() to have it ready early
> enough.

There's no need for the reset driver to be registered before its users;
the users of the reset GPIO will simply have their probe deferred until
the reset controller is available, and then everything will work out
just fine.

> The defer probe mechanism is not used here, because a reset controller
> driver should be reasonably registered early than other devices.  More
> importantly, defer probe doe not help in some nasty cases, e.g. the
> gpio-pca953x device itself needs a reset from gpio-reset driver to start
> working.

That should work fine with deferred probe.

  reply	other threads:[~2013-07-16  3:35 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30  9:09 [PATCH v8] reset: Add driver for gpio-controlled reset pins Philipp Zabel
2013-05-30  9:09 ` Philipp Zabel
2013-05-30 10:37 ` Pavel Machek
2013-05-30 10:37   ` Pavel Machek
2013-07-16  1:50 ` Shawn Guo
2013-07-16  1:50   ` Shawn Guo
2013-07-16  3:35   ` Stephen Warren [this message]
2013-07-16  3:35     ` Stephen Warren
2013-07-16  4:10     ` Shawn Guo
2013-07-16  4:10       ` Shawn Guo
2013-07-16  9:49       ` Philipp Zabel
2013-07-16  9:49         ` Philipp Zabel
2013-07-16 12:56         ` Shawn Guo
2013-07-16 12:56           ` Shawn Guo
2013-07-16 15:45       ` Stephen Warren
2013-07-16 15:45         ` Stephen Warren
2013-07-17  3:02         ` Shawn Guo
2013-07-17  3:02           ` Shawn Guo
2013-07-17 16:57           ` Stephen Warren
2013-07-17 16:57             ` Stephen Warren
2013-07-17 21:38             ` Pavel Machek
2013-07-17 21:38               ` Pavel Machek
2013-07-17 22:24               ` Stephen Warren
2013-07-17 22:24                 ` Stephen Warren
2013-07-18 11:25                 ` Pavel Machek
2013-07-18 11:25                   ` Pavel Machek
2013-07-18 18:45                   ` Olof Johansson
2013-07-18 18:45                     ` Olof Johansson
2013-07-19  3:23                     ` Shawn Guo
2013-07-19  3:23                       ` Shawn Guo
2013-07-19 15:45                       ` Stephen Warren
2013-07-19 15:45                         ` Stephen Warren
2013-07-22  7:47                         ` Shawn Guo
2013-07-22  7:47                           ` Shawn Guo
2013-07-26 10:26                     ` Philipp Zabel
2013-07-26 10:26                       ` Philipp Zabel
2013-07-18 22:55                   ` Grant Likely
2013-07-18 22:55                     ` Grant Likely
2013-07-18 22:50             ` Grant Likely
2013-07-18 22:50               ` Grant Likely
2013-07-16  9:59     ` Philipp Zabel
2013-07-16  9:59       ` Philipp Zabel
2013-07-16 15:48       ` Stephen Warren
2013-07-16 15:48         ` Stephen Warren
2013-07-16  6:51   ` Shawn Guo
2013-07-16  6:51     ` Shawn Guo
2013-07-16  9:51     ` Philipp Zabel
2013-07-16  9:51       ` Philipp Zabel
2013-07-16 12:15       ` Shawn Guo
2013-07-16 12:15         ` Shawn Guo
2013-07-16 15:47     ` Stephen Warren
2013-07-16 15:47       ` Stephen Warren
2013-07-17  3:43       ` Shawn Guo
2013-07-17  3:43         ` Shawn Guo
2013-07-17  7:17       ` Philipp Zabel
2013-07-17  7:17         ` Philipp Zabel

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=51E4BF98.8030604@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.