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

[Marek Vasut]

On 6/19/19 4:38 PM, Sam Protsenko wrote:
> 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 :)

Good, that's what I want to know. I'll delegate the rest to Lukasz.

> 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


-- 
Best regards,
Marek Vasut