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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Oct 2013 16:51:32 -0700
From:	Michael Bohan <mbohan@...eaurora.org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	David Daney <ddaney@...iumnetworks.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-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 09:54:27PM -0700, Guenter Roeck wrote:
> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> >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 ?

I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
That's an interesting thought. I was planning to scan the fdt
only once and populate my own structures, but I suppose I could
use the of_* APIs equivalently.

It seems there are some problems though.  of_fdt_unflatten_tree()
does not return errors, and so for the purposes of my driver it
would not be sufficient to detect an invalid firmware image. 

Would people entertain changing this API
(and implicitly __unflatten_device_tree) to return errors? I'm
guessing the reason it's coded that way is because the normal
usecase is 'system boot', at which time errors aren't that
meaningful.

Also, there's no way to free the memory that was allocated from
the unflatten process. May I add one?

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/