linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@antoniou-consulting.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>,
	Guenter Roeck <linux@roeck-us.net>,
	Rob Herring <robherring2@gmail.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Matt Porter <matt.porter@linaro.org>,
	Koen Kooi <koen@dominion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@mentor.com>,
	Dinh Nguyen <dinh.linux@gmail.com>, Jan Lubbe <jluebbe@lasnet.de>,
	Alexander Sverdlin <alexander.sverdlin@nsn.com>,
	Michael Stickel <ms@mycable.de>,
	Dirk Behme <dirk.behme@gmail.com>,
	Alan Tull <delicious.quinoa@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Michael Bohan <mbohan@codeaurora.org>,
	Ionut Nicu <ioan.nicu.ext@nsn.com>,
	Michal Simek <monstr@monstr.eu>,
	Matt Ranostay <mranostay@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays
Date: Tue, 12 Nov 2013 09:16:39 +0100	[thread overview]
Message-ID: <89F4284F-DB71-41ED-9B53-663539446128@antoniou-consulting.com> (raw)
In-Reply-To: <20131111170453.4D999C42336@trevor.secretlab.ca>

Hi Grant,

On Nov 11, 2013, at 6:04 PM, Grant Likely wrote:

> On Thu, 7 Nov 2013 21:46:26 +0100, Sebastian Andrzej Siewior <sebastian@breakpoint.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.
> 

Well, this can be pretty radical, but what about converting the ACPI base tree
in DT format and then take it from there.

I'm sure the state of DT encompasses most of what ACPI does ATM, modulo the
whole craziness of calling in firmware/interpreting bytecode to do stuff like
turn on a GPIO.

I might be in the minority, but it took us so many years on not having to rely
on weird firmware to get our systems to work, and ACPI seems to be heading back
into the old ways on having to rely on firmware quirks to patch firmware we 
are dependent on.

DT way of describing only, may be not to the liking of everyone, but I certainly
prefer it.

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

Regards

-- Pantelis


  reply	other threads:[~2013-11-12  8:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 18:41 [PATCH 0/3 - V2] Introducing Device Tree Overlays Pantelis Antoniou
2013-11-05 18:41 ` [PATCH 1/3] OF: Introduce Device Tree resolve support Pantelis Antoniou
2013-11-06 15:59   ` Alexander Sverdlin
2013-11-06 16:24     ` Ionut Nicu
2013-11-05 18:41 ` [PATCH 2/3] OF: Introduce DT overlay support Pantelis Antoniou
2013-11-06 16:00   ` Alexander Sverdlin
2013-11-06 16:26     ` Ionut Nicu
2013-11-06 20:41   ` Dinh Nguyen
2013-11-07  7:10     ` Pantelis Antoniou
2013-11-05 18:41 ` [PATCH 3/3] DT: proc: Add runtime overlay interface in /proc Pantelis Antoniou
2013-11-06  9:51   ` Ionut Nicu
2013-11-06  9:57     ` Pantelis Antoniou
2013-11-06 19:10   ` Rob Herring
2013-11-06 19:24     ` Pantelis Antoniou
2013-11-06 20:16       ` Matt Porter
2013-11-07  7:44         ` Pantelis Antoniou
2013-11-07 23:38   ` delicious quinoa
2013-11-08  7:12     ` Pantelis Antoniou
2013-11-05 19:06 ` [PATCH 0/3 - V2] Introducing Device Tree Overlays Guenter Roeck
2013-11-06  0:15   ` Dinh Nguyen
2013-11-06  8:53 ` Alexander Sverdlin
2013-11-06 19:01 ` Sebastian Andrzej Siewior
2013-11-06 19:08   ` Pantelis Antoniou
2013-11-06 20:31     ` Sebastian Andrzej Siewior
2013-11-06 20:41       ` Sebastian Andrzej Siewior
2013-11-07  7:24         ` Pantelis Antoniou
2013-11-07  7:23       ` Pantelis Antoniou
2013-11-07  9:45     ` Alexander Sverdlin
2013-11-06 19:30   ` Guenter Roeck
2013-11-06 20:38     ` Sebastian Andrzej Siewior
2013-11-06 21:17       ` Guenter Roeck
2013-11-07  7:27         ` Pantelis Antoniou
2013-11-07 19:25         ` Sebastian Andrzej Siewior
2013-11-07 20:06           ` Pantelis Antoniou
2013-11-07 20:46             ` Sebastian Andrzej Siewior
2013-11-07 23:00               ` Guenter Roeck
2013-11-08  7:12                 ` Pantelis Antoniou
2013-11-08  8:40                 ` Sebastian Andrzej Siewior
2013-11-08  7:09               ` Pantelis Antoniou
2013-11-11 17:04               ` Grant Likely
2013-11-12  8:16                 ` Pantelis Antoniou [this message]
2013-11-07 22:51             ` Guenter Roeck
2013-11-07 22:22           ` Guenter Roeck

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=89F4284F-DB71-41ED-9B53-663539446128@antoniou-consulting.com \
    --to=panto@antoniou-consulting.com \
    --cc=Alison_Chaiken@mentor.com \
    --cc=alexander.sverdlin@nsn.com \
    --cc=delicious.quinoa@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dinh.linux@gmail.com \
    --cc=dirk.behme@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=ioan.nicu.ext@nsn.com \
    --cc=jluebbe@lasnet.de \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=matt.porter@linaro.org \
    --cc=mbohan@codeaurora.org \
    --cc=monstr@monstr.eu \
    --cc=mranostay@gmail.com \
    --cc=ms@mycable.de \
    --cc=robherring2@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sebastian@breakpoint.cc \
    --cc=swarren@wwwdotorg.org \
    /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).