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?

>>>where you have the other pci_dev pinned on a hotplug on a box set to scan
>>>the devices in reverse order

>>    Function 1 will always be skipped, regardless of the scan order.

> Yes, but init_chipset_hpt366() will still try to access Function 1

    No!  Re-read the code please: init_chipset_hpt366() won't be called for 
function 1 if that one is not detected, and only in this case it does function 
0 access to read the saved f_CNT value.

> even if earlier init_setup_hpt374() failed to obtain reference to it.

>>>(yes its an extremely obscure case ;))

>>    "Security through obscurity". :-)

> Not in this case. :-)

    Yeah, here we have another case. ;-)

> Bart

WBR, Sergei