On Fri, Oct 30, 2015 at 05:06:06PM +, Mark Rutland wrote:
> > * Correctable errors does not generate any interrupt:
> > If we have to implement error parsing inside the firmware then work need
> > to be split between OS and firmware. Maybe OS can call SMC instruction to
> > dial into fir
On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote:
> So I think the meaning of those error register is the same, but the way
> of handle it may different from SoCs, for single bit error:
>
> - SoC may trigger a interrupt;
> - SoC may just keep silent so we need to scan the registers usi
On Tue, Oct 20, 2015 at 06:26:55PM +0100, Mark Rutland wrote:
> > Btw, how much of this is implementing generic A57 functionality?
>
> The driver is entirely A57 generic.
>
> > If a lot, can we make this a generic a57_edac driver so that multiple
> > vendors can use it?
>
> Yes.
Ok, cool.
> >
On Tue, Oct 20, 2015 at 11:44:46AM -0500, Brijesh Singh wrote:
> > This second property doesn't describe the hardware in any way. It should
> > be runtime-configurable and dpesn't belong in the DT.
> >
> > Regardless, the binding is wrong. This is in no way specific to AMD
> > Seattle, and per the
On Fri, Sep 25, 2015 at 10:52:23AM -0700, Loc Ho wrote:
> Thanks you... Next I would like to get the ACPI APEI supported. But
> unlike x86 which as NMI interface, APM hardware don't support this NMI
> interface. In order to make this works, we need an method to trigger
> the OS to indicate that the
On Thu, Sep 24, 2015 at 10:38:07AM -0700, Loc Ho wrote:
> Replace sprintf with snprintf to avoid possible string array overflow.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/edac/xgene_edac
On Thu, Sep 24, 2015 at 10:01:46AM -0700, Loc Ho wrote:
> Okay... Got it and will post another version using snprintf.
Yep, just that one patch is fine - no need for the whole patchset.
> Did you also reviewed the SoC patch as well?
Yap, that one looks ok to me.
--
Regards/Gruss,
Boris.
E
On Wed, Sep 23, 2015 at 05:40:59PM -0700, Loc Ho wrote:
> Add EDAC support for the L3 component.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 669
> -
> 1 files changed, 474 insertions(+), 195 deletions(-)
...
> @@ -878,25 +869,16
On Tue, Sep 22, 2015 at 10:46:07AM -0700, Loc Ho wrote:
> Let's me sync and give it a try. Do you see any other issue besides this?
I replied to each message separately but they were all small nitpicks
only.
Btw, I have the debugfs pile here if you want to base your stuff ontop:
git://git.kernel
On Fri, Aug 14, 2015 at 12:46:07AM -0600, Loc Ho wrote:
> This patch updates documentation for the APM X-Gene SoC EDAC DTS binding
No need to start the commit message with "This patch" - we know it is
this patch. :)
> for L3/SoC subnodes.
>
> Signed-off-by: Loc Ho
> ---
> .../devicetree/bindin
On Fri, Aug 14, 2015 at 12:46:06AM -0600, Loc Ho wrote:
> This patch exports and expose the edac_debugfs file node. This allows
> EDAC driver to create debugfs node under the EDAC debugfs node.
...
> -#ifdef CONFIG_EDAC_DEBUG
> -static struct dentry *edac_debugfs;
> +struct dentry *edac_debugfs;
On Fri, Aug 14, 2015 at 12:46:08AM -0600, Loc Ho wrote:
> This patch adds EDAC support for the L3 and SoC components.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 1169
> +
> 1 files changed, 975 insertions(+), 194 deletions(-)
...
On Mon, Aug 31, 2015 at 02:26:11PM -0700, Loc Ho wrote:
> Are you okay with this version to pull in for 4.3 release?
It was already too late for 4.3 when you sent them. I'll take a look at
them after the merge window is over and also someone (Arnd?) needs to
check the DT changes.
--
Regards/Grus
On Thu, Aug 13, 2015 at 10:41:50AM +0200, Lothar Waßmann wrote:
> What's the point in having an accessor function that returns a driver
> internal variable when this variable is exported anyway?
Not driver-internal but EDAC-core internal.
> This will only further inconsistencies because half of t
On Wed, Aug 12, 2015 at 09:30:58PM -0700, Loc Ho wrote:
> Okay... The 'inline' helps with the compiler warning. If I move all to
> header file with 'static inline' and wrapper around CONFIG_EDAC_DEBUG,
> don't I need to export and declare the variable 'edac_debugfs'? Are
> you okay with export this
On Wed, Aug 12, 2015 at 10:23:11AM -0700, Loc Ho wrote:
> I can't move it completely to the header and make it static. It will
> generate a lot of compiler warning as it isn't used by other modules.
Come again?
I'm talking about static inline functions in headers. Grep the kernel
sources for exam
On Wed, Aug 12, 2015 at 10:50:52AM -0700, Loc Ho wrote:
> I intentional left this code as is so that the driver will still works
> with older version of the EDAC code.
Huh, what? I don't think this is how upstream development works.
> I had already reversed the logic for the L3 and SoC. Are you a
On Tue, Aug 11, 2015 at 02:47:56PM -0600, Loc Ho wrote:
> This patch adds EDAC support for the L3 and SoC components.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 827
> -
> 1 files changed, 815 insertions(+), 12 deletions(-)
>
> di
On Wed, Aug 12, 2015 at 12:12:19PM +0200, Borislav Petkov wrote:
> EXPORT_SYMBOL_GPL() if it is going to be used by modules.
Better yet, move it to the header.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the l
On Tue, Aug 11, 2015 at 02:47:54PM -0600, Loc Ho wrote:
> This patch adds an function to retrieve the EDAC debugfs node. This allows
> EDAC driver to create debugfs node under the EDAC debugfs node.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/edac_core.h |1 +
> drivers/edac/edac_mc_s
On Wed, Jul 29, 2015 at 10:31:49PM -0700, Loc Ho wrote:
> Let me clarify a bit. I have one top level driver node and multiple
> instance of subnodes - 4 MC, 4 L2/L1, 1 L3C, and 1 SoC EDAC for now.
> The L3C many be multiple instance in the future. Just a note, the way
> EDAC looks up instance is
On Wed, Jul 29, 2015 at 04:39:10PM -0700, Loc Ho wrote:
> Debug folder node shows up at /sys/kernel/debug/ while the
> MC debug node shows up at /sys/kernel/debug/edac where is
> the driver node name. It would be better if everything shows up at
> /sys/kernel/debug/edac. For this to happen, I need
On Sat, Jul 25, 2015 at 01:07:42AM -0600, Loc Ho wrote:
> This patch adds EDAC support for the L3 and SoC components.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 804
> +
> 1 files changed, 804 insertions(+), 0 deletions(-)
>
> dif
On Thu, Jun 04, 2015 at 09:28:44AM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer
>
> This series of patches adds support for the Arria10 EDAC. The
> SDRAM controller and ECC registers are significantly different
> from the CycloneV/ArriaV but common areas could be abstracted.
>
r_next_arria10&id=d44a92eb044f4cc1abf34a790d647e9fa356d7b0
>
> I think I will have to ask Alan to split up his patch and send the part
> that touches altera_edac.c to linux-edac.
Nah, that's fine. If it is that hunk adding altr_sdram_prepare(), he can
simply add my ACK for the ED
On Thu, Jun 04, 2015 at 04:34:49PM -0500, Thor Thayer wrote:
> OK. I'll refactor and resend. I was using Altera's internal for-next branch.
Use this one:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#for-next
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
.@apm.com
Cc: robh...@kernel.org
Link: http://lkml.kernel.org/r/3195065.IK73o60xya@wuerfel
Signed-off-by: Borislav Petkov
---
.../devicetree/bindings/edac/apm-xgene-edac.txt| 3 +-
drivers/edac/xgene_edac.c | 55 --
2 files changed, 10 insertions(+),
On Mon, Jun 01, 2015 at 10:46:55AM -0700, Loc Ho wrote:
> You are right... Let me just prints the error code instead. Anyone who
> care will have to do post processing.
Don't forget about the usability of the driver. If a user has to go
open manuals when an error happens, you could just as well re
On Fri, May 29, 2015 at 04:04:34PM -0600, Loc Ho wrote:
> This patch adds EDAC support for the L3 and SoC components.
So what was the reason for that split now? None, AFAICT.
> +/* L3 Error device */
> +#define L3C_ESR (0x0A * 4)
> +#define L3C_ESR_DATATAG_MASK
On Fri, May 29, 2015 at 02:25:52PM -0700, Loc Ho wrote:
> On Fri, May 29, 2015 at 1:05 PM, Borislav Petkov wrote:
> > On Fri, May 29, 2015 at 08:59:26PM +0200, Borislav Petkov wrote:
> >> Does it build when you remove it?
> >
> > IOW, this should fix it:
>
&g
On Fri, May 29, 2015 at 08:59:26PM +0200, Borislav Petkov wrote:
> Does it build when you remove it?
IOW, this should fix it:
---
From: Borislav Petkov
Date: Fri, 29 May 2015 22:01:00 +0200
Subject: [PATCH] EDAC, edac_stub: Drop arch-specific include
contains only the arch-specific scrubb
On Fri, May 29, 2015 at 11:06:35AM -0700, Loc Ho wrote:
> I pull this and got this error:
>
> /projects/svdc/P4sbSW/lho/xgene2/processor/git.lho/edac-next/drivers/edac/edac_stub.c:19:22:
> fatal error: asm/edac.h: No such file or directory
> #include
> ^
> compilation termi
On Fri, May 22, 2015 at 05:32:55PM -0600, Loc Ho wrote:
> This patch adds support for the APM X-Gene SoC EDAC driver for DT.
Applied, thanks!
Phew, that was a looong process. But the final result looks nice. So
thanks for the perseverance.
All is here, if you want to do testing and other fun bef
On Thu, May 28, 2015 at 01:34:49PM +0100, Russell King - ARM Linux wrote:
> Acked-by: Russell King
Thanks!
I've got all the ACKs now :-)
>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 45df48ba0b12..325d6f3a596a 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> >
On Fri, May 22, 2015 at 04:13:22PM -0400, Chris Metcalf wrote:
> On 05/21/2015 02:11 PM, Borislav Petkov wrote:
> >From: Borislav Petkov
> >
> >So first of all, this atomic_scrub() function's naming is bad. It looks
> >like an atomic_t helper. Change it to edac_a
On Fri, May 22, 2015 at 10:23:11AM +0200, Arnd Bergmann wrote:
> > +static int edac_mc_idx;
> > +static int edac_mc_active_mask;
> > +static int edac_mc_registered_mask;
> > +static DEFINE_MUTEX(xgene_edac_mc_lock);
>
> It would also be best to avoid global variables, but it seems that at
> least
From: Borislav Petkov
So first of all, this atomic_scrub() function's naming is bad. It looks
like an atomic_t helper. Change it to edac_atomic_scrub().
The bigger problem is that this function is arch-specific and every new
arch which doesn't necessarily need that functionality stil
Adding more arch people.
On Tue, May 19, 2015 at 10:33:36PM +0200, Borislav Petkov wrote:
> On Tue, May 19, 2015 at 12:57:32PM -0700, Loc Ho wrote:
> > This was discussed here
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/326986.html.
> > Without this,
On Mon, May 18, 2015 at 05:24:37PM -0600, Loc Ho wrote:
> Add an stub atomic_scrub function and enable EDAC for arm64.
>
> Signed-off-by: Loc Ho
> ---
> arch/arm64/Kconfig|1 +
> arch/arm64/include/asm/edac.h | 28
> 2 files changed, 29 insertions(+
On Thu, Apr 30, 2015 at 09:57:46AM -0700, Loc Ho wrote:
> I had read all the emails interaction. Yes I can write a single EDAC
> driver. But I actually have multiple instances and single instance of
> the same IP's. For example, I have 4 DDR controllers, 4 CPU domains,
> one L3 and one SoC. If you
On Wed, Apr 29, 2015 at 02:56:25PM -0700, Loc Ho wrote:
> Hi,
>
> >> > Similar comments for the rest. I would define memory controller
> >> > bindings and EDAC driver, then worry about the rest.
> >>
> >> Okay.. As comment in following emails, I will break up the driver into
> >> multiple drivers
On Thu, Mar 26, 2015 at 10:39:17AM -0700, Loc Ho wrote:
> Hi Doug,
>
> Any comment with v6 of the APM EDAC driver?
So this thing is being delayed only due to the device tree stuff AFAICT.
Can someone of the DT people on To: please have a look already so that I
can queue this?
Thanks.
--
Regar
On Tue, Jan 06, 2015 at 11:13:47PM +0530, Punnaiah Choudary Kalluri wrote:
> Added EDAC support for reporting the ecc errors of synopsys ddr controller.
> The ddr ecc controller corrects single bit errors and detects double bit
> errors.
>
> Signed-off-by: Punnaiah Choudary Kalluri
Applied and q
On Sat, Jan 03, 2015 at 08:01:29AM +0530, punnaiah choudary kalluri wrote:
> p is pointing to the stack memory.
So you could go and allocate all that memory at driver init time and
reuse it each time you handle an error instead of on the stack. This way
your error handling paths are lean and fast.
On Fri, Jan 02, 2015 at 09:52:20AM +0530, Punnaiah Choudary Kalluri wrote:
> +/**
> + * synps_edac_handle_error - Handle controller error types CE and UE
> + * @mci: Pointer to the edac memory controller instance
> + * @p: Pointer to the synopsys ecc status structure
> + *
> + * H
On Tue, Dec 02, 2014 at 10:51:22AM +0530, punnaiah choudary kalluri wrote:
> >> +/**
> >> + * synps_edac_get_eccstate - Return the controller ecc enable/disable
> >> status
> >> + * @base:Pointer to the ddr memory contoller base address
> >> + *
> >> + * This routine returns the ECC enable/dis
On Mon, Dec 01, 2014 at 09:35:09PM +0530, Punnaiah Choudary Kalluri wrote:
> Added EDAC support for reporting the ecc errors of synopsys ddr controller.
> The ddr ecc controller corrects single bit errors and detects double bit
> errors.
>
> Signed-off-by: Punnaiah Choudary Kalluri
> ---
> Change
On Fri, Nov 07, 2014 at 10:31:20AM -0600, Dinh Nguyen wrote:
> If it's okay, can you please pick up this series, once everything is
> cleaned up? I just checked to make sure that there aren't any merge
> conflicts in the DTS files in this series against DTS patches that I
> have queue up for 3.19,
Hi Thor,
On Tue, Nov 04, 2014 at 04:57:44PM -0600, Thor Thayer wrote:
> We want to at least separate L2/OCRAM ECC from the SDRAM ECC because
> 1) the SDRAM preparation can take almost 2 seconds on boot and some
> customers need a faster boot time.
> 2) the SDRAM has an ECC initialization dependenc
On Thu, Oct 30, 2014 at 10:32:10AM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer
>
> Adding L2 Cache and On-Chip RAM EDAC support for the
> Altera SoCs using the EDAC device model. The SDRAM
> controller is using the Memory Controller model. All
> Altera EDAC functions live in
On Mon, Oct 27, 2014 at 05:48:17PM -0500, Thor Thayer wrote:
> Would the L2 cache and OCRAM specific functions also be in altera_edac.c?
> Each of these EDAC pieces is independent and can be compiled in without the
> others. I've read that the use of #ifdef's is discouraged and having
> separate fi
On Mon, Oct 27, 2014 at 04:35:00PM -0500, Thor Thayer wrote:
> Should I move the EDAC Device probe and error handling from
> altera_edac_mgr.c to altera_edac.c? Can I mix the MC and Device models
> in the same file?
Right, for basic practical reasons, I'd like to keep all functionality
pertaining
On Mon, Oct 27, 2014 at 01:50:24PM -0500, Thor Thayer wrote:
> Do you have any comments about this driver?
Just a question: why do you have three .c files for something which
does only error injection and nothing else AFAICT? Why isn't this part
of altera_edac.c?
--
Regards/Gruss,
Boris.
Se
> as a syscon device and allocate ECC specific SDRAM registers
> to EDAC.
>
> v7: No changes. Bump for consistency.
>
> v8: Alphabetize headers.
>
> v9: Changes to support a MFD SDRAM controller with nested EDAC.
>
> v10: Revert to version 5 (syscon) and fi
On Tue, Aug 26, 2014 at 03:28:10PM -0500, Dinh Nguyen wrote:
> If Boris is okay with driver part and everyone else is OK with the DTS
> portion, then I can apply the DTS patch to my tree, and Boris take the
> driver patch into his tree?
Actually, it would be easier for everyone involved if those p
On Thu, Jul 31, 2014 at 03:36:35PM +0200, Michal Simek wrote:
> Mixing functions for two/more different controller seems to me
> really messy.
Just stating that something is "really messy" without giving at least
one technical reason for it is not going to get you any further. So let
me give you m
On Thu, Jul 31, 2014 at 02:13:48PM +0200, Michal Simek wrote:
> Mixing two drivers in the one file is not a good idea because with
> more memory controllers it is just a mess and you are not able to
> cover all cases.
Why is it a mess?
> If this is just about providing uniq number we can easily e
On Wed, Jul 30, 2014 at 03:41:47PM +, Punnaiah Choudary Kalluri wrote:
> >So you're telling me that you want one edac driver for *two* memory
> >controllers which can be present on a single system *at* *the* *same*
> >*time*? Is that it?
>
> Yes.
Oh, this'll be fun. :-P
> >
> >How exactly is
On Mon, Jul 28, 2014 at 10:53:26PM +0530, punnaiah choudary kalluri wrote:
> I can agree with you that we can use shorter names.But ZYNQ has
> programmable logic next to processing system where one can add soft
> memory controller in the same system and may use different driver. So,
> the edac driv
On Sun, Jul 27, 2014 at 12:10:52AM +0530, Punnaiah Choudary Kalluri wrote:
> Added EDAC support for reporting the ecc errors of synopsys ddr controller.
> The ddr ecc controller corrects single bit errors and detects double bit
> errors.
>
> Signed-off-by: Punnaiah Choudary Kalluri
> ---
> Change
On Tue, Jul 08, 2014 at 01:52:05PM +0200, Pavel Machek wrote:
> I'm not joking. Try to understand and verify the code above. You
> can't. The "descriptive macro names" are useless; all the code does is
> split register in pieces. With the numbers it would be very obvious.
No, you need to fix the
On Tue, Jul 08, 2014 at 01:31:09PM +0200, Pavel Machek wrote:
> > + read_reg = readl(mc_vbase + DRAMADDRW);
> > +
> > + width = readl(mc_vbase + DRAMIFWIDTH);
> > +
> > + col = (read_reg & DRAMADDRW_COLBIT_MASK) >>
> > + DRAMADDRW_COLBIT_LSB;
> > + row = (read_reg & DRAMADDRW_ROWB
On Wed, Jun 18, 2014 at 03:26:12PM -0700, Loc Ho wrote:
> One more thing, if you going to pull this in, please use version 4 as
> that fixes the PMD (CPU L1/L2) error report and clearing.
Ah, I have a v4 too in my mbox. cool.
Please ping me when the atomic scrub lands in some maintainers tree so
On Mon, Jun 02, 2014 at 08:14:19PM -0600, Loc Ho wrote:
> This patch adds support for the APM X-Gene SoC EDAC driver and
> requires ARM64 EDAC support patch [1] to compile.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg324093.html
>
> Signed-off-by: Feng Kan
> Signed-off-by: Loc Ho
This i
On Fri, May 23, 2014 at 07:21:06PM -0600, Loc Ho wrote:
> +static ssize_t xgene_edac_mc_inject_ctrl_store(struct device *dev,
> +struct device_attribute *mattr,
> +const char *data, size_t count)
> +{
> + st
On Thu, May 15, 2014 at 11:04:51AM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
>
> v2: Use the SDRAM controller registers to calculate memory size
> instead of the Device Tree. Update To & Cc list. Add maintainer
> information.
>
> v3: EDAC driver cleanup based on comments from
On Fri, May 23, 2014 at 09:26:12AM -0700, Loc Ho wrote:
> Hi,
>
> >> +static int xgene_edac_mc_is_active(struct xgene_edac_mc_ctx *ctx, int
> >> mc_idx)
> >> +{
> >> + u32 reg;
> >> + u32 mcu_mask;
> >> +
> >> + reg = readl(ctx->csw_csr + CSW_CSWCR);
> >> + if (reg & CSW_CSWCR_DUA
On Thu, May 08, 2014 at 05:03:17PM -0600, Loc Ho wrote:
> This patch adds documentation for the APM X-Gene SoC EDAC DTS binding.
>
> Signed-off-by: Feng Kan
> Signed-off-by: Loc Ho
I guess I'm going to need an ack from a device tree maintainer if I'm
going to pick up the whole series through th
On Mon, May 12, 2014 at 06:36:57PM -0500, ttha...@altera.com wrote:
> + ptemp[0] = 0x5A5A5A5A;
> + ptemp[1] = 0xA5A5A5A5;
> + /* Clear the error injection bits */
> + regmap_write(drvdata->mc_vbase, CTLCFG, read_reg);
> + /* Ensure it has been written out */
> + wmb();
> +
>
On Fri, May 09, 2014 at 03:31:53PM -0500, Thor Thayer wrote:
> Yes, good point. Our hardware can't recover from Double Bit Errors so
> I'll go back to the panic() in that path. I like the flexibility of
> the command line parameter though...
Like to panic by default when the machine is booted norm
On Thu, May 08, 2014 at 03:37:19PM -0500, Thor Thayer wrote:
> Yes. Their reasoning is that they want to retain the rights and
> warranty language with the file (just in case the COPYING file
> changes).
Ok, thanks for checking up on this.
> Yes. I tested using edac_core.edac_mc_panic_on_ue=1 fro
On Thu, May 08, 2014 at 05:03:16PM -0600, Loc Ho wrote:
> This patch fixes the MC scrub mode comparsion bug by replacing
> '&' with '=='. The MC structure field scrub_mode is integer
> type - not bit field.
>
> Signed-off-by: Loc Ho
Applied, thanks.
--
Regards/Gruss,
Boris.
Sent from a fa
On Mon, May 05, 2014 at 05:52:17PM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
Missing commit message.
> ---
> v2: Use the SDRAM controller registers to calculate memory size
> instead of the Device Tree. Update To & Cc list. Add maintainer
> information.
>
> v3: EDAC driver cl
On Tue, Apr 29, 2014 at 11:34:00AM +0100, Lorenzo Pieralisi wrote:
> Sorry for the delay in replying. Those cache bindings need an ACK
> to get merged, and were introduced so that idle states can retrieve
> power domain information for caches. I am going to revive the idle
> bindings thread to see
; To: Grant Likely
> To: Pawel Moll
> To: Mark Rutland
> To: Ian Campbell
> To: Kumar Gala
> To: Rob Landley
> To: Russell King
> To: Dinh Nguyen
> Cc: Borislav Petkov
> Cc: devicetree@vger.kernel.org
> Cc: linux-e...@vger.kernel.org
> Cc: linux-ker...@vge
On Thu, Apr 10, 2014 at 12:09:03PM +0200, Michal Simek wrote:
> The question here is. This driver is just reporting problem through
> edac interface which is counting that errors and provide an unified
> way how to report problems.
Yes, normally you can use edac for reporting and error counting. B
On Thu, Apr 10, 2014 at 12:00:47PM +0200, Borislav Petkov wrote:
> Then you'll have to check whether edac can even stomach more than one
> drivers in parallel. TTBOMK, no one has ever done this so far... Yadda
> yadda.
Alternatively, you could put together a single edac driver which
On Thu, Apr 10, 2014 at 11:49:57AM +0200, Michal Simek wrote:
> I agree with you that we can use shorter name. I have checked this
> with Punnaiah and I can't see any problem to have more edac drivers
> in the system. For zynq there is primary ddr controller which is
> target by this driver. Then w
On Thu, Apr 10, 2014 at 08:01:36AM +0200, Michal Simek wrote:
> Just add it to Zynq maintainer fragment as we are doing for non
> zynq/xilinx drivers.
Yep, as a file pattern F:
> At least the is the first time when someone saying that only some
> functions should be documented.
I don't see the n
On Thu, Apr 10, 2014 at 08:12:17AM +0200, Michal Simek wrote:
> I am just curious about this recommendation. Does it mean that we
> shouldn't use edac interface just for reporting problems?
Yes, we should. But, if you want to have two different drivers accessing
the hardware and have to build sync
On Wed, Apr 09, 2014 at 11:15:00PM +0530, punnaiah choudary kalluri wrote:
> OK. I just checked at highbank_mc_edac and other drivers found
> no documentation for static functions. So, is it ok if i remove
> documentation completely for these static functions?
Yes. Didn't I already suggested that,
On Wed, Apr 09, 2014 at 10:59:49PM +0530, Punnaiah Choudary wrote:
> There is a driver file cache-l2x0.c under arch/arm/mm for pl310 cache
> configuration and management. Russel king had suggested to use
> single driver file for both pl310 edac implementation and cache-l2x0.c
> Here is the thread
>
On Wed, Apr 09, 2014 at 08:18:28AM -0500, Rob Herring wrote:
> I don't think so, the PL310 is present on lots of ARM chips besides
> Xilinx. I don't know how many support parity as that is optional. In
> fact the highbank_l2_edac.c is for the PL310 as well, but the
> registers it uses is all custom
On Sun, Mar 02, 2014 at 08:02:40PM +0530, Punnaiah Choudary Kalluri wrote:
> Add support for ARM Pl310 L2 cache controller parity error
>
> Signed-off-by: Punnaiah Choudary Kalluri
> ---
> .../devicetree/bindings/edac/pl310_edac_l2.txt | 19 ++
> drivers/edac/Kconfig
On Wed, Apr 09, 2014 at 11:34:31AM +0530, punnaiah choudary kalluri wrote:
> Since it is recommended in Documentation/kernel-doc-nano-HOWTO.txt
> but also said it is low priority and at the discretion of the MAINTAINER of
> that kernel source file
>
> So, if you recommend not use kernel-doc annota
On Mon, Mar 17, 2014 at 10:53:44AM +0530, Punnaiah Choudary Kalluri wrote:
> Added EDAC support for reporting the ecc errors of synopsys ddr controller.
> The ddr ecc controller corrects single bit errors and detects double bit
> errors
>
> Signed-off-by: Punnaiah Choudary Kalluri
> ---
> Changes
On Tue, Apr 08, 2014 at 05:10:54PM +0100, Mark Rutland wrote:
> Typically the bindings would go with the driver via the appropriate
> subsystem maintainer. That way we don't get bindings without drivers
> or vice-versa if there's a problem part-way, and we don't end up with
> every other driver goi
On Tue, Apr 08, 2014 at 04:40:17PM +0100, Mark Rutland wrote:
> The patches should be in the same series, but for review purposes it's
> nicer if the bindings are separate patches from the code within that
> series.
>
> I usually look at the drivers implementing bindings and prefer to be
> Cc'd on
On Fri, Apr 04, 2014 at 12:57:28PM -0700, Stephen Boyd wrote:
> The Krait L1/L2 error reporting hardware is made up a per-CPU
> interrupt for the L1 cache and a SPI interrupt for the L2.
>
> Cc: Lorenzo Pieralisi
> Cc: Mark Rutland
> Cc: Kumar Gala
> Cc:
> Signed-off-by: Stephen Boyd
> ---
>
On Tue, Apr 08, 2014 at 08:57:39AM -0500, Thor Thayer wrote:
> Yes, Altera has a group specifically supporting Linux drivers on the
> Altera SoCs.
Then please add MAINTAINERS file entry for this EDAC driver so that
people can send issues/reports to that group.
> I was told that the device tree ad
On Mon, Apr 07, 2014 at 04:54:09PM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
>
> 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.
On Thu, Apr 03, 2014 at 05:02:30PM +0200, Michal Simek wrote:
> Any comment about this driver?
It is all on the TODO list. I'll take a look after the merge window
closes.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from thi
On Tue, Jan 14, 2014 at 01:30:30PM -0800, Stephen Boyd wrote:
> This patchset adds support for the Krait L1/L2 cache error detection
> hardware. The first patch adds the Krait l2 indirection
> register code. This patch is in need of an ACK from ARM folks.
> The next two patches add the driver and t
On Mon, Dec 30, 2013 at 12:14:11PM -0800, Stephen Boyd wrote:
> This patchset adds support for the Krait L1/L2 cache error detection
> hardware. The first patch fixes a generic framework bug. The next
> two patches lay the groundwork for this driver to be added by
> exporting percpu irq functions
94 matches
Mail list logo
