Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756149AbdDFMMa (ORCPT ); Thu, 6 Apr 2017 08:12:30 -0400 Received: from esa1.microchip.iphmx.com ([68.232.147.91]:56461 "EHLO esa1.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755536AbdDFMMT (ORCPT ); Thu, 6 Apr 2017 08:12:19 -0400 X-IronPort-AV: E=Sophos;i="5.37,159,1488870000"; d="scan'208";a="1170623" Date: Thu, 6 Apr 2017 14:12:09 +0200 From: Ludovic Desroches To: Ben Hutchings CC: Ulf Hansson , , , Adrian Hunter , Ludovic Desroches , Greg Kroah-Hartman Subject: Re: [PATCH 4.4 42/76] mmc: sdhci: Do not disable interrupts while waiting for clock Message-ID: <20170406121209.qrtfkdmbsstuvbel@rfolt0960.corp.atmel.com> References: <20170328122559.966310440@linuxfoundation.org> <20170328122601.653745040@linuxfoundation.org> <1491324650.10415.3.camel@codethink.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1491324650.10415.3.camel@codethink.co.uk> User-Agent: NeoMutt/20170306 (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1214 Lines: 31 On Tue, Apr 04, 2017 at 05:50:50PM +0100, Ben Hutchings wrote: > On Tue, 2017-03-28 at 14:30 +0200, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Adrian Hunter > > > > commit e2ebfb2142acefecc2496e71360f50d25726040b upstream. > > > > Disabling interrupts for even a millisecond can cause problems for some > > devices. That can happen when sdhci changes clock frequency because it > > waits for the clock to become stable under a spin lock. > > > > The spin lock is not necessary here. Anything that is racing with changes > > to the I/O state is already broken. The mmc core already provides > > synchronization via "claiming" the host. > [...] > > In mainline, drivers/mmc/host/sdhci-of-at91.c has a slightly different > version of this code that seems to have the same issue. In 4.4 there's > another (conditional) mdelay(1) further up this function that seems to > be related to that hardware, and probably ought to have an unlock/lock > around it. Right, how do you want to proceed? Do you want me to send a patch on top of it to manage this extra mdelay? Regards Ludovic