[PATCH 00/18] vbe: Series part D

[Simon Glass]

Hi Tom,

On Fri, 20 Sept 2024 at 18:40, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Sep 20, 2024 at 06:04:05PM +0200, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 20 Sept 2024 at 17:01, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Sep 20, 2024 at 09:25:53AM +0200, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 30 Aug 2024 at 03:46, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Thu, Aug 29, 2024 at 07:06:32PM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 29 Aug 2024 at 18:49, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Aug 28, 2024 at 04:16:55PM -0600, Simon Glass wrote:
> > > > > > > > Hi Peter,
> > > > > > > >
> > > > > > > > On Wed, 28 Aug 2024 at 03:59, Peter Robinson <pbrobinson at gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > > This includes various patches towards implementing the VBE abrec
> > > > > > > > >
> > > > > > > > > What is abrec?
> > > > > > > >
> > > > > > > > It's a VBE method which supports A, B and recovery images and permits
> > > > > > > > updating from SPL onwards. The idea is that you can safely update
> > > > > > > > without bricking a device.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > bootmeth in U-Boot.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Simon Glass (18):
> > > > > > > > > >   sandbox: Add missing header file
> > > > > > > > > >   bootstd: Add stub for bootdev_setup_for_sibling_blk()
> > > > > > > > > >   gzip: Correct function comment for gunzip()
> > > > > > > > >
> > > > > > > > > Is this from upstream gzip code somewher?
> > > > > > > >
> > > > > > > > I'm not sure, actually.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >   fdtdec: Support separate BSS for all XPL builds
> > > > > > > >
> > > > > > > > Needed so that VPL can use DDT
> > > > > > > >
> > > > > > > > > >   tiny-printf: Correct return values
> > > > > > > >
> > > > > > > > I can't remember, sorry.
> > > > > > > >
> > > > > > > > > >   tpl: Support numbered aliases in device tree
> > > > > > > >
> > > > > > > > The MMC needs to be accessed using its sequence number
> > > > > > > >
> > > > > > > > > >   ram: Support driver model in TPL
> > > > > > > >
> > > > > > > > That should say VPL...but again I'm not quite sure
> > > > > > > >
> > > > > > > > > >   serial: Support debug UART in TPL
> > > > > > > >
> > > > > > > > This allows debugging of the jump from TPL to VPL
> > > > > > > >
> > > > > > > > > >   armv8: Support not having separate BSS
> > > > > > > >
> > > > > > > > VPL doesn't want a separate BSS since SDRAM isn't available that early
> > > > > > > >
> > > > > > > > > >   arm: cache: Drop a stale comment
> > > > > > > >
> > > > > > > > Just something I noticed
> > > > > > > >
> > > > > > > > > >   arm: Fix up a stale comment in sections.c
> > > > > > > >
> > > > > > > > Another thing I noticed
> > > > > > > >
> > > > > > > > > >   mmc: Support driver model in TPL
> > > > > > > >
> > > > > > > > TPL needs to read VPL from MMC
> > > > > > > >
> > > > > > > > > >   mmc: Add more debugging for SPL
> > > > > > > > > >   mmc: Log the error when init fails
> > > > > > > > > >   mmc: rockchip: Log some error returns
> > > > > > > > > >   mmc: rockchip: Allow clocks to be missing
> > > > > > > >
> > > > > > > > These all help with debugging reading of VPL from the correct MMC device
> > > > > > > >
> > > > > > > > > >   rockchip: mmc: Fix a missing colon
> > > > > > > >
> > > > > > > > Just something I noticed
> > > > > > > >
> > > > > > > > > >   rockchip: Provided SPL control over efuse presence
> > > > > > > >
> > > > > > > > We don't want this driver in TPL or VPL
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I'm not sure what most of these patches have to do with VBE?
> > > > > > > >
> > > > > > > > Basically there are a lot of little tweaks needed.
> > > > > > >
> > > > > > > Well, I think this gets back to some common feedback. You have a lot of
> > > > > > > little bugfixes, which is good, but they get sprinkled in to the next
> > > > > > > big series you post, which is bad and hard to review. And that leads to
> > > > > > > fixes not getting merged / reviewed timely because nominally simple fix
> > > > > > > A is in part 3 of a series to introduce something larger and to which
> > > > > > > there is feedback to work through.
> > > > > >
> > > > > > I actually thought I was splitting them up quite nicely. What do you suggest?
> > > > >
> > > > > I would refer back to your own comments about what some of the patches
> > > > > do and say that "Just something I noticed" should be a one off, and
> > > > > little fixes for this-and-that should be a 1-2 part series and so on.
> > > >
> > > > I really don't have a great workflow for keeping track of more than
> > > > 6-8 pending series and even that is sometimes a struggle. For testing
> > > > I need everything applied so I have every series in a sequence applied
> > > > locally.
> > > >
> > > > I will have a think about what can be done. I wonder how others do it?
> > >
> > > I believe the answer is multiple branches and merging them as needed. Or
> > > what I do is make each subsequent series a branch off the previous one
> > > (and set the upstream appropriately) and then rebase as needed.
> >
> > OK. That is my current workflow, but it can get out of hand,
> > particularly something like VBE abrec where over 100 patches in 6
> > -or-so different series are needed. I suppose that is why I keep
> > putting over doing the final two series...
>
> That should make re-branching things easier? Get your whole set of
> things in roughly good order then you can:
> git branch vN-fixes-foo commit-hash1
> git branch vM-fixes-bar commit-hash2
> ...
> git branch -u vN-fixes-foo commit-hash1 vM-fixes-bar commit-hash2
> ...
>
> And there's your series broken up and re-branched so you can have
> however many branches you need to split everything up in to something
> reviewable and mergeable in parts. Taking one of your branches that has
> everything and rebasing that on a new upstream commit that has some
> branches but not all merged should get things correct and drop the now
> upstream parts.

Yes, that's what I do. But I have no tooling to manage it, so it is
quite error-prone. I have a manual note of the series order, but as I
say, if it gets too large I just lose track.

Regards,
Simon