In message <200602191932.39840.hselasky@c2i.net>Hans Petter Selasky writes
quoted text
>Hi,
>
>Can someone here help get the following BUS-DMA code right? Currently 
>"usb_alloc_mem()" works, but "usb_free_mem()" will cause a "uvm_fault()":


[...]

quoted text
>u_int32_t
>usb_vtophys(void *ptr, u_int32_t size)
>{
>    struct usb_dma *arg = (void *)(((u_int8_t *)ptr) + size);
>    return arg->seg.ds_addr;
>}


Hans Petter,

Can I ask: what is the semantics of vtophys()? I expect you're already
well aware that exposing real physical addresses (a` la classic
FreeBSD-4 vtophys()) is completely unacceptable for a
machine-independent NetBSD driver.  That would defeat the whole
purpose of NetBSD's bus_space(9)/bus_dma(9) APIs.

I don't see usb_vtophys(9) documented anywhere NetBSD-3-stable. Are
there other resources which explain this API which I should be
checking, to help me understand your code-fragment?

Are you really expecting a physical address here, or is this some
convenient way to get at a single bus-dma opaque cookie, in an
already-existing dma_map, corresponding to the given kva?

if the latter, I don't see how a u_int32_t can *ever*, under any
circumstances, be a correct machine-independent type for this
function. (How would it work on a machine where a bus_addr_t is bigger
than 32 bits???)

Is there something else going on here I'm overlooking, or not seeing,
perhaps due to your email showing only part of a larger picture?  If
that's so, can that "something else" be clearly documented before this
code becomes a candidate for inclusion in NetBSD?

... If nothing else, and assuming the overall aim of the code you're
working on is a Good Thing: can we at least change the name to remove
the word "vtophys", to avoid any unecessary worry and confusion?


thanks,
--Jonathan