[lkml]   [1999]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ideas for abstracting driver IO from bus implementation?

Alan Cox writes:
> > (1) Can you give some examples of what tokens you might want? I've been
> mca slot, pci slot

I presume that you're making these values as tokens so that the I/O access
routines (such as pcibios_write_config_byte) can be told how to access their

If this is the case, then the Vendor-Defined-Registers access functions that I
already provide could prove useful (or may be extended). This involves a pair
of functions pointed to by my device operations structure that allow access to
the devices registers:

int (*ci_read_vdr)(cmgr_device *dev, int addr, int num, int size,
void *buf);
int (*ci_set_vdr)(cmgr_device *dev, int addr, int num, int size,
const void *buf);

You pass the functions a device structure to say how to reach the device, and
leave the actual communication method up to them. It may involve a pcibios_*
function, or it may involve rendering down to some PCMCIA operations.

> private physical address space (not to be mapped by the kernel)

I'm not sure what your mean by this - doesn't it need to be mapped so that the
kernel can access it, or do you mean giving bits of real memory to a device
for its own purposes?

> I2O wants to claim things buy bus.

What exactly do you mean? Does I2O deal with whole buses rather than devices?
Or is it a case of I2O allocating resources to a bus?

David Howells

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:50    [W:0.051 / U:3.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site