On Saturday 11 August 2007, Sergei Shtylyov wrote:
> 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 probing is done by PCI layer
and it keeps the reference to the PCI device in pci_device_probe().
> >>>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.
Argh, thinko on my side.
Unfortunately patch needs fixing anyway since the new comment is incorrect
because the reference is kept by hpt366 driver itself - pci_get_slot() in
init_setup_hpt374() - not the IDE core...
Thanks,
Bart
-
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
