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. -- Arvid Brodin | Consultant (Linux) T: +46-8-56254286 | M: +46-70-9714286 | arvid.bro...@xdin.com XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
