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-next>] [day] [month] [year] [list]
Date:   Tue, 7 Mar 2023 12:25:04 +0530
From:   Devi Priya <quic_devipriy@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Mark Brown <broonie@...nel.org>
CC:     <agross@...nel.org>, <andersson@...nel.org>, <lgirdwood@...il.com>,
        <robh+dt@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <quic_srichara@...cinc.com>,
        <quic_gokulsri@...cinc.com>, <quic_sjaganat@...cinc.com>,
        <quic_kathirav@...cinc.com>, <quic_arajkuma@...cinc.com>,
        <quic_anusha@...cinc.com>, <quic_ipkumar@...cinc.com>
Subject: Re: [PATCH V2 4/6] regulator: qcom_smd: Add support to define the
 bootup voltage



On 3/6/2023 6:39 PM, Devi Priya wrote:
> 
> 
> On 3/3/2023 6:57 PM, Konrad Dybcio wrote:
>>
>>
>> On 3.03.2023 14:21, Devi Priya wrote:
>>>
>>>
>>> On 2/23/2023 4:31 AM, Mark Brown wrote:
>>>> On Wed, Feb 22, 2023 at 11:11:42PM +0100, Konrad Dybcio wrote:
>>>>
>>>>> Thinking about it again, this seems like something that could be
>>>>> generalized and introduced into regulator core.. Hardcoding this
>>>>> will not end well.. Not to mention it'll affect all mp5496-using
>>>>> boards that are already upstream.
>>>>
>>>>> WDYT about regulator-init-microvolts Mark?
>>>>
>>>> The overwhelming majority of devices that have variable voltages
>>>> support readback, these Qualcomm firmware devices are pretty much
>>>> unique in this regard.  We don't want a general property to set a
>>>> specific voltage since normally we should be using the
>>>> constraints and don't normally need to adjust things immediately
>>>> since we can tell what the current voltage is.
>>>>
>>>> This is pretty much just going to be a device specific bodge,
>>>> ideally something that does know what the voltage is would be
>>>> able to tell us at runtime but if that's not possible then
>>>> there's no good options.  If the initial voltage might vary based
>>>> on board then a device specific DT property might be less
>>>> terrible, if it's determined by the regulator the current code
>>>> seems fine.  Or just leave the current behavour, if the
>>>> constraints are accurate then hopefully a temporary dip in
>>>> voltage is just inelegant rather than an issue.  Indeed the
>>>> current behaviour might well save power if you've got a voltage
>>>> range configured and nothing actually ever gets round to setting
>>>> the voltage (which is depressingly common, people seem keen on
>>>> setting voltage ranges even when the voltage is never varied in
>>>> practice).
>>>
>>> Hi Mark, The initial bootup voltage is actually blown into the OTP 
>>> register of the PMIC and it remains the same across boards for 
>>> IPQ9574 SoC.
>> But what about IPQ6018 which also uses MP5496? That's also gonna
>> set the voltage on there, it may be too high/low..
For IPQ6018, the bootup voltage is the same as that of IPQ9574 which is
875mV
>>
>>   Initially the SoC runs at 800MHz with a voltage of 875mV set by the 
>> bootloaders. As kernel does not know the initial voltage, during 
>> regulator registration the framework considers the current voltage to 
>> be zero and tries to bring up the regulator to minimum supported 
>> voltage of 600mV. This causes the dip which might be of concern in SS 
>> parts where the voltage might be insufficient leading to silent reboots.
>> That's an SoC-specific thing, the same regulator can be used with
>> many different ones. We can't just assume it'll always be like this.
>> I see the problem, but I believe this is not the correct solution
Okay, As we had discussions on reading back the voltage & the generic
DT property, do you suggest any other possible solutions here?
>>
>> Konrad
>>>
>>> Best Regards,
>>> Devi Priya

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ