From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Daniel Drake <dsd@laptop.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
sameo@linux.intel.com, devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, dilinger@queued.net
Subject: Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
Date: Mon, 3 Oct 2011 13:16:55 +0100 [thread overview]
Message-ID: <20111003121655.GB3731@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAMLZHHTMP+DJA35bUswXPbTv_U0DAWY_h_-Eg53-_4RuC3bx7A@mail.gmail.com>
On Mon, Oct 03, 2011 at 11:39:47AM +0100, Daniel Drake wrote:
> On Mon, Oct 3, 2011 at 11:28 AM, Mark Brown
> > I'd really expect that if we're adding stuff to the framework then it
> > should be suitable for random drivers to use.
> It is suitable. If other drivers would otherwise run into the data
> reuse problem you have described, they can use the kmemdup solution
> you have described.
This seems the wrong way round - we're working
> > To be honest I don't
> > really understand why you're changing the framework at all here, the
> > child driver is entirely specific to the parent as far as I can see.
> Because I'm trying to get devicetree-driven HDD LED support driven,
> and Grant stated that doing it this way is a hard rule:
> "What is a hard rule is that the code creating the children needs to
> know what the binding is and populate the child's of_node
> appropriately."
> I also confirmed that extending the mfd_cell layer is exactly what
> Grant was suggesting:
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/008480.html
That's in the context of adding a binding for the vx855 GPIO module
that's distinct from the binding for the rest of the chip. It's not
massively clear to me that this is a good idea.
> So I seem to be stuck between two people giving me conflicting
> requirements for merge of my work (which commenced in July, and has
> already seen several discussions and rounds of patches). Any help
> appreciated - I'm just trying to make a HDD LED blink.
It seems to me like either the IP block is heavily dependant on the core
and shouldn't be split out in the device tree at all (but should instead
be part of the core node) or the IP block is very isolated from the core
(in which case we should just be able to instantiate the device from the
device tree without using explict code in the core driver).
This all feels like there's some abstraction violation going on.
next prev parent reply other threads:[~2011-10-03 12:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 12:01 [PATCH 1/3] mfd: allow mfd_cell association with device tree node Daniel Drake
[not found] ` <20110921120148.4A81E9D401D-k/4jFdqg8LLlyo9zxV8I99HuzzzSOjJt@public.gmane.org>
2011-09-21 12:49 ` Mark Brown
[not found] ` <20110921124936.GA25620-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2011-09-21 13:02 ` Daniel Drake
2011-09-21 13:16 ` Mark Brown
2011-09-27 14:44 ` Daniel Drake
2011-09-27 15:05 ` Grant Likely
2011-09-27 15:18 ` Mark Brown
2011-09-27 16:44 ` Daniel Drake
2011-09-27 18:14 ` Mark Brown
2011-09-27 18:25 ` Daniel Drake
[not found] ` <CAMLZHHSuoeAJ-AC9daxb83+EANV=YGK-aiYpQ_j2wFiyQa5ytw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-27 18:26 ` Mark Brown
[not found] ` <20110927182636.GR4289-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-09-27 18:28 ` Daniel Drake
[not found] ` <CAMLZHHR0rMZct2E91X8k+Lhv_y-pY_5+vshZw6dj194o9vSCJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-27 18:38 ` Mark Brown
2011-09-28 9:07 ` Daniel Drake
2011-09-28 12:31 ` Mark Brown
2011-10-03 8:40 ` Daniel Drake
2011-10-03 10:28 ` Mark Brown
[not found] ` <20111003102846.GA23811-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2011-10-03 10:39 ` Daniel Drake
2011-10-03 12:16 ` Mark Brown [this message]
[not found] ` <20111003121655.GB3731-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-10-03 12:30 ` Daniel Drake
[not found] ` <CAMLZHHS+fFzuWtwOwt-g2y38g93uaZFyUGsooZyYLMT=mdWQFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-03 12:40 ` Mark Brown
[not found] ` <20111003124044.GF3731-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-10-03 12:53 ` Daniel Drake
-- strict thread matches above, loose matches on Subject: below --
2011-09-21 12:01 Daniel Drake
2011-09-28 9:08 Daniel Drake
2011-09-28 9:08 Daniel Drake
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=20111003121655.GB3731@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dilinger@queued.net \
--cc=dsd@laptop.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=sameo@linux.intel.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).