Raise maximum number of memory controllers

[Borislav Petkov <bp@alien8.de>]

On Thu, Sep 27, 2018 at 02:44:01PM -0700, Luck, Tony wrote:
> The problem with your patch that gets rid of EDAC_MAX_MCS is making
> device links under /sys/bus/edac.  Which is hinted at in some of the
> code your patch deleted:
> 
> -       /*
> -        * The memory controller needs its own bus, in order to avoid
> -        * namespace conflicts at /sys/bus/edac.
> -        */
> -       name = kasprintf(GFP_KERNEL, "mc%d", mci->mc_idx);
> -       if (!name)
> -               return -ENOMEM;
> -
> -       mci->bus->name = name;

Yes, and that needed to go because I am using a single bus. Which kinda
makes sense because you want to have a single bus and multiple devices
on it. I mean, if we *have* to have a bus.

I think this whole /sys/bus/edac thing is crap and needs to go. We
have a perfectly fine hierarchy under /sys/devices/system/edac and
duplicating it under /sys/bus/edac is just bollocks. IMHO. Feel free to
correct me with, but but, this is useful for...

> which seemed to work.

Right.

> But then I began wondering what are ABI expectations
> from applications that read the EDAC /sys files?
> 
> Is this this current source repository?  https://github.com/grondo/edac-utils
> 
> This code doesn't seem to know about the "dimm*" directories below the
> "mc*" level. It just looks for the csrow* entries.

I guess this is a question for Mauro. I never really needed any special
edac tool to get info and if you ask me, we probably should try to keep
it simple and grep sysfs. So that you can always get the info without
having to install any special tools. Like ftrace works on every system
with just a shell and basic tools. I think this is very powerful. But
this is old spartan me only thinking out loud.

In any case, I'm more than fine with dropping the bus hierarchy if
nothing uses it.

Thx.