Re: [PATCH] Probe Efika platform before CHRP.

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

>> What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?
Note that the "compatible" modification we ask could simply be to add
the one
we require at the start of your compatible list, so linux will work and
the os using
the efika original will work as well.

>> Specifically for the "sound" and "ac97" discrepency, the "sound" device
>> type has some special implications for Open Firmware firmwares. It's
>> set to ac97 as it is NOT an OF or CHRP standard "sound" node and should
>> NOT be found as such in my personal opinion.
This "sound" <> "ac97" thing is not fixed in the patch I posted recently nor
in the nvramrc I sent to gentoo before that. The only visible thing was a
a small comment buried in a very experimental driver.
As soon as nicolas told me "sound" was the standard, I said OK so be it.

But for example the "memory" type you give to the SRAM node is imho
wrong. Because memory seems to be the standard type for "real" memory,
the one that's gonna be used for the system ...

> There are two issues here:
I'd say you can even split a little more :

 * Compatible / Type of nodes :
   We need a naming schema that's coherent across nodes and will allow to
   support coherently different boards. Your naming scheme just doesn't
   provide that. The one proposed by Grant does. Now it's possible you can
   find even better and we're open to suggestion.

 * Missing bits :
  - The interrupts property of the ac97 node are just not there. This
interrupt
     exist, it's hw and you can't just decide the driver can do without
it ...

 * Bugs : I see three,
  -  The one dwmv2 mentionned
  -  I noticed the compatible properties had double \0 at the end instead
     of single ones.
  -  Incorrect init of the PSC2 for AC97 and in the tree since the "gpio"
     node is not present, the address for port config is not found in the
     device tree. The current work around is a ugly hardcoded stuff in
     the driver itself that will never be merged upstream.


Regards,

     Sylvain


PS: In the end, a long nvramrc will do the trick ... so I don't care
much for me,
I'll always know what I need to put in it.