From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: omap3: regulator_get() failure in ads7846 Date: Tue, 7 Sep 2010 13:51:19 +0100 Message-ID: <20100907125118.GC25830@sirena.org.uk> References: <4C862D15.1070606@compulab.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from cassiel.sirena.org.uk ([80.68.93.111]:52194 "EHLO cassiel.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755743Ab0IGMvX (ORCPT ); Tue, 7 Sep 2010 08:51:23 -0400 Content-Disposition: inline In-Reply-To: <4C862D15.1070606@compulab.co.il> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Igor Grinberg Cc: "Premi, Sanjeev" , "linux-omap@vger.kernel.org" , "linux-input@vger.kernel.org" On Tue, Sep 07, 2010 at 03:16:21PM +0300, Igor Grinberg wrote: > I think, this can help: > http://www.spinics.net/lists/arm-kernel/msg94759.html > Seems like there were not enough interest and it is still floating. > May be a little ping can help ;) This is a really bad idea unless the supplies genuinely are optional - we shouldn't be doing this sort of bodge in the drivers, that's just going to lead to lots of repetitive code adding complexity every time the regulator API is used. It also makes the error handling rather more obscure since systems that genuinely need the regulator won't be reporting problems clearly. The regulator API has facilties on several levels to deal with systems that have problems here: it provides fixed voltage regulators, it provides the option to substitute in dummy regulators automatically and if the regulator API is disabled then the stub functions provided will report success.