[PATCH 2/4] of: DT quirks infrastructure

[Guenter Roeck]

On Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote:
> Hi Guenter,
> 
> On 02/20/2015 11:47 AM, Guenter Roeck wrote:
> 
> [...]
> 
> > I am open to hearing your suggestions for our use case, where the CPU card with
> > the eeprom is manufactured separately from its carier cards.
> 
> I think your use case may be more compelling than two flavors of Beaglebone
> (one of which is pretty much a dead stick), but it's also less clear what your
> design constraints are (not that I really want to know, 'cause I don't).
> 
> But the logical extension of this is an N-way dtb that supports unrelated SOCs,
> and I think most would agree that's not an acceptable outcome.
> 
With this logic you can pretty much refuse to accept anything new, anywhere.
Including everything old, for that matter.

Food can be abused to poison people, therefore no one should be permitted to
distribute food. Houses can be abused to falsely imprison people, therefore
no one should live in houses. And don't even start talking about guns.
Everything can be abused, therefore we should not do anything.

Discussions about possible abuse are for sure valid, and reducing the potential
for abuse is a worthy goal, but not as argument to reject a solution for an
existing and real roblem outright.

> My thought was that every design that can afford an EEPROM to probe can afford
> a bootloader to select the appropriate dtb, and can afford the extra space
> required for multiple dtbs.
> 
There are many more use cases where this is simply not the case. Another one,
for example, is a system where the devicetree is loaded through u-boot using
tftp. In this case, u-boot would have some information about the hardware
to request the correct devicetree file, but it may not know about hardware
variants.

Sure, one could solve that problem by making u-boot aware of such variants
and maintaining a large number of dtb files as you suggest. That means,
however, that there would be that need to maintain all those dtb files
just to address minor differences, and having modify every piece of the
system for each new variant. In essence you put a lot of burden on pretty
much everyone from software to manufacturing to testing, plus possibly
hardware, just for the purpose of rejecting a relatively simple solution
for the problem Pantelis' patch set is trying to address.

Ultimately, no matter what the kernel community ends up doing, Pantelis'
solution or something similar _will_ find its way into our system.
I would very much prefer to have the code upstream, but we will carry
his patches along in our vendor branch if necessary. The functionality
and its benefits for our development, manufacturing, and testing process
are way too valuable to ignore, and it actually solves problems for which
we don't have an acceptable solution today. I would be quite surprised
if other vendors would not end up doing the same.

Guenter