[PATCH] dmicheck: fix handling of type 16 capacities > 2 TiB

Alex Hung alex.hung at canonical.com
Wed Oct 3 09:19:45 UTC 2018


On Wed, Oct 3, 2018 at 10:09 AM Elliott, Robert (Persistent Memory)
<elliott at hpe.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Alex Hung <alex.hung at canonical.com>
> > Sent: Tuesday, October 02, 2018 7:33 PM
> > To: Elliott, Robert (Persistent Memory) <elliott at hpe.com>
> > Cc: fwts-devel <fwts-devel at lists.ubuntu.com>
> > Subject: Re: [PATCH] dmicheck: fix handling of type 16 capacities > 2
> > TiB
> >
> > Hi Robert,
> >
> > Thanks for the patch, and this seems to be similar to
> > http://patchwork.ozlabs.org/patch/974876/.
> >
> > Do you have comments on the other one, ex. yours is more complete?
>
> I think they're functionally the same; that patch is simpler.
>
> An if clause might better facilitate ensuring the structure length
> includes the Extended Maximum Capacity field in the 0x8000000 case,
> and verifying this rule from the conformance list in annex A:
> "Either Maximum Capacity or Extended Maximum Capacity must be set
> to a known, non-zero value."
>

I personally think the spec is ambiguous about 0x8000000 in Maximum
Capacity. It seems to indicate Extended Maximum Capacity should be
used but also is a valid number for 2TB (Table 70 – Physical Memory
Array (Type 16) structure).

However, 0x8000000 should be a valid value in Maximum Capacity in
either case, and both patches work for me.



More information about the fwts-devel mailing list