linux-kernel - Re: [PATCH] of/lib: Export fdt routines to modules

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] [day] [month] [year] [list]

Message-ID: <5261FF4D.1080005@roeck-us.net>
Date:	Fri, 18 Oct 2013 20:41:01 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Michael Bohan <mbohan@...eaurora.org>,
	Rob Herring <robherring2@...il.com>
CC:	David Daney <ddaney@...iumnetworks.com>,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	David Gibson <david@...son.dropbear.id.au>,
	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	rob.herring@...xeda.com, ralf@...ux-mips.org,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	david.daney@...ium.com, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] of/lib: Export fdt routines to modules

On 10/18/2013 06:49 PM, Michael Bohan wrote:
> On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:
>> On 10/18/2013 02:32 PM, Michael Bohan wrote:
>>> My preference is probably straight libfdt calls, but if others
>>> think that unpacking is a better solution, I'm able to go that
>>> route as well. My only concern there is that we provide a means
>>> to detect invalid dtb image (ex. handle error codes) and also
>>> free the device_node allocations once the device is released.
>>
>> I think we need to understand what you are putting in the DT first.
>
> That's understandable. Please see my response to Mark.
>
>> Given there are other desired uses like overlays which need to add the
>> necessary loading and unflattening support, a common solution is likely
>> more desirable.
>
> But by convention, would overlays allow for 'application
> specific' data, or are they expected to meet the more rigid
> requirements of a real Device Tree?
>

Not that I am the authority on it, but the idea is that devicetree overlays
will be merged with the existing devicetree, which implies that the same
requirements would apply.

However, you would not really use overlays. You would use the devicetree
infrastructure to create a logically separate instance of a devicetree
to dynamically configure your driver (which I think is an ingenious idea).
I don't think the same rules would or should apply there.

Guenter

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