-Note: in this description 'included' means that a node (or other part of
-the tree) should be included in the region list, i.e. it will have a region
-which covers its part of the tree.
-
-This function maintains some state from the last time it is called. It
-checks the next part of the tree that it is supposed to look at
-(p.nextoffset) to see if that should be included or not. When it finds
-something to include, it sets info->start to its offset. This marks the
-start of the region we want to include.
-
-Once info->start is set to the start (i.e. not -1), we continue scanning
-until we find something that we don't want included. This will be the end
-of a region. At this point we can close off the region and add it to the
-list. So we do so, and reset info->start to -1.
-
-One complication here is that we want to merge regions. So when we come to
-add another region later, we may in fact merge it with the previous one if
-one ends where the other starts.
-
-The function fdt_add_region() will return -1 if it fails to add the region,
-because we already have a region ready to be returned, and the new one
-cannot be merged in with it. In this case, we must return the region we
-found, and wait for another call to this function. When it comes, we will
-repeat the processing of the tag and again try to add a region. This time it
-will succeed.
-
-The current state of the pointers (stack, offset, etc.) is maintained in
-a ptrs member. At the start of every loop iteration we make a copy of it.
-The copy is then updated as the tag is processed. Only if we get to the end
-of the loop iteration (and successfully call fdt_add_region() if we need
-to) can we commit the changes we have made to these pointers. For example,
-if we see an FDT_END_NODE tag we will decrement the depth value. But if we
-need to add a region for this tag (let's say because the previous tag is
-included and this FDT_END_NODE tag is not included) then we will only commit
-the result if we were able to add the region. That allows us to retry again
-next time.
-
-We keep track of a variable called 'want' which tells us what we want to
-include when there is no specific information provided by the h_include
-function for a particular property. This basically handles the inclusion of
-properties which are pulled in by virtue of the node they are in. So if you
-include a node, its properties are also included. In this case 'want' will
-be WANT_NODES_AND_PROPS. The FDT_REG_DIRECT_SUBNODES feature also makes use
-of 'want'. While we are inside the subnode, 'want' will be set to
-WANT_NODES_ONLY, so that only the subnode's FDT_BEGIN_NODE and FDT_END_NODE
-tags will be included, and properties will be skipped. If WANT_NOTHING is
-selected, then we will just rely on what the h_include() function tells us.
-
-Using 'want' we work out 'include', which tells us whether this current tag
-should be included or not. As you can imagine, if the value of 'include'
-changes, that means we are on a boundary between nodes to include and nodes
-to exclude. At this point we either close off a previous region and add it
-to the list, or mark the start of a new region.
-
-Apart from the nodes, we have mem_rsvmap, the FDT_END tag and the string
-list. Each of these dealt with as a whole (i.e. we create a region for each
-if it is to be included). For mem_rsvmap we don't allow it to merge with
-the first struct region. For the stringlist we don't allow it to merge with
-the last struct region (which contains at minimum the FDT_END tag).
-*/