From patchwork Fri Dec 18 20:09:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 7887661 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 8A0A2BEEE5 for ; Fri, 18 Dec 2015 20:09:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8F32620395 for ; Fri, 18 Dec 2015 20:09:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6F2BF2026F for ; Fri, 18 Dec 2015 20:09:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933115AbbLRUJq (ORCPT ); Fri, 18 Dec 2015 15:09:46 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34068 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932736AbbLRUJp (ORCPT ); Fri, 18 Dec 2015 15:09:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=S02Lch3YkZrehklCDXikComAW8/u+AF6ZFmxgNapdEY=; b=fuGhNWz5I74UaciUArihVZv/HGTeDFwNACPRzwnxePcntFxvXQ7etfWm+4FI6KgnOxYBd0cvTHjG1lXvdPtVRd1YlO6EoVDk/+14EFT8vuyrNv/aZNth4JQ3TT4Jk+uR8m4GMCHbZDNjsw0rdNOPBZfoidpxrJJfUi+/UOG136s=; Received: from n2100.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:45790) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aA1LO-0004ak-IU; Fri, 18 Dec 2015 20:09:38 +0000 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76) (envelope-from ) id 1aA1LL-0002uo-9U; Fri, 18 Dec 2015 20:09:35 +0000 Date: Fri, 18 Dec 2015 20:09:34 +0000 From: Russell King - ARM Linux To: David Jander Cc: Ulf Hansson , Pierre Ossman , linux-mmc , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Lucas Stach Subject: Re: SDHCI long sleep with interrupts off Message-ID: <20151218200934.GR8644@n2100.arm.linux.org.uk> References: <20151217112814.6250a3b9@archvile> <1450350190.3163.93.camel@pengutronix.de> <20151217122053.036daf37@archvile> <1450351655.3163.97.camel@pengutronix.de> <20151217132229.1c699f69@archvile> <20151217160903.556af1af@archvile> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151217160903.556af1af@archvile> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Dec 17, 2015 at 04:09:03PM +0100, David Jander wrote: > > Dear Ulf, > > On Thu, 17 Dec 2015 15:54:54 +0100 > Ulf Hansson wrote: > > The code is in general fragile. We have have kind of reached the > > point, when I apply changes that fixes one issue it may cause another. > > Oh, that is indeed bad. > I wish I was in the position to do this... but this really goes beyond my time > and my knowledge. I think most of the effort will be at cleaning up the mess > and make sure that each one of the many users works well afterwards, and it > definitely takes someone who knows the code (and it's users) very well to pull > this off. By way of illustration, when SolidRun released their Hummingboards, I spent a while working with Jon Nettleton getting UHS support going on these boards (which initially required a hardware hack.) I put together a patch set which resolved all the problems that there were at that time. Yesterday, I tried adding the necessary bits to DT, as people have started reporting _one_ problem with the SDHCI driver with UHS cards. What I found dismayed me: I found a total of six problems or variable severity in around two hours. This evening, I'm starting to work through those problems, starting with the damned trivial ones where printk()s are inappropriately noisy, which can only come down to a lack of review of submissions before applying changes. Some of these are core MMC code, so I'm afraid they aren't attributable to "no sdhci maintainer". Eg, this one is particularly annoying as it takes something like 23 attempts to probe one of two SDHCI interfaces, so we end up with 24 "voltage-ranges unspecified" messages at boot time. Author: Russell King Date: Fri Dec 18 19:57:05 2015 +0000 mmc: core: shut up "voltage-ranges unspecified" pr_info() Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by: Russell King diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 5ae89e48fd85..b5e663b67cb5 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1220,8 +1220,12 @@ int mmc_of_parse_voltage(struct device_node *np, u32 *mask) voltage_ranges = of_get_property(np, "voltage-ranges", &num_ranges); num_ranges = num_ranges / sizeof(*voltage_ranges) / 2; - if (!voltage_ranges || !num_ranges) { - pr_info("%s: voltage-ranges unspecified\n", np->full_name); + if (!voltage_ranges) { + pr_debug("%s: voltage-ranges unspecified\n", np->full_name); + return -EINVAL; + } + if (!num_ranges) { + pr_err("%s: voltage-ranges empty\n", np->full_name); return -EINVAL; }