linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/14] usb: phy: nop: Handle power supply regulator for the PHY
Date: Mon, 14 Jan 2013 11:25:49 +0000	[thread overview]
Message-ID: <20130114112549.GY23505@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <50F3D5E2.4000102@ti.com>

On Mon, Jan 14, 2013 at 11:54:42AM +0200, Roger Quadros wrote:
> On 01/11/2013 07:17 PM, Russell King - ARM Linux wrote:
> > On Thu, Jan 10, 2013 at 06:51:24PM +0200, Roger Quadros wrote:
> >> We use "vcc" as the supply name for the PHY's power supply.
> >> The power supply will be enabled during .init() and disabled
> >> during .shutdown()
> >>
> >> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >> ---
> >>  drivers/usb/otg/nop-usb-xceiv.c |   18 ++++++++++++++++++
> >>  1 files changed, 18 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
> >> index 163f972..1c6db10 100644
> >> --- a/drivers/usb/otg/nop-usb-xceiv.c
> >> +++ b/drivers/usb/otg/nop-usb-xceiv.c
> >> @@ -33,11 +33,13 @@
> >>  #include <linux/usb/nop-usb-xceiv.h>
> >>  #include <linux/slab.h>
> >>  #include <linux/clk.h>
> >> +#include <linux/regulator/consumer.h>
> >>  
> >>  struct nop_usb_xceiv {
> >>  	struct usb_phy		phy;
> >>  	struct device		*dev;
> >>  	struct clk		*clk;
> >> +	struct regulator	*vcc;
> >>  };
> >>  
> >>  static struct platform_device *pd;
> >> @@ -70,6 +72,11 @@ static int nop_init(struct usb_phy *phy)
> >>  {
> >>  	struct nop_usb_xceiv *nop = dev_get_drvdata(phy->dev);
> >>  
> >> +	if (nop->vcc) {
> >> +		if (regulator_enable(nop->vcc))
> >> +			dev_err(phy->dev, "Failed to enable power\n");
> >> +	}
> >> +
> >>  	if (nop->clk)
> >>  		clk_enable(nop->clk);
> >>  
> >> @@ -82,6 +89,11 @@ static void nop_shutdown(struct usb_phy *phy)
> >>  
> >>  	if (nop->clk)
> >>  		clk_disable(nop->clk);
> >> +
> >> +	if (nop->vcc) {
> >> +		if (regulator_disable(nop->vcc))
> >> +			dev_err(phy->dev, "Failed to disable power\n");
> >> +	}
> >>  }
> >>  
> >>  static int nop_set_peripheral(struct usb_otg *otg, struct usb_gadget *gadget)
> >> @@ -157,6 +169,12 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
> >>  		}
> >>  	}
> >>  
> >> +	nop->vcc = devm_regulator_get(&pdev->dev, "vcc");
> >> +	if (IS_ERR(nop->vcc)) {
> >> +		dev_dbg(&pdev->dev, "Error getting vcc regulator\n");
> >> +		nop->vcc = NULL;
> >> +	}
> > 
> > Is it really appropriate for drivers to do this kind of thing with
> > pointer-returning functions (I mean, setting the pointer to NULL on
> > error, rather than just using a test for IS_ERR() in the above
> > locations).  You are imposing driver-local assumptions on an API.
> > 
> > Practically it probably doesn't make much difference but given the
> > amount of mistakes that we have with IS_ERR_OR_NULL()...
> > 
> Makes sense. I'll convert it to use IS_ERR_OR_NULL() throughout.

IS_ERR_OR_NULL() is going to be deprecated and removed.  Please take a
look at how these APIs work.

If regulator support is not enabled, then devm_regulator_get() returns
NULL, and all the other regulator functions become no-ops.  This is not
an error.  Do you need the driver to error out if CONFIG_REGULATOR is
disabled?

If regulator support is enabled, then it can return a pointer-error
value (as defined when IS_ERR() is true, and _in that case only_ can it
be decoded by PTR_ERR() - PTR_ERR() is _only_ valid when IS_ERR()
returns true - it is _not_ valid for all the cases that IS_ERR_OR_NULL()
returns true.)  Otherwise, it returns a cookie as far as the driver is
concerned for the regulator suitable for passing into the other regulator
APIs.

By having the driver do something different, and make use of NULL as its
own special sentinel, it's placing additional interpretations on the API,
which can lead to bugs.  Don't do this.

If you can start making use of 'nop' vcc/clk members before they've been
"got" then initialize them to ERR_PTR(-EINVAL) first.

Also consider that when using the devm interfaces, you can do:


	nop->clk = devm_clk_get(&pdev->dev, ...);
	nop->vcc = devm_regulator_get(&pdev->dev, "vcc");

	if (IS_ERR(nop->clk))
		dev_dbg(&pdev->dev, "unable to get clock: %d\n",
			PTR_ERR(nop->clk));

	if (IS_ERR(nop->vcc))
		dev_dbg(&pdev->dev, "unable to get vcc regulator: %d\n",
			PTR_ERR(nop->vcc));
...
	if (!IS_ERR(nop->clk))
		clk_enable(nop->clk);

You may also consider that if you're going to print a warning for
regulator_enable(), that you should print the error code as well, so that
you know the reason why the failure happened.

Also consider... is dev_err() appropriate for an "error", for which you
print a message and continue as if nothing went wrong.  To me that sounds
more like a warning than an error, so maybe dev_warn() would be more
appropriate?

  reply	other threads:[~2013-01-14 11:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 16:51 [PATCH 00/14] USB: omap-ehci: Move PHY management to PHY driver Roger Quadros
2013-01-10 16:51 ` [PATCH 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data Roger Quadros
2013-01-10 23:45   ` Tony Lindgren
2013-01-11  9:40     ` Roger Quadros
2013-01-11 18:13       ` Tony Lindgren
2013-01-14 11:28         ` Roger Quadros
2013-01-14 17:18           ` Tony Lindgren
2013-01-10 16:51 ` [PATCH 02/14] usb: phy: Add new API usb_get_phy_from_dev() Roger Quadros
2013-01-10 16:51 ` [PATCH 03/14] usb: xceiv: nop: Manage PHY clock Roger Quadros
2013-01-10 16:51 ` [PATCH 04/14] usb: phy: nop: Handle power supply regulator for the PHY Roger Quadros
2013-01-10 18:06   ` Sergei Shtylyov
2013-01-11  9:41     ` Roger Quadros
2013-01-11 17:17   ` Russell King - ARM Linux
2013-01-14  9:54     ` Roger Quadros
2013-01-14 11:25       ` Russell King - ARM Linux [this message]
2013-01-14 11:51         ` Roger Quadros
2013-01-14 12:18           ` Russell King - ARM Linux
2013-01-10 16:51 ` [PATCH 05/14] usb: phy: nop: Handle RESET " Roger Quadros
2013-01-10 16:51 ` [PATCH 06/14] mfd: omap-usb-host: update nports in platform_data Roger Quadros
2013-01-22  3:29   ` Samuel Ortiz
2013-01-10 16:51 ` [PATCH 07/14] usb: ehci-omap: Instantiate PHY devices if required Roger Quadros
2013-01-10 20:48   ` Alan Stern
2013-01-11 10:59     ` Roger Quadros
2013-01-11 11:06       ` Roger Quadros
2013-01-11 15:28       ` Alan Stern
2013-01-11 16:03         ` Roger Quadros
2013-01-11 16:32           ` Russell King - ARM Linux
2013-01-14  9:48             ` Roger Quadros
2013-01-11 18:27           ` Alan Stern
2013-01-10 16:51 ` [PATCH 08/14] mfd: omap-usb-host: Remove PHY reset handling code Roger Quadros
2013-01-22  3:28   ` Samuel Ortiz
2013-01-10 16:51 ` [PATCH 09/14] usb: ehci-omap: " Roger Quadros
2013-01-10 16:51 ` [PATCH 10/14] usb: ehci-omap: Remove PHY regulator " Roger Quadros
2013-01-10 16:51 ` [PATCH 11/14] ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data Roger Quadros
2013-01-10 16:51 ` [PATCH 12/14] ARM: OMAP2+: omap4panda: Adapt HUB power to regulator framework Roger Quadros
2013-01-10 16:51 ` [PATCH 13/14] ARM: OMAP2+: omap4panda: Adapt HUB reset " Roger Quadros
2013-01-10 16:51 ` [PATCH 14/14] ARM: OMAP2+: omap4panda: Remove irrelevant USB host platform data Roger Quadros

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=20130114112549.GY23505@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).