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 <jerry.hoem...@hpe.com>
> ---
> 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.
> break;
> case 15:
> pr_attr(name, "%d.%d.%d.%d (%.2d/%.2d/%d)",
--
Jean Delvare
SUSE L3 Support
