Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1426763rda; Mon, 23 Oct 2023 12:12:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFtksgBw/sd0n4CvVB5CkloEpNii2y0lkdWDogRGzV6xLuYwh3UjYJwhtbHDHXBGoY32iSg X-Received: by 2002:a17:90b:23d6:b0:277:3565:30cf with SMTP id md22-20020a17090b23d600b00277356530cfmr18135611pjb.6.1698088330544; Mon, 23 Oct 2023 12:12:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698088330; cv=none; d=google.com; s=arc-20160816; b=GpAzizAr1Vy3cprxoksaj2u5+rqAhBP/fZ8LuRmIDnj3ZpR26Wiw3Wrk58RAGaDkrV GGrOIlFgRRMa5/k0MG5Ot3WpP4C0EkJFKpy+x6s6utliWaCF5HoGd8congDVVmynUQuI PDTQkXdNcu8WbdeY5TPzpscrp//3DTmn5MhLhxTBRAO9S6MhmiEz0mtxJcYTZwzZCMrR Ya6GrUMlSN3V8dVVXIj8229Yg5OiYDJd8gM5gXoJa1G+WEg2cEHPa1YVUnANg91ACn2u IK2GIUZak1RXp3hN/KL2M+K79Mas2oDJl3nPOQ8n8FK8eytJuInEqPNIim23zR4DCZoz H/BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=+ANiNEzN4NwfJfXcR7/XB5kRQB8CBBOMgHq2ILXU+Ks=; fh=CfFKgf8fgu+rbginYKqa38h3cNoteuuAwFHkvQOBJL8=; b=cm9bJwzuEUJvf8VkNIdoVkO3m8/Iqr78T4gVRPSyZ6K88+75D6vilFaxq93bgJm/xk CF1MAzaZFQzQNmyDFMdvoj5Oh7NhzapdvAMOzKnnp69CHq+Y2Kubkh29k4uryBd39/me VSW8pIPac/DO5tIiUQHEGZgO17Kp3ukcPJGf2P0M81uE8pRkhty+Mx3t7Vw1SDu92qSG auMJAKYcx5yt2G5lKUOt3S49LCo+EAAlhzqeqeggne9KmemNTGqXCE+u+WVGiDJJxWgH /5EuY+zFf/wb3ld/q36hsujunIn27kQnNwJLA4OSpb7Pw+7Ktq804NUgzCUkGzGOnuA3 vqeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id ob1-20020a17090b390100b002736ff3cc79si10293378pjb.23.2023.10.23.12.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Oct 2023 12:12:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 9DCB880621E4; Mon, 23 Oct 2023 12:12:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230328AbjJWTL4 (ORCPT + 99 others); Mon, 23 Oct 2023 15:11:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbjJWTLz (ORCPT ); Mon, 23 Oct 2023 15:11:55 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id B1416101 for ; Mon, 23 Oct 2023 12:11:50 -0700 (PDT) Received: (qmail 432947 invoked by uid 1000); 23 Oct 2023 15:11:49 -0400 Date: Mon, 23 Oct 2023 15:11:49 -0400 From: Alan Stern To: Meng Li Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: storage: add shutdown function for usb storage driver Message-ID: <33bd0779-bfe7-4c87-8fe6-ea8455df3b6b@rowland.harvard.edu> References: <20231023054111.2744872-1-Meng.Li@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231023054111.2744872-1-Meng.Li@windriver.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Mon, 23 Oct 2023 12:12:07 -0700 (PDT) On Mon, Oct 23, 2023 at 01:41:11PM +0800, Meng Li wrote: > On ls1043/ls1046 rdb platform, if a PCIe-USB host controller is installed, and > an USB disk is also installed on the PCIe card, when executing "reboot -f" to > reset the board, there will be below error reported: > usb 2-2: device not accepting address 2, error -108 Do you mean that this error occurs after the system has rebooted? Or do you mean that the error is reported while the reboot is taking place? That "device not accepting address" error message is generated by the USB core, not by the usb-storage driver. How will changing usb-storage help fix the problem? > This issue is introduced by linux-yocto commit 837547b64a34("driver: net: > dpaa: release resource when executing kexec") that cause to spend more > time on shutdown operation. So, the 2 platforms with DPAA are not reset > immediately after executing force reboot command. Moreover, the usb-storage > thread is still in active status, there is still control data transferred between > USB disk and PCIe host controller. But now the shutdown callback of usb pci driver > had been invoked to stop the PCIe host controller completely. In this situation, > the data transferring failed and report error. That's _supposed_ to happen. By design, the "reboot -f" command is meant to carry out an immediate reboot, without using the init system, unmounting filesystems, or doing other cleanup operations. If you want a clean reboot with no errors, don't use the "-f" option. > Therefore, add shutdown function > used to disconnect the usb mass storage device to avoid data transferring under > the stopped status of PCIe device. I don't see how this will fix the problems associated with a forced reboot. How is preventing data from being transferred any better than getting an error when you do try to transfer it? > Signed-off-by: Meng Li > --- > drivers/usb/storage/usb.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c > index ed7c6ad96a74..e076d7e3784f 100644 > --- a/drivers/usb/storage/usb.c > +++ b/drivers/usb/storage/usb.c > @@ -1142,6 +1142,15 @@ static int storage_probe(struct usb_interface *intf, > return result; > } > > +static void usb_stor_shutdown(struct device *dev) > +{ > + struct usb_driver *driver = to_usb_driver(dev->driver); > + struct usb_interface *intf = to_usb_interface(dev); > + > + if (driver->disconnect) > + driver->disconnect(intf); > +} > + > static struct usb_driver usb_storage_driver = { > .name = DRV_NAME, > .probe = storage_probe, > @@ -1151,6 +1160,7 @@ static struct usb_driver usb_storage_driver = { > .reset_resume = usb_stor_reset_resume, > .pre_reset = usb_stor_pre_reset, > .post_reset = usb_stor_post_reset, > + .drvwrap.driver.shutdown = usb_stor_shutdown, This definitely looks like a layering violation. If devices are to be disconnected during a system shutdown, the USB core should take care of it. Not the individual device drivers. What will happen if you make this change to usb-storage? In a little while you'll want to do the same thing to the uas driver. And then the usbhid driver. And the usb serial drivers. And so on... This does not seem like the best solution to whatever problem you want to solve. > .id_table = usb_storage_usb_ids, > .supports_autosuspend = 1, > .soft_unbind = 1, Alan Stern