From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init Date: Thu, 9 May 2013 14:50:17 +0100 Message-ID: <20130509135017.GD3200@sirena.org.uk> References: <1368076726-11492-1-git-send-email-skannan@codeaurora.org> <1368076726-11492-2-git-send-email-skannan@codeaurora.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RYJh/3oyKhIjGcML" Return-path: Received: from cassiel.sirena.org.uk ([80.68.93.111]:47591 "EHLO cassiel.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755015Ab3EINuZ (ORCPT ); Thu, 9 May 2013 09:50:25 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Grant Likely Cc: Ming Lei , Saravana Kannan , Greg Kroah-Hartman , Mike Turquette , Liam Girdwood , Linux Kernel Mailing List , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , Stephen Boyd --RYJh/3oyKhIjGcML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote: > However, if a device that shuts down resources after init has > completed and then cannot turn those resources back on when another > driver requests them then it sounds like there is a bigger design > problem. We're in a hotplug world and most of the time a driver cannot > assume that a resource will never get requested after initcalls have > completed. It sounds like a design bug in the driver if it cannot > handle that use case. Even if the driver copes fine it can still be desirable to avoid the power down/up cycle if it involves some user visible effect - things like blinking the display off then on for example. That said I am a little suspicious about this approach, it doesn't feel as robust as it should to go round individual callers. --RYJh/3oyKhIjGcML Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRi6mVAAoJELSic+t+oim9lU0P/jHOdV7bZDgzw1oEnF+k9D4g /Gmu9RXy/eJKFNrv05nUaBCgg7YYuLq7P3ixyNErAQjne61hY8IlbL0HYEsg7lEh CQKLotCFj+EQXT89gqeApVBlYqlMbjRuh7cmGxqwPagclal8YMWK9LGyHA/GM1aY CqsWlEpIjsQAoKu0vFYbeIwZoPk9Kvrj97w5oCZgpabU4x8YDfxdtl4C5iQjwPfI SanLKe8ykqGzvt7jS+mQWDIuy7/pdZLGAjbeSV7cytyRPeuMclRNqv/iN/j7CXF2 70Opp3tgL2TW/esdrly1Wbp1Do+2i6B0iiXaVJrtqcmXoyjVW00D6VX0DYTG3rw2 7PNpH90dJTAkNFLibfoTh4Kve9+YggMh0+r7kgTlA7LsD0fmOnR/SrhYRAG4zwRb yLFsyXyB+NQ3fTvDVooIL0nPLHn7qA6vC74ACJ47bNj7ObOji0kc/Kh0OHDuFgkL YMYiIBd+hc7TccvpRyKP80B7mpNv/fFM1/rzqygEq/HsWPexqvA7R//PXvH13JJG lzrF/hSS9j0UbJMsDI26n2eX5ZS+G4IEWf7oKRYosPz/qB3Cynoj8hkwl9EL/u9S RdD9MRFcInjhsAcuox3QLCAEFCTqKsjmqVxNwviy7O23FoMKuBkz1HP2WhwMf3Vq TlC4DredIEr9yPZFa1W2 =QdHy -----END PGP SIGNATURE----- --RYJh/3oyKhIjGcML-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@kernel.org (Mark Brown) Date: Thu, 9 May 2013 14:50:17 +0100 Subject: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init In-Reply-To: References: <1368076726-11492-1-git-send-email-skannan@codeaurora.org> <1368076726-11492-2-git-send-email-skannan@codeaurora.org> Message-ID: <20130509135017.GD3200@sirena.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote: > However, if a device that shuts down resources after init has > completed and then cannot turn those resources back on when another > driver requests them then it sounds like there is a bigger design > problem. We're in a hotplug world and most of the time a driver cannot > assume that a resource will never get requested after initcalls have > completed. It sounds like a design bug in the driver if it cannot > handle that use case. Even if the driver copes fine it can still be desirable to avoid the power down/up cycle if it involves some user visible effect - things like blinking the display off then on for example. That said I am a little suspicious about this approach, it doesn't feel as robust as it should to go round individual callers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: