Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4115663imm; Tue, 29 May 2018 22:34:46 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK1x7QC7N1vK4JwfEoWSyc+fnSuBNC7W0pQm+etmgFJJ+5Qdsw+tLCZZ3vbY5xVIIGG5qgr X-Received: by 2002:a17:902:d885:: with SMTP id b5-v6mr1445133plz.218.1527658486948; Tue, 29 May 2018 22:34:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527658486; cv=none; d=google.com; s=arc-20160816; b=i1euGIb7POGQT0T1TqE8wLbAajsaXjd+1htU9XdQLv1U4+2Ac6B4GfIlp1AkIVfg0b vCNfhgevhn6yWZoE0ntLQ7Ms4mcHuqVxU68AAxVYrsLoOoMZILRydxtUVPxttYYDryke /20EWx/yI4RxPGbmFumoObe/YSRMbgqOwzcHulmpfXHLwYuc5nL1q9lpYWSB7tveDhxf VatW3/cBnjmTHG0wAkR4Py7cWyYrEQRRQxfUyDDUWLZuOeMZEpV13m45gW5qvg7MceC4 +VVdkw7b/StTOXHE7kfhMBcuXKpnkLiSgkg46vyVB8KY65zQ5NM5W5m0Xss7F0U0WAsj Y4bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=bbrGbqq5Pz7RBaJMQKz1SIlc/ov/78iBWbUkTDLs0cU=; b=xOK7pE0v+IXPolzEpe7RgknjtDcN7lYYV/Z7oE6GPJauEeChCNB8lu0KRDWIxuNcYe 3QGCOGjn9+n4Li8wsDvywtbi6k5B5uCXKybSwOd5ObYcMhmJ3uAisWhtbv2nSjsgtRic 8xD/+WGDoxBv5MeWUuvL34+UaILmOIkjMIOEuJEDx0KTqc+UiQqcEj10t4PPUKNdfvWH +80z1BaWEoLe/tYVJFJF6G0ZQm8f1M1GYx68IRAvrGWXep8AX4vZV6lYqpyvTQTlo92C 3n1wosmDnSIZRuYPc24w1UExyXpQRIgmkkWhvNUsNjxRVKOfgH6PkrGfZhlLjmgIZ0pC NrjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=U027mb1s; dkim=fail header.i=@chromium.org header.s=google header.b=MzUsa0sc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o12-v6si33878044pls.422.2018.05.29.22.34.32; Tue, 29 May 2018 22:34:46 -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; dkim=fail header.i=@google.com header.s=20161025 header.b=U027mb1s; dkim=fail header.i=@chromium.org header.s=google header.b=MzUsa0sc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935474AbeE3Fcn (ORCPT + 99 others); Wed, 30 May 2018 01:32:43 -0400 Received: from mail-vk0-f66.google.com ([209.85.213.66]:33744 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934541AbeE3Fck (ORCPT ); Wed, 30 May 2018 01:32:40 -0400 Received: by mail-vk0-f66.google.com with SMTP id 200-v6so8257882vkc.0 for ; Tue, 29 May 2018 22:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bbrGbqq5Pz7RBaJMQKz1SIlc/ov/78iBWbUkTDLs0cU=; b=U027mb1sQu7PQtEWsOPzHiVYE5M5rR+9DVfWPtguS8pCr4ZMh0XTnAdRrVP1DquzBM 65lE+AFqGec5rdLqH2X0XytY195+eQRu+l+KVuVE//N/uOt/o5ivHf23k/04bywHmKDJ qaBB1HLJysRJsJRbqazXAOaNzuiZbMVDUUqVsKYoXKQj1H3nOsfmCERCBAKPECx1sAKa vQmyVue88E0GO8O0V91Ur+g5eQjzRaVZe/NymdbWMm2Iqf4nU8dxajrfvRp14Qq9JasS FkyxWGimCfBXQfs2Rw3Ogv5xVjiKNgqW+qZsfwquC8r7Z7r8a6TgAEDmJ1NTi5YQ9Vpl Bw3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bbrGbqq5Pz7RBaJMQKz1SIlc/ov/78iBWbUkTDLs0cU=; b=MzUsa0scXvrm9GWK6E4ma94//ubKsSCnePxwrKihTBw9bVGIpyBlpwYL8edR2AIj+A Lpf9FgWrtAHbRJCq7Kp7RwoYHoD86ftZRDzSsT7XOk7NhYSA2Fd0RV38cFGEfTjsoTAH r/BaAqDklyPWCke9oX49w6B4Ex2TbAIf8vaXc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bbrGbqq5Pz7RBaJMQKz1SIlc/ov/78iBWbUkTDLs0cU=; b=FjZ6tzMBxIY2IkVLkSgjY55logf+VOy21hgSUVVYXZKkFU0P6Yr3HpuER7PUjP1djx iSXfl+oxjhyNUkEqRh2gjS276KkxOCnGffwJt29OlFiAGUCzUVIBaQ9eYqkk+TO5QSDi LWcKBAq1OVkyrBHXgt27QWIcvuKXI6/41YDqiNWQQ1AYkWNDPsq6DJACy5YzEPWhhm4K 3wIU3zYngvsCV8MtkieN1W4IXCFW+rjG/NxWoML48Ik8TPmZhEXy0LH6vDxW1PhyoCRc 191glR7qPZi2rgPcuWBhDa7u3nRpWNzlsv5HZ/BRnxDrt/6lgLHZwZkgOt99Jcgmi4oM mSiQ== X-Gm-Message-State: ALKqPwe5KubVJiZe7ty85cKMJjHM9y+PHc9CMgekgmtKtpzuREe153r7 zXzz6M4/GjR9ZUw7mVBEsRidQBpOjrgmrPNZ6z07fA== X-Received: by 2002:a1f:d304:: with SMTP id k4-v6mr650802vkg.101.1527658359122; Tue, 29 May 2018 22:32:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:3052:0:0:0:0:0 with HTTP; Tue, 29 May 2018 22:32:38 -0700 (PDT) In-Reply-To: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org> References: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org> From: Doug Anderson Date: Tue, 29 May 2018 22:32:38 -0700 X-Google-Sender-Auth: iFkzJXiXtFTnJ7VI8j0SxXBRiTE Message-ID: Subject: Re: [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver To: David Collins Cc: Mark Brown , Liam Girdwood , Rob Herring , Mark Rutland , linux-arm-msm@vger.kernel.org, Linux ARM , devicetree@vger.kernel.org, LKML , Rajendra Nayak , Stephen Boyd Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, May 22, 2018 at 7:43 PM, David Collins wrote: > + * @ever_enabled: Boolean indicating that the regulator has been > + * explicitly enabled at least once. Voltage > + * requests should be cached when this flag is not > + * set. Do you really need this extra boolean? Can't you just check if "enabled" is still "-EINVAL"? If it is then you don't pass the voltage along. ...this would mean that you'd also need to send the voltage vote when the regulator core tries to disable unused regulators at the end of bootup, but that should be OK right? If we never touched a regulator anywhere at probe time and we're about to vote to disable it, we know there's nobody requiring it to still be on. We can vote for the voltage now without fear of messing up a vote that the BIOS left in place. In theory this should also allow you to assert your vote about the voltage of a regulator that has never been enabled, which (if I understand correctly) you consider to be a feature. --- Other than that comment, everything else here looks good to go if Mark is good with it. As per the previous threads there are some things that I don't like a ton, but I feel it is between you and Mark to decide if you're good with it. A summary of those issues are: 1. I still believe that when we disable a regulator in Linux we should tell RPMh that we vote for the lowest voltage. ...but if Mark is happy with the way the driver works now I won't push it. 2. As per my comments in the bindings patch, I still believe that "qcom,drms-mode-max-microamps" belongs in the core. Again, up to Mark. 3. As per my comments in the bindings patch, I still believe that we're just adding lots of noise to the DT most of the time by specifying both "qcom,regulator-drms-modes" and "regulator-allowed-modes". Again, up to Mark. -Doug