All of lore.kernel.org
 help / color / mirror / Atom feed
From: tsbogend@alpha.franken.de (Thomas Bogendoerfer)
To: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][MIPS] mips_machtype define as one group
Date: Sat, 12 Jul 2008 16:32:25 +0200	[thread overview]
Message-ID: <20080712143225.GA9053@alpha.franken.de> (raw)
In-Reply-To: <20080712174741.c4dd3149.yoichi_yuasa@tripeaks.co.jp>

On Sat, Jul 12, 2008 at 05:47:41PM +0900, Yoichi Yuasa wrote:
> On Fri, 11 Jul 2008 16:32:35 +0200
> tsbogend@alpha.franken.de (Thomas Bogendoerfer) wrote:
> 
> > On Fri, Jul 11, 2008 at 10:57:17PM +0900, Yoichi Yuasa wrote:
> > > mips_machtype define as one group.
> > 
> > wouldn't it make more sense to kill that completly ?
> 
> 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.

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.

> #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).

> #define  MACH_NEC_MARKEINS      0     /* NEC EMMA2RH Mark-eins */

unused

> #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.

Anything I missed ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

  reply	other threads:[~2008-07-12 14:32 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 [this message]
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

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=20080712143225.GA9053@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.