Re: [PATCH 1/2] hpt366: fix PCI clock detection for HPT374

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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