On Tue, Apr 08, 2025 at 04:11:17PM +0200, Jean Delvare wrote:
> Hi Jerry,
>
> On Thu, 2025-04-03 at 19:37 -0600, Jerry Hoemann wrote:
> > Decode of Version Data Format 0E is five bytes, not four.
> >
> > Fixes: 9d2bbd5db427b063da ("dmioem: Decode HPE OEM Record 216")
> > Signed-off-by: Jerry Hoemann <[email protected]>
> > ---
> > dmioem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/dmioem.c b/dmioem.c
> > index 1df77ec..0cc16a9 100644
> > --- a/dmioem.c
> > +++ b/dmioem.c
> > @@ -580,7 +580,7 @@ static void dmi_hp_216_version(u8 format, u8 *data)
> > pr_attr(name, "%d", data[0]);
> > break;
> > case 14:
> > - pr_attr(name, "%d.%d.%d.%d", data[0], data[1], data[2],
> > data[3]);
> > + pr_attr(name, "%d.%d.%d.%.4d", data[0], data[1], data[2],
> > WORD(data+3));
>
> I'd rather use %04d for consistency, as it seems to behave the same as
> %.4d (to be honest, I don't understand why precision is supported with
> %d in the first place).
>
> Also, is WORD(data+3) guaranteed to be < 9999? If not then left padding
> to 4 digit is kind of inconsistent.
>
> Lastly, I must say I'm surprised that you zero-pad only the last
> component of the version string. But you'll know better.
The final field is build number. I was trying avoid the situation
where build 30 looked "bigger" than build 1000.
I failed to find any definitive documentation on range of build numbers
or recommended display. Will switch back to plain old "%d".
>
> > break;
> > case 15:
> > pr_attr(name, "%d.%d.%d.%d (%.2d/%.2d/%d)",
>
> --
> Jean Delvare
> SUSE L3 Support
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------
