USB: ci13xxx_udc: Don't free dTD immediately after active bit is cleared

USB controller may access the dTD one more time after clearing the active
bit in token field.  There is a possibility of software freeing it in this
window.  When this happens, USB controller may access incorrect memory and
leads to system level issues.

dTDs are freed when requests are freed by function drivers during
disconnect or unbind.  The above race condition will come into effect only
for zero length packets.  dTDs are dynamically created for sending zero
length packets on IN endpoints.  These dTDs are immediately freed after
active bit is cleared.  Defer this to next dTD completion.  It is safe to
assume that hardware will no longer access the previous dTD when the next
dTD is completed.

Don't allocate/free setup status phase and GET_STATUS data phase requests
dynamically.  Use  one request for both cases and allocate it during bind.

CRs-Fixed: 474557
Change-Id: I5d41c310e1bb35d93b5af7d90a24ce5aab24f5f9
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usb: gadget: u_bam: fix race condition

On a usb cable connection/disconnection we place in a work queue the
function that is responsible to handle the connection/disconnection for
the RMNET interface.

If we connect the usb cable and disconnect it, we might get to the
condition that the connection function is running, though the usb cable
is disconnected. This may result in a NULL pointer access.

By this provided fix we check if the usb cable is disconnected before
trying to access a parameter that is set to NULL on cable disconnection.

CRs-Fixed: 468198
Change-Id: I5820c142ef84a7bfde773c725f6c3241f4ad60d6
Signed-off-by: Shimrit Malichi <smalichi@codeaurora.org>
Merge "USB: ci13xxx_udc: Don't free dTD immediately after active bit is cleared"
Merge "usb: gadget: u_bam: fix race condition"