All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: Concerns about our pci_{save,restore}_state()
Date: Thu, 28 Oct 2004 16:31:39 -0500	[thread overview]
Message-ID: <20041028213139.GC10049@kroah.com> (raw)
In-Reply-To: <1098677182.26697.21.camel@gaston>

On Mon, Oct 25, 2004 at 02:06:22PM +1000, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> I was looking at our "generic" pci_save_state() and pci_restore_state()
> and I have various concerns with them, I was wondering what you though
> about them...

Note, these concerns are the same before the last pci_save_state()
changes, right?  I didn't break anything new did I?  :)

>  - We should always write the command register after all the BARs,
> typically that mean write it back _last_

Hm, probably.  I'm away from my PCI book, so I don't really know about
that one.  For some reason we've been ok so far...

>  - We shouldn't write to the BIST register, it is defined as having
> side effects and writing to it any value may trigger a BIST on the
> card, with all the possible bad consequences that has

yeah, good point.  I guess most of these cards don't have BIST stuff in
them.  Or just writing back the read value is sane.  I'll dig through
the PCI book next week.

>  - What about saving/restoring more registers ? I'm not sure wether it
> should be the responsibility of the driver to save and restore things
> above dword 15, but we should at least deal with the case of P2P bridges
> who have more "standard" registers

We need to have a "bridge" driver for something like that.  I think lots
of things would benifit if we had that.  But if we had that, we need a
way to overload (or weight) different drivers that might bind to the
same device.  This is something that we've talked about for a while now,
and it's on my list of things to do in the near future.  I think once we
get that, a "generic" bridge driver will be ok to have.  Any hardware
specific quirks needed can also just be their own driver (I think Red
Hat ran into odd issues when they tried to add a pci bridge driver to
one of their older kernel trees.)

Oh, and yeah, we should probably save and restore pci express config
space too.  I need to go look to see if pci x 2.0 also has a expanded
config or not...

thanks,

greg k-h

  parent reply	other threads:[~2004-10-28 21:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-25  4:06 Concerns about our pci_{save,restore}_state() Benjamin Herrenschmidt
2004-10-25  6:11 ` Jeff Garzik
2004-10-25  6:24   ` Benjamin Herrenschmidt
2004-10-25  8:32     ` Arjan van de Ven
2004-10-25  9:04       ` Benjamin Herrenschmidt
2004-10-28  8:50     ` [linux-pm] " Patrick Mochel
2004-10-28 22:44       ` Benjamin Herrenschmidt
2004-10-28 21:31 ` Greg KH [this message]
2004-10-28 22:50   ` Benjamin Herrenschmidt

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=20041028213139.GC10049@kroah.com \
    --to=greg@kroah.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.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.