Re: [PATCH 11/16 v2] Input: atmel_mxt_ts - refactor reading object table

["Henrik Rydberg" <rydberg@euromail.se>]

> > I am talking about the data that is being read here and written in
> > mxt_check_reg_init(). By matching the struct with that data, all the
> > copies you make would go away.
> 
> The data read here is a table of object descriptors.  The data written
> in mxt_check_reg_init() is configuration data for each of the objects
> described by the descriptors.  What copies are you talking about?

In this patch, the object descriptors are read into a buffer, then
copied over to the object struct that you hold. That is the copy that
obviously goes away if the data is copied directly into the suggested
struct. In patch 9, you copy an unknown amount of data over to a
stack-allocated buffer before sending it via ic2. That is the main
technichal concern, and it was the first question you got, some days
ago.

> The config array in platform_data is a single big long array that has
> to be manually created in a platform file.  It just has blobs of data
> for each of the 'writable' objects for a given device, all
> concatenated together.

Ok, so no need for the second suggested struct or anything of that
kind. Just sort out the maximum blob size and, if necessary, avoid the
stack allocation in mxt_check_reg_init(), and it should be fine.

Henrik