From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965002AbcIFSGg (ORCPT ); Tue, 6 Sep 2016 14:06:36 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:60361 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938782AbcIFSGe (ORCPT ); Tue, 6 Sep 2016 14:06:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 06 Sep 2016 11:01:15 -0700 From: Stefan Agner To: Mark Brown Cc: Felipe Balbi , 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: <20160906082210.GE3950@sirena.org.uk> References: <20160904040416.22163-1-stefan@agner.ch> <87mvjlmpyo.fsf@linux.intel.com> <20160906082210.GE3950@sirena.org.uk> Message-ID: <56840b0a8520f348ee0517390f518274@agner.ch> User-Agent: Roundcube Webmail/1.1.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-09-06 01:22, Mark Brown wrote: > On Tue, Sep 06, 2016 at 10:45:19AM +0300, Felipe Balbi wrote: >> 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. 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. -- Stefan