From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Morse <james.morse@arm.com>, "Shenhar, Talel" <talel@amazon.com>
Cc: "Hawa, Hanna" <hhhawa@amazon.com>, Borislav Petkov <bp@alien8.de>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
"paulmck@linux.ibm.com" <paulmck@linux.ibm.com>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Chocron, Jonathan" <jonnyc@amazon.com>,
"Krupnik, Ronen" <ronenk@amazon.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"Hanoch, Uri" <hanochu@amazon.com>
Subject: Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC
Date: Sat, 08 Jun 2019 10:22:20 +1000 [thread overview]
Message-ID: <a0913966c27ee0be42796b1e49d871e7e858f6b7.camel@kernel.crashing.org> (raw)
In-Reply-To: <25efb27c-b725-137d-5735-b3ab88323846@arm.com>
On Fri, 2019-06-07 at 16:11 +0100, James Morse wrote:
> I'm coming at this from somewhere else. This stuff has to be considered all the way
> through the system. Just because each component supports error detection, doesn't mean you
> aren't going to get silent corruption. Likewise if another platform picks up two piecemeal
> edac drivers for hardware it happens to have in common with yours, it doesn't mean we're
> counting all the errors. This stuff has to be viewed for the whole platform.
Sure but you don't solve that problem by having a magic myplatform.c
overseer. And even if you do, it can perfectly access the individual IP
block drivers, finding them via phandles in the DT for example etc...
without having to make those individual drivers dependent on some over
arching machine wide probing mechanism.
> But this doesn't give you a device you can bind a driver to, to kick this stuff off.
> This (I assume) is why you added a dummy 'edac_l1_l2' node, that just probes the driver.
> The hardware is to do with the CPU and caches, 'edac_l1'_l2' doesn't correspond to any
> distinct part of the soc.
>
> The request is to use the machine compatible, not a dummy node. This wraps up the firmware
> properties too, and any other platform property we don't know about today.
>
> Once you have this, you don't really need the cpu/cache integration annotations, and your
> future memory-controller support can be picked up as part of the platform driver.
> If you have otherwise identical platforms with different memory controllers, OF gives you
> the API to match the node in the DT.
Dummy nodes are pefectly fine, and has been from the early days of Open
Firmware. That said, these aren't so much dummy as a way to expose the
control path to the caches. The DT isn't perfect in its structure and
the way caches and CPUs are represented makes it difficult to represent
arbitrary control path to them without extra nodes, which is thus what
people do.
Cheers,
Ben.
next prev parent reply other threads:[~2019-06-08 0:22 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 10:15 [PATCH 0/2] Add support for Amazon's Annapurna Labs EDAC for L1/L2 Hanna Hawa
2019-05-30 10:15 ` [PATCH 1/2] dt-bindings: EDAC: add Amazon Annapurna Labs EDAC binding Hanna Hawa
2019-05-30 11:54 ` Greg KH
2019-05-31 0:35 ` Borislav Petkov
2019-06-03 7:24 ` Woodhouse, David
2019-05-30 10:15 ` [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC Hanna Hawa
2019-05-30 11:57 ` Greg KH
2019-05-30 12:52 ` hhhawa
2019-05-30 13:04 ` Joe Perches
2019-05-30 18:19 ` Boris Petkov
2019-05-31 1:15 ` Herrenschmidt, Benjamin
2019-05-31 5:14 ` Borislav Petkov
2019-06-05 15:13 ` James Morse
2019-06-06 7:53 ` Hawa, Hanna
2019-06-06 10:03 ` Borislav Petkov
2019-06-06 10:33 ` James Morse
2019-06-06 11:22 ` Borislav Petkov
2019-06-06 11:37 ` Shenhar, Talel
2019-06-07 15:11 ` James Morse
2019-06-08 0:22 ` Benjamin Herrenschmidt [this message]
2019-06-08 0:16 ` Benjamin Herrenschmidt
2019-06-08 9:05 ` Borislav Petkov
2019-06-11 5:50 ` Benjamin Herrenschmidt
2019-06-11 7:21 ` Benjamin Herrenschmidt
2019-06-11 11:56 ` Borislav Petkov
2019-06-11 22:25 ` Benjamin Herrenschmidt
2019-06-12 3:48 ` Borislav Petkov
2019-06-12 8:29 ` Benjamin Herrenschmidt
2019-06-12 10:42 ` Borislav Petkov
2019-06-12 23:54 ` Benjamin Herrenschmidt
2019-06-13 7:44 ` Borislav Petkov
2019-06-14 10:53 ` Borislav Petkov
2019-06-12 10:42 ` Mauro Carvalho Chehab
2019-06-12 11:00 ` Borislav Petkov
2019-06-12 11:42 ` Mauro Carvalho Chehab
2019-06-12 11:57 ` Benjamin Herrenschmidt
2019-06-12 12:25 ` Borislav Petkov
2019-06-12 12:35 ` Hawa, Hanna
2019-06-12 15:34 ` Borislav Petkov
2019-06-12 23:57 ` Benjamin Herrenschmidt
2019-06-12 23:56 ` Benjamin Herrenschmidt
2019-06-11 7:29 ` Hawa, Hanna
2019-06-11 11:59 ` Borislav Petkov
2019-06-11 11:47 ` Borislav Petkov
2019-06-03 6:56 ` Hawa, Hanna
2019-06-05 15:16 ` James Morse
2019-06-11 19:56 ` Hawa, Hanna
2019-06-13 17:05 ` James Morse
2019-06-14 10:49 ` James Morse
2019-06-17 13:00 ` Hawa, Hanna
2019-06-19 17:22 ` James Morse
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=a0913966c27ee0be42796b1e49d871e7e858f6b7.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hanochu@amazon.com \
--cc=hhhawa@amazon.com \
--cc=james.morse@arm.com \
--cc=jonnyc@amazon.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=paulmck@linux.ibm.com \
--cc=robh+dt@kernel.org \
--cc=ronenk@amazon.com \
--cc=talel@amazon.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).