On Tue, 15 Mar 2005, Grant Grundler wrote:
> > Worse than that, it will disable the entire IRQ line, thus affecting other
> > devices that may be sharing it. That's not what I want; I need a way to
> > prevent a generic PCI device from issuing interrupt requests without
> > affecting other device
On Tue, Mar 15, 2005 at 10:10:57PM -0500, Brown, Len wrote:
> >Interrupt Disable bit was added via an
> >"Engineering Change Notice". At the same time, an "Interrupt Status"
> >bit was defined for the Status register.
>
> I believe that this is for (new) devices that support MSI.
Hrm...that soun
>Interrupt Disable bit was added via an
>"Engineering Change Notice". At the same time, an "Interrupt Status"
>bit was defined for the Status register.
I believe that this is for (new) devices that support MSI. While I'm
certainly out on a limb in this area, the last time I inquired about
MSI, n
On Tue, Mar 15, 2005 at 04:18:21PM -0700, Grant Grundler wrote:
...
> > Worse than that, it will disable the entire IRQ line, thus affecting other
> > devices that may be sharing it. That's not what I want; I need a way to
> > prevent a generic PCI device from issuing interrupt requests without
>
On Mon, Mar 14, 2005 at 10:46:02AM -0500, Alan Stern wrote:
...
> Very helpful, thanks. It appears that the main problem with disabling
> PCI devices as they are discovered lies with devices that are already in
> use (before their drivers have initialized!).
Yes - e.g. firmware is used to talk
On Sat, 12 Mar 2005, Grant Grundler wrote:
> Maybe this would help narrow the search?
>
> | Date: Tue, 6 Mar 2001 20:20:25 +0300
> | From: Ivan Kokshaysky <[EMAIL PROTECTED]>
> | To: Grant Grundler <[EMAIL PROTECTED]>
> | Cc: linux-kernel@vger.kernel.org
> ...
> | > The other part of the comment
On Sat, Mar 12, 2005 at 11:46:02AM -0500, Alan Stern wrote:
...
> > That is because that caused too much trouble when we tried to do it,
> > from what I remember. I think the lkml archives has that discussion
> > somewhere...
>
> It's quite believable that this might cause problems somewhere. An
On Fri, 11 Mar 2005, Greg KH wrote:
> On Fri, Mar 11, 2005 at 11:03:17AM -0500, Alan Stern wrote:
> > Greg:
> >
> > When the PCI subsystem discovers a device, it calls pci_setup_device to
> > initialize various things. It doesn't call pci_disable_device to stop the
> > device from doing DMA, o
On Fri, Mar 11, 2005 at 11:03:17AM -0500, Alan Stern wrote:
> Greg:
>
> When the PCI subsystem discovers a device, it calls pci_setup_device to
> initialize various things. It doesn't call pci_disable_device to stop the
> device from doing DMA, or do the equivalent (whatever that might be) to
On Fri, Mar 11, 2005 at 11:12:57AM -0700, Grant Grundler wrote:
> o platform devices (e.g. bridges) that don't have PCI drivers to re-enable
> them later. "transperent" Bridges are the only example I can come up with
> now but expect more to come out of the woodwork as this gets widely
> test
On Fri, Mar 11, 2005 at 04:19:08PM +, Matthew Wilcox wrote:
> > During a normal boot most devices are left in reasonably quiescent and
> > safe condition when the BIOS passes control to the OS. But sometimes a
> > few of them aren't; that's why we need to have the USB early-handoff quirk
> > c
On Fri, Mar 11, 2005 at 11:03:17AM -0500, Alan Stern wrote:
> When the PCI subsystem discovers a device, it calls pci_setup_device to
> initialize various things. It doesn't call pci_disable_device to stop the
> device from doing DMA, or do the equivalent (whatever that might be) to
> stop the
12 matches
Mail list logo
