From: Mark Brown <broonie@kernel.org>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: devicetree@vger.kernel.org, patches@opensource.wolfsonmicro.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings
Date: Wed, 25 Sep 2013 19:32:01 +0100 [thread overview]
Message-ID: <20130925183201.GT3226@sirena.org.uk> (raw)
In-Reply-To: <1380131272-16982-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On Wed, Sep 25, 2013 at 06:47:52PM +0100, Charles Keepax wrote:
> This patch creates a sub-node for the codec and attaches the required
> regulators here using the of_compatible field on the mfd_cell.
> Another issue with the Arizona bindings, I am not sure
> exactly what the best approach is this patch seems like the
> "correct" fix, but it does require a change to the binding,
> although the current binding is non-functional.
No, this is not sensible - what you're doing here is clearly a Linux
implementation detail.
> Alternatively I could simply set the codec of_node to match
> the mfd one manually in the codec driver which wouldn't need
> the binding changing but feels a bit like a work around.
That's not clever either, fiddling around with the data structures like
that is bound to cause referencing problems ("I just freed the device,
let's clean up all the memory") and general fragility.
> Any thoughts would be greatly appreciated?
You need to do something like arrange for the regulator API to resolve
attempts to look up regulators on the subnode using the parent, the
device is virtual after all.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-09-25 18:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 17:47 Charles Keepax
2013-09-25 18:32 ` Mark Brown [this message]
2013-09-26 15:29 ` Charles Keepax
2013-09-26 17:58 ` Mark Brown
2013-09-28 15:53 ` Charles Keepax
2013-09-28 22:55 ` Mark Brown
2013-09-29 14:11 ` Charles Keepax
2013-09-29 17:52 ` Mark Brown
2013-09-29 18:09 ` Charles Keepax
2013-10-10 11:21 ` Lee Jones
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=20130925183201.GT3226@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
/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
all inboxes | Powered by JetHome®