From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932456AbcFQDee (ORCPT ); Thu, 16 Jun 2016 23:34:34 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:34170 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755099AbcFQDed (ORCPT ); Thu, 16 Jun 2016 23:34:33 -0400 Subject: Re: [RFC PATCH] regulator: introduce boot protection flag To: Mark Brown References: <1462777508-24934-1-git-send-email-pingbo.wen@linaro.org> <20160608171608.GM7510@sirena.org.uk> <57614479.1060708@linaro.org> <20160615133255.GZ2282@sirena.org.uk> Cc: pingbo.wen@linaro.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com, vincent.guittot@linaro.org, stephen.boyd@linaro.org From: Pingbo Wen Message-ID: <57636FC1.3040607@linaro.org> Date: Fri, 17 Jun 2016 11:34:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160615133255.GZ2282@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote: > On Wed, Jun 15, 2016 at 08:05:13PM +0800, Pingbo Wen wrote: >> On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote: > >> If we take modules under consideration, and to make this patch more >> universal, I think what we really need is adding a flag to protect a >> regulator from registration to a specific consumer(not the first >> consumer). The regulator driver gives the initial state, and the >> specific consumer need to clear this flag while finishing regulator >> setting(by calling a function like regulator_clear_protect()). And what >> the regulator core need to do is staging all operations during >> protection. And that will cover all consumers probing order, whenever >> the regulator is registered. > > Having the consumer driver know that it's "critical" seems wrong since > different systems may have different ideas about that, it's probably > better to hook this in with the device model so that when the device > finishes probing that kicks things off. > That will imply the protection would be end when the specific device has probed, and consumers should take their place at the same time. But there have some other devices, which will set the consumer in a IRQ event, or after some other events, can't be covered. We can set the protection flag easily, but it's hard to tell whether a consumer is well initialized, the end of protection, since regulator consumer is not initialized within one call. Pingbo