Message ID | 20241003183848.58626-1-beanhuo@iokpp.de |
---|---|
Headers | show |
Series | Add multiple FFU modes based on eMMC specification 6.6.18 for flexible firmware updates | expand |
> 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