[PATCHv3 0/5] FWU: Handle meta-data in common code

[Michal Simek]

On 1/18/23 15:13, Jassi Brar wrote:
> On Wed, Jan 18, 2023 at 7:28 AM Michal Simek <michal.simek at amd.com> wrote:
>>
>> Hi,
>>
>> On 1/2/23 19:25, Jassi Brar wrote:
>>> The patchset reduces ~400 lines of code, while keeping the functionality same and making
>>> meta-data operations much faster (by using cached structures).
>>>
>>> Issue:
>>>    meta-data copies (primary and secondary) are being handled by the backend/storage layer
>>> instead of the common core in fwu.c (as also noted by Ilias)  that is, gpt_blk.c manages
>>> meta-data and similarly raw_mtd.c will have to do the same when it arrives. The code
>>> could by make smaller, cleaner and optimised.
>>>
>>> Basic idea:
>>>    Introduce  .read_mdata() and .write_mdata() in fwu_mdata_ops  that simply read/write
>>> meta-data copy. The core code takes care of integrity and redundancy of the meta-data,
>>> as a result we can get rid of every other callback .get_mdata() .update_mdata()
>>> .get_mdata_part_num()  .read_mdata_partition()  .write_mdata_partition() and the
>>> corresponding wrapper functions thereby making the code 100s of LOC smaller.
>>>
>>> Get rid of fwu_check_mdata_validity() and fwu_mdata_check() which expected underlying
>>> layer to manage and verify mdata copies.
>>> Implement  fwu_get_verified_mdata(struct fwu_mdata *mdata) public function that reads,
>>> verifies and, if needed, fixes the meta-data copies.
>>>
>>> Verified copy of meta-data is now cached as 'g_mdata' in fwu.c, which avoids multiple
>>> low-level expensive read and parse calls.
>>> gpt meta-data partition numbers are now cached in gpt_blk.c, so that we don't have to do expensive part_get_info() and uid ops.
>>
>> First of all I have strong suspicious that this series are pretty much two
>> series at once.
>>
> Yes, I submitted two patchsets.
> 1) Optimizing the api of current fwu.
> 2) Introduce support for mtd backed storage (DeveloperBox platform as
> an instance) using the new api.
> 
> They appear just fine in my inbox. Do they appear bad to you?


Take a look here.
https://lore.kernel.org/all/20230102182532.2411125-1-jaswinder.singh@linaro.org/#r
where you can see two series in the same thread.

And this pretty much confuse b4.

> 
>>
>> The second issue is that you are sending patches from
>> Jassi Brar <jassisinghbrar at gmail.com>
>> but SOB is
>> Signed-off-by: Jassi Brar <jaswinder.singh at linaro.org>
>>
>> And Tom said in past that they should match. There is a hook for it to check it
>> which everybody should be using. That's why please fix this in the next series.
>>
> I have submitted dozens of patches and pull requests over the last
> many years. This never occurred to anybody.

It really depends how you download that patches.

Thanks,
Michal