No mach-type for SHEEVAD?

[Tanmay Upadhyay]

On Monday 15 August 2011 02:30 PM, Eric Miao wrote:
> On Mon, Aug 15, 2011 at 4:53 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk>  wrote:
>> 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.
> To keep it fully in consistency, I'd like to change them all to gplugd, it's
> short and there's no ambiguity, and we'll stick to that name.
>
> I'm going to file a patch soon to fix all the occurrences of this confusing
> SHEEVAD. Once that's done, could you also help with the machine entry
> fix up, or should I file another entry to the database? Let me know.
>

I agree with Eric. It should be renamed as gplugd. It was named sheevad 
by mistake which we couldn't revert. Let me know if I need to generate 
any patch for this. Sorry for the late response. :( I was off for a 
couple of days.

Thanks,
Tanmay

>> 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).
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>