linux-kernel - Re: [PATCH 3/3] edac: altera: Add SDRAM EDAC support for CycloneV/ArriaV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Apr 2014 11:45:25 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	"tthayer@...era.com" <tthayer@...era.com>
Cc:	"robherring2@...il.com" <robherring2@...il.com>,
	"dougthompson@...ssion.com" <dougthompson@...ssion.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"rob@...dley.net" <rob@...dley.net>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"dinguyen@...era.com" <dinguyen@...era.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] edac: altera: Add SDRAM EDAC support for
 CycloneV/ArriaV

On Mon, Apr 07, 2014 at 10:54:09PM +0100, tthayer@...era.com wrote:
> From: Thor Thayer <tthayer@...era.com>
> 
> Added EDAC support for reporting ECC errors of CycloneV
> and ArriaV SDRAM controller.
> - The SDRAM Controller registers are used by the FPGA bridge so
>   these are accessed through the syscon interface.
> - The configuration of the SDRAM memory size for the EDAC framework
>   is discovered from the memory node of the device tree.
> - Documentation of the bindings in devicetree/bindings/arm/altera/
>   socfpga-sdram-edac.txt
> - Correction of single bit errors, detection of double bit errors.
> 
> Signed-off-by: Thor Thayer <tthayer@...era.com>
> To: Rob Herring <robherring2@...il.com>
> To: Doug Thompson <dougthompson@...ssion.com>
> To: Grant Likely <grant.likely@...aro.org>
> Cc: Dinh Nguyen <dinguyen@...era.com>
> Cc: devicetree@...r.kernel.org
> Cc: linux-edac@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> ---
>  drivers/edac/Kconfig          |    9 ++
>  drivers/edac/Makefile         |    2 +
>  drivers/edac/altera_mc_edac.c |  360 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 371 insertions(+)
>  create mode 100644 drivers/edac/altera_mc_edac.c

[...]

> +/* Get total memory size from Open Firmware DTB */
> +static u32 altr_sdram_get_total_mem_size(void)
> +{
> +       struct device_node *np;
> +       u32 retcode, reg_array[2];
> +
> +       np = of_find_node_by_type(NULL, "memory");
> +       if (!np)
> +               return 0;
> +
> +       retcode = of_property_read_u32_array(np, "reg",
> +                                            reg_array, ARRAY_SIZE(reg_array));

There's no requirement that #address-cells = <1> or #size-cells = <1>,
even if any values in either would fit into 32 bits. If we must read
this from the DTB rather than elsewhere, please check
of_n_{addr,size}_cells.

Additionally, it's possible that the physical memory might be described
over multiple reg entries, or multiple memory nodes for some arbitrary
reason.

Can we not get this info from elsewhere rather than having to parse the
memory node within a driver?

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