[PATCH 0/7] binman: Check code-coverage requirements

Simon Glass sjg at chromium.org
Tue Mar 4 14:10:27 CET 2025


Hi Tom,

On Thu, 27 Feb 2025 at 10:04, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Feb 27, 2025 at 09:25:25AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 25 Feb 2025 at 14:53, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Feb 25, 2025 at 02:44:12PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 25 Feb 2025 at 14:31, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Tue, Feb 25, 2025 at 02:26:39PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 25 Feb 2025 at 14:06, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Feb 25, 2025 at 01:06:25PM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > This series adds a cover-coverage check to CI for Binman. The iMX8 tests
> > > > > > > > are still not completed, so a work-around is included for those.
> > > > > > > >
> > > > > > > > A few fixes are included for some other problems.
> > > > > > > >
> > > > > > > >
> > > > > > > > Jiaxun Yang (1):
> > > > > > > >   binman: Workaround lz4 cli padding in test cases
> > > > > > > >
> > > > > > > > Simon Glass (6):
> > > > > > > >   binman: Exclude dist-packages and site-packages
> > > > > > > >   binman: Drop GetRootSkipAtStart()
> > > > > > > >   binman: fit: Drop unused code
> > > > > > > >   binman: Drop algo check in CheckSetHashValue()
> > > > > > > >   binman: Workaround missing test coverage
> > > > > > > >   CI: Run code-coverage test for Binman
> > > > > > >
> > > > > > > While we likely need Jiaxun's fix in order to be able to update to
> > > > > > > Ubuntu 24.04, the series itself doesn't apply to -next, please rebase if
> > > > > > > you intend for this to be in mainline, thanks.
> > > > > >
> > > > > > OK, would you able to pick this series up?
> > > > > >
> > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=444576
> > > > >
> > > > > It also doesn't apply. You should really put together a PR, against
> > > > > next.
> > > >
> > > > Oh, it needs another patch anyway. I'll send a v2. Once that is in I
> > > > can rework this one.
> > >
> > > Again, it would be helpful if you would send a PR and always base your
> > > patches on the appropriate upstream branch.
> >
> > I understand that, and I'm happy to rebase / resend when you are ready
> > to apply. I'd like to keep the diff as small as we can. But I don't
> > think it should hold up reviews, otherwise we're just going to diverge
> > further. When you reject patches for your tree I typically apply them
> > to my tree in the hope that they might find favour in future.
>
> I think you've got this backwards still.
>
> > For the skip-at-start series I sent a series, which you have seen.
>
> Yes, and what blocked them to start with is they defaulted to your tree
> and not mainline.

I can send a pull request for things, but your tree is missing things
and that seems to be growing over time.

As you have seen, I sent [1] to test the water so we'll see how it fares.

>
> > Speaking of patches, the PXE series seems to have got lost. It is
> > 'changes requested' but I'm not sure what changes are needed.
>
> The changes requested was that it breaks lwIP + tftp. You asked that I
> ignore that since it wasn't failing in public CI, I said it was failing
> in my CI. I then noticed that it should have failed in public CI (and
> likely was on Azure, but that's often overloaded enough I cancel runs
> when I see failures elsewhere). So I then fixed public CI so that the
> lwIP platforms there too should fail.

Well I did offer to add a test in my lab...I'll take another look at some point.

>
> > I also just found the membuf thing was never applied.
>
> Was that the one where Rasmus asked you to do it differently?

Yes and I spent quite a bit of time investigating, and replied, but
didn't see any further response. The power-of-two idea is too
restrictive and anyway is beyond the scope of my series which is
mostly to add some tests and align the naming better with U-Boot. I
did suggest some follow-on ideas. Anyway, I am wanting to use it in
future series, so it would be good to apply it.

Regards,
SImon

>
> --
> Tom

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=446179
[2] https://patchwork.ozlabs.org/project/uboot/cover/20241018030027.842749-1-sjg@chromium.org/


More information about the U-Boot mailing list