Message-ID: <20190614105301.GB2586@zn.tnic>
Date:   Fri, 14 Jun 2019 12:53:01 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     James Morse <james.morse@....com>,
        "Hawa, Hanna" <hhhawa@...zon.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "Shenhar, Talel" <talel@...zon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Chocron, Jonathan" <jonnyc@...zon.com>,
        "Krupnik, Ronen" <ronenk@...zon.com>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "Hanoch, Uri" <hanochu@...zon.com>
Subject: Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC

Reply part 2.

On Thu, Jun 13, 2019 at 09:54:18AM +1000, Benjamin Herrenschmidt wrote:
> Why ? Because one or two historical drivers mix MC and PCI then "it
> makes sense" to do that for everybody ?

Because it was like that. And now all of a sudden ARM wants something
different. So we must at least talk about it before we do it, right?

Also, I don't know if you've noticed but RAS "architecture" on Linux is
still a big WIP, to put it mildly. So before we do anything, we should
have at least some rough idea of where it is all going to.

> And then you have 20 platforms and 20 drivers, with 50% or more code
> duplication, bugs fixed in one and not the other, gratuituous behaviour
> differences to confuse users etc... No. that doesn't make sense.

No different on ARM if you have a memory controller IP which is roughly
the same IP but different vendors integrate it and they each tweak it
a bit in their own way (registers, ECC support, etc) and you get an
EDAC MC driver from every vendor and they all don't share the basic
functionality.

> I have no idea what "the DT argument" is, and that's from the guy who
> created the FDT....
> 
> I have difficulties understanding how you cannot see that having re-
> usable single drivers for a single piece of HW makes sense. If anything
> in term of avoiding duplication, bitrot, bugs being fixed in some and
> not others, etc etc... It also means more eyes on a given piece of code
> which is a good thing.
> 
> Also you "have heard more than enough" is again a sign that a whole lot
> of people are trying to tell you something that you seem to refuse to
> hear.

Hmm, I think I'm hearing it. But not without good arguments for why
we're going to do it. I believe that became clear so far..

> Whatever that "DT argument" is, did you just ignore it or had
> some good and solid arguments of your own to refute it ?

I don't care about refuting it or not - all I care about is getting good
arguments for why we should do this driver-per-IP-block thing. EDAC was
was ok so far - I wasn't going to change it just because someone is
sending me drivers per-IP block and not selling me the idea properly.

And AFAIR I haven't heard a single good argument trying to convince me
why it should be done this way. Only after this thread started and we
started poking at it, I got some good arguments.

So enough wasting time, I think we can try the per-IP things and see
where it would get us.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists