linux-kernel - Re: [PATCH 12/13] regulator: add pm8008 pmic regulator driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 14 May 2024 19:13:17 +0530
From: Satya Priya Kakitapalli <quic_skakitap@...cinc.com>
To: <johan@...nel.org>
CC: <andersson@...nel.org>, <andy.shevchenko@...il.com>, <broonie@...nel.org>,
        <conor+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <johan+linaro@...nel.org>, <konrad.dybcio@...aro.org>,
        <krzk+dt@...nel.org>, <lee@...nel.org>, <lgirdwood@...il.com>,
        <linus.walleij@...aro.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_c_skakit@...cinc.com>, <quic_gurus@...cinc.com>,
        <robh@...nel.org>, <swboyd@...omium.org>
Subject: Re: [PATCH 12/13] regulator: add pm8008 pmic regulator driver

> On Tue, May 07, 2024 at 01:48:30PM +0200, Konrad Dybcio wrote:
> > On 5/6/24 17:08, Johan Hovold wrote:
> > > From: Satya Priya <quic_c_skakit@...cinc.com>
> > > 
> > > Qualcomm Technologies, Inc. PM8008 is an I2C-controlled PMIC containing
> > > seven LDO regulators. Add a PM8008 regulator driver to support PMIC
> > > regulator management via the regulator framework.
> > > 
> > > Note that this driver, originally submitted by Satya Priya [1], has been
> > > reworked to match the new devicetree binding which no longer describes
> > > each regulator as a separate device.
> > > 
> > > This avoids describing internal details like register offsets in the
> > > devicetree and allows for extending the implementation with features
> > > like over-current protection without having to update the binding.
> > > 
> > > Specifically note that the regulator interrupts are shared between all
> > > regulators.
> > > 
> > > Note that the secondary regmap is looked up by name and that if the
> > > driver ever needs to be generalised to support regulators provided by
> > > the primary regmap (I2C address) such information could be added to a
> > > driver lookup table matching on the parent compatible.
> > > 
> > > This also fixes the original implementation, which looked up regulators
> > > by 'regulator-name' property rather than devicetree node name and which
> > > prevented the regulators from being named to match board schematics.
> > > 
> > > [1] https://lore.kernel.org/r/1655200111-18357-8-git-send-email-quic_c_skakit@quicinc.com
> > > 
> > > Signed-off-by: Satya Priya <quic_c_skakit@...cinc.com>

This is my old email which is discontinued, please use <quic_skakitap@...cinc.com>

> > > Cc: Stephen Boyd <swboyd@...omium.org>
> > > [ johan: rework probe to match new binding, amend commit message and
> > >           Kconfig entry]
> > > Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> > > ---
> > 
> > I'm a bit lukewarm on calling this qcom-pm8008-regulator.. But then
> > qcom-i2c-regulator or qpnp-i2c-regulator may bite due to being overly
> > generic.. Would you know whether this code will also be used for e.g.
> > PM8010?
> 
> Yes, for any sufficiently similar PMICs, including SPMI ones. So
> 'qpnp-regulator' would be a generic name, but only Qualcomm knows what
> PMICs they have and how they are related -- the rest of us is left doing
> tedious code forensics to try to make some sense of this.
> 
> So just like for compatible strings, letting the first supported PMIC
> name the driver makes sense as we don't know when we'll want to add a
> second one for another set of devices (and we don't want to call that
> one 'qpnp-regulator-2'). On the other hand, these names are now mostly
> internal and can more easily be renamed later.

There is a PMIC called PM8010 which also is implemented over I2C, which could use the same pm8008 regulator driver.
Hence it is better to use device_id instead of a MODULE_ALIAS().