On Wed, Aug 22, 2018 at 09:07:20PM +0800, Pu Wen wrote:
> Current I think we'd better try to follow the following way:
> For current version, we will try to minimize the modification and share
> codes,
> For later big modification, will try to split codes to make code path
> more clear.
Yes,
On Wed, Aug 22, 2018 at 09:07:20PM +0800, Pu Wen wrote:
> Current I think we'd better try to follow the following way:
> For current version, we will try to minimize the modification and share
> codes,
> For later big modification, will try to split codes to make code path
> more clear.
Yes,
On 2018/8/22 2:07, Pavel Machek wrote>> But for right now I think we
should strive to keep the changes as small
as possible and only do real splitting when they start adding new
functionality. Which would mean having a hygon_edac.c too, for example.
All, IMHO, of course. Sharing code between
On 2018/8/22 2:07, Pavel Machek wrote>> But for right now I think we
should strive to keep the changes as small
as possible and only do real splitting when they start adding new
functionality. Which would mean having a hygon_edac.c too, for example.
All, IMHO, of course. Sharing code between
On 2018/8/21 21:04, Borislav Petkov wrote:
On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
But then I don't see the point of adding the Hygon vendor, since any
check can be simplified:
I think Hygon wanted to superficially show it is not really an AMD. For
example, the Hygon
On 2018/8/21 21:04, Borislav Petkov wrote:
On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
But then I don't see the point of adding the Hygon vendor, since any
check can be simplified:
I think Hygon wanted to superficially show it is not really an AMD. For
example, the Hygon
> On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
> > But then I don't see the point of adding the Hygon vendor, since any
> > check can be simplified:
>
> I think Hygon wanted to superficially show it is not really an AMD. For
> example, the Hygon thing doesn't do SME/SEV. AFAIK.
> On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
> > But then I don't see the point of adding the Hygon vendor, since any
> > check can be simplified:
>
> I think Hygon wanted to superficially show it is not really an AMD. For
> example, the Hygon thing doesn't do SME/SEV. AFAIK.
On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
> But then I don't see the point of adding the Hygon vendor, since any
> check can be simplified:
I think Hygon wanted to superficially show it is not really an AMD. For
example, the Hygon thing doesn't do SME/SEV. AFAIK.
So we can
On Tue, Aug 21, 2018 at 01:26:13PM +0200, Paolo Bonzini wrote:
> But then I don't see the point of adding the Hygon vendor, since any
> check can be simplified:
I think Hygon wanted to superficially show it is not really an AMD. For
example, the Hygon thing doesn't do SME/SEV. AFAIK.
So we can
On 21/08/2018 13:20, Borislav Petkov wrote:
> On Tue, Aug 21, 2018 at 07:04:23PM +0800, Pu Wen wrote:
>> Sure, JV will negotiate with AMD and make sure only JV use family 18h and
>> AMD won't use family 0x18h, which will make the patch tight and clear.
>>
>> What's the best way to adapt for EDAC
On 21/08/2018 13:20, Borislav Petkov wrote:
> On Tue, Aug 21, 2018 at 07:04:23PM +0800, Pu Wen wrote:
>> Sure, JV will negotiate with AMD and make sure only JV use family 18h and
>> AMD won't use family 0x18h, which will make the patch tight and clear.
>>
>> What's the best way to adapt for EDAC
On Tue, Aug 21, 2018 at 07:04:23PM +0800, Pu Wen wrote:
> Sure, JV will negotiate with AMD and make sure only JV use family 18h and
> AMD won't use family 0x18h, which will make the patch tight and clear.
>
> What's the best way to adapt for EDAC driver?
> * To simplify the code based on AMD
On Tue, Aug 21, 2018 at 07:04:23PM +0800, Pu Wen wrote:
> Sure, JV will negotiate with AMD and make sure only JV use family 18h and
> AMD won't use family 0x18h, which will make the patch tight and clear.
>
> What's the best way to adapt for EDAC driver?
> * To simplify the code based on AMD
On 2018-08-21 16:13, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 12:14:58AM +0800, Pu Wen wrote:
...
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb..3cefb25 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -211,7 +211,8 @@ static
On 2018-08-21 16:13, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 12:14:58AM +0800, Pu Wen wrote:
...
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb..3cefb25 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -211,7 +211,8 @@ static
On Mon, Aug 20, 2018 at 12:14:58AM +0800, Pu Wen wrote:
> To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
> vendor checking for Hygon by using the code path of AMD 0x17. Add a
> vendor field to struct amd64_pvt and initialize it in per_family_init
> for vendor checking.
>
>
On Mon, Aug 20, 2018 at 12:14:58AM +0800, Pu Wen wrote:
> To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
> vendor checking for Hygon by using the code path of AMD 0x17. Add a
> vendor field to struct amd64_pvt and initialize it in per_family_init
> for vendor checking.
>
>
To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
vendor checking for Hygon by using the code path of AMD 0x17. Add a
vendor field to struct amd64_pvt and initialize it in per_family_init
for vendor checking.
Also Hygon PCI Device ID DF_F0/DF_F6(0x1460/0x1466) of Host bridges
is
To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
vendor checking for Hygon by using the code path of AMD 0x17. Add a
vendor field to struct amd64_pvt and initialize it in per_family_init
for vendor checking.
Also Hygon PCI Device ID DF_F0/DF_F6(0x1460/0x1466) of Host bridges
is
20 matches
Mail list logo
