From: Ralf Baechle <ralf@linux-mips.org>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>,
linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][MIPS] mips_machtype define as one group
Date: Mon, 14 Jul 2008 12:27:32 +0100 [thread overview]
Message-ID: <20080714112732.GD10379@linux-mips.org> (raw)
In-Reply-To: <20080712143225.GA9053@alpha.franken.de>
On Sat, Jul 12, 2008 at 04:32:25PM +0200, Thomas Bogendoerfer wrote:
> > mips_machtype is still used in some places.
> > Should we check first whether it can be removed?
>
> I don't know Ralf's opinion about the removal, but if he agrees, we
> should just look for the remaining usage cases and see, if it could
> be resolved in a differnt way.
I was also planning to get rid of it. A while ago I already removed
mips_machgroup. This was easy with no real user remaining. Removing
mips_machtype turned out to be slightly trickier since there are actual
users remaining.
> Here is my first look at all the various MACH_XXX:
>
> > #define MACH_ACER_PICA_61 0 /* Acer PICA-61 (PICA1) */
> > #define MACH_MIPS_MAGNUM_4000 1 /* Mips Magnum 4000 "RC4030" */
> > #define MACH_OLIVETTI_M700 2 /* Olivetti M700-10 (-15 ??) */
>
> all three are in arch/mips/fw/arc/identify.c, but only MACH_MIPS_MAGNUM_4000
> is used in arch/mips/jazz/setup.c. But the usage in arch/mips/jazz/setup.c
> is not quite correct and I'd like to remove it there.
>
> > #define MACH_DSUNKNOWN 0
> > #define MACH_DS23100 1 /* DECstation 2100 or 3100 */
> > #define MACH_DS5100 2 /* DECsystem 5100 */
> > #define MACH_DS5000_200 3 /* DECstation 5000/200 */
> > #define MACH_DS5000_1XX 4 /* DECstation 5000/120, 125, 133, 150*/
> > #define MACH_DS5000_XX 5 /* DECstation 5000/20, 25, 33, 50 */
> > #define MACH_DS5000_2X0 6 /* DECstation 5000/240, 260 */
> > #define MACH_DS5400 7 /* DECsystem 5400 */
> > #define MACH_DS5500 8 /* DECsystem 5500 */
> > #define MACH_DS5800 9 /* DECsystem 5800 */
> > #define MACH_DS5900 10 /* DECsystem 5900 */
>
> that's the only poweruser. I'd rename mips_machtype to dec_machtype and
> just use it for decstation as it is today.
Yep.
> > #define MACH_SNI_RM200_PCI 0 /* RM200/RM300/RM400 PCI series */
>
> only in arch/mips/fw/arc/identify
>
> > #define MACH_SGI_IP22 0 /* Indy, Indigo2, Challenge S */
> > #define MACH_SGI_IP27 1 /* Origin 200, Origin 2000, Onyx 2 */
> > #define MACH_SGI_IP28 2 /* Indigo2 Impact */
> > #define MACH_SGI_IP32 3 /* O2 */
> > #define MACH_SGI_IP30 4 /* Octane, Octane2 */
>
> all SGI defines are only in arch/mips/fw/arc/identify
>
> > #define MACH_PALLAS 0
> > #define MACH_TOPAS 1
> > #define MACH_JMR 2
> > #define MACH_TOSHIBA_JMR3927 3 /* JMR-TX3927 CPU/IO board */
>
> these 4 are unused
>
> > #define MACH_TOSHIBA_RBTX4927 4
> > #define MACH_TOSHIBA_RBTX4937 5
> > #define MACH_TOSHIBA_RBTX4938 6
>
> there is only one usage for that, so moving the code for setting of
> mips_machtype from toshiba_rbtx4927_prom.c to toshiba_rbtx4927_setup.c
> will make that defines obsolete.
>
> > #define MACH_LASAT_100 0 /* Masquerade II/SP100/SP50/SP25 */
> > #define MACH_LASAT_200 1 /* Masquerade PRO/SP200 */
>
> these are used, but could easily replaced by checking for CPU type
> (see lasat/prom.c how LASAT_100/LASAT_200 get selected).
That or a platform-private variable.
> > #define MACH_NEC_MARKEINS 0 /* NEC EMMA2RH Mark-eins */
>
> unused
I guess people blindly following Jun's old porting howto ...
> > #define MACH_MSP4200_EVAL 0 /* PMC-Sierra MSP4200 Evaluation */
> > #define MACH_MSP4200_GW 1 /* PMC-Sierra MSP4200 Gateway demo */
> > #define MACH_MSP4200_FPGA 2 /* PMC-Sierra MSP4200 Emulation */
> > #define MACH_MSP7120_EVAL 3 /* PMC-Sierra MSP7120 Evaluation */
> > #define MACH_MSP7120_GW 4 /* PMC-Sierra MSP7120 Residential GW */
> > #define MACH_MSP7120_FPGA 5 /* PMC-Sierra MSP7120 Emulation */
> > #define MACH_MSP_OTHER 255 /* PMC-Sierra unknown board type */
>
> this looks a little messy. The _EVAL and _GW defines are more a kernel
> config option than a real machine type and all they are good for is
> selecting whether there is a second serial port and which speed the
> speed kgdb should use. I'd remove that all and just set a flag, whether
> there is a second uart. I'd remove the kgbd usage, but if it's really
> needed adding another flag/variabne would do the trick.
When I looked at it last time I found that some of the mips_machtype uses
might be replaced with platform devices.
Ralf
prev parent reply other threads:[~2008-07-14 11:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-11 13:57 [PATCH][MIPS] mips_machtype define as one group Yoichi Yuasa
2008-07-11 14:32 ` Thomas Bogendoerfer
2008-07-12 8:47 ` Yoichi Yuasa
2008-07-12 8:47 ` Yoichi Yuasa
2008-07-12 14:32 ` Thomas Bogendoerfer
2008-07-13 10:45 ` Yoichi Yuasa
2008-07-13 10:45 ` Yoichi Yuasa
2008-07-13 13:13 ` Atsushi Nemoto
2008-07-14 11:27 ` Ralf Baechle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080714112732.GD10379@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=linux-mips@linux-mips.org \
--cc=tsbogend@alpha.franken.de \
--cc=yoichi_yuasa@tripeaks.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox