public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb•de>
To: linuxppc-dev@ozlabs•org
Cc: Christian Rund <Christian.Rund@de•ibm.com>,
	Hartmut Penner <HPENNER@de•ibm.com>,
	David Gibson <david@gibson•dropbear.id.au>
Subject: Re: [0/14] Ebony support, 2nd spi
Date: Tue, 20 Feb 2007 19:02:08 +0100	[thread overview]
Message-ID: <200702201902.09051.arnd@arndb.de> (raw)
In-Reply-To: <814781c1228541df932f8f4c7cc6ea89@kernel.crashing.org>

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

On Tuesday 20 February 2007 16:25, Segher Boessenkool wrote:
> >> And the ebony dts also has the a bus type of "ibm,opb" as well.
> >
> > We should really get a common name for these. I don't remember
> > what the discussions were, but it seems we came up with different
> > results for Axon and ppc4xx, which is very bad.
> 
> "Very bad"...  Well sure it's less than desirable, but
> we have to deal with this problem anyway already.
> 
> > Using type "ibm,opb" rather than just "opb" makes sense to me,
> > but I don't know if we already have shipping systems that use
> > "opb" here.
> >
> > There is probably a similar problem with the nodes for "plb4",
> > "plb5" and "ebc",
> 
> It makes sense for generic code to always if it is asked
> to match for "vendor-code,some-name" also to match on
> plain "some-name".  Well unless people start doing crazy
> things like naming something "vendor-code,pci" which
> isn't PCI compatible or something -- in that case there
> could be a function that matches on exact name only, or
> the caller can deal with it itself perhaps.
> 
> But in most cases the matching-without-prefix should work
> fine.

but is it really the right thing to call it "ibm,plb"
when the identical macro is used on amcc based systems?

I think that was our reasoning when we introduced the
code in linux to scan for "plb5", "plb4" and "opb" buses.

Changing the "device-type" now would result in the final
product to not work on the 2.6.20 kernel, which was released
with the code only scanning for the short names.

Still, it's probably a good idea to list both variants
in compatible, e.g.

type="plb4", compatible="ibm,plb\0ibm,plb4\0plb"

on CAB/axon, and

type="ibm,plb", compatible="ibm,plb4\0plb4\0plb"

on ebony and others. Do you think it makes sense to do it this
way, or should we rather adopt the axon style on the 440 boards?

> > as well as the "compatible" property of the
> > serial port, which, as you noted earlier is "ns16550" on
> > ebony and "ns16750" on axon, although it is exactly the same
> > macro.
> 
> So the "compatible" property should read ns16750, ns16550,
> ns16450, i8250.  The kernel really only needs the device
> to be compatible to the 8250; but since lots of device trees
> mention only the newer UART types, you have to match on those
> too.

Right, that sounds completely correct. I think I've done the
right thing in of_serial already. Christian, please check
what the firmware does today, and make sure to change it
accordingly.
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.

	Arnd <><

[-- Attachment #2: Type: text/html, Size: 3629 bytes --]

  reply	other threads:[~2007-02-20 18:02 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20  2:08 [0/14] Ebony support, 2nd spin David Gibson
2007-02-20  2:12 ` [PATCH 1/14] powerpc: Allow duplicate lmb_reserve() calls David Gibson
2007-02-20  2:12 ` [PATCH 4/14] Use resource_size_t for serial port IO addresses David Gibson
2007-02-20 14:44   ` Sergei Shtylyov
2007-02-21  0:19     ` David Gibson
2007-02-20  2:12 ` [PATCH 2/14] Automatically lmb_reserve() initrd David Gibson
2007-02-20  2:12 ` [PATCH 3/14] Define FIXED_PORT flag for serial_core David Gibson
2007-02-20  2:12 ` [PATCH 10/14] Early serial debug support for PPC44x David Gibson
2007-02-20 13:26   ` Segher Boessenkool
2007-02-21  0:20     ` David Gibson
2007-02-20  2:12 ` [PATCH 6/14] zImage: Cleanup and improve prep_kernel() David Gibson
2007-02-21  0:56   ` Geoff Levand
2007-02-20  2:12 ` [PATCH 5/14] zImage: Add more flexible gunzip convenience functions David Gibson
2007-02-21  0:56   ` Geoff Levand
2007-02-20  2:12 ` [PATCH 12/14] Add device tree for Ebony David Gibson
2007-02-20 15:09   ` Josh Boyer
2007-02-21  0:24     ` David Gibson
2007-02-21 12:25       ` Segher Boessenkool
2007-02-20 19:22   ` Yoder Stuart-B08248
2007-02-20 19:56     ` Segher Boessenkool
2007-02-21  4:57       ` David Gibson
2007-02-22  6:49       ` Segher Boessenkool
2007-02-20  2:12 ` [PATCH 11/14] Add arch/powerpc driver for UIC, PPC4xx interrupt controller David Gibson
2007-02-20  2:12 ` [PATCH 7/14] zImage: Cleanup and improve zImage entry point David Gibson
2007-02-21  0:57   ` Geoff Levand
2007-02-20  2:12 ` [PATCH 9/14] Port 44x MMU definitions to ARCH=powerpc David Gibson
2007-02-20  2:12 ` [PATCH 8/14] zImage wrapper for Ebony David Gibson
2007-02-20  2:12 ` [PATCH 14/14] Support for Ebony in arch/powerpc David Gibson
2007-02-20  2:12 ` [PATCH 13/14] Re-organize Kconfig code for 4xx " David Gibson
2007-02-20 13:51   ` Josh Boyer
2007-02-21  0:26     ` David Gibson
2007-02-20 14:05 ` [0/14] Ebony support, 2nd spin Josh Boyer
2007-02-20 14:14   ` Josh Boyer
2007-02-20 14:16   ` Arnd Bergmann
2007-02-20 14:46     ` Josh Boyer
2007-02-20 15:03       ` Josh Boyer
2007-02-20 15:07         ` [0/14] Ebony support, 2nd spi Arnd Bergmann
2007-02-20 15:17           ` Josh Boyer
2007-02-20 15:25           ` Segher Boessenkool
2007-02-20 18:02             ` Arnd Bergmann [this message]
2007-02-20 19:51               ` Segher Boessenkool
2007-02-20 20:29                 ` Josh Boyer
2007-02-21  0:38                   ` David Gibson
2007-02-21  1:30                     ` Josh Boyer
2007-02-21  0:44           ` David Gibson
2007-02-20 15:11         ` [0/14] Ebony support, 2nd spin Segher Boessenkool
2007-02-21  0:33         ` David Gibson
2007-02-21  0:35     ` David Gibson
2007-02-21  9:06       ` Arnd Bergmann
2007-02-25 23:57         ` David Gibson

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=200702201902.09051.arnd@arndb.de \
    --to=arnd@arndb$(echo .)de \
    --cc=Christian.Rund@de$(echo .)ibm.com \
    --cc=HPENNER@de$(echo .)ibm.com \
    --cc=david@gibson$(echo .)dropbear.id.au \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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