From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753316AbcEDMew (ORCPT ); Wed, 4 May 2016 08:34:52 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:34900 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753164AbcEDMeu (ORCPT ); Wed, 4 May 2016 08:34:50 -0400 Message-ID: <1462365283.3536.27.camel@pengutronix.de> Subject: Re: [PATCH] reset: allow to pass NULL pointer to reset_control_put() From: Philipp Zabel To: Masahiro Yamada Cc: Arnd Bergmann , Linux Kernel Mailing List Date: Wed, 04 May 2016 14:34:43 +0200 In-Reply-To: References: <1462360671-13668-1-git-send-email-yamada.masahiro@socionext.com> <8236507.We1UVOf0nF@wuerfel> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:96de:80ff:fec2:9969 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, den 04.05.2016, 20:34 +0900 schrieb Masahiro Yamada: > Hi Arnd, > > 2016-05-04 20:24 GMT+09:00 Arnd Bergmann : > > On Wednesday 04 May 2016 20:17:51 Masahiro Yamada wrote: > >> Currently, reset_control_put() just returns for error pointer, > >> but not for NULL pointer. This is not reasonable. > >> > >> Passing NULL pointer should be allowed as well to make failure path > >> handling easier. > >> > >> Signed-off-by: Masahiro Yamada > >> --- > >> > >> drivers/reset/core.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/reset/core.c b/drivers/reset/core.c > >> index 181b05d..7bb16d1 100644 > >> --- a/drivers/reset/core.c > >> +++ b/drivers/reset/core.c > >> @@ -288,7 +288,7 @@ EXPORT_SYMBOL_GPL(reset_control_get); > >> > >> void reset_control_put(struct reset_control *rstc) > >> { > >> - if (IS_ERR(rstc)) > >> + if (IS_ERR_OR_NULL(rstc)) > >> return; > >> > >> module_put(rstc->rcdev->owner); > > > > Using IS_ERR_OR_NULL() normally indicates that there is something > > wrong with the API, or with the caller. > > > > What exactly is the idea behind treating an error pointer as a valid > > input to reset_control_put() here? Maybe it should just test for > > NULL? The idea was that you could do drvdata->rstc = reset_control_get(...) in the probe() function and reset_control_put(drvdata->rstc) in remove() without having to check for IS_ERR(drvdata->rstc) again. I'm not convinced this is necessarily a good idea though. To simplify the teardown path we already have devm_reset_control_get(). > I thought about that a bit, > but there might be some (not nice) drivers that rely on the current behavior. > I did not want to break any boards with my patch. > > So, should it be > > if (!rstc) > return; > or, perhaps > > if (!rstc || WARN_ON_ONCE(IS_ERR(rstc))) > return; > > ? NULL is not a valid input to reset_control, reset_control_get(_optional) should never return NULL. I'd be in favor of turning this into if (WARN_ON(IS_ERR_OR_NULL(rstc))) return; As far as I am aware, ehci-tegra is the only driver that currently makes use of the IS_ERR(rstc) return in reset_control_put(): struct reset_control *usb1_reset; usb1_reset = of_reset_control_get(phy_np, "usb"); if (IS_ERR(usb1_reset)) { /* ... */ } else { reset_control_assert(usb1_reset); udelay(1); reset_control_deassert(usb1_reset); } reset_control_put(usb1_reset); That'd be trivial to fix. regards Philipp