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]
Date:	Mon, 20 Oct 2008 16:32:28 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	dougthompson@...ssion.com
Cc:	mitake@...stcom.com, dougthompson@...ssion.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] edac x38: new MC driver module

On Fri, 17 Oct 2008 15:39:45 -0600
dougthompson@...ssion.com wrote:

> From: Hitoshi Mitake <mitake@...stcom.com>
> 
> I wrote a new module for Intel X38 chipset.
> This chipset is very similar to Intel 3200 chipset,
> but there are some different points,
> so I copyed i3200_edac.c and modified.
> 
> This is a Intel's web page describing this chipset.
> http://www.intel.com/Products/Desktop/Chipsets/X38/X38-overview.htm
> 
> I've tested this new module with broken memory,
> and it seems working well.
> 
> This is a patch, please use.
> Hitoshi
> 
> Signed-off-by: Hitoshi Mitake <mitake@...stcom.com>
> Signed-off-by: Doug Thompson <dougthompson@...ssion.com>
> ---
> 
> Index: linux-2.6.27/drivers/edac/Kconfig
> ===================================================================
> --- linux-2.6.27.orig/drivers/edac/Kconfig
> +++ linux-2.6.27/drivers/edac/Kconfig
> @@ -102,6 +102,13 @@ config EDAC_I3000
>  	  Support for error detection and correction on the Intel
>  	  3000 and 3010 server chipsets.
>  
> +config EDAC_X38
> +	tristate "Intel X38"
> +	depends on EDAC_MM_EDAC && PCI && X86
> +	help
> +	  Support for error detection and correction on the Intel
> +	  X38 server chipsets.

Is this truly X86, or will this driver only ever be used on x86_64 kernels?

>
> ...
>
> +static u64 x38_readq(const void __iomem *addr)
> +{
> +	return readl(addr) | (((u64)readl(addr + 4)) << 32);
> +}

Because the x86_64 architecture already implements readq(), and it
would be nice to avoid creating a private version.


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