From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751877AbcDRJqf (ORCPT ); Mon, 18 Apr 2016 05:46:35 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:50814 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbcDRJqe (ORCPT ); Mon, 18 Apr 2016 05:46:34 -0400 Date: Mon, 18 Apr 2016 10:46:24 +0100 From: Mark Brown To: Pingbo Wen Cc: linux-kernel@vger.kernel.org, lgirdwood@gmail.com, Serge Broslavsky , Vincent Guittot Message-ID: <20160418094624.GM3217@sirena.org.uk> References: <5F710397-FBBA-40DE-B753-C03B9C7FF229@linaro.org> <20160412034804.GT3351@sirena.org.uk> <57148C0B.6080500@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HL3CiL6n73+IAdG4" Content-Disposition: inline In-Reply-To: <57148C0B.6080500@linaro.org> X-Cookie: Tomorrow, you can be anywhere. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC] shared regulator initialization and protection 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 --HL3CiL6n73+IAdG4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 18, 2016 at 03:26:03PM +0800, Pingbo Wen wrote: > On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote: > > On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote: > > What is the actual problem here? Every driver is responsible for > > ensuring that regulators are in a good state before it starts using the > > hardware, if some other device did something before why do we care? > Yes, I agree the driver should set the regulator before do the real work, > when the device life time is started from driver probing. But if the device > life time is started before Linux kernel loading, the regulator core should > do the regulator initialization and protection to power the device properly, > during kernel booting, until the consumer driver probed. We can't guarantee that a consumer for a device will ever load in any reasonable time. There may be no driver, the driver may have hit some other problem, the driver may not have been built or may have been built but placed on inaccessible media. It's fundamentally an unresolvable problem outside of specific system integration, we have no way of telling at what point to give up on something appearing. The closest we've got is initcalls but they are before modules get loaded so mean things break as soon as they're built modular. > > Anything based on doing things at initcall levels is fundamentally > > broken, as soon as things are built modular like most things in a distro > > kernel then it'll stop working. If the system integrator needs some > > devices to start early to provide continuity (the main case here is > > display) they need to deal with that at the system integration level. > Adding a initcall to do the consumer removing is not a decent method. > We can do some hack in regulator_get(), removing agent consumer until > specified device call regulator_get(), or the first regulator_get(). Then what happens if that driver never loads? The other consumers are stuck being unable to control the regulator indefinitely which isn't great. --HL3CiL6n73+IAdG4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXFKzvAAoJECTWi3JdVIfQjh4H/Aqkh6I7B2RsURN3QUtVQe/z FpjZYGzBaZUFbjk7T/KdNsMA3dhdQokTNdI9/7oH/oJxVfKseVZiBVF9jsNoZsUl kVbTQDazaE/k9ZvGWhLHCM5sdpWshDxdCjcCk/DRnlGuM1zsyCkoRJ+cfXgXBPcw EcNWeSLe0ChnRw+kmFCCVNmSxJVS7s9wrI+ZZ1fwKvFkQjbFMvn93+iI2Uwcwfy6 0QjiCkKZmn0KbQheHbP+uVktgk6h5mlYBbJMh3B8l584dMq4yxm8twptLXUIp1/J k46rLcwjel+NhGyyrLjbwR2ave2nY2zzBQ4y7NJEaQPlXzKJSLkrTJTqS9fJ8jk= =ROhJ -----END PGP SIGNATURE----- --HL3CiL6n73+IAdG4--