From: Kevin Hilman <khilman@deeprootsystems.com>
To: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
Koen Kooi <koen@dominion.thruhere.net>,
Felipe Balbi <balbi@ti.com>, Tony Lindgren <tony@atomide.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Matt Porter <mporter@ti.com>, Russ Dill <Russ.Dill@ti.com>,
linux-omap@vger.kernel.org, Kevin Hilman <khilman@ti.com>,
Paul Walmsley <paul@pwsan.com>,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <robherring2@gmail.com>,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Date: Sat, 03 Nov 2012 09:23:02 +0100 [thread overview]
Message-ID: <5094D466.2010209@deeprootsystems.com> (raw)
In-Reply-To: <40797D3D-D62C-4E15-B0DF-75636C1637EE@antoniou-consulting.com>
On 11/02/2012 09:43 AM, Pantelis Antoniou wrote:
[...]
>>
>> And then use the standard DT support to create later the platform_device that does represent the new super-cape devices.
>>
>
> We know this is the ideal case. In fact that's the long term goal and we had internal discussions about it.
Since you already had internal discussions about this, it would have
been a great help in avoiding lots of this discussion if you would've
summarized this ideal case from the beginning, then describe the
weaknesses and limitations of DT for handling hotplug/dynamic devices
and thus the reasoning behind creating capebus. Now it's taken this
long thread for others to try to convince you about something you
already knew to be the ideal case. Seems a bit wasteful.
Kernel development typically works by building/extending infrastructure
that is already there. Only when it's obvious that the current
infrastructure cannot be extended for a new kind of usage do we build
new infrastruture.
In this case, DT is the obvious infrastructure that needs extending. At
least we can all agree on that, for starters.
> DT is nowhere near being able to do it.
>
> That would require the introduction of a DT object file format with aliases being capable to be
> resolved dynamically. We're talking about major changes here in the way DT files are being compiled and
> used in practice.
>
> So yes, in an ideal world that would be great. We're nowhere near close today unfortunately.
>
> Assuming that we do work on a DT object format, and that the runtime resolution mechanism is approved,
> then I agree that this part of the capebus patches can be dropped and the functionality assumed by generic
> DT core.
>
> The question is that this will take time, with no guarantees that this would be acceptable from
> the device tree maintainers. So I am putting them in the CC list, to see what they think about it.
Since this thread has already ventured into the weeds a few times, I
would suggest that you summarize the DT limitations (focusing on they
dynamic/hotplug needs) and start a thread on devicetree-discuss, so that
the DT maintainers can be helpful without having to follow this thread.
IMO, the path forward is clear (though probably longer than you would
like): Let's first try and extend DT infrastructure. If that is
obviously going nowhere, and DT maintainers are against it. Then, let's
revisit capebus.
Kevin
next prev parent reply other threads:[~2012-11-03 11:50 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 15:17 [PATCH 0/3] capebus moving omap_devices to mach-omap2 Pantelis Antoniou
2012-10-31 17:52 ` Tony Lindgren
2012-10-31 18:04 ` Pantelis Antoniou
2012-10-31 18:09 ` Tony Lindgren
2012-10-31 18:24 ` Pantelis Antoniou
2012-10-31 19:55 ` Benoit Cousson
2012-10-31 20:12 ` Pantelis Antoniou
2012-10-31 21:26 ` Tony Lindgren
2012-10-31 21:36 ` Pantelis Antoniou
2012-10-31 21:43 ` Tony Lindgren
2012-10-31 22:00 ` Pantelis Antoniou
2012-10-31 22:16 ` Tony Lindgren
2012-10-31 22:14 ` Felipe Balbi
2012-11-01 7:02 ` Pantelis Antoniou
2012-11-01 10:23 ` Cousson, Benoit
2012-11-01 10:39 ` Pantelis Antoniou
2012-11-01 11:04 ` Felipe Balbi
2012-11-01 11:26 ` Pantelis Antoniou
2012-11-01 12:40 ` Felipe Balbi
2012-11-01 12:57 ` Pantelis Antoniou
2012-11-01 13:16 ` Felipe Balbi
2012-11-01 13:35 ` Pantelis Antoniou
2012-11-01 13:51 ` Alan Cox
2012-11-01 13:59 ` Pantelis Antoniou
2012-11-01 22:05 ` Felipe Balbi
2012-11-01 23:49 ` Russ Dill
2012-11-02 8:57 ` Felipe Balbi
2012-11-02 9:42 ` Russ Dill
2012-11-02 10:39 ` Koen Kooi
2012-11-02 11:00 ` Felipe Balbi
2012-11-02 16:44 ` Russ Dill
2012-11-02 11:21 ` Alan Cox
2012-11-02 12:32 ` Pantelis Antoniou
2012-11-05 0:37 ` Grant Likely
2012-11-05 15:37 ` Pantelis Antoniou
2012-11-05 19:10 ` Grant Likely
2012-11-05 19:54 ` Pantelis Antoniou
2012-11-05 20:14 ` Grant Likely
2012-11-05 22:59 ` Joel A Fernandes
2012-11-05 23:58 ` Grant Likely
2012-11-06 3:06 ` Joel A Fernandes
2012-11-06 8:14 ` Pantelis Antoniou
2012-11-06 11:16 ` Grant Likely
2012-11-06 13:54 ` Pantelis Antoniou
2012-11-02 16:07 ` Jason Kridner
2012-11-02 16:28 ` Alan Cox
2012-11-05 1:05 ` Grant Likely
2012-11-01 11:26 ` Cousson, Benoit
2012-11-01 11:39 ` Pantelis Antoniou
2012-11-01 12:00 ` Koen Kooi
2012-11-01 13:06 ` Felipe Balbi
2012-11-01 13:33 ` Koen Kooi
2012-11-02 8:15 ` Cousson, Benoit
2012-11-02 8:43 ` Pantelis Antoniou
2012-11-03 8:23 ` Kevin Hilman [this message]
[not found] ` <40797D3D-D62C-4E15-B0DF-75636C1637EE-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2012-11-05 0:22 ` Grant Likely
2012-11-05 13:25 ` Pantelis Antoniou
2012-11-05 14:34 ` Grant Likely
[not found] ` <CACxGe6ubcRqDEGyRbNmwvAMGg5ujAKvPRWe9Vmd9tiHeB7=qNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-05 15:34 ` Tony Lindgren
2012-11-05 15:56 ` Rob Herring
2012-11-05 19:40 ` Grant Likely
2012-11-01 15:18 ` [PATCH 1/3] omap-device: Remove __init from omap_device_build family functions Pantelis Antoniou
2012-11-01 15:18 ` [PATCH 2/3] da8xx-dt: Create da8xx DT adapter device Pantelis Antoniou
2012-11-01 14:36 ` Tomi Valkeinen
2012-11-01 14:38 ` Pantelis Antoniou
2012-11-01 15:18 ` [PATCH 3/3] ti-tscadc-dt: Create ti-tscadc-dt " Pantelis Antoniou
-- strict thread matches above, loose matches on Subject: below --
2012-11-01 18:50 [PATCH 0/3] capebus moving omap_devices to mach-omap2 Jason Kridner
2012-11-01 19:07 ` Tony Lindgren
2012-11-02 9:26 ` Cousson, Benoit
2012-11-02 10:19 ` Koen Kooi
2012-11-05 0:32 ` Grant Likely
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=5094D466.2010209@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=Russ.Dill@ti.com \
--cc=b-cousson@ti.com \
--cc=balbi@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=khilman@ti.com \
--cc=koen@dominion.thruhere.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mporter@ti.com \
--cc=panto@antoniou-consulting.com \
--cc=paul@pwsan.com \
--cc=robherring2@gmail.com \
--cc=tony@atomide.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).