Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

On Thu, Aug 3, 2017 at 6:31 PM, Bjorn Andersson
[off-list ref] wrote:

On Thu 03 Aug 10:45 PDT 2017, Rob Herring wrote:

quoted

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson
[off-list ref] wrote:

quoted

In some cases drivers referencing a reserved-memory region might want to
remap the entire region, but when defining the reserved-memory by "size"
the client driver has no means to know the associated base address of
the reserved memory region.

This patch adds an accessor for such drivers to acquire a handle to
their associated reserved-memory for this purpose.

A complicating factor for the implementation is that the reserved_mem
objects are created from the flattened DeviceTree, as such we can't
use the device_node address for comparison. Fortunately the name of the
node will be used as "name" of the reserved_mem and will be used when
building the full_name, so we can compare the "name" with the basename
of the full_name to find the match.

Maybe we should add the device_node pointer when we unflatten?

It did try to figure something sane out in that direction.

The solution I came up with was to amend populate_node() to in a !dryrun
block check if the "dad" full_name is /reserved-memory and if so
call call a new accessor in of_reserved_mem.c to add the "np" to the
reserved_mem object with fdt_node equal offset.

I was thinking doing it with the unflattened tree just after it has
been unflattened rather than during unflattening.

This code path is already cluttered due to the version differences when
it comes to building full_name and we would end up checking for each
node in the entire tree if the parent happens to be "/reserved-mem".

So I went for the less intrusive and more straight forward comparison
with basename(full_name) instead.

That's good, because full_name is about to become just the basename.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html