Grant Grundler wrote:
On Fri, Oct 06, 2006 at 03:59:57PM -0400, Jeff Garzik wrote:
The unmodified tulip driver checks both MWI and cacheline-size because
one of the clones (PNIC or PNIC2) will let you set the MWI bit, but
hardwires cacheline size to zero.
Maybe the generic pci_set_mwi() can v
On Fri, Oct 06, 2006 at 03:59:57PM -0400, Jeff Garzik wrote:
> The unmodified tulip driver checks both MWI and cacheline-size because
> one of the clones (PNIC or PNIC2) will let you set the MWI bit, but
> hardwires cacheline size to zero.
Maybe the generic pci_set_mwi() can verify cacheline siz
Matthew Wilcox wrote:
On Fri, Oct 06, 2006 at 03:15:15PM -0400, Jeff Garzik wrote:
Matthew Wilcox wrote:
Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
NAK, not true on all arches. sparc64 at least presumes that the
firmware DTRT
On Fri, Oct 06, 2006 at 03:15:15PM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >Also, pci_set_mwi() will fail if the cache line
> >size is 0, so we don't need to check that ourselves any more.
>
> NAK, not true on all arches. sparc64 at least presumes that the
> firmware DTRT with cachel
Matthew Wilcox wrote:
Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
NAK, not true on all arches. sparc64 at least presumes that the
firmware DTRT with cacheline size, which hurts us now given this tulip patch
Jeff
-
T
We used to check whether pci_set_mwi() had succeeded by testing the
hardware MWI bit. Now we need only check the return value (and failing
to do so is a warning). Also, pci_set_mwi() will fail if the cache line
size is 0, so we don't need to check that ourselves any more.
Signed-off-by: Matthew
