[PATCH 00/17] Various toolchain compatibility fixes/improvements

[Tom Rini]

On Fri, Mar 07, 2025 at 10:48:11PM -0800, Sam Edwards wrote:
> On Thu, Mar 6, 2025 at 7:47 AM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Mar 05, 2025 at 07:46:56PM -0800, Sam Edwards wrote:
> > > On Sun, Feb 23, 2025 at 9:55 PM Sam Edwards <cfsworks at gmail.com> wrote:
> > > >
> > > > Long time no see, U-Boot folks!
> > > >
> > > > This patchset consists of various bug fixes and correctness improvements that
> > > > I discovered while attempting to add first-class LLVM support to the build
> > > > system. These patches are NOT related to LLVM support directly; rather, they
> > > > address existing issues that should be resolved regardless of future changes.
> > > > For the most part, the patches are mutually independent and can be reviewed and
> > > > applied separately. If any patch is not suitable for merging now, feel free to
> > > > skip it: I will incorporate feedback and revisit those changes as part of the
> > > > upcoming LLVM support patchset. I'd like this patchset to be evaluated on its
> > > > own merits, based on the current state of the code, without consideration for
> > > > future LLVM support.
> > > >
> > > > Note that the issues addressed in this patchset do not occur when U-Boot is
> > > > built using the GCC/GNU toolchain. These bugs seem to be specific to builds
> > > > using other toolchains, like LLVM, and do not appear to affect users relying on
> > > > GCC/GNU. Therefore, I see no need to rush these changes into the stable branch.
> > > >
> > > > Again, these patches are mostly independent/reorderable...
> > > > ...except that: "arm: Add aligned-memory aliases to eabi_compat"
> > > > ...depends on: "arm: Add __aeabi_memclr in eabi_compat"
> > > >
> > > > Warm regards,
> > > > Sam
> > >
> > > Hi Tom,
> > >
> > > I noticed that all patches in this series have been marked 'Changes
> > > Requested' on Patchwork. While some patches do need changes, this
> > > series was intended as a set of independent submissions: each patch
> > > can be accepted, rejected, or reordered without affecting the others.
> > > Would it be possible to reconsider the remaining patches for review
> > > without resending the series?
> > >
> > > I'd like to withdraw the following patches:
> > >
> > > - [06/17] arm: Use -mstrict-align when the MMU is off (Incorrect approach)
> > > - [11/17] makefile: Fix symbol typo in binary_size_check (Will follow
> > > Simon's suggestion for a more comprehensive fix across architectures
> > > in a future submission)
> > >
> > > The feedback I've received so far was mostly requests for
> > > clarification, which I believe I've addressed in my replies. Please
> > > let me know if anything remains unclear or if further adjustments are
> > > needed.
> > >
> > > Thank you so much for your time!
> >
> > It's *really* hard to track parts of a series in that way. If they
> > aren't intended to be applied all in one go, please post them
> > individually as v2s. The clarifications likely mean a bit more rewording
> > of the commit messages are in order.
> >
> > If it's really hard on your end to resend things, I can go and poke
> > through the series (once Ilias has had time to do the reviews I see he
> > promised).
> 
> Hi Tom,
> 
> Well... that's "hard" but not "really hard" for me, so I think what
> I'll pitch is this: let's let Ilias (and others if so inclined) have a
> week to pick through the series (thanks Ilias!) and offer feedback;
> I'll resend any patches that get no/positive feedback as a v2 series
> (where the "just skip any patch deemed objectionable" option will
> still apply), and any patches that need reworking can be part of my
> upcoming LLVM support series. Would that work?

Yes, thanks!

-- 
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/20250310/e3e17b0f/attachment.sig>