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: <54C66589.3040505@atmel.com>
Date:	Mon, 26 Jan 2015 17:04:25 +0100
From:	Nicolas Ferre <nicolas.ferre@...el.com>
To:	Peter Rosin <peda@...ntia.se>,
	Sylvain Rochet <sylvain.rochet@...secur.com>,
	Wenyou Yang <wenyou.yang@...el.com>
CC:	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"alexandre.belloni@...e-electrons.com" 
	<alexandre.belloni@...e-electrons.com>
Subject: Re: [PATCH v2 02/12] pm: at91: Workaround DDRSDRC self-refresh bug
 with LPDDR1 memories.

Le 26/01/2015 16:58, Peter Rosin a écrit :
> Sylvain Rochet wrote:
>> Hello Nicolas,
>>
>> On Mon, Jan 26, 2015 at 02:34:38PM +0100, Nicolas Ferre wrote:
>>> Le 26/01/2015 11:36, Sylvain Rochet a écrit :
>>>>
>>>> I think we should explain we are dealing with an errata here, this
>>>> is not obvious at first sight, the patch summary may find its place
>>>> here :-)
>>>
>>> True but the problem is that this errata is not public yet, it will be
>>> in a couple of weeks.
>>>
>>> I have the feeling though that the commit message is pretty clear.
>>> We'll maybe add that it"s an actual errata.
>>
>> Humm, this is not what I meant actually. I only proposed a code source
>> comment explaining why this is done this way, the current patch summary
>> looked like it will be perfect between /* */ ;-)
> 
> I did not want to fill up the source with wordy comments, and settled
> for a one-liner. I don't know much about the underlying reasons other
> than the fact that LPDDR1 mode of the controller isn't working properly
> in self-refresh and that the DDR2 spec is similar enough to work.
> 
> The one-liner comment says about the same thing, but not with so
> many words. The comment does make it clear that the switch to DDR2
> is intentional, and that is all that is needed as protection from some
> future cleanup. I mean, anyone seeing that comment and just erasing
> the whole thing without further investigation is not doing a very good
> job as there is no reason to intentionally switch from LPDDR1 mode to
> DDR2 mode, other that the fact that the LPDDR1 mode isn't working for
> some reason. That reason is not to be found in the commit message
> and I have no information to improve the situation. IMO, the only thing
> missing is a pointer to the as yet unreleased errata, which should explain
> the situation clearly for any and all interested parties. May I suggest that
> someone who cares sends a patch with the comment update when the
> errata is released?

That's the option that I'll take.

Let's go for it (and anyone remind me if I don't when the errata is
released).

Bye,


> If others feel differently, by all means please reword and expand the
> comment.
> 
> Cheers,
> Peter
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ