From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41BAFC43334 for ; Tue, 26 Jul 2022 08:25:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0E528841A4; Tue, 26 Jul 2022 10:25:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=baylibre-com.20210112.gappssmtp.com header.i=@baylibre-com.20210112.gappssmtp.com header.b="qnkJXTTR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 195508419F; Tue, 26 Jul 2022 10:25:50 +0200 (CEST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4887E841D4 for ; Tue, 26 Jul 2022 10:25:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mkorpershoek@baylibre.com Received: by mail-wm1-x32c.google.com with SMTP id v5so8266188wmj.0 for ; Tue, 26 Jul 2022 01:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=mZvAZYv3SbE/xobI4eNmt6xth/qmRDDFhAcMqrHrrAU=; b=qnkJXTTRlCa9oXGMn+bBANUfviWz+SSkhUqaI48xx+fupR7tCoQPKgFr3MekPWMvbY Y+8uXXvOhKA8M32RENKS/3TIHMYBTO48okQqcoVgHA7uOJu2gWTpmYxo77Y9ZbSzQlIy lo/qI0wW/tkuvwQBkxyO/X8jXxWoV7NGDCCXdpAqPgc5IiO8OmYnjQ2oZ5nndAXsbIoM I+r4tDgEsjuHi1whd9MqvEUWxdyqsG5sFfUnaOVul6WwCl2PNI6wHK6YGkXk+E8YPFEF jbFmzQ1b5NpIUFfuIwzbSibeK5OsqobewSKVJdCOqS0qimCyKghJXADaPoBLEj9x2gZh Nlww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=mZvAZYv3SbE/xobI4eNmt6xth/qmRDDFhAcMqrHrrAU=; b=yEvruFPKWIq0iGmyv38zHYepydT9w4W6/4E5DMetYC1ubz8fDkh6W4yTamHotxHkcE MZFsFaEsjC/Bm1e4mBtEyIWDe+8su/m4EESq9XaqknP366c3RDDxBtdoqz0dMtCO/TeH 7JHwh3aAXOBRy6pVm0gicY1vegmwNi5996tLJpoU0lW9M8J9/uJQFazh8iQAqsZkH+hF MdINx7Uvk1LYjvAFRdS40JqKCcxcuqr+CBqj6kL3soIq/Tl1qNr5ydJd0cOPwFJopvi+ xhnXOsge9WCF4ZWPWHplcge+i2MPQIaVif7hEuD+XMIGHc5F9ff2dM3WPwTOehZF1B1s yTUg== X-Gm-Message-State: AJIora9mXGzJJd6Fd/2rUJKEew1CI6kQ2M67EgkeSGkKkU6amzBme5ql 9sF9ZviKfTzAikUc3BlFG6891g== X-Google-Smtp-Source: AGRyM1vGSgzxcAClDTI19SPRvxXxOHTSzYrsvXKlON1sM2x4oas67AmVqntUhTaLIMSpC0pH1ZiOyw== X-Received: by 2002:a7b:c391:0:b0:3a3:2f22:7bf6 with SMTP id s17-20020a7bc391000000b003a32f227bf6mr19088361wmj.96.1658823945514; Tue, 26 Jul 2022 01:25:45 -0700 (PDT) Received: from localhost ([82.66.159.240]) by smtp.gmail.com with ESMTPSA id d13-20020adf9c8d000000b0021e4c3b2967sm14374530wre.65.2022.07.26.01.25.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jul 2022 01:25:45 -0700 (PDT) From: Mattijs Korpershoek To: Marek Vasut , Lukasz Majewski , Neil Armstrong Cc: Simon Glass , u-boot@lists.denx.de Subject: Re: [PATCH] fastboot: release usb_gadget on reboot commands In-Reply-To: <97d45c9e-928b-fb2e-1755-193dba5eb12d@denx.de> References: <20220721135955.360195-1-mkorpershoek@baylibre.com> <5ca58b87-24d2-8b45-2bf3-29d51f413123@denx.de> <87czdtjpnp.fsf@baylibre.com> <97d45c9e-928b-fb2e-1755-193dba5eb12d@denx.de> Date: Tue, 26 Jul 2022 10:25:43 +0200 Message-ID: <87sfmo1drs.fsf@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On Mon, Jul 25, 2022 at 17:30, Marek Vasut wrote: > On 7/25/22 15:19, Mattijs Korpershoek wrote: >> On ven., juil. 22, 2022 at 23:48, Marek Vasut wrote: >> >>> On 7/21/22 15:59, Mattijs Korpershoek wrote: >>> >>> [...] >>> >>>> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c >>>> index 8ba55aab9f8f..a00d1ca571d1 100644 >>>> --- a/drivers/usb/gadget/f_fastboot.c >>>> +++ b/drivers/usb/gadget/f_fastboot.c >>>> @@ -420,7 +420,8 @@ static int fastboot_tx_write_str(const char *buffer) >>>> >>>> static void compl_do_reset(struct usb_ep *ep, struct usb_request *req) >>>> { >>>> - do_reset(NULL, 0, 0, NULL); >>>> + g_dnl_trigger_detach(); >>>> + g_dnl_trigger_reset_request(); >> >> Hi Marek, >> >> Thank you for your review and your suggestions. >> >>> >>> Wouldn't it be enough to call usb_gadget_release() before do_reset() >>> here ? Or actually fix up the hardware state in your platform reset >> >> Calling usb_gadget_release() just before do_reset() is sufficient as well. >> However usb_gadget_release(int index) takes a controller index as >> argument. >> This controller index is retrieved from the "=> fastboot" cmd and I >> could not come up with something elegant to retrieve it from >> f_fastboot.c. >> I can have another look if you think that's a better solution. > > I think it would be nice to have this kind of generic fix in addition to > one specific to your platform , as discussed below. ACK > >>> implementation, which would cover all such odd states for every other >>> USB UDC mode of operation, not just fastboot ? >> >> Implementing a platform_reset to reset the usb controller also works. >> I discussed this with Neil at [1] and he suggested to send the f_fastboot.c fix >> (this one) because it's generic and might fix issues for other boards. >> >> So, should I abandon this version and go with the platform specific fix instead ? >> >> [1] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/commit/94c79b8226875babc20311cac7dac30e79238c9d#note_1020214136 > > If your controller is responsible for causing the platform to fail to > reboot, then I think it makes sense to do a fix either in the reset > implementation for that platform, or the controller driver. To be clear, the usb controller is *not* causing the whole platform to reboot. On do_reset(), the platform resets fine. However, the usb controller is *not* put in reset. Because of that, the host does not detect a USB disconnection. Which is what I'm trying to solve here. If we do the generic fix, there is not really a point into implementing a platform specific reset. Note that on linux, when we run "reboot" the driver's remove() function takes care of usb reset.