Received: by 10.223.176.5 with SMTP id f5csp1098141wra; Wed, 7 Feb 2018 12:38:48 -0800 (PST) X-Google-Smtp-Source: AH8x226qxaBmz1zh5ALF8mkVNKyjrIyeM7gjQxbD/eJAHSGI6PWiP6cauluJWo7StVbmEoulUlZF X-Received: by 10.99.116.9 with SMTP id p9mr6022781pgc.437.1518035928043; Wed, 07 Feb 2018 12:38:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518035928; cv=none; d=google.com; s=arc-20160816; b=ETBlYzgXl80WFEY6JHwDJ1E41YrNCAEcQggsYfvSaeJR/afIaDF/UPKq54pVnWszpY mcok2SvJwH6KcytWAFKJHaXfgU3TCI8rsXxuirx49SzlbMYyHdJWbQCDZ5Ml3mblJEgj 7Awlho/S6DQ68hybXuSv7lsbd4CzH4LufMn9tG51JCcgitEpoe8spInHoh0AcTyf8sLQ h0GoE2d//PQl2E7I4oQkyjV9QUNm5EZiUp9KcRAIzcDlO0gV1JcmcMuJAubOTSwGr4Vw 0mB7LlkSH5MA2jxuWMXSp/UY6Uf7W1eqlSsw7HGkBlaRGod5ylMXhY0KKf5/Vf+wVm/r e3Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=BnAkP9Y6CYG+vyqXXBLlw5yYGkfDXPzhmgS8oOv271w=; b=wXaQ4xdn+tX9fWYvM1Hg0ek1V5egl3Wji8ZHaHlJr3JYCYKkcXVgS5UC+ZWfGLVuJ0 mSnY9MwFehs19qU2lKL3ZeWHIQ9xjiAAH9YROWOnMxOR4kU7L8YqGoluL3GnT4/oDP0p StERT0NB2UHKYAoAJTnURxgvWgWehpTAEX1NtyFNWqB7TjCRPO63S8ovTc4sDMNgDlVk 63CSnF03Hk1tZAPp5S93HLerbiDGIWH6woLxHruDoddK75cU3/vkUcDZ3/+Bvm2OAfLH bPDRmxCwiaZKaJ6dMQZUGto7TvrhHz8g2O1y4obMqe1hV2GHBnQ/osM02Gy37X6DXBQZ c9vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=oJ4Yl+kT; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 14si1589173pfk.317.2018.02.07.12.38.32; Wed, 07 Feb 2018 12:38:47 -0800 (PST) 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; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=oJ4Yl+kT; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754453AbeBGUhV (ORCPT + 99 others); Wed, 7 Feb 2018 15:37:21 -0500 Received: from fllnx210.ext.ti.com ([198.47.19.17]:17148 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754127AbeBGUhT (ORCPT ); Wed, 7 Feb 2018 15:37:19 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id w17Kb1nY002255; Wed, 7 Feb 2018 14:37:01 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1518035821; bh=2Bn3ondeosxCUv9WaLKlRJXUCoI9JBRUznJyehSVI0g=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=oJ4Yl+kTSmAGQPCXvXqsz1mZiIkkqp+VDfYUP+sOcAVr2DXQprS7gq577U4JNeas9 iIFZhtF8s5hacABiXefq6fqstZaDuUDTbxeQ+40bXhfbgwpViuJwvu2PkcfMuY8Ika 7hkCpErkFNH0pJkBvaVtN5U3T7rOcAagiZb4Yp3c= Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w17Kb1uU012791; Wed, 7 Feb 2018 14:37:01 -0600 Received: from DFLE110.ent.ti.com (10.64.6.31) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 7 Feb 2018 14:37:00 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE110.ent.ti.com (10.64.6.31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Wed, 7 Feb 2018 14:37:01 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w17Kb0a5001793; Wed, 7 Feb 2018 14:37:00 -0600 Date: Wed, 7 Feb 2018 14:37:00 -0600 From: Bin Liu To: Andreas Kemnade CC: , , , Tony Lindgren , Discussions about the Letux Kernel Subject: Re: [PATCH] usb: musb: fix enumeration after resume Message-ID: <20180207203700.GC3992@uda0271908> Mail-Followup-To: Bin Liu , Andreas Kemnade , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Tony Lindgren , Discussions about the Letux Kernel References: <20180127083403.928-1-andreas@kemnade.info> <20180206184605.GA3992@uda0271908> <20180206200024.18d40735@aktux> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20180206200024.18d40735@aktux> User-Agent: Mutt/1.5.21 (2010-09-15) X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote: > Hi, > > On Tue, 6 Feb 2018 12:46:05 -0600 > Bin Liu wrote: > > > Hi, > > > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote: > > > On dm3730 there are enumeration problems after resume. > > > Investigation led to the cause that the MUSB_POWER_SOFTCONN > > > bit is not set. If it was set before suspend (because it > > > was enabled via musb_pullup()), it is set in > > > musb_restore_context() so the pullup is enabled. But then > > > musb_start() is called which overwrites MUSB_POWER and > > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is > > > enabled and the device is not enumerated. > > > > Do you see the issue with the v4.15? > > > Yes. Tested without other patches. > It was also there in earlier kernels but I had not had motivation enough > to debug. Applied to my tree. Thanks. > So maybe it deserves a CC: Stable I would prefer it is first tested on each stable tree. > > > So let's do a subset of what musb_start() does > > > in the same way as musb_suspend() does it. Platform-specific > > > stuff it still called as there might be some phy-related stuff > > > which needs to be enabled. > > > Also interrupts are enabled, as it was the original idea > > > of calling musb_start() in musb_resume() according to > > > Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend, > > > enable them on resume") > > > > The logic in the fix makes sense, and I do see the same problem with > > AM335x on v4.9 kernel, but it doesn't happen on v4.15. I haven't checked > > if there is anything after musb_start() which sets MUSB_POWER_SOFTCON > > bit. On v4.15, the SESSION bit is set later which sets the SOFTCON bit. I didn't check how come v4.9 doesn't invoke it though. Regards, -Bin.