[lkml]   [2012]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] capebus moving omap_devices to mach-omap2
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.


 \ /
  Last update: 2012-11-03 13:21    [W:0.156 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site