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]
Message-ID: <25f0d55696be463def622a37a1f2b826@agner.ch>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ