[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201303121403.09315.arnd@arndb.de>
Date: Tue, 12 Mar 2013 14:03:09 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Kevin Liu <keyuan.liu@...il.com>
Cc: Chris Ball <cjb@...top.org>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
Stephen Warren <swarren@...dotorg.org>,
linux-arm-kernel@...ts.infradead.org,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Linus Walleij <linus.walleij@...aro.org>,
Axel Lin <axel.lin@...ics.com>,
Jingoo Han <jg1.han@...sung.com>, Felipe Balbi <balbi@...com>,
Dmitry Torokhov <dtor@...l.ru>, linux-mmc@...r.kernel.org
Subject: Re: FW: Regulator API ignored return values
On Tuesday 12 March 2013, Kevin Liu wrote:
> > - regulator_enable(host->vqmmc);
> > + ret = regulator_enable(host->vqmmc);
> > if (!regulator_is_supported_voltage(host->vqmmc, 1700000,
> > 1950000))
> > caps[1] &= ~(SDHCI_SUPPORT_SDR104 |
> > SDHCI_SUPPORT_SDR50 |
> > SDHCI_SUPPORT_DDR50);
> > + if (ret) {
> > + pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
> > + mmc_hostname(mmc), ret);
>
> Need add regulator_put here since regulator_get has succeed?
Hmm, we still don't actually bail out if the error is encountered, so
the reference count is balanced with the current patch, but I maybe
a failed regulator_enable() should actually be a fatal error?
If we do that, using devm_regulator_get() would be a nice way to
track the reference counts.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists