dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] [PATCH] Support new byte value of Processor Upgrade fiel


From: Jean Delvare
Subject: Re: [dmidecode] [PATCH] Support new byte value of Processor Upgrade field from SMBIOS 3.5.0
Date: Mon, 18 Oct 2021 18:49:33 +0200

On Mon, 18 Oct 2021 20:05:54 +0800, Coiby Xu wrote:
> On Mon, Oct 18, 2021 at 07:22:48PM +0800, Coiby Xu wrote:
> >Hi Jean,
> >
> >On Mon, Oct 18, 2021 at 12:26:50PM +0200, Jean Delvare wrote:  
> >>Hi Coiby,
> >>
> >>On Mon, 18 Oct 2021 10:24:48 +0800, Coiby Xu wrote:  
> >>>Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz has byte value 3Fh which
> >>>means Socket LGA4677 for Processor Information - Processor Upgrade
> >>>field.
> >>>
> >>>Signed-off-by: Coiby Xu <coxu@redhat.com>
> >>>---
> >>> dmidecode.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/dmidecode.c b/dmidecode.c
> >>>index 0b44182..27664e1 100644
> >>>--- a/dmidecode.c
> >>>+++ b/dmidecode.c
> >>>@@ -1394,7 +1394,8 @@ static const char *dmi_processor_upgrade(u8 code)
> >>>           "Socket BGA1510",
> >>>           "Socket BGA1528",
> >>>           "Socket LGA4189",
> >>>-          "Socket LGA1200" /* 0x3E */
> >>>+          "Socket LGA1200",
> >>>+          "Socket LGA4677" /* 0x3F */
> >>>   };
> >>>
> >>>   if (code >= 0x01 && code <= 0x3E)  
> >>
> >>You apparently didn't test your patch on the system in question.  
> >
> >Thanks for the hint about my mistake! I did test it but it was done so 
> >carelessly that I didn't realize Intel(R) Xeon(R) Platinum has 
> >Processor Upgrade Socket LGA4189 and current version could already 
> >parse it correctly.
> >
> >Btw, do you think it's better to dynamically calculate number like 0x3E by
> >array_lengh + 1? Previously I made the same mistake when updating   
>   ^^^^^^^^^^^^^^^
> Oh, it should be the length of array here.

This has been discussed before, and while there would be benefits in
doing so, there are also risks to get things wrong because many arrays
in dmidecode start at an index greater than 0. Sometimes 1, sometimes
2... So there's an offset to be applied between the last index and the
size of the array. So for the time being I am going for the status quo
and leaving things the way they are.

-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]