James Bottomley wrote:
> david-b@pacbell.net said:
>
>>The indirection is getting from the USB device (or interface) to the
>>object representing the USB controller. ...
>
> This sounds like a mirror of the problem of finding the IOMMU on parisc (there
> can be more than one).
Wouldn't it be straightforward to package that IOMMU solution using the
"call dev->whatsit->dma_op()" approach I mentioned? Storing data in
the "whatsit" seems more practical than saying driver_data is no longer
available to the device's driver. (I'll be agnostic on platform_data.)
This problem seems to me to be a common layering requirement. All the
indirections are known when the device structure is being initted, so it
might as well be set up then. True for PARISC (right?), as well as USB,
SCSI, and most other driver stacks. I suspect it'd even allow complex
voodoo for multi-path I/O too...
- Dave
> The way parisc solves this is to look in dev->platform_data and if that's null
> walk up the dev->parent until the IOMMU is found and then cache the IOMMU ops
> in the current dev->platform_data. Obviously, you can't use platform_data,
> but you could use driver_data for this. The IOMMU's actually lie on a parisc
> specific bus, so the ability to walk up the device tree without having to know
> the device types was crucial to implementing this.
>
> James
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:12 EST