H. Peter Anvin wrote:
> In article <3E6EA909.9020200@pobox.com> of
> linux.dev.kernel, you write:
>
>>diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig
>>--- a/drivers/char/Kconfig Tue Mar 11 21:37:50 2003
>>+++ b/drivers/char/Kconfig Tue Mar 11 21:37:50 2003
>>@@ -710,7 +710,7 @@
>> If you're not sure, say N.
>>
>> config HW_RANDOM
>>- tristate "Intel/AMD H/W Random Number Generator support"
>>+ tristate "Intel/AMD/Via H/W Random Number Generator support"
>> depends on (X86 || IA64) && PCI
>> ---help---
>> This driver provides kernel-side support for the Random Number
>
>
>
> How about changing this to "HW Random Number Generator"?
easily done.
>>+static inline u32 xstore(u32 *addr, u32 edx_in)
>>+{
>>+ u32 eax_out;
>>+
>>+ asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
>>+ :"=m"(*addr), "=a"(eax_out)
>>+ :"D"(addr), "d"(edx_in));
>>+
>>+ return eax_out;
>>+}
>
>
> Note that your "=m" (*addr) is never actually used here -- it doesn't
> affect the instruction encoding, and it only shows up in a comment.
> Since gcc will generate an instruction mode here, it will be highly
> confused.
>
> I am assuming 0xC0 is a modr/m byte, in which case the most sane
> interpretation of this instruction would be "xstore %eax"; %edi is
> presumably implicit since you claim it can take a REP prefix...
and yet strangely the asm code seems to be correct :)
.p2align 4,,15
.type via_data_present,@function
via_data_present:
pushl %edi
xorl %edi, %edi # zero edi
movl $3, %edx # edx_in
movl %edi, via_rng_datum # zero via_rng_datum
movl $via_rng_datum, %edi # addr
#APP
.byte 0x0F,0xA7,0xC0 /* xstore %edi (addr=via_rng_datum) */
#NO_APP
popl %edi
andl $15, %eax # eax_out
setne %al
movzbl %al, %eax
ret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:29 EST