Messages in this thread | | | Date | Fri, 14 Jun 2019 12:53:01 +0200 | From | Borislav Petkov <> | 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.
| |