From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756746AbcIGIEG (ORCPT ); Wed, 7 Sep 2016 04:04:06 -0400 Received: from mga09.intel.com ([134.134.136.24]:60014 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752946AbcIGIEB (ORCPT ); Wed, 7 Sep 2016 04:04:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,295,1470726000"; d="asc'?scan'208";a="1046682782" From: Felipe Balbi To: Roger Quadros , Stefan Agner , Mark Brown 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 In-Reply-To: <32e64ab2-2ed6-e177-b1ec-bce9e1eaa4b6@ti.com> References: <20160904040416.22163-1-stefan@agner.ch> <87mvjlmpyo.fsf@linux.intel.com> <20160906082210.GE3950@sirena.org.uk> <56840b0a8520f348ee0517390f518274@agner.ch> <32e64ab2-2ed6-e177-b1ec-bce9e1eaa4b6@ti.com> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Wed, 07 Sep 2016 11:03:19 +0300 Message-ID: <87shtckugo.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Roger Quadros writes: >>>> Stefan Agner 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. >>=20 >> Afaik it is kind of a generic device tree binding, I guess the physical >> device can have various appearances and properties... >>=20 >> A quick survey showed several device trees which do not specify >> vcc-supply... >>=20 >> 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. >>=20 >>>>> + nop->vcc =3D 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) =3D=3D -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(). >>=20 >> Despite the above findings, I still think it is the right thing to do as >> long as we specify vcc-supply to be optional. >>=20 > > 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. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXz8nHAAoJEMy+uJnhGpkG8+IQAIBgYDZry6tebKgu205/xSXF UxxpnBxHG6/iL00WNBI9BnQ124iw57cT985exQ+miWG5FDJiyCxMbEojvZ0Pqd+S QE4QFiX4rWoLSPbEwd/dYHh4BubUEFCjU0UioFnXRItS7rznKCisr/lISUHHmqZM Efo06/DTFGagBqkN0iArXOu3WOcyjSKjg7tj4VkZmGNAoVNdQIYdF6dNkrji9xpc lHdKGeFR4MHb4oQ3Rv8TRoF1cELE6LNWGXmmnvRjKuz0hVhkfyyjlzexlJrMo2zo zUjO9ICmdGUaBWS4zLogou+SroKYkGVX3Hc45bZxc7AjG/sK7iojmNZxBx9OZm+b qcTSHtEFhClbBUCV6gPpvtAF705oRab4tWcUFZHE+qAJJjQPhQ569V161hrDD1/7 mWAZ6vQamX0gvUT9BLIy+wmmN5aLhgzg6njYo6BAHnLKFOMfVu0fxkMANAw5VLew BtAyGyK3899gYfa2kl4zzQ7Iip945sy1lmUpU5kR2E/c9XDpWX1ikI5zVl48bzZD iB9DhuSpeupP9Gz3RCzmvfXUiyOeoBf4U1k9Q/NYlag2/1LnVKaTQ1kkh2+d+R5e GEkrFBCtWysPMCK6R6sJfryMWeLOaU2gYROMFbghGUvGAK2Y2vWyYZsP+K4/wb5A +ARNHDcpmn/bfcCM76BX =QajC -----END PGP SIGNATURE----- --=-=-=--