All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] AmigaOne device tree source v2
Date: Mon, 3 Sep 2007 20:12:34 +1000	[thread overview]
Message-ID: <20070903101234.GA12212@localhost.localdomain> (raw)
In-Reply-To: <ad58529dfd4a248ab904c2c5871258bf@kernel.crashing.org>

On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
> >>> 		host@0 {
> >>
> >> The unit address (after the @) should be derived from the first range
> >> listed in the 'reg' property.  It's a bus address, not a slot number.
> >
> > Actually... on PCI, the unit address is often the slot number, or
> > rather, "slot,function" with the second part ommited for non
> > multifunction devices.
> 
> Not slot number, but "device-id".  Like, if you have actual
> PCI plugin slots on your board, they likely have device ids
> 16,17,...; but slot numbers 1, 2, 3 (little labels on the box).
> 
> David's point is that unit addresses are not random numbers.

You flatter me.  But i'll happily make that point, now that my
ignorance is slightly alleviated ;-).

> >> All these devices should have unit addresses.
> >
> >  ... which for ISA are generally in the form iPORT (8242@i60 for
> > example) though I've seen the "i" ommited. Not terribly important I
> > would say but better to follow the spec.
> 
> Omitting the "i" is perfectly in line with the spec :-)
> 
> >>> 		ide@7,1 {
> >>
> >> This will need a compatible property, at least.
> >
> > Actually, it's a PCI device, it can have a compatible property based on
> > the generic PCI device compatible property generation as defined in the
> > OF PCI binding. Since that's just derived from other fields, I suppose
> > it can be omitted in a flat DT. It would be -nice- to have a more
> > explicit cpmpatible property but in that case, not absolutely necessary
> > since that device will be probed as PCI anyway.
> 
> Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
> compatible property though, for good measure.  Anything else isn't
> all that useful I think.

Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all.  Depends on whether there's anything
interesting in the omitted interrupt routing information.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2007-09-03 10:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 17:50 [RFC] AmigaOne device tree source v2 Gerhard Pircher
2007-09-03  1:34 ` David Gibson
2007-09-03  8:41   ` Benjamin Herrenschmidt
2007-09-03 10:02     ` Segher Boessenkool
2007-09-03 10:12       ` David Gibson [this message]
2007-09-03 16:11         ` Gerhard Pircher
2007-09-03 22:52           ` Segher Boessenkool
2007-09-04  0:27             ` David Gibson
2007-09-06 13:31               ` Segher Boessenkool
2007-09-04 12:20             ` Gerhard Pircher
2007-09-06 13:41               ` Segher Boessenkool
2007-09-03 14:58   ` Gerhard Pircher
2007-09-03 22:32     ` Segher Boessenkool
2007-09-04 11:49       ` Gerhard Pircher
2007-09-05  2:48         ` David Gibson
2007-09-05 11:54           ` Gerhard Pircher
2007-09-06 14:00             ` Segher Boessenkool
2007-09-06 14:09               ` Sven Luther
2007-09-06 14:42                 ` Segher Boessenkool
2007-09-06 13:56           ` Segher Boessenkool
2007-09-06 14:15             ` PCI I/O space -- reg or ranges? Scott Wood
2007-09-06 20:51               ` Gerhard Pircher
2007-09-06 21:01                 ` Segher Boessenkool
2007-09-07  0:20             ` [RFC] AmigaOne device tree source v2 David Gibson
2007-09-06 13:36         ` Segher Boessenkool
2007-09-06 21:09           ` Gerhard Pircher
2007-09-07  0:21           ` 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=20070903101234.GA12212@localhost.localdomain \
    --to=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=segher@kernel.crashing.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 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.