On Saturday, January 27, 2007 8:19 am, Matthew Wilcox wrote:
> > 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
On Saturday, January 27, 2007 8:19 am, Matthew Wilcox wrote:
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
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
> > >
On Thu, Jan 18, 2007 at 11:58:05PM -0700, Grant Grundler wrote:
> Other per bus attributes might be address routing, VGA routing enabled,
> Fast-back-to-back enabled. PCI-X bridges and PCI-e bridges might also
> advertise data related to MMRBC and similar onboard buffer mgt behaviors.
>
> ISTR,
On Thu, Jan 18, 2007 at 11:58:05PM -0700, Grant Grundler wrote:
Other per bus attributes might be address routing, VGA routing enabled,
Fast-back-to-back enabled. PCI-X bridges and PCI-e bridges might also
advertise data related to MMRBC and similar onboard buffer mgt behaviors.
ISTR, IBM
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
On Tue, 2007-01-23 at 16:22 -0800, Tim Pepper wrote:
> On 1/18/07, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > Hm, only ia64 enables that option. Matthew, do you care about those
> > files?
>
> Given the ia64 nature, unless benh was truly wanting to do something
> or ppc64, IBM's big NUMA boxes
On 1/18/07, Greg KH <[EMAIL PROTECTED]> wrote:
Hm, only ia64 enables that option. Matthew, do you care about those
files?
Given the ia64 nature, unless benh was truly wanting to do something
or ppc64, IBM's big NUMA boxes are pretty unlikely to care.
Tim
-
To unsubscribe from this list:
On 1/18/07, Greg KH [EMAIL PROTECTED] wrote:
Hm, only ia64 enables that option. Matthew, do you care about those
files?
Given the ia64 nature, unless benh was truly wanting to do something
or ppc64, IBM's big NUMA boxes are pretty unlikely to care.
Tim
-
To unsubscribe from this list: send
On Tue, 2007-01-23 at 16:22 -0800, Tim Pepper wrote:
On 1/18/07, Greg KH [EMAIL PROTECTED] wrote:
Hm, only ia64 enables that option. Matthew, do you care about those
files?
Given the ia64 nature, unless benh was truly wanting to do something
or ppc64, IBM's big NUMA boxes are pretty
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
Hello!
> 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.
I originally didn't realize that we already represent devices on the
subordinate bus
On Thursday, January 18, 2007 1:00 am, 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
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
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
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
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
On Thursday, January 18, 2007 1:00 am, 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
Hello!
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.
I originally didn't realize that we already represent devices on the
subordinate bus as
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
On Wed, Jan 17, 2007 at 07:23:52PM -0700, Matthew Wilcox wrote:
> On Wed, Jan 17, 2007 at 04:53:45PM -0800, Greg KH wrote:
> > I'm trying to clean up all the usages of struct class_device to use
> > struct device, and I ran into the pci_bus code. Right now you create a
> > symlink called "bridge"
On Wed, Jan 17, 2007 at 04:53:45PM -0800, Greg KH wrote:
> I'm trying to clean up all the usages of struct class_device to use
> struct device, and I ran into the pci_bus code. Right now you create a
> symlink called "bridge" under the /sys/class/pci_bus/:XX/ directory
> to the pci device
Hi Matt,
I'm trying to clean up all the usages of struct class_device to use
struct device, and I ran into the pci_bus code. Right now you create a
symlink called "bridge" under the /sys/class/pci_bus/:XX/ directory
to the pci device that is the bridge.
This is messy to try to convert to
Hi Matt,
I'm trying to clean up all the usages of struct class_device to use
struct device, and I ran into the pci_bus code. Right now you create a
symlink called bridge under the /sys/class/pci_bus/:XX/ directory
to the pci device that is the bridge.
This is messy to try to convert to
On Wed, Jan 17, 2007 at 04:53:45PM -0800, Greg KH wrote:
I'm trying to clean up all the usages of struct class_device to use
struct device, and I ran into the pci_bus code. Right now you create a
symlink called bridge under the /sys/class/pci_bus/:XX/ directory
to the pci device that is
On Wed, Jan 17, 2007 at 07:23:52PM -0700, Matthew Wilcox wrote:
On Wed, Jan 17, 2007 at 04:53:45PM -0800, Greg KH wrote:
I'm trying to clean up all the usages of struct class_device to use
struct device, and I ran into the pci_bus code. Right now you create a
symlink called bridge under
26 matches
Mail list logo
