On Mon, 2024-10-14 at 06:55 +0000, Avri Altman wrote:
> > + __u8 num_of_cmds = 4;
> > + off_t bytes_left, off;
> > + unsigned int bytes_per_loop, sect_done, retry = 3;
> > + struct mmc_ioc_multi_cmd *multi_cmd = NULL;
> > +
> > + if (!dev_fd || !fw_buf || !ext_csd) {
> > + fprintf(stderr, "unexpected NULL pointer\n");
> > + return -EINVAL;
> > + }
> > + /* allocate maximum required */
> > + multi_cmd = calloc(1, sizeof(struct mmc_ioc_multi_cmd) +
> > num_of_cmds * sizeof(struct mmc_ioc_cmd));
> > + if (!multi_cmd) {
> > + perror("failed to allocate memory");
> > + return -ENOMEM;
> > + }
> I was expecting that do_ffu_download will be called with struct
> mmc_ioc_multi_cmd *multi_cmd argument as well.
> That each ffu<x> mode fills it according to its own logic.
> This you won't be needing that ffu_mode additional parameter.
I wanted to clarify why the ffu_mode parameter is necessary during the
download phase. By extracting the logic into a common approach and
using ffu_mode to dynamically update the multi_cmd structure across
iterations per ffu-mode, I can handle the variations between different
FFU modes more effectively. This allows me to extract more common code
and avoid duplication, as the ffu_mode helps determine which specific
updates or adjustments need to be made to the multi_cmd at each stage.
Without this, it would be difficult to manage multiple loops or
iterations of the download process, especially when the command
structure needs to be modified in different ways depending on the mode.
The use of ffu_mode centralizes this control, making the code cleaner
and more maintainable.
Kind regards,
Bean
