Received: by 10.223.185.111 with SMTP id b44csp145266wrg; Fri, 9 Mar 2018 02:38:54 -0800 (PST) X-Google-Smtp-Source: AG47ELsi+3Qt4/A+Xb5Cf1n49gylu4abn3D0AHOKAx/HafKft1WC10jtVSn7t0YxvkWRhqW7Bfpe X-Received: by 10.99.116.16 with SMTP id p16mr22816117pgc.194.1520591933984; Fri, 09 Mar 2018 02:38:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520591933; cv=none; d=google.com; s=arc-20160816; b=KiknL++Sym9CzJfxPQtbv1lHc/HBzh/dA460kgJF43yfWE0HvkbA+JF7UgZ++dxZUv gWMXwS3xTvCjfjcOHggShAe34ePg2NkVBqucZpTLb96l9IYU0mKRnFYMRPWmqWxd+BdM UHaizDK2UnYG5wRENEuhhNyruiTuPW5DRazGL0x7R6l4IGjph2lGMlmYGO6AY7gSO94G JkKH+YHrGT6AFNwdpp0Wx9CtMdSz1jWUHIXbCkTYi1WbqocxmbEVzaoGJTs2xW2R9Mbt Y/RDMYBme2pmZ4OjHZublEzzOKkqXK+jG0oLo0eVE2Fdojt84NQfAZ3kPYHtk94BnJCk ha0Q== 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:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=EeNWdbZFQz1WvH+wHEP0ctK6qFlZHNfKIJMs24DxsNo=; b=DirlqGl2H/OToGrfict1bflasoUHIeAENdG/3U0i2hoRz4mg00/yLegj9etVwxtO54 gzNMNTuxj3HnjlN7xllvdMuI5LO4H5j/0zOdnNDy6izlnRb2jAT0XWdP8fh/gEmmoHCC VqQSERRSHG1nC1ZV59IinR6vtgxmqvSTZ+NSx6iwQ+RdojgQeiutxxBOzVO4O0G0osE9 GKIU4Gd6JdgRLDWid/MPgPhoqpSyntYITzUmIw7v5t2uWCwnyqsJFxz0t6aBtBoQ/0uW iJn4hp1Bs9YMjuqd9V6+a8C97EobcszjX2/Ze2WX+sonOxzqpyQvH6GzeJrXV1m6uf9R UzJA== 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 184si640688pfd.345.2018.03.09.02.38.39; Fri, 09 Mar 2018 02:38:53 -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; 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 S1751113AbeCIKhK (ORCPT + 99 others); Fri, 9 Mar 2018 05:37:10 -0500 Received: from mga18.intel.com ([134.134.136.126]:11097 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbeCIKhJ (ORCPT ); Fri, 9 Mar 2018 05:37:09 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2018 02:37:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,445,1515484800"; d="asc'?scan'208";a="210136462" Received: from pipin.fi.intel.com (HELO localhost) ([10.237.68.37]) by fmsmga005.fm.intel.com with ESMTP; 09 Mar 2018 02:37:06 -0800 From: Felipe Balbi To: Roger Quadros , Baolin Wang Cc: USB , LKML Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume In-Reply-To: References: <1519730526-22274-1-git-send-email-rogerq@ti.com> <87sh9l5z4l.fsf@linux.intel.com> <94cd6377-1327-2309-8d69-6ab0de2bdfd4@ti.com> <87po4i3o1v.fsf@linux.intel.com> <87k1uq3ho6.fsf@linux.intel.com> <8ec0485e-89af-568b-e34a-b0cd490817d0@ti.com> <87h8puwyn5.fsf@linux.intel.com> <5bc56ef5-66b1-d40c-1639-e748fe18cdbd@ti.com> <87muzha9h4.fsf@linux.intel.com> Date: Fri, 09 Mar 2018 12:36:58 +0200 Message-ID: <87h8ppa62d.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Roger Quadros writes: >>> This is what the v3.10 databook says >>> >>> "When issuing an End Transfer command, software must set the CmdIOC >>> bit (field 8) so that an Endpoint Command Complete event is generated >>> after the transfer ends. This is necessary to synchronize the >>> conclusion of system bus traffic before the End Transfer command is >>> completed." >>> >>> with a note >>> >>> "If GUCTL2[Rst_actbitlater] is set, Software can poll the completion >>> of the End Transfer command by polling the command active bit to be >>> cleared to 0." >>> >>> fyi. >>> >>> Rst_actbitlater - "Enable clearing of the command active bit for the >>> ENDXFER command after the command execution is completed. This bit is >>> valid in device mode only." >>> >>> So I'd prefer not to clear CMDIOC for all cases. >>> >>> Could we some how just tackle the dwc3_gadget_exit case like I did in >>> this patch? >>=20 >> if you can send a version that doesn't iterate over all endpoints twice, >> sure. We still need a comment somewhere, and I fear we may get >> interrupts later in some cases. How would we deal with that? >>=20 > > how about explicitly masking that interrupt? Is it possible? I think I showed that the bit is reserved on recent dwc3 core releases (anytyhing 2.40a+, at least). =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlqiY8oACgkQzL64meEa mQZMVA//SLuKyFvyJ9jzEdkSXmymC8nQgPSJxImfn+NCJVH4Z/9ImedZfL+SkMY6 LHdUciBRa3EVmHgB5lnC108uNfIVf6ofPlfMT2fA+CoMV0lfeFSwk9AAyZPfC/hA TVuSuNMRZdVfHZCcSs0IfpqQVs8PAFi8L5wJfy1z01Sdji2DOmDIYedHohWbNdw6 cf9bjE2r2ZYAZW8nbXQqhhQvoSLYi9AKxMKtwb8NhGnXMDnoiAWa/E41PbANSPOa 95JGpaO+MtoNlQ6x2JwCgPHGM9nht4c6GjpCnSDSWDEwzci7hwHflE0wUb0Rn+Iw a1Ii1Te6jPGNq3Z8jaP66poND7dG3Q0HKqYfNGdxHk4u6hb7qXsx0kVh6T1mhtl2 ojqZorvQHRjlZKM/IsoA/Y85gbjG/wVlk+ykYVUUYikm+/XzWS9SPfA48282yBv5 m0uNO0XhZz1fLER0QmYV073XapPTzHzI9At3xJLVDxFVvF3nyk+vutrUoSFPS7Zg ZuN/tZtioYDc1cBppvI9X7tW7X5Mi/A4xxTWwmNXPQf7T0T7eTJaanDHH5Bl+coF VkG2EEtXXucoVyc2erjJN23EaKwGe4doJBkyK2kO85VitUQwNW615o0ko5WC6tBB 9jLF5nUJeFdmDEgfrNw9lxZ+F7GOqo8gzhdTLk1hBDleza6ZsqI= =V937 -----END PGP SIGNATURE----- --=-=-=--