From: Mark Lord <liml@rtr.ca>
To: IDE/ATA development list <linux-ide@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Tejun Heo <htejun@gmail.com>, Jeff Garzik <jgarzik@pobox.com>,
linux-pci@vger.kernel.org
Subject: libata, devm_*, and MSI ?
Date: Tue, 20 Jan 2009 11:03:13 -0500 [thread overview]
Message-ID: <4975F5C1.8090107@rtr.ca> (raw)
Tejun / Jeff,
I am working on MSI support for sata_mv, and am trying to puzzle out
exactly what the kernel expects for this. Looking at other drivers,
both libata and otherwise, yields a variety of conflicting implementations.
For starters, the MSI HOW-TO suggests that drivers must be careful
to invoke pci_disable_msi() on module unload, but I don't see that
happening anywhere in libata.
Unless, Tejun, the devm_* routines automatically do this.. do they?
Next, there's no mention of a need for invoking pci_intx() in the HOW-TO,
yet some device drivers call it, and others do not.
Eg. from ahci.c, we have this:
if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev))
pci_intx(pdev, 1);
Which agrees with the existing code in sata_mv:
if (msi && pci_enable_msi(pdev))
pci_intx(pdev, 1);
Which seems to call pci_intx() only when MSI is *not* used. Fine.
But then in sata_vsc.c, we do sort of the opposite:
if (pci_enable_msi(pdev) == 0)
pci_intx(pdev, 0);
Either that one is wrong, or pci_intx() is unnecessary in all cases.
Again, the MSI HOW-TO doesn't even mention this routine.
Looking through the network drivers, it seems that some of them
do the pci_intx(pdev,1) call for the cases where pci_enable_msi() fails,
similar to ahci.c and sata_mv.c.
But not all of them do that.
Perhaps somebody from the PCI side of things might enlighten us all.
Thanks
next reply other threads:[~2009-01-20 16:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 16:03 Mark Lord [this message]
2009-01-20 16:07 ` libata, devm_*, and MSI ? Mark Lord
2009-01-20 17:44 ` Grant Grundler
2009-01-20 18:16 ` Mark Lord
2009-01-20 18:51 ` Grant Grundler
2009-01-20 19:54 ` Mark Lord
2009-01-21 11:59 ` Tejun Heo
2009-01-20 21:50 ` Daniel Barkalow
2009-01-21 3:39 ` Mark Lord
2009-01-21 4:02 ` Grant Grundler
2009-01-21 4:16 ` Michael Ellerman
2009-01-21 15:05 ` Mark Lord
2009-01-22 0:33 ` Robert Hancock
2009-01-23 18:11 ` Mark Lord
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=4975F5C1.8090107@rtr.ca \
--to=liml@rtr.ca \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.