[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.019 / U:13.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site