Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp1212653pxy; Thu, 6 May 2021 03:07:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1ND4ahFXQfYruMD8vELBtp7+MVKuD5hLDHoVrDgwP2x5QI4HGieQCPI4UL26NIsoNFbfN X-Received: by 2002:a17:907:20f7:: with SMTP id rh23mr3500214ejb.276.1620295623466; Thu, 06 May 2021 03:07:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620295623; cv=none; d=google.com; s=arc-20160816; b=YvzpxSsDpfaUH6r0NG80eUJQfA3sjh/6CjsBq/LNVx5/F6nzuqA6aakTB1eo5hIW2l cduf+PE1xsAqm0uXKX/x6u04driQZX2cF573apwaO/QfWbK/f0SKzheRrnwepfi9ly1V dXORhPK/DQ0TFRxvKJ8b7JdCHQg/6ugIwFr0uHw5Esb47QEGn3ihiuZEqs1LLtCREtiL E9TK/pYzYDZyyhmqR2vg1Bf4mc1zs1ihbm2Axb7SDZTGxTC0gdi+81p629yGqn0IFy4x pbr+0Yq29c74VldDGp5F5a0YpFBenpYRdzs89f8a32Ln/0ah+03cuYYe8ctlMJz/kbP6 uXjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=odKKyxKTQI0YT2KzH7Gsb37bl+2f9/fsLoVP91j+7w4=; b=gHZ9R5xeaEtaDYvVZwuDJp9hPJZqSoWlbIDLLycZzHU+HvQ2DGJHYfRK8rJFLso4F2 8MpFMnkbxGqIm0yr9Tgvj3K0llQXfOSss26rFZcLwbwGTEg08RHQRSqtCxnlWSIHPnEp 13aRrl/4CQemm+1Op4V8a2K3PvO03x8M/L+lGDbMABmOw4W4H3cR4mo4pUEdC4sZbx2C GsZjbrjAEAEpCRONwRgiluStkzp1ouwC9AsKzikHZiFA0JYkMjuADZ05FSAqnQATKL9R 5IhHTGUen680QFDC/uZkKc+NMIFIiPXeI5yXy3ld3wu7ByGHsRoHroxa0QYDYjQU/WYU SibQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XrcFl3DI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ky26si1987173ejc.683.2021.05.06.03.06.39; Thu, 06 May 2021 03:07:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XrcFl3DI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233855AbhEFJBV (ORCPT + 99 others); Thu, 6 May 2021 05:01:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35400 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233686AbhEFJBV (ORCPT ); Thu, 6 May 2021 05:01:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B7B72611AD; Thu, 6 May 2021 09:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620291623; bh=OErfeXtGgRd6vlDJ0sykxPf2X5MihrzXhkcnaJ5fi20=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XrcFl3DIOg3uCrNONYcIX0XmsKmAF67eGPOu46igYouDTwE81Z99GKuRivxZDi0s1 TBuOdO3DJn+PXYFGeJ5XtIDDxL+O6ftvTQgURVltR8CNg0Dc2Rn36jMKsUHg/EGL7+ JSZ8xaUxlV97fUxPh3pOrCENBNU7wiGTAyzenhXvpPFwP4xyXWPEEmUDQAY4BsMKMG AboPxfL9z1qAcyulVPqH8tWQGDMzc972ZJ2f972d+JbNwcDyHHhy64yGUktGwfLBeR KBbgnk8j/1SoTw00Q9RkXaIP+Z2qfT+whoSIzr12Ed+FKLKWCqL9iFbcF9s3kophZz tTihGM3wpSCoA== From: Felipe Balbi To: Wesley Cheng , Thinh Nguyen , "gregkh@linuxfoundation.org" Cc: "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "jackp@codeaurora.org" Subject: Re: [PATCH v2] usb: dwc3: gadget: Avoid canceling current request for queuing error In-Reply-To: <49c5e3eb-7c2b-a83b-2406-a620d91b827a@codeaurora.org> References: <1620091264-418-1-git-send-email-wcheng@codeaurora.org> <5b46e4a1-93ef-2d17-048b-5b4ceba358ae@synopsys.com> <513e6c16-9586-c78e-881b-08e0a73c50a8@codeaurora.org> <8735v1ibj4.fsf@kernel.org> <49c5e3eb-7c2b-a83b-2406-a620d91b827a@codeaurora.org> Date: Thu, 06 May 2021 12:00:15 +0300 Message-ID: <87r1ikgrts.fsf@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Wesley Cheng writes: >> If I understood the whole thing correctly, we want everything except the >> current request (the one that failed START or UPDATE transfer) to go >> through giveback(). This really tells me that we're not handling error >> case in kick_transfer and/or prepare_trbs() correctly. >>=20 > > We don't want the request passed in usb_ep_queue() to be calling > giveback() IF DONE IN the usb_ep_queue() context only. right, that's how this should behave. >> I also don't want to pass another argument to kick_transfer because it >> should be unnecessary: the current request should *always* be the last >> one in the list. Therefore we should rely on something like >> list_last_entry() followed by list_for_each_entry_safe_reverse() to >> handle this without a special case. >>=20 >> ret =3D dwc3_send_gadget_ep_cmd(); >> if (ret < 0) { >> current =3D list_last_entry(); >>=20 >> unmap(current); >> for_each_trb_in(current) { >> clear_HWO(trb); >> } >>=20 >> list_for_entry_safe_reverse() { >> move_cancelled(); >> } >> } >> > Nice, thanks for the suggestion and info! Problem we have is that kick > transfer is being used elsewhere, for example, during the TRB complete pa= th: > > static bool dwc3_gadget_endpoint_trbs_complete(struct dwc3_ep *dep, > const struct dwc3_event_depevt *event, int status) > { > ... > else if (dwc3_gadget_ep_should_continue(dep)) > if (__dwc3_gadget_kick_transfer(dep) =3D=3D 0) > no_started_trb =3D false; > > So in these types of calls, we would still want ALL requests to be > cancelled w/ giveback() called, so that the completion() callbacks can > cleanup/free those requests accordingly. > > If we went and only unmapped the last entry (and removed it from any > list), then no one would clean it up as it is outside of the > usb_ep_queue() context, and not within any of the DWC3 lists. oh, I see what you mean. At the moment we want kick_transfer to behave in two different manners and that's probably where the bug is originating from. It sounds like it's time to split kick_transfer into kick_queued_transfer() and e.g. continue_pending_transfers() The thing is that if we continue to sprinkle special cases all over the place, soon enough it'll be super hard to maintain the driver. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEE9DumQ60WEZ09LIErzlfNM9wDzUgFAmCTsB8RHGJhbGJpQGtl cm5lbC5vcmcACgkQzlfNM9wDzUikyQf+KPUf53NYTq5BWQIu+PodlU8bh2X4Cwel XeSYuLO6yJsrV+vj4j0x0diNhbBrH2W6m/0TI8CEPWaqgV+RYl3lN4wuZrSoKxHN +eEzSNdALLemT31vnYefbH0fWqWCwdoG+YLCaiN0Rro4iOH1F6gZctnNfLNu32So yIOp/JznC0xUqoiczvPSQpOszaYRo4CN6ak2H3JruLCX7hFrHO+wFK//jYAxIISH 8LJQX90cwN0FwseZdIUucOsu3pspPvjOFSCyEnWQfhH5VQRhSspREHd9YKbS6oyZ pIpE+2OkX6gDBLZ/kD7feJ4hhSndt75lVWiw3xWRQ/cMg+YN+EFqKg== =jrUs -----END PGP SIGNATURE----- --=-=-=--