Hi Tom, On Fri, 20 Sept 2024 at 18:40, Tom Rini <tr...@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 <tr...@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 <tr...@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 <tr...@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 > > > > > > > > <pbrobin...@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
