linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
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: Sat, 28 Sep 2013 16:53:08 +0100	[thread overview]
Message-ID: <20130928155308.GV3635@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20130926175843.GS19304@sirena.org.uk>

On Thu, Sep 26, 2013 at 06:58:43PM +0100, Mark Brown wrote:
> I don't see why this would only be an issue for ASoC - it happens to
> have more helpers for this right now than anything else but I'd hope
> that at some point in the future we can get some of the common patterns
> for holding regulators into the device framework.  You also have the
> potential for this to do the wrong thing if it doesn't happen to be
> talking to an MFD which is doing this since it just unconditionally
> looks at the parent.
> 
> I would suggest that rather than unconditionally doing this on lookup
> it'd be easier to do it the other way round and explicitly add mappings
> from the parent to the child when registering the device.  That doesn't
> have the potential to explode and get the wrong thing like this does.

Been a bit delayed on this as I have been investigating the
situation a little further. Is it just moving the supplies of the
parent node we object to? Or do we want to keep everything tidied
onto the one device tree node? The reason I ask is because
looking at this further we run into other problems, the MFD
framework is clearly intended to have a sub-node for each device.

For example, the GPIO driver has a similar issue if anything else
wishes to use an Arizona devices GPIO, because the GPIO driver
is on a different device to the MFD so again it can't locate it.
I haven't checked yet but I am guessing there will be similar
issues with the interrupts.

Thanks,
Charles

  reply	other threads:[~2013-09-28 15:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 17:47 [RFC PATCH] mfd: arizona: Update device tree regulator bindings Charles Keepax
2013-09-25 18:32 ` Mark Brown
2013-09-26 15:29   ` Charles Keepax
2013-09-26 17:58     ` Mark Brown
2013-09-28 15:53       ` Charles Keepax [this message]
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=20130928155308.GV3635@opensource.wolfsonmicro.com \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=broonie@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).