linux-kernel - Re: [PATCH] usb: phy: generic: request regulator optionally

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87shtckugo.fsf@linux.intel.com>
Date:   Wed, 07 Sep 2016 11:03:19 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Roger Quadros <rogerq@...com>, Stefan Agner <stefan@...er.ch>,
        Mark Brown <broonie@...nel.org>
Cc:     gregkh@...uxfoundation.org, fabio.estevam@....com,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: phy: generic: request regulator optionally


Hi,

Roger Quadros <rogerq@...com> writes:
>>>> Stefan Agner <stefan@...er.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

Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)