linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: linux-galileo@source.mvista.com, linuxppc-dev@lists.linuxppc.org
Subject: Re: [PATCH] My GT-64260 enhancements
Date: Sat, 16 Mar 02 23:03:13 PST	[thread overview]
Message-ID: <0203170703.AA00587@ivan.Harhan.ORG> (raw)


Tom Rini <trini@kernel.crashing.org> wrote:

> I'd be willing to bet $5 it's from Troy.

OK...

> IMHO, 9600 is the defacto
> default rate,

YES!!!

> but Troy likes 'fast' serial consoles.

But Troy's personal preferences shouldn't affect the public tree, should they?
If 9600 is the default baud rate for all of Linux, why should one port be
different? Who is the maintainer with authority over this? Would s/he accept a
patch to axe that 115200 line out?

> Right, And boards other than the EV-64260-BP use the zImage wrapper,
> like the Motorola MVP.
>
> [...]
>
> I'm saying that if nothing else the comment is wrong or slightly
> misleading, as it's not 'just' for the EV-64260-BP, it's for the
> Motorola MVP as well, and possibly other boards in the future which have
> to use !(StarMON || PPCBoot).

But right now there is no MVP in 2_4_devel, so for 2_4_devel as it is right now
it's for EV-64260-BP only. If/then someone adds another port that needs the
same ugly hack in the zImage wrapper, they can add -o "$CONFIG_MYBOARD" = "y"
to it. But it still won't be for all GT-64260 boards, like it won't be for my
StarMON-only boards.

> Well, (and I do need to check out the _galileo tree) iirc the stuff to
> support that option is in one of the generic files.  Or generic to the
> work currently in there.  If that's the case, and you're explicitly not
> going to support it in your files (and ports) then add a -a
> "$CONFIG_xxx" = "n" .

You still don't get it. I find that logic offensive. It makes me not want to
use the GT-64260 in my designs because your logic implies that if someone uses
the GT-64260 s/he wants to do things your way. Just because there is a generic
file doesn't mean I'm obligated to use it in my ports. I can build a board with
a GT-64260A in an epoxy-filled tamper-resistant module where StarMON sets up
the system environment and the Linux port looks just like the Adirondack one.
You'll never be able to tell that there even is a GT-64260 in that system!

Think of StarMON like OF. That's a good model, as StarMON is indeed a real
competitor to OF. Just like on OF machines the device tree tells you where
system features are located and you don't really know or care what chips
implement these features and what magic the firmware had to do to make it all
work, so with StarMON. You have so much memory, a PCI bus here, a UART there,
etc., and you don't really need to know whether it's a CPC710 or a GT-64260.

I want to design my ports like this: OK, here is my hardware feature set, let's
write the files telling Linux how to make use of it. You are forcing me to
think differently: OK, here are the chips on my board, let's see what generic
files they have for them. But I don't want to do my ports your way, and I find
it offensive that the GT-64260 code you have in the tree now essentially forces
me how to think.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

         reply	other threads:[~2002-03-17  7:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-15  6:11 [PATCH] My GT-64260 enhancements Michael Sokolov
2002-03-15 17:04 ` Tom Rini
2002-03-16  8:21   ` Michael Sokolov
2002-03-16 15:15     ` Tom Rini
2002-03-17  7:03       ` Michael Sokolov [this message]
2002-03-17 17:51         ` Dan Malek
2002-03-17 20:24           ` David Monro
2002-03-18 15:00         ` Tom Rini
2002-03-18 15:53       ` [Linux-galileo] " Mark A. Greer
2002-03-18 18:48         ` Tom Rini
2002-03-15 20:05 ` [Linux-galileo] " Nye Liu
  -- strict thread matches above, loose matches on Subject: below --
2002-03-17 18:16 Michael Sokolov
2002-03-17 18:42 ` Dan Malek
2002-03-17 20:10   ` Michael Sokolov
2002-03-18 14:54     ` Tom Rini
2002-03-20  0:46 Michael Sokolov
2002-03-19 22:55 ` Mark A. Greer

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=0203170703.AA00587@ivan.Harhan.ORG \
    --to=msokolov@ivan.harhan.org \
    --cc=linux-galileo@source.mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /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;
as well as URLs for NNTP newsgroup(s).