All of lore.kernel.org
 help / color / mirror / Atom feed
From: linas@austin.ibm.com (Linas Vepstas)
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, mcarlson@broadcom.com,
	linuxppc-dev@ozlabs.org, mchan@broadcom.com,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
Date: Mon, 22 Oct 2007 14:54:52 -0500	[thread overview]
Message-ID: <20071022195451.GE4280@austin.ibm.com> (raw)
In-Reply-To: <20071019.175308.54212640.davem@davemloft.net>

On Fri, Oct 19, 2007 at 05:53:08PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 19 Oct 2007 19:46:10 -0500
> 
> > FWIW, it looks like not all that many arches do this; the output
> > for grep -r address_hi * is pretty thin. Then, looking at
> > i386/kernel/io_apic.c as an example, one can see that the 
> > msi state save happens "by accident" if CONFIG_SMP is enabled;
> > and so its surely broekn on uniprocesor machines.
> 
> I don't see this, in all cases write_msi_msg() will transfer
> the given "*msg" to entry->msg by this assignment in
> drivers/pci/msi.c:
> 
> void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> {
>  ...
> 	entry->msg = *msg;
> }
> 
> So as long as write_msi_msg() is invoked, it will be saved
> properly.

As Michael Ellerman points out, the pseries msi setup is done
by firmware, and so this bit never happens. 

As discussed in the other thread, I'll try to set up a patch
for an arch callback for restoring msi state.

-linas

WARNING: multiple messages have this Message-ID (diff)
From: linas@austin.ibm.com (Linas Vepstas)
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@ozlabs.org, mchan@broadcom.com,
	mcarlson@broadcom.com, netdev@vger.kernel.org,
	linux-pci@atrey.karlin.mff.cuni.cz, michael@ellerman.id.au
Subject: Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
Date: Mon, 22 Oct 2007 14:54:52 -0500	[thread overview]
Message-ID: <20071022195451.GE4280@austin.ibm.com> (raw)
In-Reply-To: <20071019.175308.54212640.davem@davemloft.net>

On Fri, Oct 19, 2007 at 05:53:08PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 19 Oct 2007 19:46:10 -0500
> 
> > FWIW, it looks like not all that many arches do this; the output
> > for grep -r address_hi * is pretty thin. Then, looking at
> > i386/kernel/io_apic.c as an example, one can see that the 
> > msi state save happens "by accident" if CONFIG_SMP is enabled;
> > and so its surely broekn on uniprocesor machines.
> 
> I don't see this, in all cases write_msi_msg() will transfer
> the given "*msg" to entry->msg by this assignment in
> drivers/pci/msi.c:
> 
> void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> {
>  ...
> 	entry->msg = *msg;
> }
> 
> So as long as write_msi_msg() is invoked, it will be saved
> properly.

As Michael Ellerman points out, the pseries msi setup is done
by firmware, and so this bit never happens. 

As discussed in the other thread, I'll try to set up a patch
for an arch callback for restoring msi state.

-linas

  parent reply	other threads:[~2007-10-22 19:54 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-19 21:36 [PATCH 5/7] pci: Export the pci_restore_msi_state() function Matt Carlson
2007-10-19 23:29 ` Linas Vepstas
2007-10-20  0:36   ` Michael Chan
2007-10-20  0:04     ` Linas Vepstas
2007-10-20  0:27       ` David Miller
2007-10-20  0:46         ` [BUG] powerpc does not save msi state [was " Linas Vepstas
2007-10-20  0:46           ` Linas Vepstas
2007-10-20  0:53           ` David Miller
2007-10-20  6:43             ` Michael Ellerman
2007-10-20  6:43               ` Michael Ellerman
2007-10-20 22:50               ` Michael Chan
2007-10-21 21:13               ` Benjamin Herrenschmidt
2007-10-21 21:13                 ` Benjamin Herrenschmidt
2007-10-22 19:54             ` Linas Vepstas [this message]
2007-10-22 19:54               ` Linas Vepstas
2007-10-23  0:23               ` David Miller
2007-10-23  0:23                 ` David Miller
2007-10-23  0:32                 ` Benjamin Herrenschmidt
2007-10-23  0:32                   ` Benjamin Herrenschmidt
2007-10-20  1:29           ` Benjamin Herrenschmidt
2007-10-20  1:29             ` Benjamin Herrenschmidt
2007-10-20  1:12       ` Michael Chan
2007-10-20  0:25         ` Linas Vepstas
2007-10-21 23:21 ` David Miller
2007-10-22  1:49   ` Michael Ellerman
2007-10-22  1:49     ` Michael Ellerman
2007-10-22 18:13     ` Linas Vepstas
2007-10-22 18:13       ` Linas Vepstas
2007-10-22 21:24       ` Benjamin Herrenschmidt
2007-10-22 21:24         ` Benjamin Herrenschmidt
2007-10-23  0:13         ` Linas Vepstas
2007-10-23  0:13           ` Linas Vepstas
2007-10-23  0:29           ` Benjamin Herrenschmidt
2007-10-23  0:29             ` Benjamin Herrenschmidt
2007-10-23  4:20       ` Michael Ellerman
2007-10-23  4:20         ` Michael Ellerman
2007-10-22  4:01   ` Michael Chan
2007-10-22  4:45     ` David Miller
2007-10-22 18:19       ` Linas Vepstas
2007-10-22 18:07   ` Linas Vepstas

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=20071022195451.GE4280@austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=davem@davemloft.net \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mcarlson@broadcom.com \
    --cc=mchan@broadcom.com \
    --cc=netdev@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.