From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752401AbcDZQgf (ORCPT ); Tue, 26 Apr 2016 12:36:35 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:45206 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890AbcDZQge (ORCPT ); Tue, 26 Apr 2016 12:36:34 -0400 Date: Tue, 26 Apr 2016 17:36:25 +0100 From: Mark Brown To: Pingbo Wen Cc: linux-kernel@vger.kernel.org, lgirdwood@gmail.com, Vincent Guittot , stephen.boyd@linaro.org Message-ID: <20160426163625.GB3217@sirena.org.uk> References: <1461395466-14896-1-git-send-email-pingbo.wen@linaro.org> <1461395466-14896-2-git-send-email-pingbo.wen@linaro.org> <20160424225127.GI3217@sirena.org.uk> <5D111CFC-F2DD-4372-B66F-9F2E90877A03@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nLFWHeLI3WgDCk6A" Content-Disposition: inline In-Reply-To: <5D111CFC-F2DD-4372-B66F-9F2E90877A03@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 PATCH 2/2] regulator: add boot protection flag 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 --nLFWHeLI3WgDCk6A Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2016 at 07:46:07PM +0800, Pingbo Wen wrote: > > This is still a complete hack which is going to break as soon as things > > are built modular, it's definitely *not* something that should ever > > appear in DT since it depends so heavily on implementation details. If > > you need some driver to start early work on getting that sorted. > I think this patch can handle the case you mentioned. I have add a > regulator_has_booted flag, and it will set in regulator_init_complete() > late_initcall hook. The regulator_ops_is_valid() will ignore boot > protection if this flag is set. That doesn't help after we get to userspace so doesn't work as soon as things are built as modules. That's a key issue with making something that's robust here. > > This is also going to interact badly with any other drivers that are > > trying to configure things at runtime, if they've done enables and > > disables (or especially an enable without a matching disable) their > Ok, I have to admit that the boot_protection didn=E2=80=99t cover this. I= f other > consumer try to configure during booting, it will get some error code. > And the consumers need to re-configure the regulator state after > late_initcall. The worst thing is where we silently accept but forget about things because the code currently translates them into valid noops then later start paying attention to the operations, error codes at least the other driver can handle. > If we need to hold the state of other consumer, I prefer using a > dummy-consumer to hold this. And this is my next try. Or possibly store the data on the consumer but don't act on it then go round actually acting on it when we decide to do things - that's more what I'd have expected and seems like it might be easier than creating a separate object. --nLFWHeLI3WgDCk6A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXH5kIAAoJECTWi3JdVIfQ/OwH/RHnN1gkW6Kts8DcbNgZ0hMC R46SZ8IQu/qj/jFplNqiJ1Gu8KUWsGI7GzPYavHd7NZjNipE98mxV18aZuW3LubU NHcF8LHtYnk3+3XQzK49LniKgIF51HjRxZBsEbPiVqP3CMuAmItyfs7sKfGk0VFL japxrMHbDHYyMOweFcUvQe6xlQhh+Ym3fqYNP6bF/YSfL841IPI+/m9bT24AyIwJ 8QyN41O+ZE95kk7su3HKE7iejD2QR6YaY9xnywhsWLCBTu3PROGfbd1Jdk7aV6B1 afxTgadveJLyt8Uriw9b7PSxpOuERR6aTHucosi8AEoT3L5k7SgdCgZ70FuTh4Q= =EBIr -----END PGP SIGNATURE----- --nLFWHeLI3WgDCk6A--