From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Mon, 15 Jul 2013 21:35:52 -0600 Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins In-Reply-To: <20130716015038.GD28375@S2101-09.ap.freescale.net> References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de> <20130716015038.GD28375@S2101-09.ap.freescale.net> Message-ID: <51E4BF98.8030604@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 >> Reviewed-by: Stephen Warren > > 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 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins Date: Mon, 15 Jul 2013 21:35:52 -0600 Message-ID: <51E4BF98.8030604@wwwdotorg.org> References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de> <20130716015038.GD28375@S2101-09.ap.freescale.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130716015038.GD28375-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Shawn Guo Cc: Marek Vasut , Fabio Estevam , Mike Turquette , Pavel Machek , Len Brown , Sascha Hauer , "Rafael J. Wysocki" , Philipp Zabel , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.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 >> Reviewed-by: Stephen Warren > > 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 > 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.