From: Borislav Petkov <bp@alien8.de>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "Luck, Tony" <tony.luck@intel.com>, Russ Anderson <rja@hpe.com>,
Greg KH <gregkh@linuxfoundation.org>,
Justin Ernst <justin.ernst@hpe.com>,
russ.anderson@hpe.com, Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
Aristeu Rozanski Filho <arozansk@redhat.com>
Subject: Raise maximum number of memory controllers
Date: Mon, 1 Oct 2018 14:47:54 +0200 [thread overview]
Message-ID: <20181001124754.GD7269@zn.tnic> (raw)
On Thu, Sep 27, 2018 at 10:10:54PM -0300, Mauro Carvalho Chehab wrote:
> I don't remember about any rationale behind /sys/bus/edac. It was
> there already before I start working on EDAC about 10 years ago.
> I guess it was used in the past by edac-utils (or maybe it is just a
> side effect of the need to create a bus on some past).
>
> Btw, The documented EDAC ABI is /sys/devices/system/edac, as
> described at Documentation/ABI/testing/sysfs-devices-edac.
>
> So, I suspect it should be safe to get rid of /sys/bus/edac,
> provided that it won't cause side effects at /sys/devices/system/edac.
>
> Why I think it is safe to get rid of /sys/bus/edac?
> ---------------------------------------------------
...
Thanks for the analysis. So yap, I think we should try to rip out the
whole bus hierarchy then, when we have a quiet minute and whoever does
this, should add your analysis to the commit message so that we know.
Thx.
next reply other threads:[~2018-10-01 12:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-01 12:47 Borislav Petkov [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-09-28 1:10 Raise maximum number of memory controllers Mauro Carvalho Chehab
2018-09-27 22:03 Borislav Petkov
2018-09-27 21:44 Luck, Tony
2018-09-27 5:56 Borislav Petkov
2018-09-27 4:52 Borislav Petkov
2018-09-26 23:02 Luck, Tony
2018-09-26 18:23 Russ Anderson
2018-09-26 18:10 Luck, Tony
2018-09-26 17:39 Mauro Carvalho Chehab
2018-09-26 16:17 Borislav Petkov
2018-09-26 16:13 Aristeu Rozanski
2018-09-26 16:03 Mauro Carvalho Chehab
2018-09-26 15:27 Borislav Petkov
2018-09-26 13:53 Russ Anderson
2018-09-26 9:35 Borislav Petkov
2018-09-26 7:55 Qiuxu Zhuo
2018-09-25 18:07 Borislav Petkov
2018-09-25 17:50 Luck, Tony
2018-09-25 15:26 Borislav Petkov
2018-09-25 14:34 Justin Ernst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181001124754.GD7269@zn.tnic \
--to=bp@alien8.de \
--cc=arozansk@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=justin.ernst@hpe.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=mchehab@kernel.org \
--cc=rja@hpe.com \
--cc=russ.anderson@hpe.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).