linux-kernel - Re: [PATCH v2] arm: remove unused code in delay.S

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] [day] [month] [year] [list]

Message-Id: <1253226304.3273.249.camel@linux-1lbu>
Date:	Thu, 17 Sep 2009 17:25:04 -0500
From:	Steve Chen <schen@...sta.com>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	linux-kernel@...r.kernel.org, Marek Vasut <marek.vasut@...il.com>,
	Pavel Machek <pavel@....cz>,
	linux-arm-kernel@...ts.infradead.org,
	Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH v2] arm: remove unused code in delay.S

On Thu, 2009-09-17 at 22:37 +0100, Jamie Lokier wrote:
> Steve Chen wrote:
> > +	help
> > +	  Enable this if observing longer than expected delays.  This code
> > +	  improves delay accuracy for some CPUs.  However, it can also cause
> > +	  delay duration to be too short for others which leads to stability
> > +	  issues.
> > +
> > +	  In other words, do not enable unless you can guarantee that the
> > +	  processor (or ALL of the processors if building a generic kernel)
> > +	  delays for at least the time requested after enabling.
> > +
> >  endmenu
> 
> It would be very helpful to mention which CPUs are affected.
> Ok, we don't know exactly...
> 
> But Russell has stated that ARM610 and ARM710 benefit from enabling
> the code, and that it specifically must not be enabled for StrongARM.
> 
> Here's an additional paragraph to add on the end:
> 
> 	ARM610 and ARM710 are known to benefit from enabling this option.
> 	It should not be enabled for StrongARMs, because it is known
> 	to produce too short delays on those.
> 
Sure, I can add this paragraph in the next revision.

> Maybe you can adjust the config selectors and default to match?

I'm not sure about this one.  For one thing, in the last e-mail between
you and Russel I saw

>> Btw, do you know where PT110 fits in?  Is it like StrongARM (SA110)?
> No idea.

Not to mention the difficulties to account for all the possible
permutations for kernels that is built for multiple CPUs.  Perhaps we
can start a list of the processors that should have this flag enabled
and the list of processors should have the flag disabled (instead of the
paragraph you suggested).  This way, people can just add to the list as
they experiment with this flag on whatever CPU version that they worked
on.

Regards,

Steve

--
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/