Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757566AbcC2S1u (ORCPT ); Tue, 29 Mar 2016 14:27:50 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:52836 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753838AbcC2S1e (ORCPT ); Tue, 29 Mar 2016 14:27:34 -0400 Date: Tue, 29 Mar 2016 11:27:25 -0700 From: Mark Brown To: Geert Uytterhoeven Cc: Bjorn Andersson , Krzysztof Kozlowski , Ivaylo Dimitrov , Liam Girdwood , "linux-kernel@vger.kernel.org" , Ulf Hansson , linux-mmc , linux-samsung-soc , Javier Martinez Canillas , Marek Szyprowski , linux-renesas-soc@vger.kernel.org Message-ID: <20160329182725.GD2350@sirena.org.uk> References: <1458587912-32665-1-git-send-email-broonie@kernel.org> <1458587912-32665-2-git-send-email-broonie@kernel.org> <56F0624C.8010004@gmail.com> <20160327090859.GH5028@sirena.org.uk> <20160329145823.GK2350@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7QsOHKuLbhbLTwLB" Content-Disposition: inline In-Reply-To: X-Cookie: If anything can go wrong, it will. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 64.55.107.4 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds for our constraints X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 37 --7QsOHKuLbhbLTwLB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 29, 2016 at 08:05:34PM +0200, Geert Uytterhoeven wrote: > sh_mobile_sdhi ee100000.sd: Got WP GPIO > ======> sh_mobile_sdhi ee100000.sd: could not set regulator OCR (-22) > gpio_rcar e6055400.gpio: sense irq = 6, type = 3 > sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 97 MHz > The line marked with the arrow is introduced by the changed check, and looks > to be the origin of the failure. This isn't making any sense. Why would a change in how we apply voltage constraints on initial probe of the regulator have an impact here? The changed code shouldn't even be executing at the point where the SDHCI driver is trying to use the regulator. There's something else going on here. --7QsOHKuLbhbLTwLB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW+skLAAoJECTWi3JdVIfQ3GcH/1d/JVUnb6U4nra2rhLzVTiF UPwWSW9pkuSrDgS0R5TZsK2Mylgq91/NOj3nVbxHg58VVSyTZL0i6QqN4YypfHpa 4hN4/A8e0vRX+s2SXKM8lg2c0NlPEaAbPHLg+xm4lp3ZfZwprIEYmPCII732J88O Y6NfIM/WbKF27PsdIYjEuclevciBma5jCt4NMNpvFLX3jZO2UKU0ph0A5dcOtpkD BKQFvJ8nagSt9o8IiWPRVF2sdQnAgQCR/EnrXqZXlebM6JFjCb3UuHVwzm9Y9ITA 8PbCwSn6KagpIjv0ipLfW9E2gPQJ0qvPV01weyWSTlAyBx1e0CvKMHqJ8iBbQdc= =Wh6y -----END PGP SIGNATURE----- --7QsOHKuLbhbLTwLB--