From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH V2 5/6] x86: add CONFIG_ARM_AMBA, selected by STA2X11 Date: Mon, 2 Jul 2012 19:33:24 +0100 Message-ID: <20120702183324.GA29030@opensource.wolfsonmicro.com> References: <4FECB95D.7010200@zytor.com> <20120701104401.GA4352@mail.gnudd.com> <2b797c83-6a3c-4051-841a-a4cfa9d1cae1@email.android.com> <201207021658.27755.arnd@arndb.de> <20120702180518.GA25995@sirena.org.uk> <4FF1E37D.7050103@zytor.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Return-path: Content-Disposition: inline In-Reply-To: <4FF1E37D.7050103@zytor.com> Sender: linux-serial-owner@vger.kernel.org To: "H. Peter Anvin" Cc: Arnd Bergmann , Alessandro Rubini , linux-kernel@vger.kernel.org, giancarlo.asnaghi@st.com, alan@linux.intel.com, linux@arm.linux.org.uk, x86@kernel.org, gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org, linux-arch@vger.kernel.org List-Id: linux-arch.vger.kernel.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 02, 2012 at 11:07:57AM -0700, H. Peter Anvin wrote: > If there is a dependency there it should be registered, regardless if > x86 enables the clock API. Not really, what we *should* have is the clock API available (at least for build purposes) everywhere. The current situation where the API is randomly available on some architectures makes it unusuable in generic code which is nuts and wasting time and effort, you either need ifdefs or Kconfig hoop jumping in all the users which isn't at all sane and means if you're doing anything generic you still need a backup plan. What should be happening with this is the same as happens with all the other similar APIs - the API should stub itself out where it's not provided and the default should be that all architectures use the generic implementation. The overwhelming majority of clock API usage is just enabling the clock only while the device is running to save power when it isn't which is totally amenable to stubbing out on platforms that don't support that level of power management. > Last I saw I saw a patch to that effect, asked what the benefit was, and > got no answer. Are you positive about that? I don't recall you replying any of the times I sent out the patch and my mail archive isn't contradicting me either. --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP8eklAAoJEBus8iNuMP3dw2EP/38nYqFWf+gkQtzpYMjOUQmj tKFxCodmY7aXWKi087Hrsyzo/DA7h4tJSrCPlhBZiaWM0sX5/iziEsbV+tLWSEG+ FPDEaxXu8NdBlSQyFZqdwFlcRnU4dw9zSs3sFDXw+itS1xybjtfLhavit8KKqBNV 88JO8XWJbJVl8sH/Z84LukJ/jYMCDPQXNtKud1pHOvd1euW43sHw7OYeWWMaCNzZ 1tqyLUHd74XVyEBGGfqFqMT5uYOGwMLR+LK2OxSWZIOVObBf8qQ+6WGNSc0Pm99u w/wrsFF6eYiNPsCPlgVQgFG06BtrDbFn7npbp1lAIG+8ehC+F0V/ICC+sc6eSCGG gfMLpPI0pGwnpVu6nsaVhFrlHY2zITFU9X27eW0ZySOvGeJna4xCu9Ls+baEqg8d UIMTXE7+sd8J0VZn7K+s/LKRnQgTOWgVBliZ1spVplKnzWsOwgtnhqD2J9E1kPBQ ROdTnP+qwcfjDMiD6Nf/q0EEqOrJgjh9qBzOGWmIG7ExZpkYPoEIh2CTkNFKpjIz fgFVJKnVcQdo8kdKtH+J8Vk6fgi7bfvGs+aOPCwG4qrRJDpjCQFYuMoGI5FDrFlM Lbq7aO/mCYKvtjXTyIflWmtV9m9AZT0WlGCg50SNvt9pvSep/AHIxOlJkLo2WEIW SPIlNTQZi8OVB0W0lFUm =wn04 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@opensource.wolfsonmicro.com (Mark Brown) Date: Mon, 2 Jul 2012 19:33:24 +0100 Subject: [PATCH V2 5/6] x86: add CONFIG_ARM_AMBA, selected by STA2X11 In-Reply-To: <4FF1E37D.7050103@zytor.com> References: <4FECB95D.7010200@zytor.com> <20120701104401.GA4352@mail.gnudd.com> <2b797c83-6a3c-4051-841a-a4cfa9d1cae1@email.android.com> <201207021658.27755.arnd@arndb.de> <20120702180518.GA25995@sirena.org.uk> <4FF1E37D.7050103@zytor.com> Message-ID: <20120702183324.GA29030@opensource.wolfsonmicro.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jul 02, 2012 at 11:07:57AM -0700, H. Peter Anvin wrote: > If there is a dependency there it should be registered, regardless if > x86 enables the clock API. Not really, what we *should* have is the clock API available (at least for build purposes) everywhere. The current situation where the API is randomly available on some architectures makes it unusuable in generic code which is nuts and wasting time and effort, you either need ifdefs or Kconfig hoop jumping in all the users which isn't at all sane and means if you're doing anything generic you still need a backup plan. What should be happening with this is the same as happens with all the other similar APIs - the API should stub itself out where it's not provided and the default should be that all architectures use the generic implementation. The overwhelming majority of clock API usage is just enabling the clock only while the device is running to save power when it isn't which is totally amenable to stubbing out on platforms that don't support that level of power management. > Last I saw I saw a patch to that effect, asked what the benefit was, and > got no answer. Are you positive about that? I don't recall you replying any of the times I sent out the patch and my mail archive isn't contradicting me either. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: