public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: brking@us.ibm.com
Cc: 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 09:46:42 +1100	[thread overview]
Message-ID: <1100904402.3811.52.camel@gaston> (raw)
In-Reply-To: <419E72EF.4010100@us.ibm.com>

On Fri, 2004-11-19 at 16:25 -0600, Brian King wrote:

> I thought about that when writing up this patch, but decided against it.
> I figured it was overkill and was going to make the patch more complicated
> than it needed to be to solve the main problem I have seen, which is
> userspace code, usually hotplug/coldplug scripts, reading config space
> when an adapter is running BIST.

How so ? Why would it be more complicated to do the workaround in
drivers/pci/access.c macros instead and not touch all the wrappers ? It
would actually make a much smaller patch...

> If you think there are usages of the pci_bus_* functions in the
> kernel after the adapter device driver gets loaded, from callers other
> than adapter device drivers and userspace APIs, I would have to agree
> with you. I was hoping to keep this patch as simple as possible.
> 
> Having to protect the pci_bus_* functions requires a lookup in these
> functions to find the pci_dev to get the saved_config_space, which
> I was hoping to avoid.
> 
> Ben - do you have any concerns with this limitation for the use you have
> for this set of APIs?

If we ever endup rescanning the bus segment, indeed... I'd rather play
safe, it's easy to move the blocking to the bus access functions and
have the BIST function use the low level bus callbacks directly.

Ben.



  reply	other threads:[~2004-11-19 22:50 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 [this message]
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
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=1100904402.3811.52.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=brking@us.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox