Message-Id: <20131111170453.4D999C42336@trevor.secretlab.ca>
Date:	Mon, 11 Nov 2013 17:04:53 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>,
	Pantelis Antoniou <panto@...oniou-consulting.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Rob Herring <robherring2@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@...tor.com>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jan Lubbe <jluebbe@...net.de>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	Michael Stickel <ms@...able.de>,
	Dirk Behme <dirk.behme@...il.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Michael Bohan <mbohan@...eaurora.org>,
	Ionut Nicu <ioan.nicu.ext@....com>,
	Michal Simek <monstr@...str.eu>,
	Matt Ranostay <mranostay@...il.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays

On Thu, 7 Nov 2013 21:46:26 +0100, Sebastian Andrzej Siewior <sebastian@...akpoint.cc> wrote:
> On 07.11.13, Pantelis Antoniou wrote:
> > Hi Sebastian,
> Hi Pantelis,
> 
> > FWIW DT has been ported to x86. And is present on arm/powerpc/mips/arc and possibly
> > others.
> 
> Yes, I know. I am the one that did the work for CE4100, the first one
> that boots with DT on x86.
> 
> > So what are we talking about again? If you care about the non-DT case, why
> > don't you make a patch about how you could support Guenter's use case on
> > the x86.
> 
> I am only saying that this "hot-plug a device at a non hot-plugagle bus at
> runtime" is not limited to DT but this solution is. X86 + ACPI is not
> the only limitation. ARM is (forced) going to ACPI as well as far I
> know. And this solution is limited to DT. This is what I am pointing
> out.

I'm going to nip this in the bud before it spreads...  No.

ARM is not going wholesale to ACPI.  ACPI will be implemented on ARMv8
servers. Don't expect the rest of the ARM world to go there anytime
soon, if at all.

As for being limited to DT, that is correct currently, just as SSDT is
an ACPI specific way of doing mostly the same thing. However, I'm not sure
it needs to be a limitation. As long as there is well definied
segregation between the base tree and the overlay (ie. it would be
useful to filter which nodes can be attached to, there are security
implications here too) then it would be fine for a DT overlay to pull in
additional devices on top of an ACPI base tree.

> > His use case is not uncommon, believe it or not, and x86 would benefit from
> > something this flexible.
> 
> I *think* a more flexible solution would be something like bus_type which is
> exposed via configfs. It would be attached behind a certain device/bus where
> the "physical" hotplug interface is. The user would then be able to read the
> configuration based on whatever information he has and could then create
> devices he likes at runtime. This wouldn't depend much on the firmware that is
> used but would require a little more work I think.

I'm certainly fine with investigating the above (modulo security
concerns of creating arbitrary devices). However, that is only one
use-case. There still needs to be the mechanism of passing the kernel a
blob all at once and say, "Here is the layout of this new hunk of
hardware".  For instance, you don't want to have to build up a set of
devices from scratch every time a new device is passed in. Xilinx for
instance has a tool which creates a FDT for an FPGA bitstream right from
the FPGA tools.

g.
--
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/

Powered by blists - more mailing lists