[PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware

[Jerry Van Baren]

Timur Tabi wrote:
> Jerry Van Baren wrote:

[snip]

>> * The above should result in reasonable board-specific code.
>>   * We may want to invent a libfdt move/copy subtree function (I don't
>>       recall one being in there).  Board specific code would want to
>>       move selected subtrees out of /u-boot,hwoptions into the
>>       appropriate final node.  All the pieces are in libfdt, just would
>>       need to be hooked together in a utility subroutine.
> 
> Just being able to delete a given node/property would be enough.  By 
> default, the nodes with conditionals would be present in the device 
> tree.  The boot loader would then also strip out all conditionals from 
> the device tree before passing it to the kernel.  The kernel would then 
> receive a standard device tree like it does today.

Deleting isn't really enough because you would want to copy/move the 
configuration from a subnode of the hwoptions node to the final resting 
place in the standard tree (assuming there is a final resting place in 
the standard tree - I'm picturing SOC configuration choices here). 
Simple deletion isn't adequate in general because
* It would be silly to change linux to look in a new location for things
     that already exist in standard locations (e.g. SOC stuff)
* Deleting a node inherently deletes all of the subnodes.  In order to
     do only delete operations, you would end up with an ugly path like:
/u-boot,hwoptions/J1/on/tree/&usb/phy_type (set to  "ulpi")
     where I suspect the &usb/phy_type portion should be glued into a SOC
     (or other) pre-existing subnode.
* It is possible some choices can be used multiple times - the above
     example specifies a PHY.  There are very often multiple instances of
     only type of PHY and copying one "prototype" selection into multiple
     final destination nodes could save space and effort.

>> * With the above, nothing in the infrastructure (dtc, libfdt) needs to
>>     change.
>>
>> On a related note, would it be better to name the node 
>> "/u-boot/hwoptions" (two levels deep)?  It seems very desirable to me to 
> 
> It's not a u-boot-specific concept.  The idea of representing jumpers 
> (and other hardware options) in the device tree is not something that's 
> unique to u-boot or any boot loader. The conditionals, however, are a 
> bootloader-specific concept.  We don't want Linux to see them.

Well, then we shouldn't name it u-boot,hwoptions.  Ahh, nevermind, Scott 
beat me to that point.

Best regards,
gvb