Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut <tnt@246tNt.com>]

Matt Sealey wrote:
> So, giving it some other name is no problem at all. Just add the name
> into the
> list. You can never get rid of the list, and adding entries.. well..
> it may
> look clumsy, but it is not wrong! Especially if you're the first to
> name it.
> Linux should, I am saying, match against what the firmware provides, not
> vice-versa. I don't think it's logical for firmware vendors to keep
> changing
> names or maintain these huge lists... 
For devices themselves (like serial, fec, ...), if there was only issues
there,
I must admit I'd consider just adding the other "compatible" property (look
at the current mpc52xx_uart.c driver, it has an entry only for the efika).
BUT :
 - I'd really prefer to have it with the standard name, we're early
enough to
   change it and I love consistency ;)
 - The "other" name must _not_ conflict with the official one (and here
   that's not the case, mpc5200-ata would trigger activation of 5200 errata
   correction for ATA ... )
 - You will anyway release an update so _why_ not change that, I haven't
   heard so far a single good reason why not ...
 - For more "system" parts (like bestcomm/sram/pic), there it's a lot more
   annoying and I just want the received dt to exactly fit.

Since some changes couldn't be handled by just adding en entry to the
of_match
table (chrp type, missing irqs, sram type, ...) , I needed fixups anyway
so I
implemented all the fixups I'd like to see and deal with it in a single
place,
so at the end I have things exactly like for other 52xx boards ...

> just because of a philosophical difference
> on 2 lines of code in Linux? Especially when the other OS guys have
> not made
> any fuss..
But did the other OS support other 52xx board ? (question, I really
don't know)

If it only needed another "compatible" entry in the driver list of a
couple of
driver, and that there was no way the fw could ever change, I think we would
have (reluctantly ;) done it, but the problem is both deeper and the vendor
(you ;) have the clear opportunity to fix it better.


    Sylvain