linux-kernel - Re: [PATCH] regulator: rn5t618: fix rc5t619 ldo10 enable

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:   Thu, 14 Nov 2019 13:13:47 +0100
From:   Stefan Agner <stefan@...er.ch>
To:     Mark Brown <broonie@...nel.org>,
        Andreas Kemnade <andreas@...nade.info>
Cc:     lgirdwood@...il.com, linux-kernel@...r.kernel.org, phh@....me,
        b.galvani@...il.com
Subject: Re: [PATCH] regulator: rn5t618: fix rc5t619 ldo10 enable

On 2019-11-14 12:54, Mark Brown wrote:
> On Wed, Nov 13, 2019 at 08:26:33PM +0100, Andreas Kemnade wrote:
>> Mark Brown <broonie@...nel.org> wrote:
> 
>> > This definitely looks like a bug but without a datasheet or testing it's
>> > worrying guessing at the register bit to use for the enable for the
>> > second LDO...
> 
>> I am hoping for a Tested-By: from the one who has submitted the patch
>> for the regulator.
> 
> Or a reviewed-by from someone with access to the datasheet.
> 

I guess Pierre-Hugues should have access, as he introduced the part?

>> Well, it is not just guessing, it is there in the url I referenced. But
>> I would of course prefer a better source. At first I wanted to spread
>> my findings.
> 
> The URL you provided looked to be for a different part though?
> 
>> I am not pushing anyone to accept it without Tested-By/Reviewed-Bys.
>> What is a good way to avoid people bumping into this bug?
>> Maybe I can find the right C on the board to check.
> 
> That'd be good.  Or we could fix it by just removing enable/disable
> control for the second LDO entirely and if someone needs that control
> they can always re-add it.

We use the RN5T567 and I added support for it. Unfortunately I have no
access to the RN5T618 datasheet so I cannot tell. The RN5T567 has both
bits in marked reserved, but looking at how it the enable bit are
distributed otherwise this patch fixes it in the only way it makes
sense...

--
Stefan