Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2057156iof; Tue, 7 Jun 2022 18:19:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOv+fuaI/WlFQ3Heh+M5F04uVFtjcjm+joYpDWwDlV3d4nTmhe4xItiRxb5pObonYoxX6E X-Received: by 2002:a17:90b:33cd:b0:1e6:8a38:f0b9 with SMTP id lk13-20020a17090b33cd00b001e68a38f0b9mr32948154pjb.64.1654651157182; Tue, 07 Jun 2022 18:19:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654651157; cv=none; d=google.com; s=arc-20160816; b=FoovoFe/8xrrJgg3lGSehYupVtAQzBySTT5/KxXrMzcztMNu8Behf374YZNOePyWzo ELpZRL9K69c/lLgPTJ5HfyVpt//V0r8eTJ+2jCgr9FpFM6cCQj5rr9F25FeyBSWqeYgN /NPEHN2nMHSqjoFBWCm/rCu5X9JHNaZJoaC2wYqVVbVwAnG2wd3jqua7egjQifFIZTHJ KeaCT9tsLAan+/ihp2ggMaWsC4p48IR4S1gELoAUZ2IJRUeJMs/IbqsoZo2P6uNmTfNi ERiidb7vXoKmlHr9Mi6HesasVTX1eM7ZL+jhh/+62i9WqPL4JxpCUYIruH+z1cMBddH5 c4sg== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LyiH+9U+1Tep8lEp27ZBXKAcFFIbbh5LZcN6cLJdmfw=; b=LG7MAP79cBxz0gIY0d2/Ztd4LlaErrkuEg7UP63wObnSly6WumXQ/MpXBbV89u/hTy HFPblAixvbN2p0fAbu7Hp9fDoevPyaWbhzX/gHkit+fduE7yTgIP6a0DiLxKJPjW8mn/ RvhdamWOIK4gcs9V+KrMyQQ/pUmQvTs3t4oLyUAUhZsGgN1lXLtQ9rB+7IPIIVw/sFg/ YLmnn1XehbuqeqY1WQkTmexWy1wzGDfBkTlDQmH0TgUhbTOf/4JOJmjTiBYmfYvxJ45b GsQ0IS5DAXuTMYLerf2lP13q7TRtD7gHiGWEaW0NyzStMvWteEWcLUDT4hRFZtuY8RF3 id9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iuBUuLTl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q9-20020a638c49000000b003fc0bd70856si31856167pgn.807.2022.06.07.18.19.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 18:19:17 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iuBUuLTl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CED2E258B57; Tue, 7 Jun 2022 18:11:27 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384236AbiFGWfw (ORCPT + 99 others); Tue, 7 Jun 2022 18:35:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378460AbiFGVXP (ORCPT ); Tue, 7 Jun 2022 17:23:15 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4940B226CFB; Tue, 7 Jun 2022 12:00:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id D0E9BCE247C; Tue, 7 Jun 2022 19:00:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C34FC385A5; Tue, 7 Jun 2022 19:00:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654628433; bh=PETGTpshoDoTRoH9w/heaUnGsqX8NQyeufAgBDPT+dc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iuBUuLTlpKLrFOJkqHh9kPQ0JfJeWqd0WcizgQYJomwFKG9B/mo340eff68SsGWf4 u5rhlB6BKhXhVBjN+rccBwo2qO7SHi+KTsBx3QaTokTup472ptXiBsZ5TOOWgyqnXP DaIVzhsTvmjipXXk7l4x/9ezYPItrCzvrh0mT4PsSa7pLcSRAuCUUZ9/JVbsZpqQEo USNVw2sU7sHjD53sXPDaUC2koJIWm9cA2cdI0bcBwo1O72rEspr0ANGPvUsPjK5Zrq Nnhj4Ww7jT9vCOXVegNe5YkO+lNfWH/hYB6P0yggJTeDAEQL069ZI1yQiGHZEE2fJA zArkaLa/809aw== Date: Tue, 7 Jun 2022 20:00:27 +0100 From: Mark Brown To: cy_huang Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, lee.jones@linaro.org, dmitry.torokhov@gmail.com, lgirdwood@gmail.com, cy_huang@richtek.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org Subject: Re: [PATCH 3/4] regulator: rt5120: Add PMIC regulator support Message-ID: References: <1654581161-12349-1-git-send-email-u0084500@gmail.com> <1654581161-12349-4-git-send-email-u0084500@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ksAClhgkgYP1BOgI" Content-Disposition: inline In-Reply-To: <1654581161-12349-4-git-send-email-u0084500@gmail.com> X-Cookie: Where's SANDY DUNCAN? X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 --ksAClhgkgYP1BOgI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 07, 2022 at 01:52:40PM +0800, cy_huang wrote: This looks mostly good, a few things though: > +static void rt5120_fillin_regulator_desc(struct regulator_desc *desc, int rid) > +{ > + static const char * const name[] = { "buck1", "buck2", "buck3", "buck4", > + "ldo", "exten" }; > + static const char * const sname[] = { "vin1", "vin2", "vin3", "vin4", > + "vinldo", NULL }; It would be easier and clearer to just make this a static table like other drivers do, there's no need to generate anything dynamically as far as I can see. > +static int rt5120_of_parse_cb(struct rt5120_priv *priv, int rid, > + struct of_regulator_match *match) > +{ > + struct regulator_desc *desc = priv->rdesc + rid; > + struct regulator_init_data *init_data = match->init_data; > + > + if (!init_data || rid == RT5120_REGULATOR_BUCK1) > + return 0; > + > + if (init_data->constraints.min_uV != init_data->constraints.max_uV) { > + dev_err(priv->dev, "Variable voltage for fixed regulator\n"); > + return -EINVAL; > + } > + > + desc->fixed_uV = init_data->constraints.min_uV; > + init_data->constraints.apply_uV = 0; Drivers should never override constraints passed in by machine drivers, if there's validation needed let the core do it. The same probably applies to providing a voltage range for a fixed regulator though that's not modifying everything so not such a problem. > +static int rt5120_parse_regulator_dt_data(struct rt5120_priv *priv) > +{ > + struct device *dev = priv->dev->parent; > + struct device_node *reg_node; > + int i, ret; > + > + for (i = 0; i < RT5120_MAX_REGULATOR; i++) { > + rt5120_fillin_regulator_desc(priv->rdesc + i, i); > + > + rt5120_regu_match[i].desc = priv->rdesc + i; > + } Like I said above just make the list of regulators static data and loop through registering them. > + > + reg_node = of_get_child_by_name(dev->of_node, "regulators"); > + if (!reg_node) { > + dev_err(priv->dev, "Couldn't find 'regulators' node\n"); > + return -ENODEV; > + } > + > + ret = of_regulator_match(priv->dev, reg_node, rt5120_regu_match, > + ARRAY_SIZE(rt5120_regu_match)); > + > + of_node_put(reg_node); > + > + if (ret < 0) { > + dev_err(priv->dev, > + "Error parsing regulator init data (%d)\n", ret); > + return ret; > + } > + > + for (i = 0; i < RT5120_MAX_REGULATOR; i++) { > + ret = rt5120_of_parse_cb(priv, i, rt5120_regu_match + i); > + if (ret) { > + dev_err(priv->dev, "Failed in [%d] of_passe_cb\n", i); > + return ret; > + } > + } This is all open coding stuff that's in the core - just provde an of_parse_cb() operation and let the core take care of calling it. > +static int rt5120_device_property_init(struct rt5120_priv *priv) > +{ > + struct device *dev = priv->dev->parent; > + bool prot_enable; > + unsigned int prot_enable_val = 0; > + > + /* Assign UV/OV HW protection behavior */ > + prot_enable = device_property_read_bool(dev, > + "richtek,enable-undervolt-hiccup"); > + if (prot_enable) > + prot_enable_val |= RT5120_UVHICCUP_MASK; Use the DT APIs to parse DT - since ACPI has a very strong idea of how power management works which is fundamentally incompatible with with the DT model we should be writing code in a way that minimises the risk that we'll end up trying to parse DT properties out of ACPI systems and creating confusion as DT and ACPI software tries to run on the same system. --ksAClhgkgYP1BOgI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmKfoEsACgkQJNaLcl1U h9CbXgf/UP1xlHdcxsSMcl+dOuHtQVClDCrw8ssMEZoh5P0ptx96m8VaEPkVF/pU 64Y/IH4gv/ROwEXDSIT9ExPMBg4J0kTvOl08x+bnUl3oQUopPOC65uA03hOkI9V1 ygSjgh6WlNl6sT8mKOPRluz85uEGgzlGQviAdXhe/WvMSpYRkeQwScD61qJYE0Ur yO+goydPHRmt/kNT/fqTypQ0wKu5n0j4LzIxcKN+4ovTJiNj4jdnoPLwtr+iVDVR 5n2ze8TBEUuL2Elh0d2qWqc6DXDm/2OelFLCx03gVdkr6ahg62/QOTRnJzz2Vhgp SINDFI1pJt2+4f+R/poMsQxOUOvdPA== =d5Wn -----END PGP SIGNATURE----- --ksAClhgkgYP1BOgI--