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 17:27:31 -0700
From:	Michael Bohan <mbohan@...eaurora.org>
To:	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 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. 

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

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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/