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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Oct 2014 10:23:17 -0500 From: Aravind Gopalakrishnan <aravind.gopalakrishnan@....com> To: Borislav Petkov <bp@...en8.de> CC: <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>, <tglx@...utronix.de>, <hpa@...or.com>, <x86@...nel.org>, <bp@...e.de>, <dan.carpenter@...cle.com>, <dougthompson@...ssion.com>, <m.chehab@...sung.com>, <linux-edac@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 4/4] edac, amd64_edac: Add F15h M60h support On 10/2/2014 9:52 AM, Borislav Petkov wrote: > On Wed, Oct 01, 2014 at 02:44:21PM -0500, Aravind Gopalakrishnan wrote: >> The more I think about this, I'm finding it's hard to do this cleanly. >> I initially thought I'd just cache this in pvt->dram_type the first time I'm >> doing this. >> But, the pvt->ops->dbam_to_cs() mappers get called first before >> determine_memory_type(). >> >> So, If I look for dram_type in f15_m60h_dbam_to_chip_select() it's ugly as >> that's really the point of >> having a determine_memory_type(). >> >> Also, there's just a lot of if-else statements in determine_memory_type() >> now. >> This could benefit from having a per-family low_ops function. >> And, we can call this early... somewhere in read_mc_regs() so that we have >> information ready to use in >> f15_m60h_dbam_to_chip_select() and in init_csrows() which needs dram_type >> too. > Right, this is what I was thinking too: somewhere in read_mc_regs(), > after having collected ->dclr0, you call determine_memory_type() and > store it into pvt->dram_type. Yep. So, let me go ahead and make these changes. Shall send out a V2 once I have an answer on the LRDIMM question.. Thanks, -Aravind. >> Oh, btw- We can do away with a pvt->dram_ctrl as >> f15_m60h_dbam_to_chip_select() really just needs the dram_type. > Yes, you make the read of DRAM_CONTROL inside determine_memory_type() as > we don't need it anywhere else. > > If we do, all of a sudden, we'll move it up to read_mc_regs(). IOW, I'm > trying to centralize all reg reads in read_mc_regs() and use locally > cached info later so I don't have to access the hardware each time > needlessly, if it can be helped. > > -- 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