On Fri, Mar 07, 2025 at 10:48:11PM -0800, Sam Edwards wrote: > On Thu, Mar 6, 2025 at 7:47 AM Tom Rini <tr...@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 <cfswo...@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
signature.asc
Description: PGP signature
