[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160907185325.GC3950@sirena.org.uk>
Date: Wed, 7 Sep 2016 19:53:25 +0100
From: Mark Brown <broonie@...nel.org>
To: Stefan Agner <stefan@...er.ch>
Cc: Felipe Balbi <balbi@...nel.org>, 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
On Tue, Sep 06, 2016 at 11:01:15AM -0700, Stefan Agner wrote:
> On 2016-09-06 01:22, Mark Brown wrote:
> > 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...
Is it really realistic that a meaningful proportion of them will work
without power?
> A quick survey showed several device trees which do not specify
> vcc-supply...
The regulator framework will attempt to be forgiving in what it accepts,
the absence of a mandatory supply is sadly not a good indication that
the supply does not physically exist...
> 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.
...like here.
> > 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 disagree, and bear in mind that it is more complex all round to handle
optional supples - the reason they exist is that on devices where
supplies may be omitted you usually have to do some kind of special case
handling (like enabling internal regulators or something). If you don't
have any such special case handling but instead simply omit enables and
disables then that's a fairly clear abuse of the API.
Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)
Powered by blists - more mailing lists