On 25-03-12, Sascha Hauer wrote: > On Tue, Mar 11, 2025 at 02:42:07PM +0100, Marco Felsch wrote: > > > struct fip_state *fip_image_open(const char *filename, size_t offset) > > > { > > > @@ -470,11 +466,13 @@ struct fip_state *fip_image_open(const char *filename, size_t offset) > > > int ret; > > > int fd; > > > struct fip_state *fip_state; > > > - LIST_HEAD(entries); > > > size_t fip_headers_size, total = 0; > > > - struct fip_image_desc *desc; > > > off_t pos; > > > int n_entries = 0; > > > + struct fip_toc_entry toc_entries[16]; > > ^ > > Why did you used 16? > > Okay okay, I allocated the entries dynamically now to support an > arbitrary number of toc entries. Nice, thanks :) > > Sascha > > -------------------------------8<------------------------------ > > From 87bc7468e698e3404345ee601885ec186de7f4fa Mon Sep 17 00:00:00 2001 > From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > Date: Tue, 11 Mar 2025 13:25:18 +0100 > Subject: [PATCH] fip: rework fip_image_open() > > fip_image_open() used to do all the parsing into a struct fip_state > itself. Instead, only load the FIP image into a buffer and call > fip_do_parse_buf() with this buffer. This has the advantage that we > have all parsing of the FIP image in a single place. Also this helps > with a followup patch which calculates a sha256 over a FIP image > which can easily done when we have the whole FIP image in a contiguous > buffer. > > Link: https://lore.kernel.org/r/20250311-am625-secure-v2-5-3cbbfa092346@xxxxxxxxxxxxxx > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> Reviewed-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> if not already to late.