All of lore.kernel.org
 help / color / mirror / Atom feed
From: tthayer@opensource.altera.com (Thor Thayer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 2/5] arm: socfpga: Enable OCRAM ECC on startup.
Date: Tue, 2 Dec 2014 11:54:09 -0600	[thread overview]
Message-ID: <547DFCC1.3060805@opensource.altera.com> (raw)
In-Reply-To: <20141202151145.GN23671@leverpostej>



On 12/02/2014 09:11 AM, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 12:14:20AM +0000, tthayer at opensource.altera.com wrote:
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> This patch enables the ECC for On-Chip RAM on machine
>> startup.  The ECC has to be enabled before data is
>> is stored in memory otherwise the ECC will fail on
>> reads.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> v2: Split OCRAM ECC portion separately. Addition of iounmap()
>> and reorganization of gen_pool_free. Remove defconfig from patch.
>>
>> v3/4: No change
>>
>> v5: Remove ocram.h, use io.h instead of clk-provider.h
>>      Check prop in correct place. Add ECC EN defines.
>> ---
<snip>

>> +
>> +void socfpga_init_ocram_ecc(void)
>> +{
>> +	struct device_node *np;
>> +	const __be32 *prop;
>
> Please don't use accessors which return raw __be32s in drivers,
> typically it's the wrong thing to do and leaves horrible bugs and/or
> quirks that are painful to fix up.

OK. Thanks.

>> +	u32 ocr_edac_addr, iram_addr, len;
>> +	void __iomem  *mapped_ocr_edac_addr;
>> +	size_t size;
>> +	struct gen_pool *gp;
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "altr,ocram-edac");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find altr,ocram-edac in dtb\n");
>> +		return;
>> +	}
>> +
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM ECC mapping in dtb\n");
>> +		return;
>> +	}
>> +	ocr_edac_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> Use of_iomap(np, 0). You don't seem to pass the address around, so that
> should be sufficient.
>
>> +
>> +	gp = of_get_named_gen_pool(np, "iram", 0);
>> +	if (!gp) {
>> +		pr_err("SOCFPGA: OCRAM cannot find gen pool\n");
>> +		return;
>> +	}
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "mmio-sram");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find mmio-sram in dtb\n");
>> +		return;
>> +	}
>> +
>> +	/* Determine the OCRAM address and size */
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM mapping in dtb\n");
>> +		return;
>> +	}
>> +	iram_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> This address is overwritten below. What's going on?
>

Thanks, leftovers from debugging. I will look for a different way of 
getting the information without the be32 stuff.

>> +
>> +	iram_addr = gen_pool_alloc(gp, len);
>> +	if (iram_addr == 0) {
>> +		pr_err("SOCFPGA: cannot alloc from gen pool\n");
>> +		return;
>> +	}
>> +
>> +	memset((void *)iram_addr, 0, len);
>
> How is the iram mapped? Is memset to it safe (e.g. it unaligned accesses
> are made)?
>

I will need to look at this further - good points. The entire iram 
should be used as a pool so I didn't expect anything unusual even though 
I just realized allocations are not contiguous.

>> +
>> +	gen_pool_free(gp, iram_addr, len);
>> +
>> +	mapped_ocr_edac_addr = ioremap(ocr_edac_addr, 4);
>> +	if (!mapped_ocr_edac_addr) {
>> +		pr_err("SOCFPGA: Unable to map OCRAM ecc regs.\n");
>> +		return;
>> +	}
>> +
>> +	/* Clear any pending OCRAM ECC interrupts, then enable ECC */
>> +	writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
>> +	writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
>> +
>> +	iounmap(mapped_ocr_edac_addr);
>> +
>> +	pr_debug("SOCFPGA: Success Initializing OCRAM\n");
>> +}
>> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
>> index 0954011..065d80d 100644
>> --- a/arch/arm/mach-socfpga/socfpga.c
>> +++ b/arch/arm/mach-socfpga/socfpga.c
>> @@ -100,6 +100,14 @@ static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
>>   	writel(temp, rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>>   }
>>
>> +static void __init socfpga_cyclone5_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table,
>> +			     NULL, NULL);
>> +	if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
>> +		socfpga_init_ocram_ecc();
>
> If it's safe to do this after probing everything else, why can't this be
> a normal device probe?
>
> Thanks,
> Mark.

Good point. Thank you.

WARNING: multiple messages have this Message-ID (diff)
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: "bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org"
	<bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	"dougthompson-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org"
	<dougthompson-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	"m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
	"ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org"
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
	<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org"
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	"dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org"
	<dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
	"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"tthayer.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<tthayer.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCHv5 2/5] arm: socfpga: Enable OCRAM ECC on startup.
Date: Tue, 2 Dec 2014 11:54:09 -0600	[thread overview]
Message-ID: <547DFCC1.3060805@opensource.altera.com> (raw)
In-Reply-To: <20141202151145.GN23671@leverpostej>



On 12/02/2014 09:11 AM, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 12:14:20AM +0000, tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org wrote:
>> From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>
>> This patch enables the ECC for On-Chip RAM on machine
>> startup.  The ECC has to be enabled before data is
>> is stored in memory otherwise the ECC will fail on
>> reads.
>>
>> Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>> ---
>> v2: Split OCRAM ECC portion separately. Addition of iounmap()
>> and reorganization of gen_pool_free. Remove defconfig from patch.
>>
>> v3/4: No change
>>
>> v5: Remove ocram.h, use io.h instead of clk-provider.h
>>      Check prop in correct place. Add ECC EN defines.
>> ---
<snip>

>> +
>> +void socfpga_init_ocram_ecc(void)
>> +{
>> +	struct device_node *np;
>> +	const __be32 *prop;
>
> Please don't use accessors which return raw __be32s in drivers,
> typically it's the wrong thing to do and leaves horrible bugs and/or
> quirks that are painful to fix up.

OK. Thanks.

>> +	u32 ocr_edac_addr, iram_addr, len;
>> +	void __iomem  *mapped_ocr_edac_addr;
>> +	size_t size;
>> +	struct gen_pool *gp;
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "altr,ocram-edac");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find altr,ocram-edac in dtb\n");
>> +		return;
>> +	}
>> +
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM ECC mapping in dtb\n");
>> +		return;
>> +	}
>> +	ocr_edac_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> Use of_iomap(np, 0). You don't seem to pass the address around, so that
> should be sufficient.
>
>> +
>> +	gp = of_get_named_gen_pool(np, "iram", 0);
>> +	if (!gp) {
>> +		pr_err("SOCFPGA: OCRAM cannot find gen pool\n");
>> +		return;
>> +	}
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "mmio-sram");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find mmio-sram in dtb\n");
>> +		return;
>> +	}
>> +
>> +	/* Determine the OCRAM address and size */
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM mapping in dtb\n");
>> +		return;
>> +	}
>> +	iram_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> This address is overwritten below. What's going on?
>

Thanks, leftovers from debugging. I will look for a different way of 
getting the information without the be32 stuff.

>> +
>> +	iram_addr = gen_pool_alloc(gp, len);
>> +	if (iram_addr == 0) {
>> +		pr_err("SOCFPGA: cannot alloc from gen pool\n");
>> +		return;
>> +	}
>> +
>> +	memset((void *)iram_addr, 0, len);
>
> How is the iram mapped? Is memset to it safe (e.g. it unaligned accesses
> are made)?
>

I will need to look at this further - good points. The entire iram 
should be used as a pool so I didn't expect anything unusual even though 
I just realized allocations are not contiguous.

>> +
>> +	gen_pool_free(gp, iram_addr, len);
>> +
>> +	mapped_ocr_edac_addr = ioremap(ocr_edac_addr, 4);
>> +	if (!mapped_ocr_edac_addr) {
>> +		pr_err("SOCFPGA: Unable to map OCRAM ecc regs.\n");
>> +		return;
>> +	}
>> +
>> +	/* Clear any pending OCRAM ECC interrupts, then enable ECC */
>> +	writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
>> +	writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
>> +
>> +	iounmap(mapped_ocr_edac_addr);
>> +
>> +	pr_debug("SOCFPGA: Success Initializing OCRAM\n");
>> +}
>> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
>> index 0954011..065d80d 100644
>> --- a/arch/arm/mach-socfpga/socfpga.c
>> +++ b/arch/arm/mach-socfpga/socfpga.c
>> @@ -100,6 +100,14 @@ static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
>>   	writel(temp, rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>>   }
>>
>> +static void __init socfpga_cyclone5_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table,
>> +			     NULL, NULL);
>> +	if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
>> +		socfpga_init_ocram_ecc();
>
> If it's safe to do this after probing everything else, why can't this be
> a normal device probe?
>
> Thanks,
> Mark.

Good point. Thank you.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Thor Thayer <tthayer@opensource.altera.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "bp@alien8.de" <bp@alien8.de>,
	"dougthompson@xmission.com" <dougthompson@xmission.com>,
	"m.chehab@samsung.com" <m.chehab@samsung.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"dinguyen@opensource.altera.com" <dinguyen@opensource.altera.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"tthayer.linux@gmail.com" <tthayer.linux@gmail.com>
Subject: Re: [PATCHv5 2/5] arm: socfpga: Enable OCRAM ECC on startup.
Date: Tue, 2 Dec 2014 11:54:09 -0600	[thread overview]
Message-ID: <547DFCC1.3060805@opensource.altera.com> (raw)
In-Reply-To: <20141202151145.GN23671@leverpostej>



On 12/02/2014 09:11 AM, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 12:14:20AM +0000, tthayer@opensource.altera.com wrote:
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> This patch enables the ECC for On-Chip RAM on machine
>> startup.  The ECC has to be enabled before data is
>> is stored in memory otherwise the ECC will fail on
>> reads.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> v2: Split OCRAM ECC portion separately. Addition of iounmap()
>> and reorganization of gen_pool_free. Remove defconfig from patch.
>>
>> v3/4: No change
>>
>> v5: Remove ocram.h, use io.h instead of clk-provider.h
>>      Check prop in correct place. Add ECC EN defines.
>> ---
<snip>

>> +
>> +void socfpga_init_ocram_ecc(void)
>> +{
>> +	struct device_node *np;
>> +	const __be32 *prop;
>
> Please don't use accessors which return raw __be32s in drivers,
> typically it's the wrong thing to do and leaves horrible bugs and/or
> quirks that are painful to fix up.

OK. Thanks.

>> +	u32 ocr_edac_addr, iram_addr, len;
>> +	void __iomem  *mapped_ocr_edac_addr;
>> +	size_t size;
>> +	struct gen_pool *gp;
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "altr,ocram-edac");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find altr,ocram-edac in dtb\n");
>> +		return;
>> +	}
>> +
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM ECC mapping in dtb\n");
>> +		return;
>> +	}
>> +	ocr_edac_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> Use of_iomap(np, 0). You don't seem to pass the address around, so that
> should be sufficient.
>
>> +
>> +	gp = of_get_named_gen_pool(np, "iram", 0);
>> +	if (!gp) {
>> +		pr_err("SOCFPGA: OCRAM cannot find gen pool\n");
>> +		return;
>> +	}
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "mmio-sram");
>> +	if (!np) {
>> +		pr_err("SOCFPGA: Unable to find mmio-sram in dtb\n");
>> +		return;
>> +	}
>> +
>> +	/* Determine the OCRAM address and size */
>> +	prop = of_get_property(np, "reg", &size);
>> +	if (!prop || size < sizeof(*prop)) {
>> +		pr_err("SOCFPGA: Unable to find OCRAM mapping in dtb\n");
>> +		return;
>> +	}
>> +	iram_addr = be32_to_cpup(prop++);
>> +	len = be32_to_cpup(prop);
>
> This address is overwritten below. What's going on?
>

Thanks, leftovers from debugging. I will look for a different way of 
getting the information without the be32 stuff.

>> +
>> +	iram_addr = gen_pool_alloc(gp, len);
>> +	if (iram_addr == 0) {
>> +		pr_err("SOCFPGA: cannot alloc from gen pool\n");
>> +		return;
>> +	}
>> +
>> +	memset((void *)iram_addr, 0, len);
>
> How is the iram mapped? Is memset to it safe (e.g. it unaligned accesses
> are made)?
>

I will need to look at this further - good points. The entire iram 
should be used as a pool so I didn't expect anything unusual even though 
I just realized allocations are not contiguous.

>> +
>> +	gen_pool_free(gp, iram_addr, len);
>> +
>> +	mapped_ocr_edac_addr = ioremap(ocr_edac_addr, 4);
>> +	if (!mapped_ocr_edac_addr) {
>> +		pr_err("SOCFPGA: Unable to map OCRAM ecc regs.\n");
>> +		return;
>> +	}
>> +
>> +	/* Clear any pending OCRAM ECC interrupts, then enable ECC */
>> +	writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
>> +	writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
>> +
>> +	iounmap(mapped_ocr_edac_addr);
>> +
>> +	pr_debug("SOCFPGA: Success Initializing OCRAM\n");
>> +}
>> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
>> index 0954011..065d80d 100644
>> --- a/arch/arm/mach-socfpga/socfpga.c
>> +++ b/arch/arm/mach-socfpga/socfpga.c
>> @@ -100,6 +100,14 @@ static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
>>   	writel(temp, rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>>   }
>>
>> +static void __init socfpga_cyclone5_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table,
>> +			     NULL, NULL);
>> +	if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
>> +		socfpga_init_ocram_ecc();
>
> If it's safe to do this after probing everything else, why can't this be
> a normal device probe?
>
> Thanks,
> Mark.

Good point. Thank you.

  reply	other threads:[~2014-12-02 17:54 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12  0:14 [PATCHv5 0/5] Add Altera peripheral memories to EDAC framework tthayer at opensource.altera.com
2014-11-12  0:14 ` tthayer
2014-11-12  0:14 ` tthayer
2014-11-12  0:14 ` [PATCHv5 1/5] arm: socfpga: Enable L2 Cache ECC on startup tthayer at opensource.altera.com
2014-11-12  0:14   ` tthayer
2014-11-12  0:14   ` tthayer
2014-11-12  7:32   ` Dinh Nguyen
2014-11-12  7:32     ` Dinh Nguyen
2014-11-12  7:32     ` Dinh Nguyen
2014-11-12  0:14 ` [PATCHv5 2/5] arm: socfpga: Enable OCRAM " tthayer at opensource.altera.com
2014-11-12  0:14   ` tthayer
2014-11-12  0:14   ` tthayer
2014-11-12  7:33   ` Dinh Nguyen
2014-11-12  7:33     ` Dinh Nguyen
2014-11-12  7:33     ` Dinh Nguyen
2014-12-02 15:11   ` Mark Rutland
2014-12-02 15:11     ` Mark Rutland
2014-12-02 15:11     ` Mark Rutland
2014-12-02 17:54     ` Thor Thayer [this message]
2014-12-02 17:54       ` Thor Thayer
2014-12-02 17:54       ` Thor Thayer
2014-11-12  0:14 ` [PATCHv5 3/5] edac: altera: Remove SDRAM module compile tthayer at opensource.altera.com
2014-11-12  0:14   ` tthayer
2014-11-12  0:14   ` tthayer
2014-11-12  0:14 ` [PATCHv5 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support tthayer at opensource.altera.com
2014-11-12  0:14   ` tthayer
2014-11-12  0:14   ` tthayer
2014-12-02 15:25   ` Mark Rutland
2014-12-02 15:25     ` Mark Rutland
2014-12-02 17:55     ` Thor Thayer
2014-12-02 17:55       ` Thor Thayer
2014-11-12  0:14 ` [PATCHv5 5/5] arm: dts: Add Altera L2 Cache and OCRAM EDAC tthayer at opensource.altera.com
2014-11-12  0:14   ` tthayer
2014-11-12  0:14   ` tthayer
2014-11-18 20:56   ` [RESEND PATCHv5 " Thor Thayer
2014-11-18 20:56     ` Thor Thayer
2014-11-18 20:56     ` Thor Thayer
2014-12-01 20:47     ` Thor Thayer
2014-12-01 20:47       ` Thor Thayer
2014-12-01 20:47       ` Thor Thayer
2014-12-02 15:01       ` Mark Rutland
2014-12-02 15:01         ` Mark Rutland
2014-12-02 17:51         ` Thor Thayer
2014-12-02 17:51           ` Thor Thayer
2014-12-02 14:57   ` [PATCHv5 " Mark Rutland
2014-12-02 14:57     ` Mark Rutland
2014-12-02 17:55     ` Thor Thayer
2014-12-02 17:55       ` Thor Thayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547DFCC1.3060805@opensource.altera.com \
    --to=tthayer@opensource.altera.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.