All of lore.kernel.org
 help / color / mirror / Atom feed
From: Udo van den Heuvel <udovdh@xs4all.nl>
To: Dave Jones <davej@redhat.com>,
	Udo van den Heuvel <udovdh@xs4all.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Michael Buesch <mb@bu3sch.de>,
	folkert van Heusden <folkert@vanheusden.com>
Subject: Re: enable dual rng on VIA C7
Date: Tue, 27 Nov 2007 17:08:26 +0100	[thread overview]
Message-ID: <474C40FA.1070501@xs4all.nl> (raw)
In-Reply-To: <20071126185843.GD15764@redhat.com>

Dave Jones wrote:
> On Mon, Nov 26, 2007 at 06:02:39PM +0100, Udo van den Heuvel wrote:
> 
>  > I did not know we are already that far ;-)
>  > I mean: can this patch be aplied without hurting C3/C7 CPU's with just
>  > one RNG? Maybe an expert needs to test/answer?
>  > Maybe some logic needs to be applied around the extra bit?
>  
>>From the padlock spec..
> 
> "SRC Bits[9:8] Noise source select (I): These bits control the two noise
>  sources on the processor that input bits to the accumulation buffers.
>  On Nehemiah processors prior to stepping 8, these bits are reserved
>  and undefined. The default RESET state is both bits = 0." 
> 
> Something like this perhaps ?

Yes, I think that's a big step in the right direction!

But I am no expert and cannot really judge how necessary or correct the
implementation is w.r.t. the 'undefined' function bits for CPU's that
lack a certain feature.

  reply	other threads:[~2007-11-27 16:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-11 18:49 enable dual rng on VIA C7 Udo van den Heuvel
2007-11-26  7:39 ` Andrew Morton
2007-11-26 17:02   ` Udo van den Heuvel
2007-11-26 18:58     ` Dave Jones
2007-11-27 16:08       ` Udo van den Heuvel [this message]
2007-11-27 18:50         ` Dave Jones
2007-11-27 19:01           ` Udo van den Heuvel
2007-11-27 20:51           ` Andrew Morton
2007-12-01 16:51             ` Udo van den Heuvel
2008-01-25 19:03             ` Udo van den Heuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474C40FA.1070501@xs4all.nl \
    --to=udovdh@xs4all.nl \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=folkert@vanheusden.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.