Hi,
Sriharsha Allenki <sallenki@xxxxxxxxxxxxxx> writes:
> If the HWO bit is set for the TRB (or the first TRB if scatter-gather
> is used) of a request, it implies that core is still processing it.
> In that case do not reclaim that TRB and do not giveback the
> request to the function driver, else it will result in a SMMU
> translation fault when core tries to access the buffer
> corresponding to this TRB.
This is not entirely true. There are cases where driver *must* clear HWO
bit manually and driver currently accounts for that. Care to explain
what problem you actually found? Preferrably with tracepoint data
showing the fault.
> Signed-off-by: Sriharsha Allenki <sallenki@xxxxxxxxxxxxxx>
> ---
> drivers/usb/dwc3/gadget.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index a9aba71..4a2c5fc 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2476,6 +2476,14 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
> {
> int ret;
>
> + /*
> + * If the HWO is set, it implies the TRB is still being
> + * processed by the core. Hence do not reclaim it until
> + * it is processed by the core.
> + */
> + if (req->trb->ctrl & DWC3_TRB_CTRL_HWO)
> + return 1;
I'm pretty sure you're regressing a bunch of other cases here.
--
balbi
Attachment:
signature.asc
Description: PGP signature
