linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: Dave Jones <davej@redhat.com>
Cc: Greg KH <gregkh@suse.de>, Pavel Machek <pavel@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	trenn@suse.de, thoenig@suse.de
Subject: Re: [RFC] [PATCH] Execute PCI quirks on resume from suspend-to-RAM
Date: Thu, 11 May 2006 06:01:59 +0200	[thread overview]
Message-ID: <4462B737.80108@gmx.net> (raw)
In-Reply-To: <20060511023109.GB11693@redhat.com>

Dave Jones wrote:
> On Wed, May 10, 2006 at 11:36:41PM +0200, Carl-Daniel Hailfinger wrote:
>  > Greg KH wrote:
>  > > On Wed, May 10, 2006 at 12:30:34PM +0200, Carl-Daniel Hailfinger wrote:
>  > >> Thinking about it again, if we restored the full pci config space
>  > >> on resume, this quirk handling would be completely unnecessary.
>  > >> Any reasons why we don't do that?
>  > > 
>  > > We do do that.  Look at pci_restore_state().
>  > > 
>  > > Actually, look at it in the latest -mm tree, that version works better
>  > > than mainline does right now :)
>  > 
>  > Sorry. Even the version in -mm does not restore all 256 bytes, so it
>  > will not change anything.
> 
> You can't generically look at a PCI device past the first 32 bytes.
> *anything* could be there, including registers which cause the machine
> to lock up when they get read.
> 
> This is exactly the reason that lspci by default only shows 32 bytes,
> and you need to be root to see past that limit.

You mean 64 bytes?

>  > So either we really restore the full config space (probably a good idea
>  > by itself)
> 
> No, *really* *really* bad idea :)

I had hoped the warnings in the lspci man page would be obsolete now.
Wishful thinking, it appears. Thanks for the hint.


Unfortunately, that means we either have to introduce a new PCI_FIXUP_
type or we execute PCI_FIXUP_HEADER also on resume. Which is better?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

  reply	other threads:[~2006-05-11  4:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10  0:55 [RFC] [PATCH] Execute PCI quirks on resume from suspend-to-RAM Carl-Daniel Hailfinger
2006-05-10  9:39 ` Pavel Machek
2006-05-10 10:30   ` Carl-Daniel Hailfinger
2006-05-10 20:56     ` Greg KH
2006-05-10 21:36       ` Carl-Daniel Hailfinger
2006-05-11  2:31         ` Dave Jones
2006-05-11  4:01           ` Carl-Daniel Hailfinger [this message]
2006-05-11 15:17             ` Carl-Daniel Hailfinger
2006-05-11 15:28               ` Matthew Garrett

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=4462B737.80108@gmx.net \
    --to=c-d.hailfinger.devel.2006@gmx.net \
    --cc=davej@redhat.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=thoenig@suse.de \
    --cc=trenn@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).