linux-kernel - Re: [RFT][PATCH 2/2] regulator: lm363x: Fix n

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, 8 Jul 2019 10:04:09 +0800
From:   Axel Lin <axel.lin@...ics.com>
To:     Dan Murphy <dmurphy@...com>
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFT][PATCH 2/2] regulator: lm363x: Fix n_voltages setting for lm36274

Axel Lin <axel.lin@...ics.com> 於 2019年6月27日 週四 上午7:58寫道：
>
> > > With your current code where LM36274_LDO_VSEL_MAX and n_voltages is 0x34,
> > > the maximum voltage will become 400000 + 50000 * 0x34 = 6.6V which
> > > does not match the datasheet.
> >
> > Not sure how you get 6.6v the LDO max is 6.5v.
> >
> > After 0x32->0x7f maps to 6.5v
> >
> > 000000 = 4 V
> > 000001 = 4.05 V
> > :
> > 011110 = 5.5 V (Default)
> > :
> > 110010 = 6.5 V
> >
> > 110011 to 111111 map to 6.5 V <- Should never see 6.6v from LDO
> >
> > Page 7 of the Datasheet says range is 4v->6.5v
> Hi Dan,
>
> The device indeed can only support up to 6.5V, the point is you are using
> linear equation to calculate the voltage of each selecter.
> In your current code:
> #define LM36274_LDO_VSEL_MAX           0x34 (and it's .n_voltages)
> So it supports selector 0 ... 0x33.
> For selector 0x33 in the linear equation is
> 4000000 + 50000 * 51 = 6550000 (i.e. 6.55V)
> i.e. The device actually only support up to 6.5V but the driver
> reports it support up to 6.55V
>      because regulator_list_voltage() will return 6.55V for selector 0x33.
> (I have off-by-one in my previous reply because when .n_voltages is
> 0x34, it supports up to 0x33)

Similar comment as I mentioned in another path.
Did you check regulator_list_voltage() output for the boundary case
with and without this patch?