Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754010AbcDVQiK (ORCPT ); Fri, 22 Apr 2016 12:38:10 -0400 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:37694 "EHLO mx0a-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbcDVQiI (ORCPT ); Fri, 22 Apr 2016 12:38:08 -0400 Authentication-Results: ppops.net; spf=none smtp.mail=rf@opensource.wolfsonmicro.com Message-ID: <571A536A.9000509@opensource.wolfsonmicro.com> Date: Fri, 22 Apr 2016 17:38:02 +0100 From: Richard Fitzgerald User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Mark Brown CC: , , Subject: Re: [PATCH] regulator: arizona-ldo1: Only enable status change if we have LDOENA References: <1461332608-14760-1-git-send-email-rf@opensource.wolfsonmicro.com> <20160422150446.GF3217@sirena.org.uk> In-Reply-To: <20160422150446.GF3217@sirena.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604220203 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2145 Lines: 41 On 22/04/16 16:04, Mark Brown wrote: > On Fri, Apr 22, 2016 at 02:43:28PM +0100, Richard Fitzgerald wrote: >> The driver was hardcoding REGULATOR_CHANGE_STATUS on the regulator >> which made the regulator core assume that it can be powered off. >> >> The power state of the regulator is controlled by the LDOENA pin so >> this patch changes to only setting the REGULATOR_CHANGE_STATUS flag >> if we have a valid gpio for LDOENA. > What's the difference between this and the previous version of the patch > and what problem is this aiming to solve? If we want to disable the > regulator why would we not be happy to do that by removing the supply? The background to all this is that runtime suspend and resume needs to know whether the DCVDD turned off. If it definitely turned off a regmap cache sync is safe - if not or I can't be sure then I need the overhead of a forced reset to restore register defaults before the sync. What I'm trying to achieve here is to stop the regulator core sending false notifications that LDO1 has been turned off. The way that the regulator core code handles the disable notifier has no dependency on what happens to the parent supply. The REGULATOR_CHANGE_STATUS flag is used to indicate whether the status of _this_ regulator can be changed (it doesn't affect whether the parent is disabled). So if LDO1 is disabled without an LDOENA and without this patch, it looks like the current core behaviour of the functions regulator_disable(), _regulator_disable() and _regulator_do_disable() is: 1) Are we the last user? - Yes 2) _regulator_can_change_status()? - Yes because REGULATOR_CHANGE_STATUS is set 3) Send PRE_DISABLE notification 4) call _regulator_do_disable(), no GPIO pin and no disable callback so return 0 (claims success even though there was no way to disable it) 5) Send REGULATOR_EVENT_DISABLE 6) Return to regulator_disable() and then disable the parent supply The result will be that we got a disable notification though LDO1 wasn't disabled. I think it's a bug that LDO1 claimed to be able to turn off when it couldn't, and fixing that prevents bogus disable notifications.