linux-kernel - Re: [PATCH V9 4/6] regulator: Add a regulator driver for the PM8008 PMIC

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]

Message-ID: <aae93f42-c949-0b86-6559-01a4d07fb838@quicinc.com>
Date:   Thu, 7 Apr 2022 10:42:39 +0530
From:   "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@...cinc.com>
To:     Stephen Boyd <swboyd@...omium.org>, Mark Brown <broonie@...nel.org>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_collinsd@...cinc.com>,
        <quic_subbaram@...cinc.com>, <quic_jprakash@...cinc.com>
Subject: Re: [PATCH V9 4/6] regulator: Add a regulator driver for the PM8008
 PMIC


On 4/6/2022 11:46 PM, Stephen Boyd wrote:
> Quoting Mark Brown (2022-04-06 10:27:44)
>> On Wed, Apr 06, 2022 at 10:21:01AM -0700, Stephen Boyd wrote:
>>> Quoting Mark Brown (2022-04-06 09:36:14)
>>>> On Wed, Apr 06, 2022 at 08:51:48AM -0700, Stephen Boyd wrote:
>>>>> My guess is that this is one IC that responds to multiple i2c addresses.
>>>>> The "main" qcom,pm8008 address is 0x8 and that supports things like
>>>>> interrupts. Then there's an address for regulators at 0x9 which controls
>>>>> the handful of LDOs on the PMIC.
>>>> So it's like the TI TWL4030 and Palmas - in which case it should
>>>> probably be handled similarly?
>>> How did those work out? I wasn't involved and I don't know what you
>>> mean. Do they have multiple i2c addresses they respond to?
>> Yes, exactly.  The main device uses i2c_new_dummy_device() to
>> instantiate the extras when it probes.  See twl-core.c
> Cool. That approach sounds good to me. Then the regulators can be child
> nodes of the qcom,pm8008 node at i2c address 0x8? It still feels like
> making a struct driver for each regulator node is overkill and will
> waste memory.
>
>>>> Note that the original sumbission was
>>>> *also* a MFD subfunction, but using a DT compatible to match the
>>>> platform device - this is the first I've heard of this being a separate
>>>> I2C function.
>>> I'm mainly looking at the dts file now. It clearly has two i2c devices
>>> at 0x8 and 0x9. Maybe the regulator driver followed the mfd design
>>> because the first driver for this device is an mfd.
>> I'm guessing from the naming that they're also externally described as
>> the same device - presumably it's two dies shoved together in the same
>> package for some reason without being otherwise joined up.  Is the
>> second device geniunely regulators only or does it have anything else
>> bundled in there?
> I think it's regulators only. Pretty sure I asked qcom this a round or
> two ago on this patch series and they said that. Let's wait for Satya to
> respond.


Yes, it contains regulators only.