[PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

The very fact of matching device to driver by their
"name/type/compatible" list
is just the way it's done/specified in OF. Unless I'm deeply mistaken
(could always
happen, nobody's perfect heh) ...

The mpc5200b-psc-i2s and mpc5200-psc-i2s are in fact different device
... they
have different register set (compare both datasheet, you'll notice small
difference).
They just happen to be handled by the same driver and that driver
handles those
difference internally because they're small ...

So back to ethernet since you seem to like it ;) If fsl produce a new
chip (let's call
it mpc5321) , either it has _exactly_ the same interface (not a single
difference),
they you could call it mpc52xx in your device tree. Sure it looks weird but
sorry we can't predict the future and draft things for chips that don't
exist yet ...
If it's different, (even slighty, like it handles frame >2048 for
example), then
just give it a new name and add it as supported by the same driver. If
that's the
5321 entry that matched, then allow frames >2048.

>From what I've saw, if they can't even keep the same register set
between two
revision of the same controller, I doubt they will between chips. The I2C
controller is a good example, it's almost all the same between several
fsl chip,
except for the clocking selection. So as I see it, the I2C driver would have
several "compatible" match, for each different variation of the core. How
you name those instance is not really important as long as there is no
possible
conflicts.


You're proposing (if I understood correctly), that we first match the device
to a driver by using the normal name/type/compatible list but with very
broad names like "fsl-ethernet", then look at the SVR to know if it's in
fact
this driver we need to load (two fsl chip could have completly different
ethernet
cores) and also using SVR decide what "quirk" we need to apply.
Note I'm not even commenting yet, I first need to be sure of what you're
saying,
but the SVR thing will already not work if you're not in a SoC context ...


Regards,

    Sylvain


Matt Sealey wrote:
> Why is it so funny? I'd love to be enlightened rather than just plain
> insulted about it.
>
> I don't think any of that can be taken into account by simply giving things
> *names* and then having a 3-week discussion and committee hearing about how
> someone gave it a DIFFERENT name. It is even more strange to me, that nobody
> HAS a standard name for the devices on the MPC5200B, yet we are arguing
> about what would look nicer in the Linux source code?
>
> Small example:
>
> mpc5200b-fec, mpc5200-fec, mpc52xx-fec doesn't tell you anything, and
> then with the 5500 or 5120 or something, you then have worked out you
> named your original devices wrong, and now need to make it compatible
> with those? Do you switch features on and off based on a string comparison?
> What if a certain chip revision has a bug you need to work around (there
> are plenty in the original MPC5200!), is that meant to be encoded in the
> "compatible" property too, somehow? Or would you check the SVR too? If
> you would check that, why not use this as the basis of the support for
> that driver? For a PCI device, you are given basically a 32-bit UID for
> each device, which is attached to a unique domain, host, bus, device
> and function number. You manage well here without giving it names.
>
> An Intel processor might return a string for CPUID - mine says it's a
> "Intel(R) Pentium(R) M 1.70GHz". That string is absolutely useless in
> determining it's compatibility. It's just a name. It may as well say
> "Fight Famine In Rwanda" for all the good it does.
>
> I think there are better ways and better places to encode certain
> properties of the system as a whole (as the system is a lot more than
> just that single chip) than having a bunch of strings in a property
> which claim that it is compatible with something else, strictly defined
> naming conventions and so on across chip ranges. Although we are talking
> here mostly about two boards with the same chip basically - Lite5200
> and Efika, there may be more boards with similar hardware supported,
> extra hardware supported, new chips which look very much like the 5200
> but have slightly different or bugfixed operation (and here is my point)
> which I do not think you can encode in names and compatibile names.
>
>