linux-kernel - Re: [PATCH] EDAC: mv64x60 calculate memory size correctly

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:   Tue, 6 Jun 2017 21:19:04 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Borislav Petkov <bp@...en8.de>
CC:     "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] EDAC: mv64x60 calculate memory size correctly

On 07/06/17 04:55, Borislav Petkov wrote:
> On Tue, Jun 06, 2017 at 03:07:04AM +0000, Chris Packham wrote:
>> I'll wait for feedback before sending a v2.
> 
> You can't be expecting me to review PPC code reliably. :-)

Yeah sorry I should have included linuxppc-dev. Will do on v2.

I don't think the architecture matters with this particular change. It's 
just about using the appropriate APIs to look something up from the 
architecture agnostic devicetree.

Note that there is a similar pattern in altera_edac.c and cpc925_edac.c 
that could probably benefit from something like my proposed v2.

> AFAIR from the recent discussion, Michael said that the aim is to remove
> CONFIG_MV64X60 and since this driver depends on it, that would make it
> obsolete too.

Which would be reason enough for me to stop tinkering with 
mv64x60_edac.c as you suggest.

> But I don't think we've ever "hijacked" a driver and renamed it to be
> used as a driver on a different architecture - that would be just too
> unorthodox.
> 
> So if I had to decide, I'd suggest you create your own armada_edac.c or
> whatever that is and put your code there. Or, if you're going to support
> multiple Marvell chips, then call it mv_edac.c or marvell_edac.c or so
> and start building a fine driver there.
> 
> How does that sound?

"mvebu" is the current trend for this family of orion/kirkwood/armada 
SoCs. I can take mv64x60_edac.c and gut it to use as a base. That would 
also offer me the opportunity to do some of the other things I've been 
wanting to.

I'll still send out v2 of this patch and include cleanups for altera and 
cpc925 in a series. You can decide which if any to apply.