From: ebiederm@xmission.com (Eric W. Biederman)
To: Michael Ellerman <michael@ellerman.id.au>
Cc: linux-pci@atrey.karlin.mff.cuni.cz,
Greg Kroah-Hartman <greg@kroah.com>,
"David S. Miller" <davem@davemloft.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
<linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>,
<daniel.e.wolstenholme@intel.com>
Subject: Re: [PATCH 14/21] MSI: Use a list instead of the custom link structure
Date: Wed, 28 Mar 2007 00:29:45 -0600 [thread overview]
Message-ID: <m13b3pswx2.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070322105343.3B358DDF6D@ozlabs.org> (Michael Ellerman's message of "Thu, 22 Mar 2007 21:51:41 +1100")
Michael Ellerman <michael@ellerman.id.au> writes:
> The msi descriptors are linked together with what looks a lot like
> a linked list, but isn't a struct list_head list. Make it one.
>
> The only complication is that previously we walked a list of irqs, and
> got the descriptor for each with get_irq_msi(). Now we have a list of
> descriptors and need to get the irq out of it, so it needs to be in the
> actual struct msi_desc. We use 0 to indicate no irq is setup.
>
> At some point after a pci_dev is created we need to initialise its
> msi_list. pci_device_add() looks like the right place to do that, although
> I'm not convinced it's 100% safe. In drivers/char/agp/alpha-agp.c we create
> a pci_dev and I don't see that it ever gets passed to pci_device_add(), but
> we probably don't care.
Well that one appears to be a dummy place holder and probably should at
least have a kzalloc to initialize all of the fields to know values.
Regardless the normal pci device allocation does use kzalloc so we will
have well defined if not beautiful behavior if we try and use it.
Until we have a case where we need to use the msi_list outside of
where we enable and disable msi we should be perfectly fine initializing
the list somewhere inside of pci_enable_msi, and pci_enable_msix.
With dev->msi_enabled and dev->msix_enabled serving as flags to the
rest of the world that it is safe to look at the list.
It certainly sounds safer to me then becoming to closely coupled with
code that doesn't really care about how msi works. Heck even though
we repeat the call twice I bet it will even be less code.
> --- msi-new.orig/include/linux/msi.h
> +++ msi-new/include/linux/msi.h
> @@ -1,6 +1,8 @@
> #ifndef LINUX_MSI_H
> #define LINUX_MSI_H
>
> +#include <linux/list.h>
> +
> struct msi_msg {
> u32 address_lo; /* low 32 bits of msi message address */
> u32 address_hi; /* high 32 bits of msi message address */
> @@ -24,10 +26,8 @@ struct msi_desc {
> unsigned default_irq; /* default pre-assigned irq */
> }msi_attrib;
>
> - struct {
> - __u16 head;
> - __u16 tail;
> - }link;
> + int irq;
This should be "unsigned int irq"
> + struct list_head list;
>
> void __iomem *mask_base;
> struct pci_dev *dev;
Eric
next parent reply other threads:[~2007-03-28 6:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070322105343.3B358DDF6D@ozlabs.org>
2007-03-28 6:29 ` Eric W. Biederman [this message]
2007-03-29 5:03 ` Michael Ellerman
2007-03-29 5:24 ` Eric W. Biederman
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=m13b3pswx2.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=daniel.e.wolstenholme@intel.com \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=michael@ellerman.id.au \
/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
Powered by JetHome