linux-kernel - Re: [PATCH] regulator: rt6160: Convert to use regulator_set_ramp_delay

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>] [day] [month] [year] [list]

Message-ID: <CAFRkauCdRoChK-djEi+TzC4As5JzykPF=fb1YmDukEjWJG0K_g@mail.gmail.com>
Date:   Fri, 4 Jun 2021 11:30:39 +0800
From:   Axel Lin <axel.lin@...ics.com>
To:     cy_huang(黃啟原) <cy_huang@...htek.com>
Cc:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "u0084500@...il.com" <u0084500@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCH] regulator: rt6160: Convert to use regulator_set_ramp_delay_regmap

cy_huang(黃啟原) <cy_huang@...htek.com> 於 2021年6月4日 週五 上午10:26寫道：
>
>
>
> cy_huang(黃啟原) <cy_huang@...htek.com> 於 2021年6月3日 週四 下午11:18寫道：
>
>
> Hi,> >
>
>
> cy_huang(黃啟原) <cy_huang@...htek.com> 於 2021年6月3日 週四 下午6:20寫道：
>
>
>
>
> Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
>
>
>
>
>
> There's some reason.
> You can refer to https://lkml.org/lkml/2021/6/1/1145.
>
> It's because our ramp value order is from small to large, not large to
> small.
> It conflicts with find_closest_bigger value chosen logic.
>
> I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> regulator_set_ramp_delay_regmap. (both functions get the same selector
> for a given delay)
>
> Could you check if this patch works?
>
> Sure.
>
> After my test sample code, below's the result.
> ascending [1000 2500 5000 10000]
> target =  1000 =>sel = 0
> target =  2500 =>sel = 1
> target =  5000 =>sel = 2
> target = 10000 =>sel = 3
> target =  1700 =>sel = 1
> target =  2750 =>sel = 2
> target =  7500 =>sel = 3
> target = 15000 =>failed to find best select, sel = 3
> target =     0 =>sel = 0
> descending [10000 5000 2500 1000]
> target =  1000 =>sel = 3
> target =  2500 =>sel = 2
> target =  5000 =>sel = 1
> target = 10000 =>sel = 0
> target =  1700 =>sel = 2
> target =  2750 =>sel = 1
> target =  7500 =>sel = 0
> target = 15000 =>failed to find best select, sel = 0
> target =     0 =>sel = 3
>
>
> It means when target is in range or even over, the result are all correct.
> But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> When the ramp target is equal to 0, it means the user want to disable the rammpping function.
>
> As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
>
>
> If your table is [1000 2500 5000 10000], find_closest_bigger() will
> choose sel=0 when ramp_delay=0.
> If your table is [10000 5000 2500 1000], find_closest_bigger() will
> choose sel=3 when ramp_delay=0.
> i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
>
> This meets your exception.
>
> Actually, even if your table is [10000, 1000, 5000, 2500],
> find_closest_bigger() still can choose the correct selector.
> i.e. sel=1 when ramp_delay=0 in this case.
>
> This selection may be wrong.
> ramp_delay=0 means ramp disabled,
> If chip not support rampping disable, this selection must be configured as fastest rampping value, not the minimum one.

0 does not mean ramp disable.
It could be explicitly set to zero or its unintialized (zero by default).
see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea