On Tue, Jul 05, 2005 at 01:46:20PM -0400, John W. Linville wrote:
> On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
> > On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
>
> > > + /* Some devices lose PCI config header data during D3hot->D0
> >
> > Can you name
On Tue, Jul 05, 2005 at 01:46:20PM -0400, John W. Linville wrote:
On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
+ /* Some devices lose PCI config header data during D3hot-D0
Can you name some of those
On Fri, Jul 08, 2005 at 12:33:33AM -0700, David S. Miller wrote:
> Do PCI devices ever come out of reset in a PM state, and thus
> would execute John's new code as a side effect?
PCI spec requires that all devices must enter D0 state from
power on reset, so this code shouldn't be executed unless
From: Ivan Kokshaysky <[EMAIL PROTECTED]>
Date: Fri, 8 Jul 2005 11:03:58 +0400
> On Thu, Jul 07, 2005 at 11:35:30PM -0700, David S. Miller wrote:
> > That's fine, what would be the most minimal implementation?
>
> #define pci_update_resource(dev, res, n) BUG()
>
> No, I'm serious - I don't
On Thu, Jul 07, 2005 at 11:35:30PM -0700, David S. Miller wrote:
> That's fine, what would be the most minimal implementation?
#define pci_update_resource(dev, res, n)BUG()
No, I'm serious - I don't believe that generic implementation of
pcibios_resource_to_bus() in the proposed patch
From: Ivan Kokshaysky <[EMAIL PROTECTED]>
Date: Fri, 8 Jul 2005 09:51:04 +0400
> Why not just implement sparc64 version of pci_update_resource elsewhere
> (perhaps a dummy one, if you don't need PCI PM), rather than force the
> rest of the world to duplicate the code?
That's fine, what would be
From: Ivan Kokshaysky [EMAIL PROTECTED]
Date: Fri, 8 Jul 2005 09:51:04 +0400
Why not just implement sparc64 version of pci_update_resource elsewhere
(perhaps a dummy one, if you don't need PCI PM), rather than force the
rest of the world to duplicate the code?
That's fine, what would be the
On Thu, Jul 07, 2005 at 11:35:30PM -0700, David S. Miller wrote:
That's fine, what would be the most minimal implementation?
#define pci_update_resource(dev, res, n)BUG()
No, I'm serious - I don't believe that generic implementation of
pcibios_resource_to_bus() in the proposed patch
From: Ivan Kokshaysky [EMAIL PROTECTED]
Date: Fri, 8 Jul 2005 11:03:58 +0400
On Thu, Jul 07, 2005 at 11:35:30PM -0700, David S. Miller wrote:
That's fine, what would be the most minimal implementation?
#define pci_update_resource(dev, res, n) BUG()
No, I'm serious - I don't believe
On Fri, Jul 08, 2005 at 12:33:33AM -0700, David S. Miller wrote:
Do PCI devices ever come out of reset in a PM state, and thus
would execute John's new code as a side effect?
PCI spec requires that all devices must enter D0 state from
power on reset, so this code shouldn't be executed unless
On Thu, Jul 07, 2005 at 08:11:03PM -0700, David S. Miller wrote:
> > Problem: pci_update_resource doesn't exist for sparc64.
>
> Yes, the drivers/pci/setup-res.c code isn't compiled in on
> sparc64 because it assumes a totally different model of
> PCI bus probing than we use on sparc64.
Why not
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 7 Jul 2005 20:57:04 -0400
> Problem: pci_update_resource doesn't exist for sparc64.
Yes, the drivers/pci/setup-res.c code isn't compiled in on
sparc64 because it assumes a totally different model of
PCI bus probing than we use on sparc64.
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
> On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
> > Rather than reimplementing the internals of pci_update_resource() it
> > may be worth splitting the common stuff out so it gets fixed for both
> >
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
Rather than reimplementing the internals of pci_update_resource() it
may be worth splitting the common stuff out so it gets fixed for both
pci_update_resource()
From: John W. Linville [EMAIL PROTECTED]
Date: Thu, 7 Jul 2005 20:57:04 -0400
Problem: pci_update_resource doesn't exist for sparc64.
Yes, the drivers/pci/setup-res.c code isn't compiled in on
sparc64 because it assumes a totally different model of
PCI bus probing than we use on sparc64.
On
On Thu, Jul 07, 2005 at 08:11:03PM -0700, David S. Miller wrote:
Problem: pci_update_resource doesn't exist for sparc64.
Yes, the drivers/pci/setup-res.c code isn't compiled in on
sparc64 because it assumes a totally different model of
PCI bus probing than we use on sparc64.
Why not just
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
> On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
> > On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
> > > 64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
> > > ought to support
On Wed, Jul 06, 2005 at 03:34:54AM +0400, Ivan Kokshaysky wrote:
On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
ought to support 64-bit BARs
On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
> On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
> > 64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
> > ought to support 64-bit BARs on 32-bit machines.
>
> This only occurs because the
On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
> On Sat, Jul 02, 2005 at 09:09:13AM +0100, Russell King wrote:
> > The PCI subsystem is incomplete for 64-bit BAR support. What it does
> > do though is ensure that 64-bit BARs will work correctly in a 32-bit
> > system. Therefore,
On Sat, Jul 02, 2005 at 09:09:13AM +0100, Russell King wrote:
> The PCI subsystem is incomplete for 64-bit BAR support. What it does
> do though is ensure that 64-bit BARs will work correctly in a 32-bit
> system. Therefore, I think that folk who want 64-bit BAR support to
> work need to do some
On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
> On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
> > + /* Some devices lose PCI config header data during D3hot->D0
>
> Can you name some of those devices here?
> I just want to know what sort of devices need to
On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
+ /* Some devices lose PCI config header data during D3hot-D0
Can you name some of those devices here?
I just want to know what sort of devices need to be
On Sat, Jul 02, 2005 at 09:09:13AM +0100, Russell King wrote:
The PCI subsystem is incomplete for 64-bit BAR support. What it does
do though is ensure that 64-bit BARs will work correctly in a 32-bit
system. Therefore, I think that folk who want 64-bit BAR support to
work need to do some
On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
On Sat, Jul 02, 2005 at 09:09:13AM +0100, Russell King wrote:
The PCI subsystem is incomplete for 64-bit BAR support. What it does
do though is ensure that 64-bit BARs will work correctly in a 32-bit
system. Therefore, I
On Tue, Jul 05, 2005 at 10:46:20PM +0100, Russell King wrote:
On Tue, Jul 05, 2005 at 09:05:55PM +0100, Matthew Wilcox wrote:
64-bit BARs work fine on 64-bit machines. I'm ambivalent whether we
ought to support 64-bit BARs on 32-bit machines.
This only occurs because the problematical
26 matches
Mail list logo
