From: Brian King <brking@us.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg KH <greg@kroah.com>,
Paul Mackerras <paulus@samba.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] pci: Block config access during BIST
Date: Sat, 20 Nov 2004 19:55:36 -0600 [thread overview]
Message-ID: <419FF598.9080606@us.ibm.com> (raw)
In-Reply-To: <1100995616.27157.44.camel@gaston>
Benjamin Herrenschmidt wrote:
>>It still doesn't address Greg's issue about making this apply to the
>>pci_bus_* functions as well, but I'm not sure of a good way to do that
>>due to the reasons given earlier.
>
>
> Looks good to me, I don't sure we actually have to deal with pci_bus_*
> functions, do we ? When are they called ?
For what we are trying to solve, which is blocking userspace config
accesses, I don't think we do. Greg - are you ok with this?
>>+void pci_block_config_access(struct pci_dev *dev)
>>+{
>>+ unsigned long flags;
>>+
>>+ spin_lock_irqsave(&pci_lock, flags);
>>+ dev->block_cfg_access = 1;
>>+ spin_unlock_irqrestore(&pci_lock, flags);
>>+}
>
>
> Shouldn't we save the config space here ?
I thought about that when coding this up and thought it would
be better to simply have the function do what it advertises and no
more. Seems strange that a function called pci_block_config_access
would go and do a bunch of pci config accesses, but we can
certainly add it if you like.
-Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2004-11-21 2:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-19 20:23 [PATCH 1/2] pci: Block config access during BIST brking
2004-11-19 21:32 ` Greg KH
2004-11-19 22:25 ` Brian King
2004-11-19 22:46 ` Benjamin Herrenschmidt
2004-11-19 23:22 ` Brian King
2004-11-20 0:23 ` Benjamin Herrenschmidt
2004-11-19 22:45 ` Benjamin Herrenschmidt
2004-11-20 2:27 ` Alan Cox
2004-11-20 7:09 ` Benjamin Herrenschmidt
2004-11-20 12:42 ` Alan Cox
2004-11-20 22:32 ` Benjamin Herrenschmidt
2004-11-20 23:38 ` Brian King
2004-11-21 0:06 ` Benjamin Herrenschmidt
2004-11-21 1:55 ` Brian King [this message]
2004-11-21 7:03 ` Benjamin Herrenschmidt
2004-11-21 17:22 ` Brian King
2004-12-03 15:26 ` Brian King
2004-11-24 11:49 ` Alan Cox
2004-11-25 22:00 ` Paul Mackerras
2004-11-25 21:11 ` Alan Cox
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=419FF598.9080606@us.ibm.com \
--to=brking@us.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.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.