Kristian Høgsberg wrote: > On 5/11/07, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote: >> James Bottomley wrote: >> > It strikes me that in all of this, we could also consider doing the DMA >> > mapping inside the mid layer (instead of in every driver). ... >> The old SBP-2 driver needs the virtual addresses of S/G elements if >> compiled with a certain config option. This option is meant for use >> with FireWire controllers which do not implement OHCI-1394, or to run >> the IEEE 1394 stack in a more secure mode. ... > Well, if we want to make a more secure mode for fw-sbp2.c where it, > like the old driver, manually copies the payload data from the general > async receive buffer to the destination, we'll still need the virtual > address. Yes, that's right. /If/ we are going to implement such a mode, then (a) the virtual addresses have to be passed down to ->queuecommand, and (b) DMA mapping would be unnecessary and wasteful. (For the list: By "secure" we mean that we wouldn't allow the FireWire controller to act as a bus bridge, and would be able to do boundary checks on local bus addresses which, in the SBP-2 protocol, are generally coming from the _target_. Without such a mode, the lower 4G of the initiator's memory are at the mercy of the target's firmware.) > How does the usb storage driver handle this? > > Kristian -- Stefan Richter -=====-=-=== -=-= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
