On Wed, Feb 02, 2005 at 09:33:06AM -0600, Brian King wrote:
> Matthew Wilcox wrote:
> >On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
> >
> >>>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
Matthew Wilcox wrote:
On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
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.
We have to do *something*. We can't just throw away writes.
On Tue, 2005-02-01 at 10:58 -0800, Greg KH wrote:
> > If we've done a write to config space while the adapter was blocked,
> > shouldn't we replay those accesses at this point?
>
> This has been discussed a lot already. I think we might as well let the
> thing fail in random and odd ways, as it'
On Tue, 2005-02-01 at 17:47 +, Matthew Wilcox wrote:
> On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
> > >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.
>
> W
On Tue, 2005-02-01 at 15:44 +, Matthew Wilcox wrote:
>
> > +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);
> > +}
Matthew Wilcox wrote:
On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
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.
We have to do *something*. We can't just throw away writes.
On Tue, Feb 01, 2005 at 03:44:00PM +, Matthew Wilcox wrote:
> On Tue, Feb 01, 2005 at 09:12:56AM -0600, Brian King wrote:
> > Greg KH wrote:
> > >On Fri, Jan 28, 2005 at 08:35:46AM -0600, Brian King wrote:
> > >>+void pci_block_user_cfg_access(struct pci_dev *dev)
> > >>+{
> > >>+ unsigned long
On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
> >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.
We have to do *something*. We can't just throw away writes.
I see a fe
Matthew Wilcox wrote:
>>+++ linux-2.6.11-rc2-bk9-bjking1/drivers/pci/access.c 2005-02-01
08:39:57.0 -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_dwor
On Tue, Feb 01, 2005 at 09:12:56AM -0600, Brian King wrote:
> Greg KH wrote:
> >On Fri, Jan 28, 2005 at 08:35:46AM -0600, Brian King wrote:
> >>+void pci_block_user_cfg_access(struct pci_dev *dev)
> >>+{
> >>+ unsigned long flags;
> >>+
> >>+ pci_save_state(dev);
> >>+ spin_lock_irqsave(&pci_
Thanks for looking at this, Greg.
Greg KH wrote:
On Fri, Jan 28, 2005 at 08:35:46AM -0600, Brian King wrote:
+PCI_USER_READ_CONFIG(byte, u8)
+PCI_USER_READ_CONFIG(word, u16)
+PCI_USER_READ_CONFIG(dword, u32)
+PCI_USER_WRITE_CONFIG(byte, u8)
+PCI_USER_WRITE_CONFIG(word, u16)
+PCI_USER_WRITE_CONFIG(d
On Fri, Jan 28, 2005 at 08:35:46AM -0600, Brian King wrote:
> +#define PCI_USER_READ_CONFIG(size,type) \
> +int pci_user_read_config_##size \
> + (struct pci_dev *dev, int pos, type *val) \
> +{\
> + unsigne
Alan Cox wrote:
On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
Well, I honestly think that this is unnecessary burden. I think that
just dropping writes & returning data from the cache on reads is enough,
blocking userspace isn't nece
On Thu, 2005-01-27 at 15:53 +, Alan Cox wrote:
> On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
> > Well, I honestly think that this is unnecessary burden. I think that
> > just dropping writes & returning data from the cache
Alan Cox wrote:
On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
Well, I honestly think that this is unnecessary burden. I think that
just dropping writes & returning data from the cache on reads is enough,
blocking userspace isn't nece
On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
> On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
> Well, I honestly think that this is unnecessary burden. I think that
> just dropping writes & returning data from the cache on reads is enough,
> blocking userspace isn't necessary, b
On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
> Here is the last one. I've looked at making userspace sleep until BIST
> is finished. The downside I see to this is that is complicates the patch
> due to the following reasons:
>
> 1. In order to also make this work for Ben's PPC power man
Alan Cox wrote:
On Maw, 2005-01-18 at 15:14, Brian King wrote:
Alan - are you satisfied with the most recent patch, or would you prefer
the patch not returning failure return codes and just bit bucketing
writes and returning all ff's on reads? Either way works for me.
Which was the last one. For
On Maw, 2005-01-18 at 15:14, Brian King wrote:
> Alan - are you satisfied with the most recent patch, or would you prefer
> the patch not returning failure return codes and just bit bucketing
> writes and returning all ff's on reads? Either way works for me.
Which was the last one. For userspace
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 09:14:21AM -0600, Brian King wrote:
Andi Kleen wrote:
As Brian said the device he was working with would just not answer,
leading to a bus abort. This would get on a PC.
You could simulate this if you want, although I think a EBUSY or EIO
is bette
On Tue, Jan 18, 2005 at 09:14:21AM -0600, Brian King wrote:
> Andi Kleen wrote:
> >As Brian said the device he was working with would just not answer,
> >leading to a bus abort. This would get on a PC.
> >You could simulate this if you want, although I think a EBUSY or EIO
> >is better.
>
Andi Kleen wrote:
As Brian said the device he was working with would just not answer,
leading to a bus abort. This would get on a PC.
You could simulate this if you want, although I think a EBUSY or EIO
is better.
Alan - are you satisfied with the most recent patch, or would you prefer
t
On Sun, 2005-01-16 at 23:07 +0100, Andi Kleen wrote:
> > What is complex in there ? I agree it's not convenient to do this from
> > the very low level ones that don't take the pci_dev * as an argument,
> > but from the higher level ones that does, the overhead is basically to
> > test a flag in the
On Sul, 2005-01-16 at 04:48, Andi Kleen wrote:
> I just request that this shouldn't be done in the low level pci_config_read_*
> functions. Please keep them simple and lean. If you want such complex
> semantics for user space do it in a separate layer.
It seems reasonable not to implement the wai
> What is complex in there ? I agree it's not convenient to do this from
> the very low level ones that don't take the pci_dev * as an argument,
> but from the higher level ones that does, the overhead is basically to
> test a flag in the pci_dev, I doubt it will be significant in any way
> perform
On Sun, 2005-01-16 at 05:48 +0100, Andi Kleen wrote:
> > Right. Though I think the "will be back soon" and "is invisible" are
> > pretty much the same thing. That is, in both our cases (BIST and pmac
> > PM), we want the device to still be visible to userland, as it actually
> > exist, should be pr
> Right. Though I think the "will be back soon" and "is invisible" are
> pretty much the same thing. That is, in both our cases (BIST and pmac
> PM), we want the device to still be visible to userland, as it actually
> exist, should be properly detected by userland config tools etc..., but
> may on
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
> On Sad, 2005-01-15 at 06:20, Benjamin Herrenschmidt wrote:
> > I'm pretty sure similar situations can happen on other archs when
> > pushing a bit on power management, especially things like handhelds
> > (though not much of them are PCI based fo
On Sad, 2005-01-15 at 06:20, Benjamin Herrenschmidt wrote:
> I'm pretty sure similar situations can happen on other archs when
> pushing a bit on power management, especially things like handhelds
> (though not much of them are PCI based for now).
>
> That's why a "generic" mecanism to hide such d
29 matches
Mail list logo
