From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756149AbdDFMMa (ORCPT <rfc822;w@1wt.eu>);
        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
        <rfc822;linux-kernel@vger.kernel.org>);
        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 <ludovic.desroches@microchip.com>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
CC: Ulf Hansson <ulf.hansson@linaro.org>, <linux-kernel@vger.kernel.org>,
        <stable@vger.kernel.org>, Adrian Hunter <adrian.hunter@intel.com>,
        Ludovic Desroches <ludovic.desroches@microchip.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 <adrian.hunter@intel.com>
> > 
> > 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