Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5950234ybe; Tue, 17 Sep 2019 16:43:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqz8I6fHNRB16CTcbXDapIV1ib5wNePK5DwPWx/jIJwdasxqww4ZM+D5n8f8hCXPBMSGkOTe X-Received: by 2002:a50:f152:: with SMTP id z18mr7198023edl.141.1568763827915; Tue, 17 Sep 2019 16:43:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568763827; cv=none; d=google.com; s=arc-20160816; b=I0hVydrv8sF6hWFtUyTiuVMwZ0mAeDpwE1KVxAY7ldNXSi1nOfvhudGtL0DDZVrrwl oFmLhE/J/9vsAD3jl9Ysaf/hDNFsCBk3dG7lS8fTqzy4y+ltKee0R4UveQuHUuLq7hOZ nbRab3Yg1xvai2mR+5M5jPvRUKVxXg5vVqFzSZpeDoqw5RkazQYu8i1CiG6MWb7yFwkd ieR+Hr6qqMxhSlH7D15B9d/DMq8Pe0vun4YJx+d9+nI2js9iZGbfNALYjB+9ZyVdgZ4a 2yb65UBn1y9eyftvYLJfdFR50jf3SHQG6e6B+i4/SPDBdwMNHAHTv2WaaePoE1qmZV4K 5FIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=AQOlayj3P48evU784ih+NoYcoZ4/KfgU4SvEbBrjZYQ=; b=rGPf2zENjAq1yZfegxc9MSaet3XD+i9xMfj0lZdmqsvXvkvt+Sk93HrZoc2qPz/NPl x5qdDuCA0+Gb4fQd6y/dvgEVDAvsRJJ6aHBxqY90EcY1aAW6qLAZqcEJ8V7nyFz4SQXu AkR1O7wZpjFfYq7fzWso8sD6JXiLPh/FXCbk1YXsmNdwbO0de19HvdiG9z3UmPxlKX+p 72RgQrwxEctIivg+KrABpYhYC9eC04PdmbR7wwP6WgEkw4xmUoWtX/xK0/YPMN/cMxhb jZUn5ElLlNYmR+AdYQ5vD9R1+mC8hEMjZWtQYUHUGt+DRK/RFq2FqS2RKAPp3yD4gUDU 453g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z12si2028990eju.15.2019.09.17.16.43.24; Tue, 17 Sep 2019 16:43:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729748AbfIQPka (ORCPT + 99 others); Tue, 17 Sep 2019 11:40:30 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:51065 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729702AbfIQPk2 (ORCPT ); Tue, 17 Sep 2019 11:40:28 -0400 Received: from dude02.hi.pengutronix.de ([2001:67c:670:100:1d::28] helo=dude02.lab.pengutronix.de) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iAFaZ-0003ZZ-HU; Tue, 17 Sep 2019 17:40:23 +0200 Received: from mfe by dude02.lab.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1iAFaY-0003yb-FZ; Tue, 17 Sep 2019 17:40:22 +0200 From: Marco Felsch To: zhang.chunyan@linaro.org, dianders@chromium.org, lgirdwood@gmail.com, broonie@kernel.org, ckeepax@opensource.cirrus.com Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de Subject: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage Date: Tue, 17 Sep 2019 17:40:19 +0200 Message-Id: <20190917154021.14693-2-m.felsch@pengutronix.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190917154021.14693-1-m.felsch@pengutronix.de> References: <20190917154021.14693-1-m.felsch@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::28 X-SA-Exim-Mail-From: mfe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") regulators marked with boot-on can't be disabled anymore because the commit handles always-on and boot-on regulators the same way. Now commit 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") changed the regulator_resolve_supply() logic a bit by using 'use_count'. So we can't just skip the 'use_count++' during set_machine_constraints(). The easiest way I found is to correct the 'use_count' just before returning the rdev device during regulator_register(). Signed-off-by: Marco Felsch --- drivers/regulator/core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e0c0cf462004..f9444f509440 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5170,6 +5170,11 @@ regulator_register(const struct regulator_desc *regulator_desc, /* try to resolve regulators supply since a new one was registered */ class_for_each_device(®ulator_class, NULL, NULL, regulator_register_resolve_supply); + + /* cleanup use_count -> boot-on marked regulators can be disabled */ + if (rdev->constraints->boot_on && !rdev->constraints->always_on) + rdev->use_count--; + kfree(config); return rdev; -- 2.20.1