linux-kernel - Re: [PATCH 0/3] capebus moving omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5094D466.2010209@deeprootsystems.com>
Date:	Sat, 03 Nov 2012 09:23:02 +0100
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	"Cousson, Benoit" <b-cousson@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Felipe Balbi <balbi@...com>, Tony Lindgren <tony@...mide.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, Kevin Hilman <khilman@...com>,
	Paul Walmsley <paul@...an.com>,
	devicetree-discuss@...ts.ozlabs.org,
	Rob Herring <robherring2@...il.com>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [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.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/