Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1826203iog; Tue, 14 Jun 2022 14:25:47 -0700 (PDT) X-Google-Smtp-Source: AGRyM1smqSvlCvtZTvzBe1JHKKmeAtXJ/qB07UhrqONymnYQvF5D3bQTPK317D/nJ0+nfFoId7+H X-Received: by 2002:a17:903:1209:b0:168:e42f:8709 with SMTP id l9-20020a170903120900b00168e42f8709mr6171828plh.99.1655241946904; Tue, 14 Jun 2022 14:25:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655241946; cv=none; d=google.com; s=arc-20160816; b=ICmip9o91KLet36IWinzc94PL0U00Pav+z7oHDXh9rJihO5DON8/+UWTmDcdW7iPqi yPBeh3OhmaPqezzMNm+P7ZriGwmukc8lPdC7lsfJF+/wvqRBMGJyJBlvzpmyfe/N39lK 8ZriYYQFMZaqTifEpuSorDLQhxowT1mMqxrlKi7Ixe41/tHIrsTWS1yZuHIZLpB6FU17 hhhIdJw4NrPM9B2OJhztAxosE654uj/z04qsnKu4LkPh4DMF/pB4BxmOq/hGo8AfbMoL jDYbdWazbRbpwZTQlglZuU43CQB8qZg9B8J91w3aLHY6gyYffIOKYsP5bOFkFqZHLUlH cktg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=UDsOFLddT7JI3MY9amnekfXssOa8lE99LyN4VJ+GI5Q=; b=gwiCdEhEZ3xCe8JvjIgycdugTVFoX3Hk69RRxHTen4wBTu6w1zWon76kAswChxaadj wWpGAwPoS9sXurxy2oJZKgwkqWiHrTz0ysGhPT6kfKhR3m0aUEppXfsaEV06AWVAX8pA zXQ4tQr9eN60gY66EBrhKCFGE6NvBocLSFzQ4GATjwqYhEuyJyFaiWmopXKUQ6JjLPaw kRS9cfTxSmv05GyL6TO9/+M9kFRuERrK7rBn6L/91rEUAIIgXVP4Ae3edL30m3t4Vwbv oFtlcr8Iy8lI/7TgKIB/zg9DPFrup0t1k9IGlXEMkM87AzRUxayF/nZ7ZYK3W/KrAG/h Wbow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="HLyQxB/v"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 36-20020a631564000000b0039dad7a82fdsi14755919pgv.632.2022.06.14.14.25.12; Tue, 14 Jun 2022 14:25:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="HLyQxB/v"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352978AbiFNU67 (ORCPT + 99 others); Tue, 14 Jun 2022 16:58:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358020AbiFNU6b (ORCPT ); Tue, 14 Jun 2022 16:58:31 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C99B84FC4F for ; Tue, 14 Jun 2022 13:58:27 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id e24so9533741pjt.0 for ; Tue, 14 Jun 2022 13:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=UDsOFLddT7JI3MY9amnekfXssOa8lE99LyN4VJ+GI5Q=; b=HLyQxB/vhxqwX8dv4nCCRMMJmV6YyxGoUccXlaScuHaHZ81Z+2W1DIZXCS/TDp6AlH XW7KGiieBSkB01yZ3jsUUgR9VL0mcv9v/tnsavE4Sz9q3lgtqH6e1ZRXfFCNo7ZIib6r QB4keemPVwSkME5HYki1rNfp0aBIEmMzOHZr919acoQRChGvd4o8VUH6CnRfqvhIvCVc PKQcy5cQcYiKdXqkoaXPjeiPjt3n7CjXPav5gaN2GrPReugP+zhnMjTLjh8wiBqB4XI3 xsM1uJ0lEh9dMRy+sUWGmZKunougrqwxMUdAIOMXcLOyhWr5ytHTqFQuQP0xZJzYjQDQ 9Obg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=UDsOFLddT7JI3MY9amnekfXssOa8lE99LyN4VJ+GI5Q=; b=uUZyMI6rIAEK6211pxC99OVR0/Wfa2qUaRnqZzVlfZXRY6Y7H/s3ZFIJfdFH0susCZ oG8kUO+/XntlBsfHgUm84aBNw/e1zvgABHNaJXiqyfAniWCm1llCoKYQQ26cz8WGxmhp t2G91gZSTpNhXZy1GnCKVNkjbwKBsG8yTXH1FEOq/327fDfCmezViyQkOQv8qltp16o6 8XAWl6SOyL/Q/+sVxThgUnB9tlBLBUow0EqYH9hDi0/07wDLRQ47Fk0W15Fgt5L5Ey9r uFpYuZi476Sr5uYAfbWCF76volQLWjRqQVFJ9BzwBSQCJ5C93zFQQaMQVWSSYObSkA9F lwOw== X-Gm-Message-State: AJIora8gfUQL1WbPBF75bUa0yXMod6UY842Clp9riNBCL2zuUY9afVJZ AjSZKqgEpjamOnp5z24PfhADEmYwgh4MenJm X-Received: by 2002:a17:90b:1d06:b0:1e6:7a84:3c6e with SMTP id on6-20020a17090b1d0600b001e67a843c6emr6502103pjb.202.1655240306825; Tue, 14 Jun 2022 13:58:26 -0700 (PDT) Received: from google.com ([192.77.111.2]) by smtp.gmail.com with ESMTPSA id h10-20020a170902680a00b001635c9e7f77sm7668254plk.57.2022.06.14.13.58.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jun 2022 13:58:26 -0700 (PDT) Date: Tue, 14 Jun 2022 21:58:24 +0100 From: Lee Jones To: Helmut Grohne Cc: Support Opensource , linux-kernel@vger.kernel.org, Adam Thomson , Mark Brown , Wolfram Sang Subject: Re: [PATCH v2 1/2] mfd: da9062: enable being a system-power-controller Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Apr 2022, Helmut Grohne wrote: > The DA9062 can be the device used to power the CPU. In that case, it can > be used to power off the system. In the CONTROL_A register, the M_*_EN > bits must be zero for the corresponding *_EN bits to have an effect. We > zero them all to turn off the system. > > Signed-off-by: Helmut Grohne > --- > drivers/mfd/da9062-core.c | 31 +++++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > This series effectively is a rebased resend. The earlier posting was > https://lore.kernel.org/all/20200107120559.GA700@laureti-dev/. At that time, > Adam Thomson critisized the use of regmap and i2c inside a pm_power_off hook > since irqs are disabled. He reached out to Lee Jones, who asked Mark Brown and > Wolfram Sang, but never got any reply. I noted that a fair number of other > drivers do use regmap and i2c despite this issue. In the mean time, more > instances were added: > * drivers/mfd/acer-ec-a500.c uses i2c > * drivers/mfd/ntxec.c uses i2c > * drivers/mfd/rk808.c uses regmap and i2c > Given that we proceeded with accepting the use of i2c and regmap inside > pm_power_off hooks, I think we can proceed with this patch as well. > > Helmut > > diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c > index 2774b2cbaea6..e7af5b5f16e0 100644 > --- a/drivers/mfd/da9062-core.c > +++ b/drivers/mfd/da9062-core.c > @@ -620,6 +620,23 @@ static const struct of_device_id da9062_dt_ids[] = { > }; > MODULE_DEVICE_TABLE(of, da9062_dt_ids); > > +/* Hold client since pm_power_off is global. */ Please drop this comment. > +static struct i2c_client *da9062_i2c_client; > + > +static void da9062_power_off(void) > +{ > + struct da9062 *chip = i2c_get_clientdata(da9062_i2c_client); > + const unsigned int mask = DA9062AA_SYSTEM_EN_MASK | > + DA9062AA_POWER_EN_MASK | DA9062AA_POWER1_EN_MASK | > + DA9062AA_M_SYSTEM_EN_MASK | DA9062AA_M_POWER_EN_MASK | > + DA9062AA_M_POWER1_EN_MASK; > + int ret = regmap_update_bits(chip->regmap, DA9062AA_CONTROL_A, mask, 0); This is messy. Please separate declarations and assignments here. The top one is passable. > + if (ret < 0) > + dev_err(&da9062_i2c_client->dev, > + "DA9062AA_CONTROL_A update failed, %d\n", ret); You're talking to the user here. Please use language that is more user-friendly. > +} > + > static int da9062_i2c_probe(struct i2c_client *i2c, > const struct i2c_device_id *id) > { > @@ -720,6 +737,15 @@ static int da9062_i2c_probe(struct i2c_client *i2c, > return ret; > } > > + if (of_device_is_system_power_controller(i2c->dev.of_node)) { > + if (!pm_power_off) { > + da9062_i2c_client = i2c; > + pm_power_off = da9062_power_off; > + } else { > + dev_warn(&i2c->dev, "Poweroff callback already assigned\n"); Do we really mind/care? Is there anything we can do about it? Thus, do we really need to warn() about it? > + } > + } > + > return ret; > } > > @@ -727,6 +753,11 @@ static int da9062_i2c_remove(struct i2c_client *i2c) > { > struct da9062 *chip = i2c_get_clientdata(i2c); > > + if (pm_power_off == da9062_power_off) > + pm_power_off = NULL; > + if (da9062_i2c_client) > + da9062_i2c_client = NULL; > + > mfd_remove_devices(chip->dev); > regmap_del_irq_chip(i2c->irq, chip->regmap_irq); > -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog