[PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Ok, let's try to at least be a little productive:

Could you tell us at least what in that list will be taken care of,
what you might consider and what you really will never change
while you're standing ;)

Her we go :

1) What I think should absolutely be fixed : (non compliancy
with the ieee1275 document are marked as bug) :
 - PSC init (for PSC2 and PSC6 you said as well): Theses
   are obviously bugs, no argument there.
 - Missing IRQ for the sound node : Again, this is obviously
   missing, the interrupt does exists and it should be in the
   dt, whether or not you think the driver will use it or not.
 - Partition numbering problem (again, an obvious bug)
 - Double \0 : This one is a bug (just confirmed it re-reading
   the specs) Altough I must admit the kernel just won't care
   it's nevertheless a bug and should be
 - "chrp" type : If I understood correctly your previous mail
   you're ok with it.
 - "memory" type of the SRAM: I quote the 1275.pdf, section
   3.7.6 : "In this context, 'memory' refers to traditional
   RAM, suitable for temporary storage of data". I think we
   can agree sram is not conventionnal RAM. You're free (and
   should) still use the reg and available property but not
   the type ram. I must also say that the current fixup I
   implemented doesn't really work because this can only be
   fixed too late ... (node already processed and added as
   normal memory).

2) What I'd really like to see fixed (but that I can't mark as
'bugs' as obviously as the other)
 - The compatible properties of system node (like sram,
   bestcomm and pic) should at least include the mpc52xx-...
   strings as defined in the 'linux' bindings. Better than
   include, be exacty what has been defined but include would
   "do the trick".



3) 'real' Device compatible names : Those can be handled in
the driver, eventually differentiating from other using the
name ... (Although the ata node is really boring because it
_perfectly_ match the defined binding of the 5200 ATA ...)

Without (1), we would need a nvramrc (to fix very early stuff),
and since it's needed, might as well fix everything in nvramrc.
With only (1), we will still need a fixup, but that could
be done in efika_fixup in prom_init.c, since we need fixup
there, we will probably do everything there.
With (1) & (2) the efika will boot, just some driver won't
work so we need to add some more entry in their of_match
but that's acceptable.

> When it doesn't make any difference at all ("sram" and "memory" and
> "ac97" to "sound", the difference between mpc5200-blah and mpc5200b-blah
> and a couple of stray null characters) I feel there's no point whatsoever
> in doing it when it entails that much work.
Well, you're gonna need to change _some_ strings at least (if
not, I'm just loosing my time here ...) I can hardly believe
changing a string to another is that hard, especially if it's
to comply to the specification you claim to be compatible with ;p

(and 'ac97' should be 'sound' as it is now, certainly don't go
change it ;)

> We can't fix the 1.3 firmware, it's already on the
> first production batch, end of story. 
You mean the new firmware can't be flashed to the old boards ?



    Sylvain


PS: I know there are already fixup but ... my mistake I keep
dreaming of a world when things do get fixed without hacks ;-)