[PATCH 0/3] capebus moving omap_devices to mach-omap2

Kevin Hilman khilman at deeprootsystems.com
Sat Nov 3 19:23:02 EST 2012


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


More information about the devicetree-discuss mailing list