searching for pci busses

searching for pci busses

[Jiri Slaby]

Hello,

I want to ask, if there is any function to call (as we debated with Jeff), which
does something like this:
1) I have some vendor/device ids in table
2) I want to traverse raws of the table and compare to system devices, and if
found, stop and return pci_dev struct (or raw in the table).
I have this code for the time being:

static struct pci_device_id ids[] = {
    { PCI_DEVICE(0x1234, 0x4321) },
    /* ... whatever ... */
    { 0 }
};

for (id = ids; id->vendor; id++) {
  d = pci_get_device(id->vendor, id->device, NULL);
  if (d != NULL) {
    /* get some info */
    pci_dev_put(d);
    break;
  }
}

I'm searching for a bus or something, which is only one in the system, but would
be made by more vendors.
Simply, something like pci_dev_present(), but with a result of pci_dev or index
of the raw in the ids table corresponding to the found device (instead of
returning 0/1).

thanks,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: searching for pci busses

[Greg KH]

On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
> Hello,
> 
> I want to ask, if there is any function to call (as we debated with Jeff), which
> does something like this:
> 1) I have some vendor/device ids in table
> 2) I want to traverse raws of the table and compare to system devices, and if
> found, stop and return pci_dev struct (or raw in the table).

What's wrong with pci_match_id()?

Or just using the pci_register_driver() function properly, which handles
all of this logic for you?

thanks,

greg k-h

Re: searching for pci busses

[Jeff Garzik]

Greg KH wrote:
> On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
>> Hello,
>>
>> I want to ask, if there is any function to call (as we debated with Jeff), which
>> does something like this:
>> 1) I have some vendor/device ids in table
>> 2) I want to traverse raws of the table and compare to system devices, and if
>> found, stop and return pci_dev struct (or raw in the table).
> 
> What's wrong with pci_match_id()?
> 
> Or just using the pci_register_driver() function properly, which handles
> all of this logic for you?

These aren't PCI devices proper.  These are embedded non-PCI devices, 
which must search for an unrelated PCI device to figure out what type of 
platform they are on.

	Jeff

Re: searching for pci busses

[Greg KH]

On Mon, May 29, 2006 at 05:59:39PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> >On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
> >>Hello,
> >>
> >>I want to ask, if there is any function to call (as we debated with 
> >>Jeff), which
> >>does something like this:
> >>1) I have some vendor/device ids in table
> >>2) I want to traverse raws of the table and compare to system devices, 
> >>and if
> >>found, stop and return pci_dev struct (or raw in the table).
> >
> >What's wrong with pci_match_id()?
> >
> >Or just using the pci_register_driver() function properly, which handles
> >all of this logic for you?
> 
> These aren't PCI devices proper.  These are embedded non-PCI devices, 
> which must search for an unrelated PCI device to figure out what type of 
> platform they are on.

Ok, then use pci_match_id() or pci_get_device().

thanks,

greg k-h

Re: searching for pci busses

[Jon Smirl]

On 5/30/06, Greg KH <gregkh@suse.de> wrote:
> On Mon, May 29, 2006 at 05:59:39PM -0400, Jeff Garzik wrote:
> > Greg KH wrote:
> > >On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
> > >>Hello,
> > >>
> > >>I want to ask, if there is any function to call (as we debated with
> > >>Jeff), which
> > >>does something like this:
> > >>1) I have some vendor/device ids in table
> > >>2) I want to traverse raws of the table and compare to system devices,
> > >>and if
> > >>found, stop and return pci_dev struct (or raw in the table).
> > >
> > >What's wrong with pci_match_id()?
> > >
> > >Or just using the pci_register_driver() function properly, which handles
> > >all of this logic for you?
> >
> > These aren't PCI devices proper.  These are embedded non-PCI devices,
> > which must search for an unrelated PCI device to figure out what type of
> > platform they are on.
>
> Ok, then use pci_match_id() or pci_get_device().

This is how DRM does it...

        for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
                pid = (struct pci_device_id *)&driver->pci_driver.id_table[i];

                pdev = NULL;
                /* pass back in pdev to account for multiple identical cards */
                while ((pdev =
                        pci_get_subsys(pid->vendor, pid->device, pid->subvendor,
                                       pid->subdevice, pdev)) != NULL) {
                        /* stealth mode requires a manual probe */
                        pci_dev_get(pdev);
                        drm_get_dev(pdev, pid, driver);
                }
        }
        return 0;


-- 
Jon Smirl
jonsmirl@gmail.com

Re: searching for pci busses

[Greg KH]

On Tue, May 30, 2006 at 12:52:31PM -0400, Jon Smirl wrote:
> On 5/30/06, Greg KH <gregkh@suse.de> wrote:
> >On Mon, May 29, 2006 at 05:59:39PM -0400, Jeff Garzik wrote:
> >> Greg KH wrote:
> >> >On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
> >> >>Hello,
> >> >>
> >> >>I want to ask, if there is any function to call (as we debated with
> >> >>Jeff), which
> >> >>does something like this:
> >> >>1) I have some vendor/device ids in table
> >> >>2) I want to traverse raws of the table and compare to system devices,
> >> >>and if
> >> >>found, stop and return pci_dev struct (or raw in the table).
> >> >
> >> >What's wrong with pci_match_id()?
> >> >
> >> >Or just using the pci_register_driver() function properly, which handles
> >> >all of this logic for you?
> >>
> >> These aren't PCI devices proper.  These are embedded non-PCI devices,
> >> which must search for an unrelated PCI device to figure out what type of
> >> platform they are on.
> >
> >Ok, then use pci_match_id() or pci_get_device().
> 
> This is how DRM does it...

6 words that should never be uttered as a reason to justify anything...

thanks,

greg k-h

Re: searching for pci busses

[Matthew Wilcox]

On Tue, May 30, 2006 at 12:52:31PM -0400, Jon Smirl wrote:
> This is how DRM does it...

>        for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
>                pid = (struct pci_device_id *)&driver->pci_driver.id_table[i];

Why do you cast away the const warning?  Why not just make pid a pointer
to const?  drm_get_dev already has the const qualifier, so somebody
realised what the right thing to do was.

But looking at this code just reinforces the basic problem -- that DRM
does everything wrong and it needs shooting in the head.

Re: searching for pci busses

[Jon Smirl]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On 5/30/06, Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, May 30, 2006 at 12:52:31PM -0400, Jon Smirl wrote:
> > This is how DRM does it...
>
> >        for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
> >                pid = (struct pci_device_id *)&driver->pci_driver.id_table[i];
>
> Why do you cast away the const warning?  Why not just make pid a pointer
> to const?  drm_get_dev already has the const qualifier, so somebody
> realised what the right thing to do was.

Nobody pointed that out before (That code has been around for a while,
I suspect one of the routines being called wasn't always marked as
taking a const parameter). I made a patch and attached it. You can
send it to DaveA, they reject everything from me.

> But looking at this code just reinforces the basic problem -- that DRM
> does everything wrong and it needs shooting in the head.

DRM has to do that loop because the fbdev drivers are already bound to
the device. There is a more complex version in DRM CVS that looks for
the fbdev drivers, if they are not present DRM will bind to the
device, otherwise it falls back in stealth mode. It also adds code to
manually mark PCI memory regions in use. Confusion over who can bind
has impacts on attaching to the suspend/resume hooks.

But binding is only a minor problem. The true problem is who controls
the state loaded inside of the device.

-- 
Jon Smirl
jonsmirl@gmail.com

[-- Attachment #2: drm.patch --]
[-- Type: text/x-patch, Size: 752 bytes --]

diff --git a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c
index 3c0b882..3af48be 100644
--- a/drivers/char/drm/drm_drv.c
+++ b/drivers/char/drm/drm_drv.c
@@ -253,7 +253,7 @@ int drm_lastclose(drm_device_t * dev)
 int drm_init(struct drm_driver *driver)
 {
 	struct pci_dev *pdev = NULL;
-	struct pci_device_id *pid;
+	const struct pci_device_id *pid;
 	int i;
 
 	DRM_DEBUG("\n");
@@ -261,7 +261,7 @@ int drm_init(struct drm_driver *driver)
 	drm_mem_init();
 
 	for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
-		pid = (struct pci_device_id *)&driver->pci_driver.id_table[i];
+		pid = &driver->pci_driver.id_table[i];
 
 		pdev = NULL;
 		/* pass back in pdev to account for multiple identical cards */

Re: searching for pci busses

[Jiri Slaby]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Smirl napsal(a):
> On 5/30/06, Greg KH <gregkh@suse.de> wrote:
>> On Mon, May 29, 2006 at 05:59:39PM -0400, Jeff Garzik wrote:
>> > Greg KH wrote:
>> > >On Sun, May 28, 2006 at 01:12:26AM +0159, Jiri Slaby wrote:
>> > >>Hello,
>> > >>
>> > >>I want to ask, if there is any function to call (as we debated with
>> > >>Jeff), which
>> > >>does something like this:
>> > >>1) I have some vendor/device ids in table
>> > >>2) I want to traverse raws of the table and compare to system
>> devices,
>> > >>and if
>> > >>found, stop and return pci_dev struct (or raw in the table).
>> > >
>> > >What's wrong with pci_match_id()?
>> > >
>> > >Or just using the pci_register_driver() function properly, which
>> handles
>> > >all of this logic for you?
>> >
>> > These aren't PCI devices proper.  These are embedded non-PCI devices,
>> > which must search for an unrelated PCI device to figure out what
>> type of
>> > platform they are on.
>>
>> Ok, then use pci_match_id() or pci_get_device().
> 
> This is how DRM does it...
> 
>        for (i = 0; driver->pci_driver.id_table[i].vendor != 0; i++) {
>                pid = (struct pci_device_id
> *)&driver->pci_driver.id_table[i];
> 
>                pdev = NULL;
>                /* pass back in pdev to account for multiple identical
> cards */
>                while ((pdev =
>                        pci_get_subsys(pid->vendor, pid->device,
> pid->subvendor,
>                                       pid->subdevice, pdev)) != NULL) {
>                        /* stealth mode requires a manual probe */
>                        pci_dev_get(pdev);
>                        drm_get_dev(pdev, pid, driver);
>                }
>        }
>        return 0;
> 
> 
It's similar to code in my root post, so thanks for replies, it's maybe the best
way.

thanks,
- --
Jiri Slaby         www.fi.muni.cz/~xslaby
~\-/~      jirislaby@gmail.com      ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEfHqnMsxVwznUen4RAkQKAKCTZqlxtJwKTjlDP07ZAes9Jk5KOACgkSzt
zxyv1TitUGpv6rnppOiPyEI=
=3pfI
-----END PGP SIGNATURE-----