On 2015/10/21 17:35, Borislav Petkov wrote:
> 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 jus
On 10/21/2015 05:01 AM, Andre Przywara wrote:
> Hi,
>
> On 21/10/15 10:35, Borislav Petkov wrote:
>> 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 er
Hi,
On 21/10/15 10:35, Borislav Petkov wrote:
> 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
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
Hi Boris, Mark,
On 2015/10/21 1:36, Borislav Petkov wrote:
> 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
On 2015/10/21 1:25, Mark Rutland wrote:
> On Tue, Oct 20, 2015 at 11:44:46AM -0500, Brijesh Singh wrote:
>> Hi Mark,
>>
>> Thanks for review.
>>
>> -Brijesh
>>
>> On 10/19/2015 03:52 PM, Mark Rutland wrote:
>>> Hi,
>>>
>>> Please Cc the devicetree list (devicet...@vger.kernel.org) when sending
>>>
On 2015/10/21 5:26, Brijesh Singh wrote:
> Hi Hanjun,
>
> Thanks for review.
>
> -Brijesh
> On 10/19/2015 09:21 PM, Hanjun Guo wrote:
>> Hi Brijesh,
>>
>> On 2015/10/20 3:23, Brijesh Singh wrote:
[...]
>> The codes above are common for all A57 architectures, other A57 SoCs will
>> use the same
>>
Hi Hanjun,
Thanks for review.
-Brijesh
On 10/19/2015 09:21 PM, Hanjun Guo wrote:
> Hi Brijesh,
>
> On 2015/10/20 3:23, Brijesh Singh wrote:
>> Add support for the AMD Seattle SoC EDAC driver.
>>
>> Signed-off-by: Brijesh Singh
>> ---
>> .../devicetree/bindings/edac/amd-seattle-edac.txt | 1
On 10/20/2015 12:41 PM, Mark Rutland wrote:
> On Tue, Oct 20, 2015 at 07:36:39PM +0200, Borislav Petkov wrote:
>> 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.
>>>
>>>
On Tue, Oct 20, 2015 at 07:36:39PM +0200, Borislav Petkov wrote:
> 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_ed
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 06:57:44PM +0200, Borislav Petkov wrote:
> 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 b
On Tue, Oct 20, 2015 at 11:44:46AM -0500, Brijesh Singh wrote:
> Hi Mark,
>
> Thanks for review.
>
> -Brijesh
>
> On 10/19/2015 03:52 PM, Mark Rutland wrote:
> > Hi,
> >
> > Please Cc the devicetree list (devicet...@vger.kernel.org) when sending
> > binding patches. I see you've added the peop
Hi Mark,
Thanks for review.
-Brijesh
On 10/19/2015 03:52 PM, Mark Rutland wrote:
> Hi,
>
> Please Cc the devicetree list (devicet...@vger.kernel.org) when sending
> binding patches. I see you've added the people from the MAINTAINERS
> entry; the list should also be Cc'd.
>
Noted.
> On Mon, Oc
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
Hi Brijesh,
On 2015/10/20 3:23, Brijesh Singh wrote:
> Add support for the AMD Seattle SoC EDAC driver.
>
> Signed-off-by: Brijesh Singh
> ---
> .../devicetree/bindings/edac/amd-seattle-edac.txt | 15 +
> drivers/edac/Kconfig | 6 +
> drivers/edac/Makefile
Hi,
Please Cc the devicetree list (devicet...@vger.kernel.org) when sending
binding patches. I see you've added the people from the MAINTAINERS
entry; the list should also be Cc'd.
On Mon, Oct 19, 2015 at 02:23:17PM -0500, Brijesh Singh wrote:
> Add support for the AMD Seattle SoC EDAC driver.
>
+ Arnd for the DT bindings.
On Mon, Oct 19, 2015 at 02:23:17PM -0500, Brijesh Singh wrote:
> Add support for the AMD Seattle SoC EDAC driver.
>
> Signed-off-by: Brijesh Singh
> ---
> .../devicetree/bindings/edac/amd-seattle-edac.txt | 15 +
> drivers/edac/Kconfig
Add support for the AMD Seattle SoC EDAC driver.
Signed-off-by: Brijesh Singh
---
.../devicetree/bindings/edac/amd-seattle-edac.txt | 15 +
drivers/edac/Kconfig | 6 +
drivers/edac/Makefile | 1 +
drivers/edac/seattle_edac.c
19 matches
Mail list logo