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

Date:	Wed, 16 Oct 2013 21:54:27 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Michael Bohan <mbohan@...eaurora.org>,
	David Daney <ddaney@...iumnetworks.com>
CC:	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-discuss@...ts.ozlabs.org, david.daney@...ium.com,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] of/lib: Export fdt routines to modules

On 10/16/2013 05:27 PM, Michael Bohan wrote:
> On Wed, Oct 16, 2013 at 04:39:03PM -0700, David Daney wrote:
>> On 10/16/2013 04:27 PM, Michael Bohan wrote:
>>> Ever since the following commit, libfdt has been available for
>>> usage in the kernel:
>>>
>>>       commit ab25383983fb8d7786696f5371e75e79c3e9a405
>>>       Author: David Daney <david.daney@...ium.com>
>>>       Date:   Thu Jul 5 18:12:38 2012 +0200
>>>
>>>       of/lib: Allow scripts/dtc/libfdt to be used from kernel code
>>>
>>> Export these functions to modules so that they may be used
>> >from device drivers.
>>> ---
>>> +EXPORT_SYMBOL_GPL(fdt_next_tag);
>>
>> The code was all written by David Gibson, and is dual GPL/BSD
>> licensed.  So I am not sure you should be using the GPL flavor of
>> the export directive.
>
> Yeah, I wasn't quite sure about this myself. I can remove the GPL
> if it's incorrect.
>
>> But more than this.  I don't understand why a driver would be
>> parsing the FDT in the first place.  If there is a device tree, why
>> hasn't it been unflattened, and thus used via the normal device tree
>> functions.
>
> My motivation is actually to use the fdt format as a firmware.
> I have a requirement to express driver metadata that's loadable
> from the filesystem. This data is not reasonable to place in the
> system Device Tree, since it's application specific and does not
> actually describe hardware. The fact that the format chosen is
> 'flattened device tree' is merely just a coincidence.
>
Still, what prevents you from unflattening it and just using the
normal device tree functions as David suggested ?

Guenter

> When considering formats, dts / fdt is convenient since:
>
> -The dts syntax meets requirements by being human-readable.
> -There exists a device-tree compiler already
> -Linux knows how to deal with fdt, so the driver implementation
>   becomes more simple.
>
> Thanks,
> Mike
>

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