From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-ide@vger.kernel.org
Subject: Re: [PATCH 1/2] hpt366: fix PCI clock detection for HPT374
Date: Sat, 11 Aug 2007 23:31:14 +0200 [thread overview]
Message-ID: <200708112331.14270.bzolnier@gmail.com> (raw)
In-Reply-To: <46BDF08C.1070508@ru.mvista.com>
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
>
> >> 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?
> >>>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.
>
> >> Alas, it's your thinko, *again*. ;-)
>
> >>>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...
>
> >> Actually, init_setup_hpt374() grabs function 1 to register pair of devices
> >>(in hopes that the callers have already "pinned" function 0), and
> >>init_chipset_hpt366() "pins" function 0 to read the saved f_CNT.
>
> > Yep, this would make a nice code comment instead the current one. :)
>
> Ugh, will try to reword it... :-|
Thanks.
Bart
next prev parent reply other threads:[~2007-08-11 21:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-05 20:06 [PATCH 1/2] hpt366: fix PCI clock detection for HPT374 Sergei Shtylyov
2007-08-06 17:10 ` Bob Ham
2007-08-06 17:18 ` Sergei Shtylyov
2007-08-07 9:01 ` Bob Ham
2007-08-06 19:29 ` Alan Cox
2007-08-10 15:41 ` Sergei Shtylyov
2007-08-10 17:19 ` Alan Cox
2007-08-10 17:29 ` Sergei Shtylyov
2007-08-10 21:54 ` Bartlomiej Zolnierkiewicz
2007-08-11 16:03 ` Sergei Shtylyov
2007-08-11 16:41 ` Bartlomiej Zolnierkiewicz
2007-08-11 16:54 ` Sergei Shtylyov
2007-08-11 17:07 ` Bartlomiej Zolnierkiewicz
2007-08-11 17:23 ` Sergei Shtylyov
2007-08-11 21:31 ` Bartlomiej Zolnierkiewicz [this message]
2007-08-17 17:43 ` Sergei Shtylyov
2007-08-08 21:10 ` Bartlomiej Zolnierkiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708112331.14270.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=sshtylyov@ru.mvista.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).