public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-pci@atrey.karlin.mff.cuni.cz,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Adam Belay <abelay@MIT.EDU>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: Bug in PCI core
Date: Fri, 13 Oct 2006 18:34:27 +0100	[thread overview]
Message-ID: <1160760867.25218.77.camel@localhost.localdomain> (raw)
In-Reply-To: <20061013164933.GD11633@parisc-linux.org>

Ar Gwe, 2006-10-13 am 10:49 -0600, ysgrifennodd Matthew Wilcox:
> No it didn't.  It's undefined behaviour to perform *any* PCI config
> access to the device while it's doing a D-state transition.  It may have

I think you missed the earlier parts of the story - the kernel caches
the base config register state.

> happened to work with the chips you tried it with, but more likely you
> never hit that window because X simply didn't try to do that.

Which is why the kernel caches the register state. This all came up long
ago and the solution we currently have was the one chosen after
considerable debate and analysis about things like locking. We preserved
the historical reliable interface going back to the early Linux PCI
support and used by all the apps.


There are several problems with making it return an error

- What does user space do ?

	while(pci_...() == -EAGAIN) yield();

which is useful how - there is no select operation for waiting here, and
while it could be added it just gets uglier

- Who actually wants to get an error in that specific case ?

If you can find someone who desperately wants an error code then code in
O_DIRECT support to do it and preserve the existing sane API.

The job of the kernel is not to expose hardware directly, it is to
provide sane interfaces to it. We don't have separate interfaces to
conf1, conf2, pcibios etc for good reason. Exposing everyone to ugly
minor details of the PCI transition handling isn't progress.


Alan

  reply	other threads:[~2006-10-13 17:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11 20:41 Bug in PCI core Alan Stern
2006-10-13  1:01 ` [linux-pm] " Benjamin Herrenschmidt
2006-10-13  8:50   ` Adam Belay
2006-10-13  9:16     ` Benjamin Herrenschmidt
2006-10-13  9:31       ` Martin Mares
2006-10-13 12:25         ` [linux-pm] " Benjamin Herrenschmidt
2006-10-13 14:29     ` Alan Stern
2006-10-13 15:26       ` [linux-pm] " Alan Cox
2006-10-13 15:29         ` Arjan van de Ven
2006-10-13 16:06           ` Alan Cox
2006-10-13 16:34             ` Adam Belay
2006-10-13 16:36               ` [linux-pm] " Matthew Wilcox
2006-10-13 17:09               ` Alan Cox
2006-10-13 16:49                 ` Matthew Wilcox
2006-10-13 17:34                   ` Alan Cox [this message]
2006-10-13 17:13                     ` Arjan van de Ven
2006-10-13 17:57                     ` Alan Stern
2006-10-13 19:18                       ` [linux-pm] " Matthew Wilcox
2006-10-13 20:59                         ` Alan Stern
2006-10-13 19:30                     ` Adam Belay
2006-10-13 23:00                     ` Benjamin Herrenschmidt
2006-10-14  2:33                       ` Alan Stern
2006-10-14  3:04                         ` [linux-pm] " Roland Dreier
2006-10-14  3:07                         ` Matthew Wilcox
2006-10-14  3:19                         ` Bill Randle
2006-10-14  5:47                         ` Greg KH
2006-10-13 17:01                 ` Adam Belay
2006-10-13 16:40           ` Adam Belay
2006-10-13 20:48       ` [linux-pm] " Pavel Machek
2006-10-14  5:34 ` Greg KH

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=1160760867.25218.77.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=abelay@MIT.EDU \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-pm@lists.osdl.org \
    --cc=matthew@wil.cx \
    /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