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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 4 Jun 2021 08:13:21 +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月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.

Regards,
Axel