> Hi,
> Thank you for this series.
>
> > Hi Avri, Ulf
> >
> > Following the discussions with Avri at the 2024 ALPSS, I am submitting
> > these patches to introduce multiple FFU modes, as defined in the eMMC
> > specification 6.6.18.
> >
> > The new FFU implementation can support diverse vendor requirements and
> > operational conditions.
> Ack on that.
> I concur that various devices may respond better to different mode.
> Thus, allowing different modes to choose from, improves the overall
> operational stability.
>
> Will try to review it early next week.
Gave it a quick look, and some stuff concerning your design pops up:
1) You are changing the api to follow a more common optarg mode.
While I agree that this is a most welcome enhancement - it should be done in its own designated series,
And in a way that will not break the legacy api.
2) given the extent of use of this feature - I don't think that the api of the current mode (default) should be changed.
Meaning people should still be able to run ./mmc ffu <fluf> <dev> as they always did.
3) Essentially by adding modes you are mainly changing the part that encapsulates the content of the multi-ioctl.
If instead of adding a new mode argument, you would add new commands - I think you would end up with much less code.
Meaning, we would have now:
./mmc ffu <fluf> <dev> /* the current (default) mode */
./mmc ffu2 <fluf> <dev> /* mode 2 */
./mmc ffu3 <fluf> <dev> /* mode 3 */
Etc.
And each vendor / FAEs / validation team etc. would be able to choose whatever suite best.
Please also note that we have a man page and a docs section.
Will give it a thorough look next week.
Thanks,
Avri
>
> Thanks,
> Avri
