[lkml]   [2000]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: pdev_enable_device no longer used ?

On Mon, 11 Dec 2000, Jamie Lokier wrote:

> Here are a few more:
> net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
> net/gmac.c: PCI_CACHE_LINE_SIZE, 8);

> scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n",

For this one, this happens on Intel:

- ONLY if PCI cache line size was configured to ZERO (i.e. not


- ONLY if user asked for this through the boot command line.

Anyway, the driver WARNs user about if it shoe-horns some value as you can
see above.

Btw, there is a single case where using MWI is a workaround.

Given that all known systems have a known PCI CACHE LINE SIZE for L2/L3,
if POST software + O/S PCI driver are loose enough not to provide the
RIGHT value of the PCI CACHE LINE LINE for devices that support it, what
software drivers can do ?

May-be, they should just refuse to attach the device, at least when this
information _must_ be known in order to work-around a device problem. This
will remove some ugly code for non-Intel plat-forms from the sym53c8xx
source, by the way.

Having to call some pdev_enable_device() to have the cache line size
configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER,
etc.. are configured prior to entering driver probe. Why should the cache
line size be deferred to some call to some obscure mismaned thing ?



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.074 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site