From: Brian King <brking@us.ibm.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Greg KH <greg@kroah.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andi Kleen <ak@muc.de>, Paul Mackerras <paulus@samba.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH 1/1] pci: Block config access during BIST (resend)
Date: Tue, 01 Feb 2005 11:35:05 -0600 [thread overview]
Message-ID: <41FFBDC9.2010206@us.ibm.com> (raw)
In-Reply-To: <20050201154400.GC10088@parcelfarce.linux.theplanet.co.uk>
Matthew Wilcox wrote:
>>+++ linux-2.6.11-rc2-bk9-bjking1/drivers/pci/access.c 2005-02-01
08:39:57.000000000 -0600
>>@@ -60,3 +60,78 @@ EXPORT_SYMBOL(pci_bus_read_config_dword)
>> EXPORT_SYMBOL(pci_bus_write_config_byte);
>> EXPORT_SYMBOL(pci_bus_write_config_word);
>> EXPORT_SYMBOL(pci_bus_write_config_dword);
>>+
>>+#define PCI_USER_READ_CONFIG(size,type) \
>>+int pci_user_read_config_##size \
>>+ (struct pci_dev *dev, int pos, type *val) \
>
> { \
> unsigned long flags; \
>
> Could you line up the \ so they're uniform like the above PCI_OP_READ?
Ok.
>>+ int ret = 0; \
>>+ u32 data = -1; \
>>+ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
>>+ spin_lock_irqsave(&pci_lock, flags); \
>>+ if (likely(!dev->block_ucfg_access)) \
>>+ ret = dev->bus->ops->read(dev->bus, dev->devfn, pos, sizeof(type), &data); \
>>+ else if (pos < sizeof(dev->saved_config_space)) \
>>+ data = dev->saved_config_space[pos/sizeof(dev->saved_config_space[0])]; \
>>+ spin_unlock_irqrestore(&pci_lock, flags); \
>>+ *val = (type)data; \
>
>
> Does this actually work? Surely if you're reading byte 14, you get the
> byte that was at address 12 or 15 in the config space, depending whether
> you're on a big or little endian machine?
It actually only works for 4 byte accesses. I am fixing this and will be
posting a patch later.
>>+void pci_unblock_user_cfg_access(struct pci_dev *dev)
>>+{
>>+ unsigned long flags;
>>+
>>+ spin_lock_irqsave(&pci_lock, flags);
>>+ dev->block_ucfg_access = 0;
>>+ spin_unlock_irqrestore(&pci_lock, flags);
>>+}
>
>
> If we've done a write to config space while the adapter was blocked,
> shouldn't we replay those accesses at this point?
I did not think that was necessary. It will certainly make the patch
more complicated. To implement it would really require we make the
userspace writers wait, which gets ugly since the wait is based on a
flag that can be updated at interrupt level so you end up with some fun
spinlocking. Not a big deal, it just starts getting ugly. Keep in mind,
one of the potential uses of this is for power management on PPC where a
given device could have its config space blocked for a long time.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2005-02-01 17:35 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-10 14:49 [PATCH 1/1] pci: Block config access during BIST (resend) brking
2005-01-10 16:10 ` Andi Kleen
2005-01-10 16:25 ` Brian King
2005-01-10 16:29 ` Andi Kleen
2005-01-10 22:57 ` Brian King
2005-01-11 14:37 ` Alan Cox
2005-01-11 17:33 ` Andi Kleen
2005-01-11 22:17 ` Brian King
2005-01-13 15:36 ` Alan Cox
2005-01-13 15:35 ` Alan Cox
2005-01-13 18:03 ` Andi Kleen
2005-01-13 18:46 ` Alan Cox
2005-01-13 20:23 ` Andi Kleen
2005-01-13 19:44 ` Alan Cox
2005-01-13 21:50 ` Andi Kleen
2005-01-15 0:33 ` Alan Cox
2005-01-15 1:44 ` Andi Kleen
2005-01-15 1:01 ` Alan Cox
2005-01-15 6:20 ` Benjamin Herrenschmidt
2005-01-16 0:58 ` Alan Cox
2005-01-16 4:01 ` Benjamin Herrenschmidt
2005-01-16 4:48 ` Andi Kleen
2005-01-16 20:53 ` Benjamin Herrenschmidt
2005-01-16 22:07 ` Andi Kleen
2005-01-16 22:14 ` Benjamin Herrenschmidt
2005-01-16 21:10 ` Alan Cox
2005-01-18 15:14 ` Brian King
2005-01-18 23:31 ` Andi Kleen
2005-01-18 23:36 ` Brian King
2005-01-19 22:40 ` Alan Cox
2005-01-26 16:34 ` Brian King
2005-01-26 22:10 ` Benjamin Herrenschmidt
2005-01-27 15:53 ` Alan Cox
2005-01-27 18:44 ` Brian King
2005-01-27 23:15 ` Benjamin Herrenschmidt
2005-01-28 14:35 ` Brian King
2005-02-01 7:27 ` Greg KH
2005-02-01 15:12 ` Brian King
2005-02-01 15:44 ` Matthew Wilcox
2005-02-01 17:35 ` Brian King [this message]
2005-02-01 17:47 ` Matthew Wilcox
2005-02-01 19:01 ` Brian King
2005-02-01 23:00 ` Benjamin Herrenschmidt
2005-02-02 15:33 ` Brian King
2005-02-08 20:08 ` Greg KH
2005-06-21 16:08 ` Brian King
2005-08-23 15:11 ` [PATCH 1/2] " Brian King
2005-08-23 15:14 ` [PATCH 2/2] ipr: " Brian King
2005-09-01 23:03 ` [PATCH 1/2] pci: " Andrew Morton
2005-09-02 23:56 ` Brian King
2005-09-02 22:43 ` Grant Grundler
2005-09-02 23:11 ` Paul Mackerras
2005-09-03 0:08 ` Grant Grundler
2005-09-03 23:37 ` Brian King
2005-09-03 19:39 ` Grant Grundler
2005-09-05 18:31 ` Brian King
2005-09-06 4:48 ` Grant Grundler
2005-09-06 14:28 ` Brian King
2005-09-07 5:49 ` Paul Mackerras
2005-09-07 14:58 ` Grant Grundler
2005-09-07 22:39 ` Paul Mackerras
2005-09-08 1:21 ` Grant Grundler
2005-09-08 3:05 ` Brian King
2005-09-08 4:08 ` Grant Grundler
2005-02-01 18:58 ` [PATCH 1/1] " Greg KH
2005-02-01 23:07 ` Benjamin Herrenschmidt
2005-02-01 22:58 ` Benjamin Herrenschmidt
2005-01-10 19:23 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2004-12-14 19:41 brking
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=41FFBDC9.2010206@us.ibm.com \
--to=brking@us.ibm.com \
--cc=ak@muc.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--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