On 18/10/12 01:11 PM, Arvid Brodin wrote:
On 2012-10-17 00:32, Richard Retanubun wrote:
Hi Arvid,
I am working on isp1763-hcd (a smaller, kind-of-sort-of variant of isp1760)
The driver was adapted from the original isp1760 before you worked on it a bunch.
I am looking at my adapted driver again because we have a case where isp1763
is connected to two modem (one on each port) and alloc_mem() failed because
it ran out of 4096 chuck to allocate (from the 20KB payload size that isp1763 have, 16KB
(4x4096) is allocated for this)
I am having trouble understanding the protection mechanism for alloc_mem failing
in the current state of isp1760-hcd.
I understand that the qtd->payload_addr will not be assigned,
but how does that trace back to isp1760_urb_enqueue() knowing that the urb that it is
currently
being asked to enqueue cannot be serviced due to lack of payload memory so that we can
correctly
return -ENOMEM there?
or is there a different mechanism to say:
"listen usbcore, I got no more payload/internal buffer space,
please let my caller know so they can abort and try again"
Thanks so much for everyone's time
Hi Richard!
If there's not enough free on-chip memory to transfer a qtd, we just leave it in the
software/kernel queue and wait until other qtds have finished, and then try again. So
there's no trace-back to the urb_enqeue() function. The same mechanism is used if we run
out of on-chip slots.
Thanks for the guidance Arvid.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
