All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Roger Quadros <rogerq@ti.com>, Stefan Agner <stefan@agner.ch>,
	Mark Brown <broonie@kernel.org>
Cc: gregkh@linuxfoundation.org, fabio.estevam@nxp.com,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: phy: generic: request regulator optionally
Date: Wed, 07 Sep 2016 11:03:19 +0300	[thread overview]
Message-ID: <87shtckugo.fsf@linux.intel.com> (raw)
In-Reply-To: <32e64ab2-2ed6-e177-b1ec-bce9e1eaa4b6@ti.com>

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]


Hi,

Roger Quadros <rogerq@ti.com> writes:
>>>> Stefan Agner <stefan@agner.ch> writes:
>>>
>>>>> According to the device tree bindings the vcc-supply is optional.
>>>
>>> This is nonsense unless the device can work without this supply.  Given
>>> that the supply is called VCC that doesn't seem entirely likely.
>> 
>> Afaik it is kind of a generic device tree binding, I guess the physical
>> device can have various appearances and properties...
>> 
>> A quick survey showed several device trees which do not specify
>> vcc-supply...
>> 
>> That said, I checked the device at hand, and it actually has a USB PHY
>> power supply inputs, but the device tree does not model them.
>> 
>>>>> +	nop->vcc = devm_regulator_get_optional(dev, "vcc");
>>>>>  	if (IS_ERR(nop->vcc)) {
>>>>>  		dev_dbg(dev, "Error getting vcc regulator: %ld\n",
>>>>>  					PTR_ERR(nop->vcc));
>>>>> -		if (needs_vcc)
>>>>> -			return -EPROBE_DEFER;
>>>>> +		if (needs_vcc || PTR_ERR(nop->vcc) == -EPROBE_DEFER)
>>>>> +			return PTR_ERR(nop->vcc);
>>>
>>>> does this look okay from a regulator API perspective?
>>>
>>> That's how to use _get_optional() but it's really unusual that you
>>> should be using _get_optional().
>> 
>> Despite the above findings, I still think it is the right thing to do as
>> long as we specify vcc-supply to be optional.
>> 
>
> I think the right behaviour would be that if vcc-supply is specified
> in the DT then failure to get that supply is a serious failure and
> probe should fail.
>
> So the correct fix would be to call devm_regulator_get() only if
> needs_vcc is true.

The way it is, AFAICT, regulator fwk will return a dummy regulator for
cases where supply isn't in DT.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

  reply	other threads:[~2016-09-07  8:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-04  4:04 [PATCH] usb: phy: generic: request regulator optionally Stefan Agner
2016-09-06  7:45 ` Felipe Balbi
2016-09-06  8:22   ` Mark Brown
2016-09-06 18:01     ` Stefan Agner
2016-09-07  7:25       ` Roger Quadros
2016-09-07  8:03         ` Felipe Balbi [this message]
2016-09-07 18:53       ` Mark Brown
2016-09-07 20:32         ` Stefan Agner

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=87shtckugo.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=broonie@kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@ti.com \
    --cc=stefan@agner.ch \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.