From: Matthew Wilcox <matthew@wil.cx>
To: Greg KH <greg@kroah.com>
Cc: Martin Mares <mj@ucw.cz>,
colpatch@us.ibm.com, linux-kernel@vger.kernel.org,
linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [RFC] pci_bus conversion to struct device
Date: Sat, 27 Jan 2007 09:19:35 -0700 [thread overview]
Message-ID: <20070127161935.GB10427@parisc-linux.org> (raw)
In-Reply-To: <20070118090044.GA23596@kroah.com>
On Thu, Jan 18, 2007 at 01:00:44AM -0800, Greg KH wrote:
> On Thu, Jan 18, 2007 at 09:14:06AM +0100, Martin Mares wrote:
> > Hello!
> >
> > > I recommend we just delete the pci_bus class. I don't think it serves
> > > any useful purpose. The bridge can be inferred frmo the sysfs hierarchy
> > > (not to mention lspci will tell you). The cpuaffinity file should be
> > > moved from the bus to the device -- it really doesn't make any sense to
> > > talk about which cpu a bus is affine to, only a device.
> >
> > It doesn't seem to serve any useful purpose other than the affinity now,
> > but I still think that it conceptually belongs there, because it makes
> > sense to have per-bus attributes. For example, in the future we could
> > show data width and signalling speed.
Data width is kind of hard to figure out since it's negotiated per
transaction. One could conceive of a device which only does 32-bit
transactions to some addresses, and 64-bit transactions to others.
What I've done in recent patches is make these kinds of attributes
available per slot.
> So, if it were to stay, where in the tree should it be? Hanging off of
> the pci device that is the bridge? Or just placing these files within
> the pci device directory itself, as it is the bridge.
/sys/bus/pci/busses ?
> There are also some "legacy io" binary sysfs files in these directories
> for those platforms that support it (#ifdef HAVE_PCI_LEGACY), and I'm
> guessing that there is some user for them out there, otherwise they
> would not have been added...
>
> Hm, only ia64 enables that option. Matthew, do you care about those
> files?
I think they were added for Altix ... not sure who uses them. Maybe X?
next prev parent reply other threads:[~2007-01-27 16:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-18 0:53 [RFC] pci_bus conversion to struct device Greg KH
2007-01-18 2:23 ` Matthew Wilcox
2007-01-18 3:31 ` Greg KH
2007-01-18 8:14 ` Martin Mares
2007-01-18 9:00 ` Greg KH
2007-01-18 18:23 ` Jesse Barnes
2007-01-18 21:01 ` Martin Mares
2007-01-24 0:22 ` Tim Pepper
2007-01-24 0:47 ` Benjamin Herrenschmidt
2007-01-27 16:19 ` Matthew Wilcox [this message]
2007-01-29 19:13 ` Jesse Barnes
2007-01-19 6:58 ` Grant Grundler
2007-01-27 16:16 ` Matthew Wilcox
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=20070127161935.GB10427@parisc-linux.org \
--to=matthew@wil.cx \
--cc=colpatch@us.ibm.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=mj@ucw.cz \
/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.