[U-Boot] [PATCH v3] fastboot: Remove "slot-suffixes" variable

[Sam Protsenko]

On Wed, Jun 19, 2019 at 4:52 PM Marek Vasut <marex at denx.de> wrote:
>
> On 6/19/19 2:14 PM, Sam Protsenko wrote:
> > On Tue, Jun 18, 2019 at 7:31 PM Marek Vasut <marek.vasut at gmail.com> wrote:
> >>
> >> On 6/18/19 4:57 PM, Sam Protsenko wrote:
> >>> Hi Marek,
> >>>
> >>> As you mentioned USB PR is now open, please apply this patch in u-boot-usb.
> >>
> >> Fastboot is gadget stuff, so that's up to Lukasz.
> >> Is this a bugfix ?
> >>
> >
> > No, this is not a bugfix. In this topic:
> >
> >     [U-Boot] [PULL] u-boot-usb/master
> >
> > you mentioned to me:
> >
> >     "Please do, the USB PR is now in."
> >
> > Maybe I misunderstood you, but I though I had to re-send V2 (which is
> > not a bugfix, and won't applied to v2019.07) on top of V1 (which is
> > already applied). So basically this patch is not for v2019.07, but for
> > later release (should be applied when merge window opens). Sorry for
> > confusion.
>
> The v1 is in, shall it be reverted then ? I am quite confused myself now.
>

Shortly: IMHO, leave it all as is, and please apply V3 when merge
window opens :)

Details:
  1. It was never my intention to get this patch merged into v2019.07
exactly (even V1). I just sent it because I found out that this should
be done to make U-Boot's fastboot work with AOSP/master, when user
have partitions like ("boot_a", "system_a") in the partition table.
But right now there are none users like this in U-Boot (grep shows it
instantly). And also A/B switching algorithm is not implemented in
U-Boot yet (we are working on it right now). So it doesn't matter, if
we apply this patch for v2019.07 or for the next release. Basically
this is a preparation for the near future, when we we'll have slotted
partitions ("boot_a", "boot_b") for Android devices in U-Boot.
  2. This patch (merged V1 and this V3) can break U-Boot compatibility
with old fastboot tools, but it fixes U-Boot w.r.t. new fastboot tool.
I don't see any sane (automatic) way to provide backward compatibility
right now, as fastboot basically lacks of protocol version. But again,
I don't think that's an issue, as I don't see any A/B users in
upstream U-Boot right now.
  3. All that said, I think that either way of merging this is fine.
So if V1 is already merged, I suggest keeping it merged, and when
merge window opens, let's merge V3. Just to spare any extra work.
Because *right now* it doesn't break and doesn't fix anything.

Later I'm gonna send another patch-series for adding new fastboot
variables, which was recently added in fastboot tool. Seems like
Google undergoes some changes w.r.t. fastboot protocol, because of new
"dynamic partitions" requirements, but they forget to keep versioning
in sync. So maybe later I will add some compat mechanism, like
variable or config option. But that will be done for the next release,
of course.

Hope now it's clear. Sorry for any confusion induced.

Another (more general) question is: should I wait for merge window to
open before sending any patches, if those are not fixes? If no, should
I indicate somehow that some particular patch should be / shouldn't be
merge into -rc?

Thanks!

> --
> Best regards,
> Marek Vasut