tree 0a559cf56013fb423e50a5b8343e18d9893d1153
parent d20dfdd4d21d7cae2cbc29e91674ea45f4a025d6
author David Gibson <david@gibson.dropbear.id.au> 1318459231 +0000
committer Alexander Graf <agraf@suse.de> 1319991114 +0100

ppc: Remove broken partial PVR matching

The ppc target contains a ppc_find_by_pvr() function, which looks up a
CPU spec based on a PVR (that is, based on the value in the target cpu's
Processor Version Register).  PVR values contain information on both the
cpu model (upper 16 bits, usually) and on the precise revision (low 16
bits, usually).

ppc_find_by_pvr, as well as making exact PVR matches, attempts to find
"close" PVR matches, when we don't have a CPU spec for the exact revision
specified.  This sounds like a good idea, execpt that the current logic
is completely nonsensical.

It seems to assume CPU families are subdivided bit by bit in the PVR in a
way they just aren't.  Specifically, it requires a match on all bits of the
specified pvr up to the last non-zero bit.  This has the bizarre effect
that when the low bits are simply a sequential revision number (a common
though not universal pattern), then odd specified revisions must be matched
exactly, whereas even specified revisions will also match the next odd
revision, likewise for powers of 4, 8 and so forth.

To correctly do inexact matching we'd need to re-organize the table of CPU
specs to include a mask showing what PVR range the spec is compatible with
(similar to the cputable code in the Linux kernel).

For now, just remove the bogosity by only permitting exact PVR matches.
That at least makes the matching simple and consistent.  If we need inexact
matching we can add the necessary per-subfamily masks later.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>