From: Michael Ellerman <michael@ellerman.id.au>
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: Sat, 20 Oct 2007 16:43:26 +1000 [thread overview]
Message-ID: <1192862606.7688.4.camel@concordia> (raw)
In-Reply-To: <20071019.175308.54212640.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Fri, 2007-10-19 at 17:53 -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.
>
> Platforms need not do this explicitly.
I'm short on context here, and it's Saturday, so excuse me if I'm
missing the point somewhere.
On pseries machines we don't call write_msi_msg(), because we don't
control the contents of the message, firmware does. So entry->msg will
be bogus.
That's a pity, but AFAIK it shouldn't be a problem because we don't
enable CONFIG_PM on those machines anyway. If we ever want to we'll need
to sort out with firmware how that will work WRT restoring MSI state.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: David Miller <davem@davemloft.net>
Cc: linas@austin.ibm.com, linuxppc-dev@ozlabs.org,
mchan@broadcom.com, mcarlson@broadcom.com,
netdev@vger.kernel.org, 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: Sat, 20 Oct 2007 16:43:26 +1000 [thread overview]
Message-ID: <1192862606.7688.4.camel@concordia> (raw)
In-Reply-To: <20071019.175308.54212640.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Fri, 2007-10-19 at 17:53 -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.
>
> Platforms need not do this explicitly.
I'm short on context here, and it's Saturday, so excuse me if I'm
missing the point somewhere.
On pseries machines we don't call write_msi_msg(), because we don't
control the contents of the message, firmware does. So entry->msg will
be bogus.
That's a pity, but AFAIK it shouldn't be a problem because we don't
enable CONFIG_PM on those machines anyway. If we ever want to we'll need
to sort out with firmware how that will work WRT restoring MSI state.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-20 6:43 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 [this message]
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
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=1192862606.7688.4.camel@concordia \
--to=michael@ellerman.id.au \
--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.