From: Brian King <brking@us.ibm.com>
To: Greg KH <greg@kroah.com>
Cc: paulus@samba.org, benh@kernel.crashing.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] pci: Block config access during BIST
Date: Fri, 19 Nov 2004 16:25:51 -0600 [thread overview]
Message-ID: <419E72EF.4010100@us.ibm.com> (raw)
In-Reply-To: <20041119213232.GB13259@kroah.com>
Greg KH wrote:
> On Fri, Nov 19, 2004 at 02:23:22PM -0600, brking@us.ibm.com wrote:
>
>>-static inline int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
>>-{
>>- return pci_bus_read_config_byte (dev->bus, dev->devfn, where, val);
>>-}
>
>
> Well, as much as I despise this patch, you should at least get it
> correct :)
>
> You need to block the pci_bus_* functions too, otherwise the parts of
> the kernel that use them will stomp all over your device, right?
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.
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?
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2004-11-19 22:28 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 [this message]
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
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=419E72EF.4010100@us.ibm.com \
--to=brking@us.ibm.com \
--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.