Hi Alan,

On Thu, Feb 11, 2016 at 2:17 PM, atull [off-list ref] wrote:

quoted

quoted

quoted

I looked into it further and now I've got a solution for this issue
that I can post soon.  I can stop using the DT overlay configfs
interface and add a sysfs file for applying an overlay to an FPGA
region.  The FPGA region implementation will see the overlay before it
becomes part of the live tree.  Then it can do the FPGA programming
and see that succeed before the child nodes become part of the live
tree.  If FPGA programming fails, the overlay will be rejected before
it becomes part of the live tree.  By the time 'firmware-name' and the
child nodes show up in the live tree, they will be post-configuration
information.

I agree this would be a very nice interface, but Rob is right, having
two different
interfaces to load device-trees is probably bad in general.

quoted

Yes.  If any handler returns error, the overlay doesn't go into the
main tree.  Handler type to be registed could be:

  int pre_add_handler(struct device_node *overlay,
                      struct device_node *target)

And a third parameter of some flags to indicate whether the
overlay is being added or removed.

Looks good to me.

quoted

That gives us the overlay after it's been unflattened and phandles
resolved and the node that it was targeted to.  I was going to
need find_target_node() to be exported, but this avoids that.

Registration could by compatible string, of match, or path.  Path
would be too rigid in my case, I'd want to register for compatible
"fpga-region"

Looks good to me. I think we're getting pretty close :)

Moritz