No mach-type for SHEEVAD?

[Russell King - ARM Linux]

On Mon, Aug 15, 2011 at 02:33:09PM +0800, Eric Miao wrote:
> On Mon, Aug 15, 2011 at 2:32 PM, Eric Miao <eric.miao at linaro.org> wrote:
> > Interestingly, gplugd has already been registered in the machine database
> > by Ofer.
> >
> > 2625    GURU_PLUGD      gplugd  Ofer Zaarur     mainlined
> 
> Russell,
> 
> Any idea if this entry would have any chance to be in -next?

Updating that file is becoming more of a burden because of all the crap
that's been accumulating in the database.  It used to be the case at
one time that I could just run a script which grabbed the file and
committed it.  Those days have long since passed.  It now requires manual
editing to remove all the crap which now exists.

For instance, these entries are never going to be added in their
current form:

+argonst_mp             MACH_HYNET_INE          HYNET_INE               1319
+riot_gx2               MACH_RIOT_VOX           RIOT_VOX                2577
+nautel_am35xx          MACH_NAUTEL_LPC3240     NAUTEL_LPC3240          2591
+gplugd                 MACH_SHEEVAD            SHEEVAD                 2625
+dig297                 MACH_OMAP3_CPS          OMAP3_CPS               2751
+lpc_evo                MACH_LPC2               LPC2                    2777
+ep3505                 MACH_EP3517             EP3517                  3056
+pydtd                  MACH_PYRAMID_TD         PYRAMID_TD              3295
+guf_vincell            MACH_GUF_PLANET         GUF_PLANET              3297
+geneva_b4              MACH_GENEVA_B           GENEVA_B                3308
+ea2468devkit           MACH_LPC2468OEM         LPC2468OEM              3389
+fe2478mblox            MACH_LPC2478MICROBLOX   LPC2478MICROBLOX        3391
+msm8960_mtp            MACH_MSM8960_MDP        MSM8960_MDP             3397
+omap_tabletblaze       MACH_OMAP_BLAZE         OMAP_BLAZE              3429
+ge863pro3              MACH_GE863              GE863                   3469
+arm                    MACH_ARM                ARM                     3573
+omap3                  MACH_OMAP3              OMAP3                   3574
+mach_ecog45            MACH_MACH_ECOG45        MACH_ECOG45             3595
+linux_pad              MACH_THEPAD             THEPAD                  3608
+imx                    MACH_IMX                IMX                     3611
+coreware_sam9260_      MACH_COREWARE_SAM9260_  COREWARE_SAM9260_       3634

because either they're an architecture name, a SoC name, or the
machine_is_xxx() does not match the MACH_TYPE_xxx and CONFIG_ macros
(because they haven't talked to me about changing them.)  That includes
the gplugd/sheevad stuff, which would (continue) to be deleted from the
file I merge for one of those reasons.

Now that the gplugd stuff is in, is it called gplugd or sheevad?
The registry entry above shows that it was called sheevad but it has
been changed to gplugd.  The file is called gplugd.c but it uses
sheevad internally.  So god only knows, it's a complete and utter mess.

So no, I'm not merging that entry until someone (a) tells me what it
should be, and (b) fixes stuff up to use the correct name.

That goes for the other entries, some of which I'm just going to expire
from the registry (like the ARM, IMX and OMAP3 ones) so I never have to
bother with them again.

I'm also thinking that the in-kernel mach-types will _only_ contain those
entries which have code in mainline - eliminating the "touched in the
last 12 months" criterion.  That certainly does reduce the amount of broken
entries to be dealt with down to just one entry (the gplugd one).