2004-10-20 18:56:03

by Hanna Linder

[permalink] [raw]
Subject: [RFT 2.6] intel-agp.c: replace pci_find_device with pci_get_device


As pci_find_device is going away soon I have converted this file to use
pci_get_device instead. I have compile tested it. If anyone has this hardware
and could test it that would be great.

Hanna Linder
IBM Linux Technology Center

Signed-off-by: Hanna Linder <[email protected]>
---

diff -Nrup linux-2.6.9cln/drivers/char/agp/intel-agp.c linux-2.6.9patch2/drivers/char/agp/intel-agp.c
--- linux-2.6.9cln/drivers/char/agp/intel-agp.c 2004-10-18 16:35:52.000000000 -0700
+++ linux-2.6.9patch2/drivers/char/agp/intel-agp.c 2004-10-19 16:05:47.000000000 -0700
@@ -1493,7 +1493,7 @@ static int find_i810(u16 device)
{
struct pci_dev *i810_dev;

- i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL, device, NULL);
+ i810_dev = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL);
if (!i810_dev)
return 0;
intel_i810_private.i810_dev = i810_dev;
@@ -1504,9 +1504,9 @@ static int find_i830(u16 device)
{
struct pci_dev *i830_dev;

- i830_dev = pci_find_device(PCI_VENDOR_ID_INTEL, device, NULL);
+ i830_dev = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL);
if (i830_dev && PCI_FUNC(i830_dev->devfn) != 0) {
- i830_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
+ i830_dev = pci_get_device(PCI_VENDOR_ID_INTEL,
device, i830_dev);
}

@@ -1715,6 +1715,7 @@ static void __devexit agp_intel_remove(s
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

+ pci_dev_put(pdev);
agp_remove_bridge(bridge);
agp_put_bridge(bridge);
}



2004-10-20 22:13:19

by Matthew Wilcox

[permalink] [raw]
Subject: Re: [KJ] [RFT 2.6] intel-agp.c: replace pci_find_device with pci_get_device

On Wed, Oct 20, 2004 at 11:52:14AM -0700, Hanna Linder wrote:
>
> As pci_find_device is going away soon I have converted this file to use
> pci_get_device instead. I have compile tested it. If anyone has this hardware
> and could test it that would be great.

Should be converted to the pci_driver API.

--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain

2004-10-20 22:08:30

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [KJ] [RFT 2.6] intel-agp.c: replace pci_find_device with pci_get_device

On Wed, Oct 20, 2004 at 11:03:47PM +0100, Matthew Wilcox wrote:
> On Wed, Oct 20, 2004 at 11:52:14AM -0700, Hanna Linder wrote:
> >
> > As pci_find_device is going away soon I have converted this file to use
> > pci_get_device instead. I have compile tested it. If anyone has this hardware
> > and could test it that would be great.
>
> Should be converted to the pci_driver API.

No. It's already using the pci_driver API, but the same device can be
handled differently depending on the presence of another one. Maybe
pci_dev_present would fit here.

2004-10-20 22:59:54

by Dave Jones

[permalink] [raw]
Subject: Re: [KJ] [RFT 2.6] intel-agp.c: replace pci_find_device with pci_get_device

On Wed, Oct 20, 2004 at 11:06:38PM +0100, Christoph Hellwig wrote:

> > > As pci_find_device is going away soon I have converted this file to use
> > > pci_get_device instead. I have compile tested it. If anyone has this hardware
> > > and could test it that would be great.
> >
> > Should be converted to the pci_driver API.
>
> No. It's already using the pci_driver API, but the same device can be
> handled differently depending on the presence of another one. Maybe
> pci_dev_present would fit here.

Maybe, but if this kind of cleanup work is done on this code,
I want it sat in -mm for quite a while. This code has been
quite fragile in the past, and I've lost count how many
times we've broken some Intel i8xx variant inadvertantly.

The fragility is a good indicator however to just how crap
that code actually is, and was one of my motivations for
moving the EM64T stuff to the -mch driver.

Dave