From: Grant Grundler <grundler@parisc-linux.org>
To: Brice Goglin <brice@myri.com>
Cc: linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [patch 3/7] Check root chipset no_msi flag instead of all parent busses flags
Date: Tue, 4 Jul 2006 01:06:43 -0600 [thread overview]
Message-ID: <20060704070643.GA16632@colo.lackof.org> (raw)
In-Reply-To: <20060703004055.835863000@myri.com>
On Sun, Jul 02, 2006 at 08:40:02PM -0400, Brice Goglin wrote:
> MSI only requires support in the root chipset, which may not even have
> a subordinate bus.
Brice,
The above comment and the main part of this patch don't look right to me.
Maybe it's the glass of wine I had two hours ago and it's around midnight
now...
If the "root chipset" is not a PCI device and the architecture doesn't
fake it, the root chipset (aka "PCI Host bus controller") is not visible
to PCI subsystem. Some of the arch code (e.g. drivers/parisc/dino.c)
uses "bus->self == NULL" to differentiate between PCI-PCI secondary busses
and PCI bus below a "root chipset". ISTR alpha and sparc doing the same.
Can you confirm I'm remembering/understanding this bit correctly?
> pci_msi_supported() now checks the no_msi flag in the root_chipset pci_dev
> struct instead of the PCI_BUS_FLAGS_NO_MSI flag of all its parent busses.
> The MSI quirk now sets the no_msi flag accordingly.
I don't see how this could work for alpha/parisc/sparc (IIRC) or any other
architecture that doesn't create "fake" PCI Root busses.
I think your previous patch was correct in this regard.
> Index: linux-git/drivers/pci/msi.c
> ===================================================================
> --- linux-git.orig/drivers/pci/msi.c 2006-07-02 20:28:28.000000000 -0400
> +++ linux-git/drivers/pci/msi.c 2006-07-02 20:28:58.000000000 -0400
> @@ -905,19 +905,24 @@
> * @dev: pointer to the pci_dev data structure of MSI device function
> *
> * MSI must be globally enabled and supported by the device and
> - * its parent busses.
> + * its root chipset.
> **/
> static
> int pci_msi_supported(struct pci_dev * dev)
> {
> - struct pci_bus *bus;
> + struct pci_dev *pdev;
>
> if (!pci_msi_enable || !dev || dev->no_msi)
> return -1;
>
> - for (bus = dev->bus; bus; bus = bus->parent)
> - if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> - return -1;
> + /* find root complex for our device */
> + pdev = dev;
> + while (pdev->bus && pdev->bus->self)
> + pdev = pdev->bus->self;
In particular, I'm thinking this loop isn't correct though I'm not
in a particular, erm, "certain" frame of mind right now.
Under a parisc root device, pdev->bus->self would be NULL.
Maybe that's why parisc uses pci_scan_bus_parented()
instead of pci_scan_bus(). (I've forgot the background
behind that change).
thanks,
grant
next prev parent reply other threads:[~2006-07-04 7:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 0:39 [patch 0/7] Improve MSI detection v5 Brice Goglin
2006-07-03 0:40 ` [patch 1/7] Merge existing MSI disabling quirks Brice Goglin
2006-07-03 0:40 ` [patch 2/7] Factorize common MSI detection code from pci_enable_msi() and msix() Brice Goglin
2006-07-03 0:40 ` [patch 3/7] Check root chipset no_msi flag instead of all parent busses flags Brice Goglin
2006-07-04 7:06 ` Grant Grundler [this message]
2006-07-04 23:12 ` Brice Goglin
2006-07-05 3:48 ` Grant Grundler
2006-07-05 4:38 ` Brice Goglin
2006-07-06 15:39 ` Grant Grundler
2006-07-06 15:46 ` Brice Goglin
2006-07-06 0:50 ` Benjamin Herrenschmidt
2006-07-03 0:40 ` [patch 4/7] Rename PCI_CAP_ID_HT_IRQCONF into PCI_CAP_ID_HT Brice Goglin
2006-07-03 0:40 ` [patch 5/7] Blacklist PCI-E chipsets depending on Hypertransport MSI capability Brice Goglin
2006-07-03 0:40 ` [patch 6/7] Drop pci_msi_quirk Brice Goglin
2006-07-03 0:40 ` [patch 7/7] Drop pci bus_flags Brice Goglin
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=20060704070643.GA16632@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=brice@myri.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/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