Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Mark Rutland]

On Wed, Oct 21, 2015 at 03:41:37PM -0500, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.
> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +

To counter my original point, I now believe that the MIDR alone is
woefully insufficient to detect if we can use this feature. That needs
to be described explicitly to us (e.g. via DT), or the feature needs to
be abstracted entirely (e.g. using APEI).

More on that below.

> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };

As I mentioned previously, this is _not_ an ARMv8 feature. It's not a
Cortex-A series feature (nor a Cortex series feature).

This is an IMPLEMENTATION DEFINED feature. If we need compatible
strings, we need one for each particular implementation, as we have for
the IMPLEMENTATION DEFINED PMU bindings (e.g. "arm,cortex-a57-pmu"). For
ACPI I expect vendors to implement APEI.

We also need to consider:

* big.LITTLE and/or multi-cluster
  - Describe _which_ CPUs have the feature
  - Describe the affinity of any interrupts
  - Do we need to describe cluster topology (i.e. which CPUs are in the
same cluster)?

* Virtualization
  - HCR_EL2.TIDCP will trap access to this feature, and hypervisors will
have to set this to prevent guests from corrupting the HW state. As
far as I am aware, KVM and/or Xen will likely kill the guest in this
case (e.g. by injecting an undefined instruction abort).

* Interaction with firmware
  - When/do we handle interrupts?
  - When is it valid to write back and clear an error? We should not do
this behind the back of any firmware that owns the interface.

* Future CPU revisions.
  - The feature is IMPLEMENTATION DEFINED, and has no discoverability
mechanism. We have no guarantee that future revisions of the CPUs
currently supporting the feature will continue to support the
feature and/or have a compatible interface. Handling this is
painful.

We shy from using IMPLEMENTATION DEFINED features because of issues like
these. Ideally, this would all be left to firmware, and handled with a
generic interface like APEI.

Thanks,
Mark.

> +
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Mark Rutland]

On Wed, Oct 21, 2015 at 03:41:37PM -0500, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.
> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +

To counter my original point, I now believe that the MIDR alone is
woefully insufficient to detect if we can use this feature. That needs
to be described explicitly to us (e.g. via DT), or the feature needs to
be abstracted entirely (e.g. using APEI).

More on that below.

> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };

As I mentioned previously, this is _not_ an ARMv8 feature. It's not a
Cortex-A series feature (nor a Cortex series feature).

This is an IMPLEMENTATION DEFINED feature. If we need compatible
strings, we need one for each particular implementation, as we have for
the IMPLEMENTATION DEFINED PMU bindings (e.g. "arm,cortex-a57-pmu"). For
ACPI I expect vendors to implement APEI.

We also need to consider:

* big.LITTLE and/or multi-cluster
  - Describe _which_ CPUs have the feature
  - Describe the affinity of any interrupts
  - Do we need to describe cluster topology (i.e. which CPUs are in the
same cluster)?

* Virtualization
  - HCR_EL2.TIDCP will trap access to this feature, and hypervisors will
have to set this to prevent guests from corrupting the HW state. As
far as I am aware, KVM and/or Xen will likely kill the guest in this
case (e.g. by injecting an undefined instruction abort).

* Interaction with firmware
  - When/do we handle interrupts?
  - When is it valid to write back and clear an error? We should not do
this behind the back of any firmware that owns the interface.

* Future CPU revisions.
  - The feature is IMPLEMENTATION DEFINED, and has no discoverability
mechanism. We have no guarantee that future revisions of the CPUs
currently supporting the feature will continue to support the
feature and/or have a compatible interface. Handling this is
painful.

We shy from using IMPLEMENTATION DEFINED features because of issues like
these. Ideally, this would all be left to firmware, and handled with a
generic interface like APEI.

Thanks,
Mark.

> +
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Hanjun Guo]

On 2015/10/24 1:58, Brijesh Singh wrote:
>> So I checked the x86 code: the driver is always loaded as soon as the
>> hardware is there (looking at PCI device IDs from the on-chip
>> northbridge, for instance). The trick here is to have the Kconfig option
>> defaulting to "=n", so a kernel builder would have to explicitly enable
>> this. Android or embedded kernels wouldn't do this, for instance, while
>> a server distribution would do.
>> If a user doesn't want to be bothered with the driver, there is always
>> the possibility of blacklisting the module.
>> Setting a system policy is IMHO out of scope for a DT binding.
>>
> Will update Kconfig to make it n by default.
>
 * Its possible that other SoC's might handle single-bit and double-bit 
 errors differently compare to 
   Seattle platform. In Seattle platform both errors are handled by 
 firmware but if other SoC 
   wants OS to handle these errors then they might need DT binding to 
 provide the irq numbers etc.
>> What do you mean exactly with "firmware handles these errors"?
>> What would the firmware do? I guess just logging the error and then
>> possibly reset the register? How would this change the driver?
>>
> On Seattle platform SoC generates a interrupt on both single bit and double 
> bit error
> and that interrupt is handled by firmware, so we don't need to do anything in 
> the driver.
> Driver just need to poll registers to log correctable errors (because they do 
> not generate interrupt).
> This very driver is doing exactly what we want. DT binding is not required.
>
> But Hanjun's comment on very first patch hinted me that there is possibility 
> that
> SoC generate a interrupt on single bit and double bit but firmware does not 
> handle it.
> In those cases driver will need be extended to handle interrupt.

yes, exactly.

>
> I will submit v3 for review with DT binding removed. We can revisit DT 
> binding need in future.
>
>>> I totally agree with you here,  thanks for putting them together.
>>> Different SoCs may handle the error in different ways, we need
>>> bindings to specialize them, irq number is a good example :)
>> But how does this affect this very driver, polling just those two registers?
>> Where would the interrupt come into the game here? Where is the proposed
>> DT binding for that interrupt?
>>
>> AFAICT EL3 firmware handling errors would just hide this information
>> from the driver, so if the f/w decides to "handle" uncorrectable ECC
>> errors in a fatal way, there is nothing the driver could do anyway, right?

Yes, if EL3 firmware is involved, the driver don't need to handle such 
interrupt.

>>
>> Can you sketch a concrete example where we would actually need the
>> driver to know about the firmware capabilities?

So if firmware don't handle it, just like the APM xgene did in xgene_edac.c, we
need handle it in the driver, then DT bindings with irq number are needed.
You know, I'm working on ACPI and will enthusiastically encourage people using
APEI with firmware handle error first :) , but I think we can't rule out such
cases (driver handle the errors).

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

> So I checked the x86 code: the driver is always loaded as soon as the
> hardware is there (looking at PCI device IDs from the on-chip
> northbridge, for instance). The trick here is to have the Kconfig option
> defaulting to "=n", so a kernel builder would have to explicitly enable
> this. Android or embedded kernels wouldn't do this, for instance, while
> a server distribution would do.
> If a user doesn't want to be bothered with the driver, there is always
> the possibility of blacklisting the module.
> Setting a system policy is IMHO out of scope for a DT binding.
> 
Will update Kconfig to make it n by default.

>>> * Its possible that other SoC's might handle single-bit and double-bit 
>>> errors differently compare to 
>>>   Seattle platform. In Seattle platform both errors are handled by firmware 
>>> but if other SoC 
>>>   wants OS to handle these errors then they might need DT binding to 
>>> provide the irq numbers etc.
> 
> What do you mean exactly with "firmware handles these errors"?
> What would the firmware do? I guess just logging the error and then
> possibly reset the register? How would this change the driver?
> 
On Seattle platform SoC generates a interrupt on both single bit and double bit 
error
and that interrupt is handled by firmware, so we don't need to do anything in 
the driver.
Driver just need to poll registers to log correctable errors (because they do 
not generate interrupt).
This very driver is doing exactly what we want. DT binding is not required.

But Hanjun's comment on very first patch hinted me that there is possibility 
that
SoC generate a interrupt on single bit and double bit but firmware does not 
handle it.
In those cases driver will need be extended to handle interrupt.

I will submit v3 for review with DT binding removed. We can revisit DT binding 
need in future.

>> I totally agree with you here,  thanks for putting them together.
>> Different SoCs may handle the error in different ways, we need
>> bindings to specialize them, irq number is a good example :)
> 
> But how does this affect this very driver, polling just those two registers?
> Where would the interrupt come into the game here? Where is the proposed
> DT binding for that interrupt?
> 
> AFAICT EL3 firmware handling errors would just hide this information
> from the driver, so if the f/w decides to "handle" uncorrectable ECC
> errors in a fatal way, there is nothing the driver could do anyway, right?
> 
> Can you sketch a concrete example where we would actually need the
> driver to know about the firmware capabilities?
> 
> Cheers,
> Andre.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Stephen Boyd]

Drive by nitpicks

On 10/21, Brijesh Singh wrote:
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> +
> +#define L1_CACHE  0
> +#define L2_CACHE  1
> +
> +int poll_msec = 100;

static?

> +
> +struct cortex_arm64_edac {
> + struct edac_device_ctl_info *edac_ctl;
> +};
[..]
> +
> +static int cortex_arm64_edac_probe(struct platform_device *pdev)
> +{
> + int rc;
> + struct cortex_arm64_edac *drv;
> + struct device *dev = >dev;
> +
> + drv = devm_kzalloc(dev, sizeof(*drv), GFP_KERNEL);
> + if (!drv)
> + return -ENOMEM;
> +
> + drv->edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
> +num_possible_cpus(), "L", 2,
> +1, NULL, 0,
> +edac_device_alloc_index());
> + if (IS_ERR(drv->edac_ctl))
> + return -ENOMEM;
> +
> + drv->edac_ctl->poll_msec = poll_msec;
> + drv->edac_ctl->edac_check = arm64_monitor_cache_errors;
> + drv->edac_ctl->dev = dev;
> + drv->edac_ctl->mod_name = dev_name(dev);
> + drv->edac_ctl->dev_name = dev_name(dev);
> + drv->edac_ctl->ctl_name = "cpu_err";
> + drv->edac_ctl->panic_on_ue = 1;
> + platform_set_drvdata(pdev, drv);
> +
> + rc = edac_device_add_device(drv->edac_ctl);
> + if (rc)
> + goto edac_alloc_failed;
> +
> + return 0;
> +
> +edac_alloc_failed:
> + edac_device_free_ctl_info(drv->edac_ctl);
> + return rc;

Simplify to:

rc = edac_device_add_device(...
if (rc)
edac_device_free_ctl_info(..

return rc;

> +}
> +
> +
> +static const struct of_device_id cortex_arm64_edac_of_match[] = {
> + { .compatible = "arm,armv8-edac" },
> + {},

Dropping the comma here is good style because it forces us to add
a comma if we were to add an element after the sentinel,
hopefully causing us to question why we're doing that in the
first place.

> +};
> +MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
> +
> +static struct platform_driver cortex_arm64_edac_driver = {
> + .probe = cortex_arm64_edac_probe,
> + .remove = cortex_arm64_edac_remove,
> + .driver = {
> + .name = "arm64-edac",
> + .owner = THIS_MODULE,

platform_driver_register() sets this so we can drop this
assignment here.

> + .of_match_table = cortex_arm64_edac_of_match,
> + },
> +};
> +
> +static int __init cortex_arm64_edac_init(void)
> +{
> + int rc;
> +
> + /* Only POLL mode is supported so far */
> + edac_op_state = EDAC_OPSTATE_POLL;
> +
> + rc = platform_driver_register(_arm64_edac_driver);
> + if (rc) {
> + edac_printk(KERN_ERR, EDAC_MOD_STR, "failed to register\n");
> + return rc;
> + }
> +
> + return 0;

This could be simplified to

rc = ...
if (rc)
edac_printk(...

return rc;

Or even just 'return platform_driver_register()' and not care
about printing a message in that case because the end-user can't
do anything with the message anyway.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Andre Przywara]

On 23/10/15 02:41, Hanjun Guo wrote:
> Hi Brijesh,
> 
> On 2015/10/22 22:46, Brijesh Singh wrote:
>> Hi Andre,
>>
>> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>>> On 21/10/15 21:41, Brijesh Singh wrote:
 Add support for Cortex A57 and A53 EDAC driver.
>>> Hi Brijesh,
>>>
>>> thanks for the quick update! Some comments below.
>>>
 Signed-off-by: Brijesh Singh 
 CC: robh...@kernel.org
 CC: pawel.m...@arm.com
 CC: mark.rutl...@arm.com
 CC: ijc+devicet...@hellion.org.uk
 CC: ga...@codeaurora.org
 CC: dougthomp...@xmission.com
 CC: b...@alien8.de
 CC: mche...@osg.samsung.com
 CC: devicet...@vger.kernel.org
 CC: guohan...@huawei.com
 CC: andre.przyw...@arm.com
 CC: a...@arndb.de
 CC: linux-kernel@vger.kernel.org
 CC: linux-e...@vger.kernel.org
 ---

 v2:
 * convert into generic arm64 edac driver
 * remove AMD specific references from dt binding
 * remove poll_msec property from dt binding
 * add poll_msec as a module param, default is 100ms
 * update copyright text
 * define macro mnemonics for L1 and L2 RAMID
 * check L2 error per-cluster instead of per core
 * update function names
 * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
   read hotplug-safe
 * add error check in probe routine

  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
  drivers/edac/Kconfig   |   6 +
  drivers/edac/Makefile  |   1 +
  drivers/edac/cortex_arm64_edac.c   | 457 
 +
  4 files changed, 479 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
  create mode 100644 drivers/edac/cortex_arm64_edac.c

 diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
 b/Documentation/devicetree/bindings/edac/armv8-edac.txt
 new file mode 100644
 index 000..dfd128f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
 @@ -0,0 +1,15 @@
 +* ARMv8 L1/L2 cache error reporting
 +
 +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
 +Register can be used for checking L1 and L2 memory errors.
 +
 +The following section describes the ARMv8 EDAC DT node binding.
 +
 +Required properties:
 +- compatible: Should be "arm,armv8-edac"
 +
 +Example:
 +  edac {
 +  compatible = "arm,armv8-edac";
 +  };
 +
>>> So if there is nothing in here, why do we need the DT binding at all (I
>>> think Mark hinted at that already)?
>>> Can't we just use the MIDR as already suggested by others?
>>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>>> specific and not architectural.
>>>
>> Yes, I was going with Mark suggestion to remove DT binding but then came 
>> across these cases which kind of hinted to keep DT binding:
>>
>> * Without DT binding, the driver will always be loaded on arm64 unless its 
>> blacklisted.

So I checked the x86 code: the driver is always loaded as soon as the
hardware is there (looking at PCI device IDs from the on-chip
northbridge, for instance). The trick here is to have the Kconfig option
defaulting to "=n", so a kernel builder would have to explicitly enable
this. Android or embedded kernels wouldn't do this, for instance, while
a server distribution would do.
If a user doesn't want to be bothered with the driver, there is always
the possibility of blacklisting the module.
Setting a system policy is IMHO out of scope for a DT binding.

>> * Its possible that other SoC's might handle single-bit and double-bit 
>> errors differently compare to 
>>   Seattle platform. In Seattle platform both errors are handled by firmware 
>> but if other SoC 
>>   wants OS to handle these errors then they might need DT binding to provide 
>> the irq numbers etc.

What do you mean exactly with "firmware handles these errors"?
What would the firmware do? I guess just logging the error and then
possibly reset the register? How would this change the driver?

> I totally agree with you here,  thanks for putting them together.
> Different SoCs may handle the error in different ways, we need
> bindings to specialize them, irq number is a good example :)

But how does this affect this very driver, polling just those two registers?
Where would the interrupt come into the game here? Where is the proposed
DT binding for that interrupt?

AFAICT EL3 firmware handling errors would just hide this information
from the driver, so if the f/w decides to "handle" uncorrectable ECC
errors in a fatal way, there is nothing the driver could do anyway, right?

Can you sketch a concrete example where we would actually need the
driver to know about the firmware capabilities?

Cheers,
Andre.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

> So I checked the x86 code: the driver is always loaded as soon as the
> hardware is there (looking at PCI device IDs from the on-chip
> northbridge, for instance). The trick here is to have the Kconfig option
> defaulting to "=n", so a kernel builder would have to explicitly enable
> this. Android or embedded kernels wouldn't do this, for instance, while
> a server distribution would do.
> If a user doesn't want to be bothered with the driver, there is always
> the possibility of blacklisting the module.
> Setting a system policy is IMHO out of scope for a DT binding.
> 
Will update Kconfig to make it n by default.

>>> * Its possible that other SoC's might handle single-bit and double-bit 
>>> errors differently compare to 
>>>   Seattle platform. In Seattle platform both errors are handled by firmware 
>>> but if other SoC 
>>>   wants OS to handle these errors then they might need DT binding to 
>>> provide the irq numbers etc.
> 
> What do you mean exactly with "firmware handles these errors"?
> What would the firmware do? I guess just logging the error and then
> possibly reset the register? How would this change the driver?
> 
On Seattle platform SoC generates a interrupt on both single bit and double bit 
error
and that interrupt is handled by firmware, so we don't need to do anything in 
the driver.
Driver just need to poll registers to log correctable errors (because they do 
not generate interrupt).
This very driver is doing exactly what we want. DT binding is not required.

But Hanjun's comment on very first patch hinted me that there is possibility 
that
SoC generate a interrupt on single bit and double bit but firmware does not 
handle it.
In those cases driver will need be extended to handle interrupt.

I will submit v3 for review with DT binding removed. We can revisit DT binding 
need in future.

>> I totally agree with you here,  thanks for putting them together.
>> Different SoCs may handle the error in different ways, we need
>> bindings to specialize them, irq number is a good example :)
> 
> But how does this affect this very driver, polling just those two registers?
> Where would the interrupt come into the game here? Where is the proposed
> DT binding for that interrupt?
> 
> AFAICT EL3 firmware handling errors would just hide this information
> from the driver, so if the f/w decides to "handle" uncorrectable ECC
> errors in a fatal way, there is nothing the driver could do anyway, right?
> 
> Can you sketch a concrete example where we would actually need the
> driver to know about the firmware capabilities?
> 
> Cheers,
> Andre.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Andre Przywara]

On 23/10/15 02:41, Hanjun Guo wrote:
> Hi Brijesh,
> 
> On 2015/10/22 22:46, Brijesh Singh wrote:
>> Hi Andre,
>>
>> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>>> On 21/10/15 21:41, Brijesh Singh wrote:
 Add support for Cortex A57 and A53 EDAC driver.
>>> Hi Brijesh,
>>>
>>> thanks for the quick update! Some comments below.
>>>
 Signed-off-by: Brijesh Singh 
 CC: robh...@kernel.org
 CC: pawel.m...@arm.com
 CC: mark.rutl...@arm.com
 CC: ijc+devicet...@hellion.org.uk
 CC: ga...@codeaurora.org
 CC: dougthomp...@xmission.com
 CC: b...@alien8.de
 CC: mche...@osg.samsung.com
 CC: devicet...@vger.kernel.org
 CC: guohan...@huawei.com
 CC: andre.przyw...@arm.com
 CC: a...@arndb.de
 CC: linux-kernel@vger.kernel.org
 CC: linux-e...@vger.kernel.org
 ---

 v2:
 * convert into generic arm64 edac driver
 * remove AMD specific references from dt binding
 * remove poll_msec property from dt binding
 * add poll_msec as a module param, default is 100ms
 * update copyright text
 * define macro mnemonics for L1 and L2 RAMID
 * check L2 error per-cluster instead of per core
 * update function names
 * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
   read hotplug-safe
 * add error check in probe routine

  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
  drivers/edac/Kconfig   |   6 +
  drivers/edac/Makefile  |   1 +
  drivers/edac/cortex_arm64_edac.c   | 457 
 +
  4 files changed, 479 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
  create mode 100644 drivers/edac/cortex_arm64_edac.c

 diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
 b/Documentation/devicetree/bindings/edac/armv8-edac.txt
 new file mode 100644
 index 000..dfd128f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
 @@ -0,0 +1,15 @@
 +* ARMv8 L1/L2 cache error reporting
 +
 +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
 +Register can be used for checking L1 and L2 memory errors.
 +
 +The following section describes the ARMv8 EDAC DT node binding.
 +
 +Required properties:
 +- compatible: Should be "arm,armv8-edac"
 +
 +Example:
 +  edac {
 +  compatible = "arm,armv8-edac";
 +  };
 +
>>> So if there is nothing in here, why do we need the DT binding at all (I
>>> think Mark hinted at that already)?
>>> Can't we just use the MIDR as already suggested by others?
>>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>>> specific and not architectural.
>>>
>> Yes, I was going with Mark suggestion to remove DT binding but then came 
>> across these cases which kind of hinted to keep DT binding:
>>
>> * Without DT binding, the driver will always be loaded on arm64 unless its 
>> blacklisted.

So I checked the x86 code: the driver is always loaded as soon as the
hardware is there (looking at PCI device IDs from the on-chip
northbridge, for instance). The trick here is to have the Kconfig option
defaulting to "=n", so a kernel builder would have to explicitly enable
this. Android or embedded kernels wouldn't do this, for instance, while
a server distribution would do.
If a user doesn't want to be bothered with the driver, there is always
the possibility of blacklisting the module.
Setting a system policy is IMHO out of scope for a DT binding.

>> * Its possible that other SoC's might handle single-bit and double-bit 
>> errors differently compare to 
>>   Seattle platform. In Seattle platform both errors are handled by firmware 
>> but if other SoC 
>>   wants OS to handle these errors then they might need DT binding to provide 
>> the irq numbers etc.

What do you mean exactly with "firmware handles these errors"?
What would the firmware do? I guess just logging the error and then
possibly reset the register? How would this change the driver?

> I totally agree with you here,  thanks for putting them together.
> Different SoCs may handle the error in different ways, we need
> bindings to specialize them, irq number is a good example :)

But how does this affect this very driver, polling just those two registers?
Where would the interrupt come into the game here? Where is the proposed
DT binding for that interrupt?

AFAICT EL3 firmware handling errors would just hide this information
from the driver, so if the f/w decides to "handle" uncorrectable ECC
errors in a fatal way, there is nothing the driver could do anyway, right?

Can you sketch a concrete example where we would actually need the
driver to know about the firmware capabilities?

Cheers,
Andre.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Stephen Boyd]

Drive by nitpicks

On 10/21, Brijesh Singh wrote:
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> +
> +#define L1_CACHE  0
> +#define L2_CACHE  1
> +
> +int poll_msec = 100;

static?

> +
> +struct cortex_arm64_edac {
> + struct edac_device_ctl_info *edac_ctl;
> +};
[..]
> +
> +static int cortex_arm64_edac_probe(struct platform_device *pdev)
> +{
> + int rc;
> + struct cortex_arm64_edac *drv;
> + struct device *dev = >dev;
> +
> + drv = devm_kzalloc(dev, sizeof(*drv), GFP_KERNEL);
> + if (!drv)
> + return -ENOMEM;
> +
> + drv->edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
> +num_possible_cpus(), "L", 2,
> +1, NULL, 0,
> +edac_device_alloc_index());
> + if (IS_ERR(drv->edac_ctl))
> + return -ENOMEM;
> +
> + drv->edac_ctl->poll_msec = poll_msec;
> + drv->edac_ctl->edac_check = arm64_monitor_cache_errors;
> + drv->edac_ctl->dev = dev;
> + drv->edac_ctl->mod_name = dev_name(dev);
> + drv->edac_ctl->dev_name = dev_name(dev);
> + drv->edac_ctl->ctl_name = "cpu_err";
> + drv->edac_ctl->panic_on_ue = 1;
> + platform_set_drvdata(pdev, drv);
> +
> + rc = edac_device_add_device(drv->edac_ctl);
> + if (rc)
> + goto edac_alloc_failed;
> +
> + return 0;
> +
> +edac_alloc_failed:
> + edac_device_free_ctl_info(drv->edac_ctl);
> + return rc;

Simplify to:

rc = edac_device_add_device(...
if (rc)
edac_device_free_ctl_info(..

return rc;

> +}
> +
> +
> +static const struct of_device_id cortex_arm64_edac_of_match[] = {
> + { .compatible = "arm,armv8-edac" },
> + {},

Dropping the comma here is good style because it forces us to add
a comma if we were to add an element after the sentinel,
hopefully causing us to question why we're doing that in the
first place.

> +};
> +MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
> +
> +static struct platform_driver cortex_arm64_edac_driver = {
> + .probe = cortex_arm64_edac_probe,
> + .remove = cortex_arm64_edac_remove,
> + .driver = {
> + .name = "arm64-edac",
> + .owner = THIS_MODULE,

platform_driver_register() sets this so we can drop this
assignment here.

> + .of_match_table = cortex_arm64_edac_of_match,
> + },
> +};
> +
> +static int __init cortex_arm64_edac_init(void)
> +{
> + int rc;
> +
> + /* Only POLL mode is supported so far */
> + edac_op_state = EDAC_OPSTATE_POLL;
> +
> + rc = platform_driver_register(_arm64_edac_driver);
> + if (rc) {
> + edac_printk(KERN_ERR, EDAC_MOD_STR, "failed to register\n");
> + return rc;
> + }
> +
> + return 0;

This could be simplified to

rc = ...
if (rc)
edac_printk(...

return rc;

Or even just 'return platform_driver_register()' and not care
about printing a message in that case because the end-user can't
do anything with the message anyway.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Hanjun Guo]

On 2015/10/24 1:58, Brijesh Singh wrote:
>> So I checked the x86 code: the driver is always loaded as soon as the
>> hardware is there (looking at PCI device IDs from the on-chip
>> northbridge, for instance). The trick here is to have the Kconfig option
>> defaulting to "=n", so a kernel builder would have to explicitly enable
>> this. Android or embedded kernels wouldn't do this, for instance, while
>> a server distribution would do.
>> If a user doesn't want to be bothered with the driver, there is always
>> the possibility of blacklisting the module.
>> Setting a system policy is IMHO out of scope for a DT binding.
>>
> Will update Kconfig to make it n by default.
>
 * Its possible that other SoC's might handle single-bit and double-bit 
 errors differently compare to 
   Seattle platform. In Seattle platform both errors are handled by 
 firmware but if other SoC 
   wants OS to handle these errors then they might need DT binding to 
 provide the irq numbers etc.
>> What do you mean exactly with "firmware handles these errors"?
>> What would the firmware do? I guess just logging the error and then
>> possibly reset the register? How would this change the driver?
>>
> On Seattle platform SoC generates a interrupt on both single bit and double 
> bit error
> and that interrupt is handled by firmware, so we don't need to do anything in 
> the driver.
> Driver just need to poll registers to log correctable errors (because they do 
> not generate interrupt).
> This very driver is doing exactly what we want. DT binding is not required.
>
> But Hanjun's comment on very first patch hinted me that there is possibility 
> that
> SoC generate a interrupt on single bit and double bit but firmware does not 
> handle it.
> In those cases driver will need be extended to handle interrupt.

yes, exactly.

>
> I will submit v3 for review with DT binding removed. We can revisit DT 
> binding need in future.
>
>>> I totally agree with you here,  thanks for putting them together.
>>> Different SoCs may handle the error in different ways, we need
>>> bindings to specialize them, irq number is a good example :)
>> But how does this affect this very driver, polling just those two registers?
>> Where would the interrupt come into the game here? Where is the proposed
>> DT binding for that interrupt?
>>
>> AFAICT EL3 firmware handling errors would just hide this information
>> from the driver, so if the f/w decides to "handle" uncorrectable ECC
>> errors in a fatal way, there is nothing the driver could do anyway, right?

Yes, if EL3 firmware is involved, the driver don't need to handle such 
interrupt.

>>
>> Can you sketch a concrete example where we would actually need the
>> driver to know about the firmware capabilities?

So if firmware don't handle it, just like the APM xgene did in xgene_edac.c, we
need handle it in the driver, then DT bindings with irq number are needed.
You know, I'm working on ACPI and will enthusiastically encourage people using
APEI with firmware handle error first :) , but I think we can't rule out such
cases (driver handle the errors).

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] EDAC: Add ARM64 EDAC

[Singh, Brijeshkumar]

Hi Steve,

Thanks for pointing the link, I have not seen that driver before; I was mainly 
looking at driver/edac/xgene_edac.c and some other arm edac drivers.  My first 
attempt was to do AMD specific edac driver to log correctable L1/L2 error but 
based on feedback I worked on v2 generic driver which now looks very similar to 
your driver, are you planning to upstream your driver ? I can work with you to 
verify it on my current hardware setup. It seems your driver also handles 
single-bit and double-bit error which I have no way to test in my current 
hardware setup. On Seattle platform most of error handling is done through 
firmware APEI except correctable L1/L2.  Let me know your thoughts. 

-Brijesh

From: Stepan Moskovchenko [step...@codeaurora.org]
Sent: Thursday, October 22, 2015 8:51 PM
To: Singh, Brijeshkumar
Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; 
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; dougthomp...@xmission.com; 
b...@alien8.de; mche...@osg.samsung.com; devicet...@vger.kernel.org; 
guohan...@huawei.com; andre.przyw...@arm.com; a...@arndb.de; 
linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org
Subject: Re: [PATCH v2] EDAC: Add ARM64 EDAC

 >>> +++ b/drivers/edac/cortex_arm64_edac.c
 >>> @@ -0,0 +1,457 @@
 >>> +/*
 >>> + * Cortex ARM64 EDAC
 >>> + *
 >>> + * Copyright (c) 2015, Advanced Micro Devices
 >>> + * Author: Brijesh Singh 
 >>> + *

>Hi Brijesh,

>Your ARM64 EDAC driver seems rather similar to the existing driver that
>is linked below. If you have indeed based your driver on this one, can
>you please provide the appropriate attribution?

>https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Stepan Moskovchenko]

>>> +++ b/drivers/edac/cortex_arm64_edac.c
>>> @@ -0,0 +1,457 @@
>>> +/*
>>> + * Cortex ARM64 EDAC
>>> + *
>>> + * Copyright (c) 2015, Advanced Micro Devices
>>> + * Author: Brijesh Singh 
>>> + *

Hi Brijesh,

Your ARM64 EDAC driver seems rather similar to the existing driver that 
is linked below. If you have indeed based your driver on this one, can 
you please provide the appropriate attribution?


https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10

Thank you
Steve

--
 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Hanjun Guo]

Hi Brijesh,

On 2015/10/22 22:46, Brijesh Singh wrote:
> Hi Andre,
>
> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>> On 21/10/15 21:41, Brijesh Singh wrote:
>>> Add support for Cortex A57 and A53 EDAC driver.
>> Hi Brijesh,
>>
>> thanks for the quick update! Some comments below.
>>
>>> Signed-off-by: Brijesh Singh 
>>> CC: robh...@kernel.org
>>> CC: pawel.m...@arm.com
>>> CC: mark.rutl...@arm.com
>>> CC: ijc+devicet...@hellion.org.uk
>>> CC: ga...@codeaurora.org
>>> CC: dougthomp...@xmission.com
>>> CC: b...@alien8.de
>>> CC: mche...@osg.samsung.com
>>> CC: devicet...@vger.kernel.org
>>> CC: guohan...@huawei.com
>>> CC: andre.przyw...@arm.com
>>> CC: a...@arndb.de
>>> CC: linux-kernel@vger.kernel.org
>>> CC: linux-e...@vger.kernel.org
>>> ---
>>>
>>> v2:
>>> * convert into generic arm64 edac driver
>>> * remove AMD specific references from dt binding
>>> * remove poll_msec property from dt binding
>>> * add poll_msec as a module param, default is 100ms
>>> * update copyright text
>>> * define macro mnemonics for L1 and L2 RAMID
>>> * check L2 error per-cluster instead of per core
>>> * update function names
>>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>>   read hotplug-safe
>>> * add error check in probe routine
>>>
>>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>>  drivers/edac/Kconfig   |   6 +
>>>  drivers/edac/Makefile  |   1 +
>>>  drivers/edac/cortex_arm64_edac.c   | 457 
>>> +
>>>  4 files changed, 479 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> new file mode 100644
>>> index 000..dfd128f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> @@ -0,0 +1,15 @@
>>> +* ARMv8 L1/L2 cache error reporting
>>> +
>>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>>> +Register can be used for checking L1 and L2 memory errors.
>>> +
>>> +The following section describes the ARMv8 EDAC DT node binding.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "arm,armv8-edac"
>>> +
>>> +Example:
>>> +   edac {
>>> +   compatible = "arm,armv8-edac";
>>> +   };
>>> +
>> So if there is nothing in here, why do we need the DT binding at all (I
>> think Mark hinted at that already)?
>> Can't we just use the MIDR as already suggested by others?
>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>> specific and not architectural.
>>
> Yes, I was going with Mark suggestion to remove DT binding but then came 
> across these cases which kind of hinted to keep DT binding:
>
> * Without DT binding, the driver will always be loaded on arm64 unless its 
> blacklisted.
> * Its possible that other SoC's might handle single-bit and double-bit errors 
> differently compare to 
>   Seattle platform. In Seattle platform both errors are handled by firmware 
> but if other SoC 
>   wants OS to handle these errors then they might need DT binding to provide 
> the irq numbers etc.

I totally agree with you here,  thanks for putting them together.
Different SoCs may handle the error in different ways, we need
bindings to specialize them, irq number is a good example :)

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

Hi Mauro,

On 10/21/2015 04:25 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 21 Oct 2015 15:41:37 -0500
> Brijesh Singh  escreveu:
> 
>> Add support for Cortex A57 and A53 EDAC driver.
>>
>> Signed-off-by: Brijesh Singh 
>> CC: robh...@kernel.org
>> CC: pawel.m...@arm.com
>> CC: mark.rutl...@arm.com
>> CC: ijc+devicet...@hellion.org.uk
>> CC: ga...@codeaurora.org
>> CC: dougthomp...@xmission.com
>> CC: b...@alien8.de
>> CC: mche...@osg.samsung.com
>> CC: devicet...@vger.kernel.org
>> CC: guohan...@huawei.com
>> CC: andre.przyw...@arm.com
>> CC: a...@arndb.de
>> CC: linux-kernel@vger.kernel.org
>> CC: linux-e...@vger.kernel.org
>> ---
>>
>> v2:
>> * convert into generic arm64 edac driver
>> * remove AMD specific references from dt binding
>> * remove poll_msec property from dt binding
>> * add poll_msec as a module param, default is 100ms
>> * update copyright text
>> * define macro mnemonics for L1 and L2 RAMID
>> * check L2 error per-cluster instead of per core
>> * update function names
>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>   read hotplug-safe
>> * add error check in probe routine
>>
>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>  drivers/edac/Kconfig   |   6 +
>>  drivers/edac/Makefile  |   1 +
>>  drivers/edac/cortex_arm64_edac.c   | 457 
>> +
>>  4 files changed, 479 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>
>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> new file mode 100644
>> index 000..dfd128f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> @@ -0,0 +1,15 @@
>> +* ARMv8 L1/L2 cache error reporting
>> +
>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>> +Register can be used for checking L1 and L2 memory errors.
>> +
>> +The following section describes the ARMv8 EDAC DT node binding.
>> +
>> +Required properties:
>> +- compatible: Should be "arm,armv8-edac"
>> +
>> +Example:
>> +edac {
>> +compatible = "arm,armv8-edac";
>> +};
>> +
>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index ef25000..dd7c195 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -390,4 +390,10 @@ config EDAC_XGENE
>>Support for error detection and correction on the
>>APM X-Gene family of SOCs.
>>  
>> +config EDAC_CORTEX_ARM64
>> +tristate "ARM Cortex A57/A53"
>> +depends on EDAC_MM_EDAC && ARM64
> 
> It would be good to be able to compile it on non-ARM64 archs
> if COMPILE_TEST, e. g.:
> 
>   depends on EDAC_MM_EDAC && (ARM64 || COMPILE_TEST)
> 
> That would allow testing tools like Coverity to test it. As far as
> I know, the public license we use only works on x86.
> 
>> +help
>> +  Support for error detection and correction on the
>> +  ARM Cortex A57 and A53.
>>  endif # EDAC
>> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
>> index ae3c5f3..ac01660 100644
>> --- a/drivers/edac/Makefile
>> +++ b/drivers/edac/Makefile
>> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)  += 
>> octeon_edac-pci.o
>>  obj-$(CONFIG_EDAC_ALTERA_MC)+= altera_edac.o
>>  obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
>>  obj-$(CONFIG_EDAC_XGENE)+= xgene_edac.o
>> +obj-$(CONFIG_EDAC_CORTEX_ARM64) += cortex_arm64_edac.o
>> diff --git a/drivers/edac/cortex_arm64_edac.c 
>> b/drivers/edac/cortex_arm64_edac.c
>> new file mode 100644
>> index 000..c37bb94
>> --- /dev/null
>> +++ b/drivers/edac/cortex_arm64_edac.c
>> @@ -0,0 +1,457 @@
>> +/*
>> + * Cortex ARM64 EDAC
>> + *
>> + * Copyright (c) 2015, Advanced Micro Devices
>> + * Author: Brijesh Singh 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "edac_core.h"
>> +
>> +#define EDAC_MOD_STR "cortex_arm64_edac"
>> +
>> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
>> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
>> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
>> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
>> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
>> +#define A57_CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
>> +#define 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

Hi Andre,

On 10/21/2015 06:52 PM, Andre Przywara wrote:
> On 21/10/15 21:41, Brijesh Singh wrote:
>> Add support for Cortex A57 and A53 EDAC driver.
> 
> Hi Brijesh,
> 
> thanks for the quick update! Some comments below.
> 
>>
>> Signed-off-by: Brijesh Singh 
>> CC: robh...@kernel.org
>> CC: pawel.m...@arm.com
>> CC: mark.rutl...@arm.com
>> CC: ijc+devicet...@hellion.org.uk
>> CC: ga...@codeaurora.org
>> CC: dougthomp...@xmission.com
>> CC: b...@alien8.de
>> CC: mche...@osg.samsung.com
>> CC: devicet...@vger.kernel.org
>> CC: guohan...@huawei.com
>> CC: andre.przyw...@arm.com
>> CC: a...@arndb.de
>> CC: linux-kernel@vger.kernel.org
>> CC: linux-e...@vger.kernel.org
>> ---
>>
>> v2:
>> * convert into generic arm64 edac driver
>> * remove AMD specific references from dt binding
>> * remove poll_msec property from dt binding
>> * add poll_msec as a module param, default is 100ms
>> * update copyright text
>> * define macro mnemonics for L1 and L2 RAMID
>> * check L2 error per-cluster instead of per core
>> * update function names
>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>   read hotplug-safe
>> * add error check in probe routine
>>
>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>  drivers/edac/Kconfig   |   6 +
>>  drivers/edac/Makefile  |   1 +
>>  drivers/edac/cortex_arm64_edac.c   | 457 
>> +
>>  4 files changed, 479 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>
>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> new file mode 100644
>> index 000..dfd128f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> @@ -0,0 +1,15 @@
>> +* ARMv8 L1/L2 cache error reporting
>> +
>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>> +Register can be used for checking L1 and L2 memory errors.
>> +
>> +The following section describes the ARMv8 EDAC DT node binding.
>> +
>> +Required properties:
>> +- compatible: Should be "arm,armv8-edac"
>> +
>> +Example:
>> +edac {
>> +compatible = "arm,armv8-edac";
>> +};
>> +
> 
> So if there is nothing in here, why do we need the DT binding at all (I
> think Mark hinted at that already)?
> Can't we just use the MIDR as already suggested by others?
> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
> specific and not architectural.
> 
Yes, I was going with Mark suggestion to remove DT binding but then came across 
these cases which kind of hinted to keep DT binding:

* Without DT binding, the driver will always be loaded on arm64 unless its 
blacklisted.
* Its possible that other SoC's might handle single-bit and double-bit errors 
differently compare to 
  Seattle platform. In Seattle platform both errors are handled by firmware but 
if other SoC 
  wants OS to handle these errors then they might need DT binding to provide 
the irq numbers etc.

But if recommendation is to remove DT binding then I can remove it in next 
version. 

>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index ef25000..dd7c195 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -390,4 +390,10 @@ config EDAC_XGENE
>>Support for error detection and correction on the
>>APM X-Gene family of SOCs.
>>  
>> +config EDAC_CORTEX_ARM64
>> +tristate "ARM Cortex A57/A53"
>> +depends on EDAC_MM_EDAC && ARM64
>> +help
>> +  Support for error detection and correction on the
>> +  ARM Cortex A57 and A53.
>>  endif # EDAC
>> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
>> index ae3c5f3..ac01660 100644
>> --- a/drivers/edac/Makefile
>> +++ b/drivers/edac/Makefile
>> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)  += 
>> octeon_edac-pci.o
>>  obj-$(CONFIG_EDAC_ALTERA_MC)+= altera_edac.o
>>  obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
>>  obj-$(CONFIG_EDAC_XGENE)+= xgene_edac.o
>> +obj-$(CONFIG_EDAC_CORTEX_ARM64) += cortex_arm64_edac.o
>> diff --git a/drivers/edac/cortex_arm64_edac.c 
>> b/drivers/edac/cortex_arm64_edac.c
>> new file mode 100644
>> index 000..c37bb94
>> --- /dev/null
>> +++ b/drivers/edac/cortex_arm64_edac.c
>> @@ -0,0 +1,457 @@
>> +/*
>> + * Cortex ARM64 EDAC
>> + *
>> + * Copyright (c) 2015, Advanced Micro Devices
>> + * Author: Brijesh Singh 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

Hi Mauro,

On 10/21/2015 04:25 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 21 Oct 2015 15:41:37 -0500
> Brijesh Singh  escreveu:
> 
>> Add support for Cortex A57 and A53 EDAC driver.
>>
>> Signed-off-by: Brijesh Singh 
>> CC: robh...@kernel.org
>> CC: pawel.m...@arm.com
>> CC: mark.rutl...@arm.com
>> CC: ijc+devicet...@hellion.org.uk
>> CC: ga...@codeaurora.org
>> CC: dougthomp...@xmission.com
>> CC: b...@alien8.de
>> CC: mche...@osg.samsung.com
>> CC: devicet...@vger.kernel.org
>> CC: guohan...@huawei.com
>> CC: andre.przyw...@arm.com
>> CC: a...@arndb.de
>> CC: linux-kernel@vger.kernel.org
>> CC: linux-e...@vger.kernel.org
>> ---
>>
>> v2:
>> * convert into generic arm64 edac driver
>> * remove AMD specific references from dt binding
>> * remove poll_msec property from dt binding
>> * add poll_msec as a module param, default is 100ms
>> * update copyright text
>> * define macro mnemonics for L1 and L2 RAMID
>> * check L2 error per-cluster instead of per core
>> * update function names
>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>   read hotplug-safe
>> * add error check in probe routine
>>
>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>  drivers/edac/Kconfig   |   6 +
>>  drivers/edac/Makefile  |   1 +
>>  drivers/edac/cortex_arm64_edac.c   | 457 
>> +
>>  4 files changed, 479 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>
>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> new file mode 100644
>> index 000..dfd128f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> @@ -0,0 +1,15 @@
>> +* ARMv8 L1/L2 cache error reporting
>> +
>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>> +Register can be used for checking L1 and L2 memory errors.
>> +
>> +The following section describes the ARMv8 EDAC DT node binding.
>> +
>> +Required properties:
>> +- compatible: Should be "arm,armv8-edac"
>> +
>> +Example:
>> +edac {
>> +compatible = "arm,armv8-edac";
>> +};
>> +
>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index ef25000..dd7c195 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -390,4 +390,10 @@ config EDAC_XGENE
>>Support for error detection and correction on the
>>APM X-Gene family of SOCs.
>>  
>> +config EDAC_CORTEX_ARM64
>> +tristate "ARM Cortex A57/A53"
>> +depends on EDAC_MM_EDAC && ARM64
> 
> It would be good to be able to compile it on non-ARM64 archs
> if COMPILE_TEST, e. g.:
> 
>   depends on EDAC_MM_EDAC && (ARM64 || COMPILE_TEST)
> 
> That would allow testing tools like Coverity to test it. As far as
> I know, the public license we use only works on x86.
> 
>> +help
>> +  Support for error detection and correction on the
>> +  ARM Cortex A57 and A53.
>>  endif # EDAC
>> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
>> index ae3c5f3..ac01660 100644
>> --- a/drivers/edac/Makefile
>> +++ b/drivers/edac/Makefile
>> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)  += 
>> octeon_edac-pci.o
>>  obj-$(CONFIG_EDAC_ALTERA_MC)+= altera_edac.o
>>  obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
>>  obj-$(CONFIG_EDAC_XGENE)+= xgene_edac.o
>> +obj-$(CONFIG_EDAC_CORTEX_ARM64) += cortex_arm64_edac.o
>> diff --git a/drivers/edac/cortex_arm64_edac.c 
>> b/drivers/edac/cortex_arm64_edac.c
>> new file mode 100644
>> index 000..c37bb94
>> --- /dev/null
>> +++ b/drivers/edac/cortex_arm64_edac.c
>> @@ -0,0 +1,457 @@
>> +/*
>> + * Cortex ARM64 EDAC
>> + *
>> + * Copyright (c) 2015, Advanced Micro Devices
>> + * Author: Brijesh Singh 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "edac_core.h"
>> +
>> +#define EDAC_MOD_STR "cortex_arm64_edac"
>> +
>> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
>> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
>> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
>> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
>> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
>> 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Brijesh Singh]

Hi Andre,

On 10/21/2015 06:52 PM, Andre Przywara wrote:
> On 21/10/15 21:41, Brijesh Singh wrote:
>> Add support for Cortex A57 and A53 EDAC driver.
> 
> Hi Brijesh,
> 
> thanks for the quick update! Some comments below.
> 
>>
>> Signed-off-by: Brijesh Singh 
>> CC: robh...@kernel.org
>> CC: pawel.m...@arm.com
>> CC: mark.rutl...@arm.com
>> CC: ijc+devicet...@hellion.org.uk
>> CC: ga...@codeaurora.org
>> CC: dougthomp...@xmission.com
>> CC: b...@alien8.de
>> CC: mche...@osg.samsung.com
>> CC: devicet...@vger.kernel.org
>> CC: guohan...@huawei.com
>> CC: andre.przyw...@arm.com
>> CC: a...@arndb.de
>> CC: linux-kernel@vger.kernel.org
>> CC: linux-e...@vger.kernel.org
>> ---
>>
>> v2:
>> * convert into generic arm64 edac driver
>> * remove AMD specific references from dt binding
>> * remove poll_msec property from dt binding
>> * add poll_msec as a module param, default is 100ms
>> * update copyright text
>> * define macro mnemonics for L1 and L2 RAMID
>> * check L2 error per-cluster instead of per core
>> * update function names
>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>   read hotplug-safe
>> * add error check in probe routine
>>
>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>  drivers/edac/Kconfig   |   6 +
>>  drivers/edac/Makefile  |   1 +
>>  drivers/edac/cortex_arm64_edac.c   | 457 
>> +
>>  4 files changed, 479 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>
>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> new file mode 100644
>> index 000..dfd128f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>> @@ -0,0 +1,15 @@
>> +* ARMv8 L1/L2 cache error reporting
>> +
>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>> +Register can be used for checking L1 and L2 memory errors.
>> +
>> +The following section describes the ARMv8 EDAC DT node binding.
>> +
>> +Required properties:
>> +- compatible: Should be "arm,armv8-edac"
>> +
>> +Example:
>> +edac {
>> +compatible = "arm,armv8-edac";
>> +};
>> +
> 
> So if there is nothing in here, why do we need the DT binding at all (I
> think Mark hinted at that already)?
> Can't we just use the MIDR as already suggested by others?
> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
> specific and not architectural.
> 
Yes, I was going with Mark suggestion to remove DT binding but then came across 
these cases which kind of hinted to keep DT binding:

* Without DT binding, the driver will always be loaded on arm64 unless its 
blacklisted.
* Its possible that other SoC's might handle single-bit and double-bit errors 
differently compare to 
  Seattle platform. In Seattle platform both errors are handled by firmware but 
if other SoC 
  wants OS to handle these errors then they might need DT binding to provide 
the irq numbers etc.

But if recommendation is to remove DT binding then I can remove it in next 
version. 

>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index ef25000..dd7c195 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -390,4 +390,10 @@ config EDAC_XGENE
>>Support for error detection and correction on the
>>APM X-Gene family of SOCs.
>>  
>> +config EDAC_CORTEX_ARM64
>> +tristate "ARM Cortex A57/A53"
>> +depends on EDAC_MM_EDAC && ARM64
>> +help
>> +  Support for error detection and correction on the
>> +  ARM Cortex A57 and A53.
>>  endif # EDAC
>> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
>> index ae3c5f3..ac01660 100644
>> --- a/drivers/edac/Makefile
>> +++ b/drivers/edac/Makefile
>> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)  += 
>> octeon_edac-pci.o
>>  obj-$(CONFIG_EDAC_ALTERA_MC)+= altera_edac.o
>>  obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
>>  obj-$(CONFIG_EDAC_XGENE)+= xgene_edac.o
>> +obj-$(CONFIG_EDAC_CORTEX_ARM64) += cortex_arm64_edac.o
>> diff --git a/drivers/edac/cortex_arm64_edac.c 
>> b/drivers/edac/cortex_arm64_edac.c
>> new file mode 100644
>> index 000..c37bb94
>> --- /dev/null
>> +++ b/drivers/edac/cortex_arm64_edac.c
>> @@ -0,0 +1,457 @@
>> +/*
>> + * Cortex ARM64 EDAC
>> + *
>> + * Copyright (c) 2015, Advanced Micro Devices
>> + * Author: Brijesh Singh 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Stepan Moskovchenko]

>>> +++ b/drivers/edac/cortex_arm64_edac.c
>>> @@ -0,0 +1,457 @@
>>> +/*
>>> + * Cortex ARM64 EDAC
>>> + *
>>> + * Copyright (c) 2015, Advanced Micro Devices
>>> + * Author: Brijesh Singh 
>>> + *

Hi Brijesh,

Your ARM64 EDAC driver seems rather similar to the existing driver that 
is linked below. If you have indeed based your driver on this one, can 
you please provide the appropriate attribution?


https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10

Thank you
Steve

--
 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Hanjun Guo]

Hi Brijesh,

On 2015/10/22 22:46, Brijesh Singh wrote:
> Hi Andre,
>
> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>> On 21/10/15 21:41, Brijesh Singh wrote:
>>> Add support for Cortex A57 and A53 EDAC driver.
>> Hi Brijesh,
>>
>> thanks for the quick update! Some comments below.
>>
>>> Signed-off-by: Brijesh Singh 
>>> CC: robh...@kernel.org
>>> CC: pawel.m...@arm.com
>>> CC: mark.rutl...@arm.com
>>> CC: ijc+devicet...@hellion.org.uk
>>> CC: ga...@codeaurora.org
>>> CC: dougthomp...@xmission.com
>>> CC: b...@alien8.de
>>> CC: mche...@osg.samsung.com
>>> CC: devicet...@vger.kernel.org
>>> CC: guohan...@huawei.com
>>> CC: andre.przyw...@arm.com
>>> CC: a...@arndb.de
>>> CC: linux-kernel@vger.kernel.org
>>> CC: linux-e...@vger.kernel.org
>>> ---
>>>
>>> v2:
>>> * convert into generic arm64 edac driver
>>> * remove AMD specific references from dt binding
>>> * remove poll_msec property from dt binding
>>> * add poll_msec as a module param, default is 100ms
>>> * update copyright text
>>> * define macro mnemonics for L1 and L2 RAMID
>>> * check L2 error per-cluster instead of per core
>>> * update function names
>>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>>>   read hotplug-safe
>>> * add error check in probe routine
>>>
>>>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>>>  drivers/edac/Kconfig   |   6 +
>>>  drivers/edac/Makefile  |   1 +
>>>  drivers/edac/cortex_arm64_edac.c   | 457 
>>> +
>>>  4 files changed, 479 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>>  create mode 100644 drivers/edac/cortex_arm64_edac.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
>>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> new file mode 100644
>>> index 000..dfd128f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> @@ -0,0 +1,15 @@
>>> +* ARMv8 L1/L2 cache error reporting
>>> +
>>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>>> +Register can be used for checking L1 and L2 memory errors.
>>> +
>>> +The following section describes the ARMv8 EDAC DT node binding.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "arm,armv8-edac"
>>> +
>>> +Example:
>>> +   edac {
>>> +   compatible = "arm,armv8-edac";
>>> +   };
>>> +
>> So if there is nothing in here, why do we need the DT binding at all (I
>> think Mark hinted at that already)?
>> Can't we just use the MIDR as already suggested by others?
>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>> specific and not architectural.
>>
> Yes, I was going with Mark suggestion to remove DT binding but then came 
> across these cases which kind of hinted to keep DT binding:
>
> * Without DT binding, the driver will always be loaded on arm64 unless its 
> blacklisted.
> * Its possible that other SoC's might handle single-bit and double-bit errors 
> differently compare to 
>   Seattle platform. In Seattle platform both errors are handled by firmware 
> but if other SoC 
>   wants OS to handle these errors then they might need DT binding to provide 
> the irq numbers etc.

I totally agree with you here,  thanks for putting them together.
Different SoCs may handle the error in different ways, we need
bindings to specialize them, irq number is a good example :)

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] EDAC: Add ARM64 EDAC

[Singh, Brijeshkumar]

Hi Steve,

Thanks for pointing the link, I have not seen that driver before; I was mainly 
looking at driver/edac/xgene_edac.c and some other arm edac drivers.  My first 
attempt was to do AMD specific edac driver to log correctable L1/L2 error but 
based on feedback I worked on v2 generic driver which now looks very similar to 
your driver, are you planning to upstream your driver ? I can work with you to 
verify it on my current hardware setup. It seems your driver also handles 
single-bit and double-bit error which I have no way to test in my current 
hardware setup. On Seattle platform most of error handling is done through 
firmware APEI except correctable L1/L2.  Let me know your thoughts. 

-Brijesh

From: Stepan Moskovchenko [step...@codeaurora.org]
Sent: Thursday, October 22, 2015 8:51 PM
To: Singh, Brijeshkumar
Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; 
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; dougthomp...@xmission.com; 
b...@alien8.de; mche...@osg.samsung.com; devicet...@vger.kernel.org; 
guohan...@huawei.com; andre.przyw...@arm.com; a...@arndb.de; 
linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org
Subject: Re: [PATCH v2] EDAC: Add ARM64 EDAC

 >>> +++ b/drivers/edac/cortex_arm64_edac.c
 >>> @@ -0,0 +1,457 @@
 >>> +/*
 >>> + * Cortex ARM64 EDAC
 >>> + *
 >>> + * Copyright (c) 2015, Advanced Micro Devices
 >>> + * Author: Brijesh Singh <brijeshkumar.si...@amd.com>
 >>> + *

>Hi Brijesh,

>Your ARM64 EDAC driver seems rather similar to the existing driver that
>is linked below. If you have indeed based your driver on this one, can
>you please provide the appropriate attribution?

>https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Andre Przywara]

On 21/10/15 21:41, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.

Hi Brijesh,

thanks for the quick update! Some comments below.

> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +
> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };
> +

So if there is nothing in here, why do we need the DT binding at all (I
think Mark hinted at that already)?
Can't we just use the MIDR as already suggested by others?
Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
specific and not architectural.

> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64)  += cortex_arm64_edac.o
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> @@ -0,0 +1,457 @@
> +/*
> + * Cortex ARM64 EDAC
> + *
> + * Copyright (c) 2015, Advanced Micro Devices
> + * Author: Brijesh Singh 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "edac_core.h"
> +
> +#define EDAC_MOD_STR "cortex_arm64_edac"
> +
> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
> +#define A57_CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
> +#define A57_CPUMERRSR_EL1_FATAL(x)   ((x) & (1UL << 63))
> +#define A57_L1_I_TAG_RAM  0x00
> +#define A57_L1_I_DATA_RAM 0x01
> +#define A57_L1_D_TAG_RAM  0x08
> 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Mauro Carvalho Chehab]

Em Wed, 21 Oct 2015 15:41:37 -0500
Brijesh Singh  escreveu:

> Add support for Cortex A57 and A53 EDAC driver.
> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +
> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };
> +
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64

It would be good to be able to compile it on non-ARM64 archs
if COMPILE_TEST, e. g.:

depends on EDAC_MM_EDAC && (ARM64 || COMPILE_TEST)

That would allow testing tools like Coverity to test it. As far as
I know, the public license we use only works on x86.

> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64)  += cortex_arm64_edac.o
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> @@ -0,0 +1,457 @@
> +/*
> + * Cortex ARM64 EDAC
> + *
> + * Copyright (c) 2015, Advanced Micro Devices
> + * Author: Brijesh Singh 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "edac_core.h"
> +
> +#define EDAC_MOD_STR "cortex_arm64_edac"
> +
> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
> +#define A57_CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
> +#define A57_CPUMERRSR_EL1_FATAL(x)   ((x) & (1UL << 63))
> +#define A57_L1_I_TAG_RAM  0x00
> +#define A57_L1_I_DATA_RAM 0x01
> +#define A57_L1_D_TAG_RAM  0x08
> +#define A57_L1_D_DATA_RAM 0x09
> 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Mauro Carvalho Chehab]

Em Wed, 21 Oct 2015 15:41:37 -0500
Brijesh Singh  escreveu:

> Add support for Cortex A57 and A53 EDAC driver.
> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +
> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };
> +
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64

It would be good to be able to compile it on non-ARM64 archs
if COMPILE_TEST, e. g.:

depends on EDAC_MM_EDAC && (ARM64 || COMPILE_TEST)

That would allow testing tools like Coverity to test it. As far as
I know, the public license we use only works on x86.

> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64)  += cortex_arm64_edac.o
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> @@ -0,0 +1,457 @@
> +/*
> + * Cortex ARM64 EDAC
> + *
> + * Copyright (c) 2015, Advanced Micro Devices
> + * Author: Brijesh Singh 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "edac_core.h"
> +
> +#define EDAC_MOD_STR "cortex_arm64_edac"
> +
> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
> +#define A57_CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
> +#define A57_CPUMERRSR_EL1_FATAL(x)   ((x) & (1UL << 63))
> +#define A57_L1_I_TAG_RAM  0x00
> +#define A57_L1_I_DATA_RAM 0x01
> 

Re: [PATCH v2] EDAC: Add ARM64 EDAC

[Andre Przywara]

On 21/10/15 21:41, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.

Hi Brijesh,

thanks for the quick update! Some comments below.

> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicet...@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: linux-kernel@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/armv8-edac.txt|  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 457 
> +
>  4 files changed, 479 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt 
> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> new file mode 100644
> index 000..dfd128f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
> @@ -0,0 +1,15 @@
> +* ARMv8 L1/L2 cache error reporting
> +
> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
> +Register can be used for checking L1 and L2 memory errors.
> +
> +The following section describes the ARMv8 EDAC DT node binding.
> +
> +Required properties:
> +- compatible: Should be "arm,armv8-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,armv8-edac";
> + };
> +

So if there is nothing in here, why do we need the DT binding at all (I
think Mark hinted at that already)?
Can't we just use the MIDR as already suggested by others?
Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
specific and not architectural.

> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index ef25000..dd7c195 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -390,4 +390,10 @@ config EDAC_XGENE
> Support for error detection and correction on the
> APM X-Gene family of SOCs.
>  
> +config EDAC_CORTEX_ARM64
> + tristate "ARM Cortex A57/A53"
> + depends on EDAC_MM_EDAC && ARM64
> + help
> +   Support for error detection and correction on the
> +   ARM Cortex A57 and A53.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..ac01660 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64)  += cortex_arm64_edac.o
> diff --git a/drivers/edac/cortex_arm64_edac.c 
> b/drivers/edac/cortex_arm64_edac.c
> new file mode 100644
> index 000..c37bb94
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_edac.c
> @@ -0,0 +1,457 @@
> +/*
> + * Cortex ARM64 EDAC
> + *
> + * Copyright (c) 2015, Advanced Micro Devices
> + * Author: Brijesh Singh 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "edac_core.h"
> +
> +#define EDAC_MOD_STR "cortex_arm64_edac"
> +
> +#define A57_CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
> +#define A57_CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
> +#define A57_CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
> +#define A57_CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
> +#define A57_CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
> +#define A57_CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
> +#define A57_CPUMERRSR_EL1_FATAL(x)   ((x) & (1UL << 63))
> +#define A57_L1_I_TAG_RAM  0x00
> +#define A57_L1_I_DATA_RAM