Re: [PATCH 1/3] nfit: Account for table size length variation

["Verma, Vishal L" <vishal.l.verma@intel.com>]

On Tue, 2015-11-24 at 11:24 -0500, Linda Knippers wrote:
> 
> Actually, the spec is pretty clear in this case.  If you look at the
> length definition for that table (5-133) it says:
> 
> 	Length in bytes for entire structure.
> 	The length of this structure is either 32 bytes or 80 bytes. The
> 	length of the structure can be 32 bytes only if the Number of
> 	Block Control Windows field has a value of 0.
> 
> The structure is 80 bytes but it is legal to have a 32-byte table.
> We hit a similar problem with the original NFIT code.  We could
> explicitly check for a size of 32 but we didn't before.

Thanks, I missed that. No objections from me any more :)

> 
> > If we make add_tables process only header.length and accept the
> > shortened table, there is nothing to tell future code that the
> > structure
> > that piece of memory is casted to is a truncated one.
> > 
> > Thoughts?
> 
> If we want to be more paranoid about buggy FW when we're comparing old
> and new tables, we could compare based on the length of the old and
> new
> tables since we have both pieces of information.  That would let you
> catch
> the case where a table size changes during a hotplug event or whenever
> the
> _FIT is processed.  Since you were comparing based on structure size
> instead
> of header length, I didn't change that.

Agreed this can be incremental work.

> 
> -- ljk
> > 
> > 	-Vishal
> > 
>