public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Greg KH <greg@kroah.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] PCI / OF linkage in sysfs
Date: Thu, 05 Feb 2004 10:50:33 +1100	[thread overview]
Message-ID: <1075938633.4029.53.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402041522390.2086@home.osdl.org>


> Where does this stop? Do we start doing the same for all different kinds 
> of buses, and all kinds of firmware? 
> 
> In other words, instead of having <n> different buses all know about <m>
> different kinds of firmware information that they really have nothing else
> to do with, it's much better to just have the <m> different kinds of 
> firmware information export their own information.
> 
> It just sounds _wrong_ to have the PCI layer have knowledge of OF. It has 
> nothing to do with OF. For OF information, you should go to the /sys/of 
> tree, which has the information that OF knows about (which may, of course, 
> then include the information about PCI devices).

I don't quite agree... There are cases for example (USB, Firewire) where
we could construct an OF path to be used by the bootloader setup without
having the OF information in the first place (for devices that weren't
plugged during boot typically). I do no intend to go that way for 2.6
though.

In both cases, we don't "have" the information.

OF doesn't have informations about the linux PCI layout (bus numbering can
be different between OF and linux for example) and PCI doesn't have information
about OF (except that on ppc64, pci_dev->arch_data points to the OF node).

However, the arch code provides a routine that can provide that mapping
PCI -> OF (and in _that_ direction, there is one to go the other way around,
but I hate it, it's not very reliable at the moment, though I could rewrite
it..., and on ppc64, this is the most efficient way too).

It's just about providing a pointer to OF node, not actual informations out
of the device-tree...

Ben.


 


  parent reply	other threads:[~2004-02-04 23:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-04  7:12 [PATCH] PCI / OF linkage in sysfs Benjamin Herrenschmidt
2004-02-04 22:08 ` Linus Torvalds
2004-02-04 23:13   ` Greg KH
2004-02-04 23:28     ` Benjamin Herrenschmidt
2004-02-04 23:39       ` Greg KH
2004-02-04 23:28     ` Linus Torvalds
2004-02-04 23:38       ` Greg KH
2004-02-04 23:50       ` Benjamin Herrenschmidt [this message]
2004-02-05  0:04         ` Linus Torvalds
2004-02-05  0:13           ` Benjamin Herrenschmidt
2004-02-05  0:39             ` Linus Torvalds
2004-02-05  0:50               ` Benjamin Herrenschmidt
2004-02-05 15:08               ` Eric W. Biederman
2004-02-04 23:26   ` Benjamin Herrenschmidt

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=1075938633.4029.53.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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