Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3064747imc; Wed, 13 Mar 2019 08:03:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZuRmyaGNzgI0bbkopUd7zKJE6UhnaqoW5zcWmXRfSgTWpGXKuTONzIGP4dH3D+glLOln2 X-Received: by 2002:a65:518b:: with SMTP id h11mr30489457pgq.41.1552489431379; Wed, 13 Mar 2019 08:03:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552489431; cv=none; d=google.com; s=arc-20160816; b=AjyJOX6EfSz7AxTXPsMyYGHQtN1iK0Tx05qAV/K7YU/YOLuTjUdcAZhQUQ/DwgCR9E ewU7Hm/zyCJSxipn4BZkz/TxvMcufn44cFHZscxJ+hRDJrHuS8JJUBVtIDv6i2frS8Jn t8succlTEMflFrd8XgFkVjjpdUdLldcAkggX3jDS0UauqyCqmpHbsJpI7qwWuBIC1LN6 LI3p2h2G73wqfaSWfROgQO910bAHHBJUjDOZjYl9FkU8GdF5tMci7L7pGmvCUw1oYGZv agZqae2rggHgkH36nltwdVqTBFqoPAWGbehO8XN/jzbpDlP27vlRebP1soE5ZEXveq/Y L8fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=hSugnqnoJFSNcvCBKdbaU7QD11ItzVJo4CVY/LKjPw8=; b=WMqzEnfrhWpZAbcezyDupHScr3nmXYPEmLNx1yj/OcRdSx8Mc2PrcP6/QwuHzDB2IS VXNtQi+ls88KsksOAF0+iPpaEN+VhvKVCfoJyrX1O6u+L6oOLy8U+BNaMD0pjbqgYL4b vw3fRajaahpjh+6wUwjhKcwph7Odj4wXWj/eQyO8Vp2RzbXe99sWAvLqTSMGz0c2YRFC IWPLNbInBKAcFqg4Rhg4HOGn1qqmkRRZVxAJ+5PpwlNYCrdEt0u//sI9N+1gBT6f9vi5 m4tH/GaWkqVvX1dYTVMw/gSfsMaOKXn3uT+9JYXPOYCD45F9Dk4/BKqEalQj7WUOgziB fprg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=ZbJPTAbw; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si586608pgs.568.2019.03.13.08.03.30; Wed, 13 Mar 2019 08:03:51 -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=@sirena.org.uk header.s=20170815-heliosphere header.b=ZbJPTAbw; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726737AbfCMPCB (ORCPT + 99 others); Wed, 13 Mar 2019 11:02:01 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:43842 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbfCMPCA (ORCPT ); Wed, 13 Mar 2019 11:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hSugnqnoJFSNcvCBKdbaU7QD11ItzVJo4CVY/LKjPw8=; b=ZbJPTAbwiih08LWJ34FlQHgN2 9gIG41WG7joyBJE17zW+bp2hFygf0eiC5xiYy29kdH9bUnmspY8nVv0/LkmYeCdX7NQAImJruJFnz UsRLvaDi2FzMUa/uW1jfuwU3VwJv0ruY9SCoulM5Tbh1Te81WNrNtQYvX6/knjgtp+Reo=; Received: from cpc102320-sgyl38-2-0-cust46.18-2.cable.virginm.net ([82.37.168.47] helo=debutante.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpa (Exim 4.89) (envelope-from ) id 1h45Nt-0003Ii-AX; Wed, 13 Mar 2019 15:01:33 +0000 Received: by debutante.sirena.org.uk (Postfix, from userid 1000) id 8EF9A1128B97; Wed, 13 Mar 2019 15:01:32 +0000 (GMT) Date: Wed, 13 Mar 2019 15:01:32 +0000 From: Mark Brown To: Hsin-Hsiung Wang Cc: Lee Jones , Rob Herring , Matthias Brugger , Eddie Huang , Marc Zyngier , srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, Liam Girdwood , Mark Rutland , Sean Wang , Alessandro Zummo , Alexandre Belloni Subject: Re: [PATCH v2 6/9] regulator: mt6358: Add support for MT6358 regulator Message-ID: <20190313150132.GA5951@sirena.org.uk> References: <1552275991-34648-1-git-send-email-hsin-hsiung.wang@mediatek.com> <1552275991-34648-7-git-send-email-hsin-hsiung.wang@mediatek.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <1552275991-34648-7-git-send-email-hsin-hsiung.wang@mediatek.com> X-Cookie: Availability is limited. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 11, 2019 at 11:46:28AM +0800, Hsin-Hsiung Wang wrote: > +static const u32 vefuse_voltages[] = { > + 1700000, 1800000, 1900000, > +}; This and a bunch of the other regulators look like they're just linear ranges and could use the linear range helpers. > +static const u32 vcn33_bt_voltages[] = { > + 3300000, 3400000, 3500000, > +}; > + > +static const u32 vcn33_wifi_voltages[] = { > + 3300000, 3400000, 3500000, > +}; These also have the same range so no matter which helpers are used I'd expect the data to be shared, I think some of the other regulators might have shared tables but didn't confirm. > +static inline unsigned int mt6358_map_mode(unsigned int mode) > +{ > + return mode == MT6358_BUCK_MODE_FORCE_PWM ? > + REGULATOR_MODE_FAST : REGULATOR_MODE_NORMAL; > +} Please write normal if statements, it makes the code more readable. > +static int mt6358_set_voltage_sel(struct regulator_dev *rdev, > + unsigned int selector) > +{ > + int idx, ret; > + const u32 *pvol; > + struct mt6358_regulator_info *info = rdev_get_drvdata(rdev); > + > + pvol = (const u32 *)info->index_table; > + > + idx = pvol[selector]; > + ret = regmap_update_bits(rdev->regmap, info->desc.vsel_reg, > + info->desc.vsel_mask, > + idx << info->vsel_shift); > + > + return ret; > +} This looks like something other devices might do - rather than implement it in the driver it would be a bit better to add it to helpers.c as a reusable function. > +static int mt6358_get_buck_voltage_sel(struct regulator_dev *rdev) > +{ > + int ret, regval; > + struct mt6358_regulator_info *info = rdev_get_drvdata(rdev); > + > + ret = regmap_read(rdev->regmap, info->da_vsel_reg, ®val); > + if (ret != 0) { > + dev_info(&rdev->dev, > + "Failed to get mt6358 Buck %s vsel reg: %d\n", > + info->desc.name, ret); > + return ret; > + } > + > + ret = (regval >> info->da_vsel_shift) & info->da_vsel_mask; > + > + return ret; > +} This is just the generic get_voltage_sel() as far as I can see? > + /* Read PMIC chip revision to update constraints and voltage table */ > + if (regmap_read(mt6397->regmap, MT6358_SWCID, ®_value) < 0) { > + dev_err(&pdev->dev, "Failed to read Chip ID\n"); > + return -EIO; > + } We never use the value we read here? --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlyJG0kACgkQJNaLcl1U h9Bqcwf/cBs7hTJMGSxxGTMQXuOiF7spWZKUwkRLK+rWiYzZv7xUeHEoUoSLZzm/ d1xUkLNQ48R3p7Ey4aVzFf3HltiH9RGj+3g8OszIJS6SdTybiZYhJqMsAMnqfX/x tIbiu6NhlLrtm6qfKEEjHHnYSu1dIhMm6Y6JJ4D/yjpxWBed6xR0LlGTk7s3b3Gs xf1hGjBU2Hl0CE4TiamypPcVTzEIx4mzw1VpB2qBXwCoDLG1wnJKwjAmFVFNyWLo jpEeWmmqBboKOiRw+LfVXPW7CF35a3smalwrzBhIYToBop3b95kY5Pza/r7Vmr84 203AJzm4IdIG7xe56xcuLu3AOOQqaA== =Aw1h -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh--