From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752579AbdBMSv5 (ORCPT ); Mon, 13 Feb 2017 13:51:57 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:34064 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476AbdBMSvz (ORCPT ); Mon, 13 Feb 2017 13:51:55 -0500 Date: Mon, 13 Feb 2017 10:51:52 -0800 From: Dmitry Torokhov To: Mark Brown Cc: Liam Girdwood , Guenter Roeck , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] regulator: devres: introduce managed enable and disable operations Message-ID: <20170213185152.GC20057@dtor-ws> References: <20170213023249.GA27688@dtor-ws> <20170213180129.wutjitdr72klhxwu@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170213180129.wutjitdr72klhxwu@sirena.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 13, 2017 at 06:01:29PM +0000, Mark Brown wrote: > On Sun, Feb 12, 2017 at 06:32:49PM -0800, Dmitry Torokhov wrote: > > > v2: restored lost regulator_disable() stub > > > Mark, note that there is also patch introducing devm_clk_prepare() and > > devm_clk_prepare_enable() that Russell did not hate so I think it will > > get applied eventually. I believe lack of CLK methods was cited as a > > reason for not having managed enable for regulators. > > No, that's never been an issue. The concern is partly that nobody > bothered writing the patch but also that it gets messy over suspend and > resume since you end up with drivers either doing explicit releases of > managed resources (which is not normally a good pattern) or mixing > managed and unmanaged access to the same resource which is also fun. I see where you are coming from, but I think that it is lesser concern than mixing managed and unmanaged resources in probe() and remove() and making sure that release order is right when they are mixed like that. I think it is helps if you think about devm_regulator_enable and regular regulator_enable as managed and unmanaged *actions*, not resources. So managed action of enabling regulator will be undone on remove() and you have to manually undo unmanaged regulator_disable() on resume(). It is not worse than having unbalanced regulator_enable/disable between probe()/suspend()/resume()/remove(). Thanks. -- Dmitry