linux-kernel - Re: [PATCH 2/4] regulator: Add driver for MT6331 PMIC regulators

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:   Mon, 23 May 2022 15:22:39 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     lgirdwood@...il.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, matthias.bgg@...il.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 2/4] regulator: Add driver for MT6331 PMIC regulators

Il 23/05/22 15:00, Mark Brown ha scritto:
> On Mon, May 23, 2022 at 02:49:19PM +0200, AngeloGioacchino Del Regno wrote:
>> Il 20/05/22 16:45, Mark Brown ha scritto:
>>> On Fri, May 20, 2022 at 03:33:03PM +0200, AngeloGioacchino Del Regno wrote:
> 
>>>> +static const unsigned int ldo_volt_table10[] = {
>>>> +	1200000, 1300000, 1500000, 1800000,
>>>> +	1200000, 1300000, 1500000, 1800000,
>>>> +	1200000, 1300000, 1500000, 1800000,
>>>> +	1200000, 1300000, 1500000, 1800000,
>>>> +};
> 
>>> So the top bits of the voltate selection field just get ignored?  Might
>>> be easier to just write the code to not include the top bits.
>>>
> 
>> No, they're all valid values for real... but I guess that I can simplify
>> this voltage table by simply modifying the bitmask that we use for the
>> regulators that are using this table....
> 
> Right, my point here is that it looks awfully like the documentation
> (this came from documentation I guess?) is including some extra bits
> that get ignored in the voltage selection field here.  That seems like a
> weird choice somewhere along the line.
> 

I wish I had a datasheet for these parts...

All of this comes from analyzing a running device on the downstream 3.4 kernel
and on understanding the (not really readable) downstream kernel code...
..but yes, I agree on the fact that this seems to be a weird choice.

Ah, besides, I hooked up an oscilloscope to the VCAM_IO and I can see that the
vreg really does react as expected upon setting the upper bits.. but since it
still works without, we can safely ignore them, which makes us able to simplify
the driver (as no custom code for that will be required) and, at the same time,
avoid seeing a table of values repeated 4 times in a row.

>>>> +	if (info->qi > 0) {
>>>> +		reg = info->desc.enable_reg;
>>>> +		en_mask = info->qi;
> 
>>> If the regulator doesn't have status readback it shouldn't provide a
>>> get_status() operation.
> 
>> What I've understood is that when there's no "QI" flag, the enable register
>> will provide the regulator status (EN/DIS) acting like QI, that's why I've
>> added that if branch...
> 
>> Anyway, I'll recheck this part before sending the next version!
> 
> That would be fairly unusual, often a regulator won't even detect when
> it's gone out of regulation.

Actually, there *is* support for this kind of detection... luckily the registers
and masks/bits are all dumped in a "upmu_hw.h" header downstream, regardless of
whether they're used or not in the code, so at least there's that reference to
look at... and I can see that there are bits to manage the overcurrent protection
(OVP) and configurable (OCPLVL) overcurrent protection (OCP_EN / OC_EN)...

...so, the regulator will indeed shut itself off and clear either/both the QI_EN
and/or its relative bit in the enable register... I've also just found hints of
the latter (enable register being set to 0) downstream, so I'm sure that this is
indeed right.

And finally... I would really like to test the OCP/OVP features to write some
code managing that, but I'm using a production smartphone (a Xperia M5, like
mentioned in the cover letter) for research and testing and you surely understand
that it's not time yet to take this risk... I will, later - but I have to finish
the upstreaming of this SoC and platform before chasing the green smoke... :-)