[PATCH 00/18] vbe: Series part D

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240920/3b22103b/attachment.sig>