From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B1B82DB7BF for ; Wed, 11 Feb 2026 16:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770826084; cv=none; b=g/Lzvlu7uLoMh+5Tub1LsyoPhyAukIG/w3aTMYQpPN1UWzALNsLVHz7ycghoNSN0TPHPocJaZDoIRSNGyXYDcS3gox1+WLqGiDJh3lSrTqtGOMO1UtisYpOGBl6QDsIZZUjHzcsWLAvj+hTgwjJyNLWiZhsNpF9iIXUmpe3j6G0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770826084; c=relaxed/simple; bh=s04o5hTyrMpNFBENViq5Qgrk2QRSzV1Z2DuGYu8iosI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VM4bD3IkTlD22a5VvkccbrXTPIh4iRMiV75n+7aWodgVoAqoqXeg8pqnF9NIsnqQXF1DSO25CLuJ9uTTVcxwcWMwY6umZlaiq44jQj/SSOQ+ZyQAN+RYX/fVTQKV5d5i1QuiuSQLrzaZuL5xbNCDusVVO1CZ25VKgOMDms5Z0Jo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=BcEQYGUj; arc=none smtp.client-ip=209.85.160.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="BcEQYGUj" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-502acd495feso60606601cf.2 for ; Wed, 11 Feb 2026 08:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1770826082; x=1771430882; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=i6MYvX1gR68dNM+fhSBJT97Ks8m4rTWUudCKuKAg+KA=; b=BcEQYGUj10AqwjQhVkuNjdRaCKPRRAYHJ6FmykxMcU8433xtaDnJbp6874cId++lQy g4Aq6LogDJLMRzapsdt7Qtd7A1qwKQ9N/Q/q7awDZpEI3E/Agep09nu+iJpouill2qpV QsigpQvovKi/mOh2Jj3UeR3w+N6+c3Q6/mrRWazjhFiefKzVxAZ5UzF+Ja7sMxhsp20O 2p2P0sagp6G8djDpUIYhqKO3FZoGCBn5NFijuErGB/b9SBEYWH3o7X4KdEI7oZKdKu1H QjnF+in91jLfbbWWqHoODNbJapbiU+kTIBupWyJiVz0n+ow239Rnmvh/Z5i0CM65x0p/ IxGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770826082; x=1771430882; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i6MYvX1gR68dNM+fhSBJT97Ks8m4rTWUudCKuKAg+KA=; b=xRt78G7FK+GW4d0a4+rxoSELlvtFLV0ACUrtd55zjutJ6bZ8cBES+CdqpsnLvKxIZv +22dgBo7ic4vs510V0ARs9VdEApUYvIFqhlZZTuoMkfDmuDTvNFaRXUAHfud+pmQOlWk h6E8NjxIJDjD/MZpxtvjwZ64Hka7ttvDlEtnqZrvErVGF8gZPit4I0wZz9/xNRhUsePj MvYZt8zerEQ/BSTZVD4KXPeM+iKMSKQ+yHnMY+oHgFU4wH3ScGRuRb3pHt4enB95Np/D ZwjmKJ8EGsqhjjt08W/bSEEDKcJ4yDweeT73FeKHkhYnkMjtenMfArAJrnZzfGv5Wyxg GgGA== X-Forwarded-Encrypted: i=1; AJvYcCWNK5d5/N49zuekwHcrpmLbbQJfKoSl5QVvJ9+PzEGBxejZej/xTKMif2bymDcoGueOqMq5o7M6LTmNEdk=@vger.kernel.org X-Gm-Message-State: AOJu0YxV5SmLOg6gWSSPlOPscp1P0hES8DTiGV43klZkEcl/xw4lv303 In5fOOvTTV5/lqdrIttzVfAeIlOcaC2DVGGs/iwXzix26Rwg1OPCZDJbivbVpO73Dwt5SCUJt95 HiUs= X-Gm-Gg: AZuq6aIsICW0+HTawWigZ5zOJuPqdjhBp53GV3xLRRWKVchokp5eyzM0oFmmBJ781SQ 9Rr+fl0gEAQYXZGAt1sE75JYVVq1nrn4S9VvANxfRqBMHlrmUqIUHH0MsoyNtryRY8/cie/0ywU BJAeJ2EF/RfmjTesKkF9MlRgcR0/2SRBaZFtYZBJb3n8Zrnh8kWph+sOXLCxrvbBLPIx0pkzZnV HJcGtGbEbKa5r7GROaawFuKArIvH35r8f4jsKcrHwPyntbOIFBr09HmkJKB3a1Bzzfu16cnxvTj giZldNSPj1QL+xiNsZpzMbTK0JpwdBs/9Ixe4yk1h/WLm36+Rig3HDzfuIiccAA0ojaAOH3jDZd nmQbtRti/y/Z0eoTx9t4PTNugAuBMJw+QXcYavSmz8O4Bd1Wsn1mhGyi4LkfTGTCH/VcmTW6xWW vYp73INddQ6DfppKwoe3FOxyqpNneM5Eb3SFO/tlua/g== X-Received: by 2002:a05:622a:4ce:b0:501:b1be:c31b with SMTP id d75a77b69052e-5068102b8c5mr43217181cf.14.1770826082356; Wed, 11 Feb 2026 08:08:02 -0800 (PST) Received: from rowland.harvard.edu ([140.247.181.15]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cb2b0bc8f5sm143497785a.6.2026.02.11.08.08.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Feb 2026 08:08:01 -0800 (PST) Date: Wed, 11 Feb 2026 11:07:57 -0500 From: Alan Stern To: Greg KH Cc: Xu Yang , m.grzeschik@pengutronix.de, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, jun.li@nxp.com Subject: Re: [PATCH] usb: port: add delay after usb_hub_set_port_power() Message-ID: <5639afb1-217e-47f3-906d-e2b7b87bbe7f@rowland.harvard.edu> References: <20260211103628.3265850-1-xu.yang_2@nxp.com> <1be3ca8a-032d-487e-92f4-67b2070be213@rowland.harvard.edu> <2026021153-tactful-steadily-5eae@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2026021153-tactful-steadily-5eae@gregkh> On Wed, Feb 11, 2026 at 04:47:42PM +0100, Greg KH wrote: > On Wed, Feb 11, 2026 at 10:04:32AM -0500, Alan Stern wrote: > > On Wed, Feb 11, 2026 at 06:36:28PM +0800, Xu Yang wrote: > > > When disable the root hub port, somehow the device is disconnected and > > > re-connected again. This happens because usb_clear_port_feature() does not > > > clear a truly happened port change. That says, in fact, port change event > > > may happen after usb_clear_port_feature() is called. Then the subsequent > > > port change event will have impact on usb device suspend routine. > > > > This is not a very good description of the problem. Here's a better > > one: > > > > When a port is disabled, an attached device will be disconnected. This > > causes a port-status-change event, which will race with hub autosuspend > > (if the disabled port was the only connected port on its hub), causing > > an immediate resume and a second autosuspend. Both of these can be > > avoided by adding a short delay after the call to > > usb_hub_set_port_power(). > > What guarantees that a "short delay" will solve this? And how long of a > delay? What guarantees that sleeping will not just reduce the race > window? There is no guarantee, but the probability is high. The delay merely needs to be long enough for the hub driver's kernel thread to handle the port-status-change event. For root hubs, this is interrupt-driven so it should happen pretty quickly (unless the thread is busy handling another device or root hub). For external hubs, the delay won't be long enough. And even if the delay doesn't work, we're no worse off than we are now -- you end up with an autosuspend-autoresume-autosuspend sequence in quick succession, where the first two aren't necessary but do no real harm. Another way to avoid the problem would be to set the root hub's autosuspend delay to a few milliseconds. But we set the delay to 0 in commit 596d789a211d ("USB: set hub's default autosuspend delay as 0") for what seemed to be good reasons. Alan Stern