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 21DB7C00140 for ; Tue, 26 Jul 2022 15:42:30 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8C6BF8409F; Tue, 26 Jul 2022 17:42:28 +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="lKio/38t"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 09D8B84055; Tue, 26 Jul 2022 17:42:27 +0200 (CEST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 2E80583FC9 for ; Tue, 26 Jul 2022 17:42:24 +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-wr1-x431.google.com with SMTP id m17so20434056wrw.7 for ; Tue, 26 Jul 2022 08:42:24 -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=3S5OoMljFrpPYX7Hkr0HpUMTxOz9Ex19x26TBcfqwYQ=; b=lKio/38tr5ULCBX8RWQziTNwB3hdIwLu+lUJ+xANWP+0LW7ozuoU9iB+7zvcf9uI2Z 8rmkNKmvCWoYWg1wmkg0D+4A0lCS/h6JB4FYX/fPh7s85H2YN6fW4mk+WXPrtSFD1QBC PQvzM+v8LXv3sxd2tnAir/eAf/o3HhpOdrUPfTaU80gh1Jp4CxkCkUYkeH9TBDhPlIG3 ht0Xq2Ahhe/w6G0p+VOtlQJF2yGtK6NtHHjsmWj+DsjHwSq69BJWWD1b3HXgXhbeZbv8 h6FPb1RXH9v33gxQLZ0p+0t4dga8iOsJEuRdMMQwNWaWQLwsMwdmKAbeX3oCwYoh9JLF Vd7A== 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=3S5OoMljFrpPYX7Hkr0HpUMTxOz9Ex19x26TBcfqwYQ=; b=GxI96CdSl7UH31pMFMxuWpJa8pHNDk+g6k0ZXj7f0qutGFZL4qpfTG4weDOacX2CXX JB8+BMq8ja8VLomn/BoYV+be1GbX3YJS4jmtyFbbzz/J6Y98W45NeyCiJVq0q1dV1pRv siTsq+VqyRhX+Y4xaTVg3AIDYWxaV3SfaYr/JMeurzwzDy2BD9QSDr6I2yjP4diLLYek hdtTWeowaBNiKxsLwZ9s9na6x3vgsKidZdrzLzyMQF39SeYytQx2t8RB6yUu0bmegUTU J6soRviwmn7Q/FyeLvQw4bi2nheqy4d6swvqkMvUAm94ZbwS3nyKi5wtVV/5XvFQT0yu U2Aw== X-Gm-Message-State: AJIora9NC3pOBARcNPlhx8JVYMq/RuWN3eUT/M9m8C3cvfml980TIUBN iyEtsGwM/HjNButvC4+m1fW28w== X-Google-Smtp-Source: AGRyM1uYCG2LawrZdFqsHeHvCYg6AL+ATuF3IRutBl494tVXsL+rKu8laajKfHgDGD1mIM7eMvHa7g== X-Received: by 2002:a5d:5e93:0:b0:21e:8de5:36be with SMTP id ck19-20020a5d5e93000000b0021e8de536bemr5855175wrb.325.1658850143662; Tue, 26 Jul 2022 08:42:23 -0700 (PDT) Received: from localhost ([82.66.159.240]) by smtp.gmail.com with ESMTPSA id b12-20020a5d550c000000b0021e4fd8e10bsm8262657wrv.11.2022.07.26.08.42.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jul 2022 08:42:23 -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: 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> <87sfmo1drs.fsf@baylibre.com> Date: Tue, 26 Jul 2022 17:42:21 +0200 Message-ID: <878rofanj6.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 Hi Marek, On Tue, Jul 26, 2022 at 15:36, Marek Vasut wrote: > On 7/26/22 10:25, Mattijs Korpershoek wrote: > [...] >>>>> 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. > > Yes, this is how I understand the problem too. > > Assume someone would run e.g. ums code, which would bring up the > controller too, I suspect it would also cause the same reset issues. > Which is why I wonder whether we shouldn't add this kind of fix into the > reset handler for the platform itself. Oh. Got it. I was solely focusing on my use case (fastboot) and not considering ums or other things. Thank you for the explanation. It probably makes sense to add it in the platform reset in that case. > >> 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. > > Does that also work with sysrq-B or reboot -nf (one of the fast reboots) ? # echo b > /proc/sysrq-trigger [ 3713.306318] sysrq: Resetting [ 3713.306462] SMP: stopping secondary CPUs Also triggers the same bug as the one I'm attempting to solve here. We observe a very long delay before the host reports: [31124.104342] usb 1-1: USB disconnect, device number 20 Thank you for bringing that up!