Bartlomiej Zolnierkiewicz wrote:
+ if (chip_type == HPT374 && (PCI_FUNC(dev->devfn) & 1)) { + struct pci_dev *dev1 = pci_get_slot(dev->bus, + dev->devfn - 1);
Can be NULL
Not really. This may not be called if it's NULL -- see hpt374_init_setup(). Maybe worth a comment though...
+ unsigned long io_base = pci_resource_start(dev1, 4);
Kaboom
That was a dud bomb. ;-)
What stops a hot unplug of a 374 from causing that to occur. I don't see
Pinned as in pci_get_device()? If so, see setup-ide.c:ide_scan_pcibus(). The IDE core does that for me.
ide_scan_pcibus() is used iff IDE is built-in.
Moreover pci_get_device() holds reference _only_ to the current PCI device (the reference count to @from PCI device is _always_ decremented).
Indeed... doesn't it look like a buglet in the IDE core?
It is OK, when ide_scan_pcibus() is not used
But whan it is used?
Then it keeps the reference to PCI device itself by using pci_get_device()...
Well, that I know. What I was asking is where the reference is kept after the driver init time -- we're still working with the PCI device, so unplagging it would be wrong thing to do. Actually, we should never call pci_dev_put() since IDE drivers are not unloadable, right?
Now that I look at pci_device_probe() it seems that there should be additional pci_dev_get() call in ide_scan_pcidev() if d->probe() succeeds. Care to fix it?
Yeah. OK to convert it to kernel style by the same patch? MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
