On Mon, 2024-10-14 at 06:56 +0000, Avri Altman wrote:
> > + } else if (ffu_mode == 2) {
> > + set_single_cmd(&multi_cmd->cmds[0],
> > MMC_SET_BLOCK_COUNT,
> > 0, 0, bytes / 512);
> > + multi_cmd->cmds[0].flags = MMC_RSP_SPI_R1 |
> > MMC_RSP_R1 |
> > MMC_CMD_AC;
> > + set_single_cmd(&multi_cmd->cmds[1],
> > MMC_WRITE_MULTIPLE_BLOCK, 1, bytes / 512, arg);
> > + mmc_ioc_cmd_set_data(multi_cmd->cmds[1], buf +
> > offset);
> > + }
> > +}
> Actually, I was hoping to avoid the "ffu_mode" extra argument.
> So that each do_ffu<x> has its own fluf encapsulation logic.
>
> Thanks,
> Avri
Thank you for the suggestion. After reviewing the approach, I believe
it's not feasible to encapsulate the above code logic entirely within
each do_ffu<x> function.
The primary reason is that during the download phase, especially when
multiple loops are required, I need to update certain state variables
dynamically, such as the ffu_mode. This allows for handling the
different stages of the process efficiently across iterations. The
encapsulation logic would prevent us from adjusting these variables
between loops, which is crucial for ensuring the proper progression and
handling of larger data sets.
Without this flexibility, we'd run into issues when the process
requires multiple passes or loops, making it difficult to adjust the
behavior mid-operation.
Let me know if you have any further suggestions, or if you'd like to
discuss alternate solutions.
Kind regards,
Bean
