On Mon, Aug 03, 2015 at 05:23:54PM +0100, Matt Fleming wrote:
Rafael, Boris?
The ghes.c change looks fine I guess. The whole patchset makes sense
now, with the arch bits extracted. So
Acked-by: Borislav Petkov b...@suse.de
However, we probably should work towards adhering to EFI memory
On Fri, Jun 05, 2015 at 10:57:01AM +0100, Matt Fleming wrote:
[ Cc'ing Boris and Tony. Folks original patch is here,
https://lkml.kernel.org/r/1433185940-24770-4-git-send-email-zjzh...@codeaurora.org
]
On Mon, 01 Jun, at 12:12:20PM, Jonathan (Zhixiong) Zhang wrote:
From: Jonathan
On Fri, Jun 05, 2015 at 09:43:26AM -0700, Zhang, Jonathan Zhixiong wrote:
Thanks Matt for the review. Yes, you are right on, I am following
this:
modify ghes_ioremap_* to query the EFI memmap (if
it's available at runtime) to lookup the correct mapping attributes.
A: Because it messes up
On Fri, Jun 05, 2015 at 10:05:13AM -0700, Zhang, Jonathan Zhixiong wrote:
What is DDR?
I think this needs to be clarified first before we go any further.
I thought the word memory might be confusing, because there are
So you mean normal RAM here?
memories on the system that is not
On Tue, Apr 08, 2014 at 12:54:47PM -0700, Stephen Boyd wrote:
and also, this message looks a bit cryptic for issuing it at ALERT
level. I'm ssuming people won't come to you and ask you what it
means...? :)
Ok. I can lower it to error level?
I'm just trying to put you in the user's shoes
On Mon, Apr 07, 2014 at 02:56:49PM -0700, Stephen Boyd wrote:
No. This is the template I'm told to use.
By whom? And why?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the
On Tue, Apr 08, 2014 at 05:19:29PM +0100, One Thousand Gnomes wrote:
Including the without warranty is standard practice at a lot of
companies. It's not even wasting space - it'll compress beautifully as
there are already lots of similar headers all over the tree.
Right, I was just trying to
On Fri, Apr 04, 2014 at 12:57:29PM -0700, Stephen Boyd wrote:
Add support for the Krait CPU cache error detection. This is a
simplified version of the code originally written by Stepan
Moskovchenko[1] ported to the EDAC device framework.
[1]
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 the
On Wed, Jan 08, 2014 at 05:54:28PM -0800, Stephen Boyd wrote:
Ok. Borislav, should I resend to add krait_ before these functions?
Yes please - I can't even build-test here so I'm relying on you.
That's why I thought it might be a better idea for this purely arm patch
to go through some other
On Mon, Dec 30, 2013 at 12:14:13PM -0800, Stephen Boyd wrote:
In the near future we're going to use these percpu irq functions
in the Krait CPU EDAC driver. Export them so that the EDAC driver
can be compiled as a module.
Acked-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Stephen
On Mon, Dec 30, 2013 at 12:14:16PM -0800, Stephen Boyd wrote:
Add support for the Krait CPU cache error detection. This is a
simplified version of the code originally written by Stepan
Moskovchenko[1] ported to the EDAC device framework.
[1]
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 as
Acked-by: Borislav Petkov b...@suse.de
Btw, you might want to remove the hex numbers in the trace above and
leave only the call stack to make it more readable.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Wed, Apr 27, 2011 at 03:12:19PM -0700, Michael Bohan wrote:
On 4/27/2011 12:38 AM, Borislav Petkov wrote:
Great, whatever you guys come up with, we'd like to give it a run too.
We (AMD) hit the same issue in one of our tests but in our case we end
up in an endless loop of the state machine
15 matches
Mail list logo
