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

[Jerry Van Baren]

Timur Tabi wrote:
> Scott Wood wrote:
> 
>> That's your model.  Mine involves merging a fragment that corresponds 
>> to an active hwoption, with no complex conditional evaluation or 
>> deletion of anything from the main tree.
> 
> I think my model (which is also Jon's, I think) is easier to read and 
> implement.
> 
>> How would you express the alternate setting of phy_type in a 
>> subtractive model?  You can't have two nodes with the same name and 
>> different phy_types, and you can't have two phy_type properties in one 
>> node.
> 
> The conditionals would have to be correct:
> 
> 
> phy-node [ if j22 = on ]
> {
>     phy-type = 1
> }
> 
> phy-node [ if j22 = off ]
> {
>     phy-type = 2
> }
> 
> Obviously, j22 can be either on or off, but never both.  If the DTS is 
> coded incorrectly, then it will have problems, but I think that's a fair 
> trade-off for the easier implementation.

OK, your syntax implies fairly significant changes to the dtc/dtb/u-boot 
(and possibly linux, depending on what detritus is left after u-boot 
does the selections).  Scott's syntax fits into the current fdt 
definition, tools, and blob-users with the exception that u-boot would 
have board specific selection code added, but that needs to be added 
regardless.

Best regards,
gvb