Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757051Ab3J1TYm (ORCPT ); Mon, 28 Oct 2013 15:24:42 -0400 Received: from cassiel.sirena.org.uk ([80.68.93.111]:60812 "EHLO cassiel.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755810Ab3J1TYj (ORCPT ); Mon, 28 Oct 2013 15:24:39 -0400 Date: Mon, 28 Oct 2013 12:23:54 -0700 From: Mark Brown To: Grazvydas Ignotas Cc: Alexander Shiyan , Luciano Coelho , Mark Rutland , devicetree@vger.kernel.org, Russell King , Pawel Moll , Ian Campbell , Tony Lindgren , Greg Kroah-Hartman , Stephen Warren , linux-doc@vger.kernel.org, "John W. Linville" , Rob Herring , "linux-kernel@vger.kernel.org" , Sachin Kamat , Bill Pemberton , Felipe Balbi , Rob Landley , netdev@vger.kernel.org, "linux-wireless@vger.kernel.org" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Message-ID: <20131028192354.GA18208@sirena.org.uk> References: <1382890469-25286-1-git-send-email-sre@debian.org> <1382890469-25286-3-git-send-email-sre@debian.org> <1382891056.102746625@f315.i.mail.ru> <20131027201218.GA4414@earth.universe> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: X-Cookie: You will have a long and boring life. User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 66.78.236.243 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on cassiel.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2359 Lines: 54 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote: > When wl12xx family of chips is connected through SDIO, we already have > that pin set up as a regulator controlled with the help of mmc > subsystem. When time comes to communicate with the chip, mmc subsystem > sees this as yet another SD card and looks for associated regulator > for it, and the board file has that set up as a fixed regulator > controlling that pin (see pandora_vmmc3 in > arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after > first SDIO communications are over, pm_runtime calls are used in > drivers/net/wireless/ti/wl1251/sdio.c . Is this actually controlling VMMC though, or is it some other control? If it's not controlling VMMC then it shouldn't say that it is. > I don't know if something similar can be done done in SPI case, but > I'm sure this is not the first your-so-called regulator misuse. It's not the first but that doesn't make controlling something other than a regulator through the regulator API any less broken. --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSbrnBAAoJELSic+t+oim9zIwQAIvaD4m/WxkD0sxXd8pb5lKQ Y88rGx5PwOI7AnVd1e+dHdv/EUrdhYQd7GpUC3YQ5aARR5BqKJhkw4woTuhKAdTl vOMq2FFzXIEeLpwt7zoSu4naXGz+X2WYlSPOs8itze448Y5m5abFWI1433IEAD2C MdMkaL6C+rLpzFYk5dGRsgK0efCc0jWgoJUmLnhCQH2UDOvCAVqL0HMzbe3TvnOE BDrnyvti2XH/B708MVxRWjsNdxwcwD6PvjSSviSL/x57fjgs97NG3qDfuICSy4Vl zcimUlnIaJXkLvA7tS+c5CcNS2MsJAoi3FiufQVmRAtK42CKLMrDEudKkeacSvmn wd6yAZUh9MqHsLJj48OeWPzD4EMq3MVhlDUsHeCiI6OcEdoPTgEu2rQiPYN4Ihd2 UawXig1687VV6SgCkERjrW4oPA8GIu0lR/y4T/Po34UhhthVBGBE1xkc4ER8JDrt WxxVQXKwFLke2J7qbMd1ngGyHCShLaw2aKhwuxJyOl+J09LgXtY4WH8vpp/ruY8m 0Ncsy88BKliO6AXnYqW648oP2axHnt/2uiw10wLjmk33RT0a4qrxeQsGF4YK0I4e yrytIfz+kzLO1i/fdtvonRJvbLMLFG4514s6NTwa6l5olSzDc719BZsY4Q33u6kk V+RxybJIeUSgZ5Zfb8Pa =YWan -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/