linux-kernel - Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays

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]

Date:	Fri, 8 Nov 2013 09:09:37 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	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

Hi Sebastian,

On Nov 7, 2013, at 10:46 PM, Sebastian Andrzej Siewior 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.
> 

Who is forcing ACPI on ARM? Maybe for ARM64 and server markets but interest
in ACPI for all the other markets I'd say is nil.

A DT limited solution has more reach _today_ that what ACPI _might_ do sometime.

There is a big big world outside of x86.

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

You might've missed the posting, but the original implementation was using a
bus (a capebus) and that went over like a lead ballon.

People use this, and find the concept useful.

In a nutshell, sure, there _might_ be better ways to do it, but no-one has
actually stepped forward and did it better.

>> Regards
>> 
>> -- Pantelis
> 
> Sebastian

Regards

-- Pantelis

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