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