Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp622990ybb; Thu, 28 Mar 2019 09:00:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqw9oRVb7wRYMQyjz/8fORp8HxRFbh9IEY4BjaGYEKxVInM4IhoRyXbZaCjkVnWDlO/sc8w8 X-Received: by 2002:a17:902:848d:: with SMTP id c13mr29567258plo.279.1553788811732; Thu, 28 Mar 2019 09:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553788811; cv=none; d=google.com; s=arc-20160816; b=SNtoLf7ZyzjTE+akkVAfHYX8NFU7zZmccowOMVn4TsagwSNmUFYruE9p048BH3AM+o 6sZjpjl19HdCpSwoq4G8lA+2W9FTaRJda0BKeg7PU2fBeFpmf0STD9FVPQ4SdgLSiL6u D2FLXfc9DetlKTO+W/cwEC+sE66ErVu0JeEZFH7FBMJVkJBJG+xAkEe3ilYHokarAMDR Z1wosidd2ov/S7T82v6dtB5v1JrmL03xarZvOllayiwxLwu2nZDcZt7i1idlpP8Q60s2 vRn8+iUzIyOe48KA4OL/GN8rCNZy4eJP3PZCm067X/YBCwSvJu1b05v5bRSh745iW94D Axdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=+XipJYp0Qi3bJe5G3HI4AOTPG+sY3KVqP6z4GrgNtqE=; b=PWGTf7KY1uN3c77RTIHYVDqe56WDXZ+RGsaoNnlFeUYQzkWZfxWsDPaEObZ85hezj4 GYqU6mRMcWO/Nyo6QVsEdgnh0IrUaluYiKsFMeG2/SZwqLiBD/LxPhCd6SBpzT9DOqPA 6CliEg0q/T9JXNIl8kDNRNz4y4trPCRtl1U5HTA/CDYImfJon0NRy++7dYML2QPxfVZl 0Aa8eCyqH4KxQpMnS2NAnuv4Gv6LmAzoDeQfKI2Fgp7pw4dljsbmVzjH1FTAPYFzEmzX wdzKltAJHwvMdn3oILd9FgZsDawzoLoGPj6myA/4YWmmUnpnfvOgtokPBA/rzPlEhV0z O2Hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 37si22194769plc.233.2019.03.28.08.59.55; Thu, 28 Mar 2019 09:00:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726087AbfC1P5q (ORCPT + 99 others); Thu, 28 Mar 2019 11:57:46 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:53680 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726252AbfC1P5q (ORCPT ); Thu, 28 Mar 2019 11:57:46 -0400 Received: (qmail 4110 invoked by uid 2102); 28 Mar 2019 11:57:44 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Mar 2019 11:57:44 -0400 Date: Thu, 28 Mar 2019 11:57:44 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Oliver Neukum cc: Kento.A.Kobayashi@sony.com, , , , , , Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port In-Reply-To: <1553786139.14990.6.camel@suse.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Mar 2019, Oliver Neukum wrote: > On Do, 2019-03-28 at 07:53 +0000, Kento.A.Kobayashi@sony.com wrote: > > Hi, > > > > > Sorry, > > > > > > I thought this was clear. Your patch is making the assumption that the reset is triggered by the SCSI layer. You cannot make that assumption, as there is an ioctl for resetting a USB device. > > > In case we are getting an error during the reset (our endpoints vanish), the device driver must report that to the USB layer, so the driver will always be disconnected. > > > We cannot drop errors. > > > > > > Regards > > > Oliver > > > > This patch modified uas_post_reset to skip rebind operation to avoid exception while -ENODEV happens not drop error. > > If uas_post_reset happens -ENODEV, usb_reset_and_verify_device must happen error. > > So,when we use ioctl(USBDEVFS_RESET) to reset device, if usb_reset_and_verify_device happens error, the error will be reported through ioctl return value. > > OK, It is possible that I am stupid. We must rebind if uas_post_reset() > fails. The driver will crash without the endpoints. Can you please > explain again in greater detail, what you are trying to achieve? Actually no, the driver doesn't have to do anything if the post-reset method fails. usbcore will take care of rebinding automatically. Alan Stern