From: Daniel Drake <dsd-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
To: Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org,
sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node
Date: Mon, 3 Oct 2011 11:39:47 +0100 [thread overview]
Message-ID: <CAMLZHHTMP+DJA35bUswXPbTv_U0DAWY_h_-Eg53-_4RuC3bx7A@mail.gmail.com> (raw)
In-Reply-To: <20111003102846.GA23811-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Mon, Oct 3, 2011 at 11:28 AM, Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> 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.
> 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
And Grant is undoubtedly a source of authority on device tree
implementation stuff.
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.
Thanks,
Daniel
next prev parent reply other threads:[~2011-10-03 10:39 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 [this message]
2011-10-03 12:16 ` Mark Brown
[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-28 9:08 Daniel Drake
2011-09-28 9:08 Daniel Drake
2011-09-21 12:01 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=CAMLZHHTMP+DJA35bUswXPbTv_U0DAWY_h_-Eg53-_4RuC3bx7A@mail.gmail.com \
--to=dsd-2x9k7bc8m7mdnm+yrofe0a@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dilinger-pFFUokh25LWsTnJN9+BGXg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
/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).