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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
