Richard Henderson wrote:
> On Wed, Jun 27, 2001 at 02:07:37PM -0500, Tom Gall wrote:
> > Consider also in drivers/pci/pci.c:
> >
> > The function pci_bus_exists checks based on bus numbers. This function is
> > of course used by pci_alloc_primary_bus, which is in turn used by
> > pci_scan_bus.
Richard Henderson wrote:
On Wed, Jun 27, 2001 at 02:07:37PM -0500, Tom Gall wrote:
Consider also in drivers/pci/pci.c:
The function pci_bus_exists checks based on bus numbers. This function is
of course used by pci_alloc_primary_bus, which is in turn used by
pci_scan_bus. As is
"Khachaturov, Vassilii" wrote:
>
> On Wed, 27 Jun 2001, Jeff Garzik wrote:
>
> > However, I think the driver (only going by your
> description) would be
> > more correct to use a pointer to struct pci_dev. We have a
> token in the
> > kernel that is guaranteed 100% unique to any given PCI
On Wed, 27 Jun 2001, Jeff Garzik wrote:
> However, I think the driver (only going by your
description) would be
> more correct to use a pointer to struct pci_dev. We have a
token in the
> kernel that is guaranteed 100% unique to any given PCI device: the
> pointer to its struct pci_dev.
Is
Tom Gall wrote:
> Gérard Roudier wrote:
> > The driver checks against PCI bus+dev+func in 2 situations:
> >
> > 1) To apply the boot order that user can set up in the controller NVRAMs.
> > 2) To detect buggy double reporting of the same device by the kernel PCI
> >code (this made lot of
Gérard Roudier wrote:
>
> On Wed, 27 Jun 2001, Jeff Garzik wrote:
>
> > Tom Gall wrote:
> > > Well you have device drivers like the symbios scsi driver for instance that
> > > tries to determine if it's seen a card before. It does this by looking at the
> > > bus,dev etc numbers... It's quite
Gérard Roudier wrote:
> The driver checks against PCI bus+dev+func in 2 situations:
>
> 1) To apply the boot order that user can set up in the controller NVRAMs.
> 2) To detect buggy double reporting of the same device by the kernel PCI
>code (this made lot of troubles at some time).
Cool.
On Wed, 27 Jun 2001, Jeff Garzik wrote:
> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers... It's quite reasonable for two different scsi
On Wed, 27 Jun 2001, Jeff Garzik wrote:
Tom Gall wrote:
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers... It's quite reasonable for two different scsi cards to
Gérard Roudier wrote:
The driver checks against PCI bus+dev+func in 2 situations:
1) To apply the boot order that user can set up in the controller NVRAMs.
2) To detect buggy double reporting of the same device by the kernel PCI
code (this made lot of troubles at some time).
Cool. The
Gérard Roudier wrote:
On Wed, 27 Jun 2001, Jeff Garzik wrote:
Tom Gall wrote:
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers... It's quite reasonable for
Tom Gall wrote:
Gérard Roudier wrote:
The driver checks against PCI bus+dev+func in 2 situations:
1) To apply the boot order that user can set up in the controller NVRAMs.
2) To detect buggy double reporting of the same device by the kernel PCI
code (this made lot of troubles at
On Wed, 27 Jun 2001, Jeff Garzik wrote:
However, I think the driver (only going by your
description) would be
more correct to use a pointer to struct pci_dev. We have a
token in the
kernel that is guaranteed 100% unique to any given PCI device: the
pointer to its struct pci_dev.
Is it?
Khachaturov, Vassilii wrote:
On Wed, 27 Jun 2001, Jeff Garzik wrote:
However, I think the driver (only going by your
description) would be
more correct to use a pointer to struct pci_dev. We have a
token in the
kernel that is guaranteed 100% unique to any given PCI device: the
Jeff Garzik wrote:
> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers... It's quite reasonable for two different scsi cards to be
> > on the
> Well you have device drivers like the symbios scsi driver for instance that
> tries to determine if it's seen a card before. It does this by looking at the
> bus,dev etc numbers...
Can it be done by comparing struct pci_dev pointers for equal?
-- Pete
-
To unsubscribe from this list: send the
Tom Gall wrote:
> Well you have device drivers like the symbios scsi driver for instance that
> tries to determine if it's seen a card before. It does this by looking at the
> bus,dev etc numbers... It's quite reasonable for two different scsi cards to be
> on the same bus number, same dev
> Why not use sysdata like the other arches?
>
> Changing the meaning of dev->bus->number globally seems pointless. If
> you are going to do that, just do it the right way and introduce another
> struct member, pci_domain or somesuch.
Thats 2.5 material. For 2.4 we should do as davem
Hi,
> The following 3 functions are added. Their purpose is a little
> different than to add support for more than 256 buses but they are
> important. Skip ahead and I'll explain what they are for
>
> int (*pci_read_bases)(struct pci_dev *, int cnt,int rom); /* These optional
> hooks
Jeff Garzik wrote:
>
> Tom Gall wrote:
> > The first part changes number, primary, and secondary to unsigned ints from
> > chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
> > pci controller in with the bus number. In our case we do it like this:
> >
> >
Tom Gall wrote:
> The first part changes number, primary, and secondary to unsigned ints from
> chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
> pci controller in with the bus number. In our case we do it like this:
>
> pci_controller=dev->bus->number>>8)
Hi All,
I'm looking for commentary on the following. As you might recall I had posted
a note a few days back on the lkml about the kinds of systems ppc64 runs on and
the reality of having a boatload of PCI buses out there.
I sure appreciate all the comments and feedback.
Today appended
Hi All,
I'm looking for commentary on the following. As you might recall I had posted
a note a few days back on the lkml about the kinds of systems ppc64 runs on and
the reality of having a boatload of PCI buses out there.
I sure appreciate all the comments and feedback.
Today appended
Tom Gall wrote:
The first part changes number, primary, and secondary to unsigned ints from
chars. What we do is encode the PCI domain aka PCI Primary Host Bridge, aka
pci controller in with the bus number. In our case we do it like this:
pci_controller=dev-bus-number8) 0xFF
Hi,
The following 3 functions are added. Their purpose is a little
different than to add support for more than 256 buses but they are
important. Skip ahead and I'll explain what they are for
int (*pci_read_bases)(struct pci_dev *, int cnt,int rom); /* These optional
hooks provide */
Why not use sysdata like the other arches?
Changing the meaning of dev-bus-number globally seems pointless. If
you are going to do that, just do it the right way and introduce another
struct member, pci_domain or somesuch.
Thats 2.5 material. For 2.4 we should do as davem suggested and
Tom Gall wrote:
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers... It's quite reasonable for two different scsi cards to be
on the same bus number, same dev number
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers...
Can it be done by comparing struct pci_dev pointers for equal?
-- Pete
-
To unsubscribe from this list: send the
Jeff Garzik wrote:
Tom Gall wrote:
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers... It's quite reasonable for two different scsi cards to be
on the same bus
29 matches
Mail list logo
