On Wed June 25 2008 02:41:11 Martin Mares wrote: > > Is there any interest in patches to libpci to provide read/write access > > to the cards' BARs? > > Definitely yes. Cool! How about this for a plan: I'll add a struct pci_bar with some fields to manage BAR access. I'll add this to struct pci_dev, down in the section marked "Fields used internally". struct pci_bar will have a type (mem or io), address, and a void* to hold mmapped memory regions, plus whatever else turns out to be relevant. I could leave type and address in pci_dev->base_addr and mask them out of there as needed, if you prefer. Then i'll add a pair of functions to struct pci_methods, similar to read() and write(), but taking an additional argument specifying the BAR to access. int (*read_bar)(struct pci_dev *, int bar, int pos, byte *buf, int len); int (*write_bar)(struct pci_dev *, int bar, int pos, byte *buf, int len); I'll add a pair of test programs like setpci to read and write pci regions. I'm only going to implement read_bar and write_bar for Linux because that's all I know; all other pci_methods will have them NULL until someone else implements them. Memory regions will be mmapped (on first use), IO regions will be accessed by inb/outb and friends. I think this should work for proc.c and sysfs.c and none of the others. Sound sane? Am I missing something? -- Sebastian Kuzminsky "The brain is [a machine]. The fact that it's made out of meat is a red herring." -- David Adler <http://www.spectrum.ieee.org/print/6268> -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
