From: Mark Brown <broonie@kernel.org>
To: Stefan Agner <stefan@agner.ch>
Cc: Felipe Balbi <balbi@kernel.org>,
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, 7 Sep 2016 19:53:25 +0100 [thread overview]
Message-ID: <20160907185325.GC3950@sirena.org.uk> (raw)
In-Reply-To: <56840b0a8520f348ee0517390f518274@agner.ch>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-09-07 18:53 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
2016-09-07 18:53 ` Mark Brown [this message]
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=20160907185325.GC3950@sirena.org.uk \
--to=broonie@kernel.org \
--cc=balbi@kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).