On 08/13/2018 03:39 PM, Tom Rini wrote: [...] >>>> Next step is to upstream the DT >>>> changes to Linux kernel, then sync the changes to U-Boot to satisfy >>>> this obsession - using exactly the same DT as Linux. >>> >>> This is not gonna happen. >>> >>> Sorry, you're really just wasting my time with this foolishness. If >>> U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is >>> broken and must be fixed. So far I only see you attacking this patch and >>> trying to pull in everything you can do avoid accepting this patch or >>> providing a better alternative. This is not a constructive discussion, >>> so I stop here. >> >> The fix in this patch is purely hack, period. > > Lets step back for a moment. > > First, U-Boot intends to be, in the case where a relevant DTS file > exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, > u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that > are omitted for various reasons).
Right, which doesn't apply here. None of those u-boot,... props are needed in this case. > Second, I've asked before (both in this thread and on IRC), and not > gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and > _this_ DT node need to be matched and populate some data > structures". You did get an answer to that on irc from George. Looks like of_pci_find_child_device() indrivers/pci/of.c > Marek's patch seems to be, in short "here's where U-Boot > needs to wire things up". Bin has said that no, the function in > question is for other things. I disagree with this. It's a bind function and assigns other parameters of the driver instance too. > I think knowing where Linux does this > would be instructive to figure out where we need to have some additional > logic added OR we can make some cost/benefit analysis to see if it makes > more sense overall to add compatibles to some nodes rather than add to > the binary size. Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one). -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
