[PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and appended DTB

[Christian Marangi (Ansuel)]

Il giorno lun 2 feb 2026 alle ore 11:27 Geert Uytterhoeven
<geert at linux-m68k.org> ha scritto:
>
> Hi Christian,
>
> Trying to revive this thread...
>
> On Thu, 13 Jun 2024 at 18:51, Christian Marangi <ansuelsmth at gmail.com> wrote:
> > On Thu, Jun 13, 2024 at 04:59:49PM +0100, Russell King (Oracle) wrote:
> > > On Thu, Jun 13, 2024 at 03:50:58PM +0200, Linus Walleij wrote:
> > > > On Thu, Jun 13, 2024 at 1:24 PM Christian Marangi <ansuelsmth at gmail.com> wrote:
> > > >
> > > > > Sorry for asking again... but any news for this?
> > > > >
> > > > > I have also added the 2 patch here [1] [2].
> > > > >
> > > > > Been in incoming from a long time and I have seen other patch getting
> > > > > accepted. Did I do something wrong in submitting the 2 patch?
> > > >
> > > > Hm Russell must have had some concerns, Russell?
> > >
> > > I've been snowed under for about the last six weeks - with only the
> > > occasional day that isn't silly. It's that kind of frustrating snowed
> > > under where each problem is a bit like a brick wall placed every 1m
> > > and you're supposed to be doing a 100m sprint race - you can't see
> > > the next brick wall until you've climbed over the first.
> > >
> > > Whether I have time to read the mailing lists or not depends entirely
> > > on what is happening on any particular day.
> > >
> > > > If for nothing else I think some Tested-by:s would be appreciated,
> > > > do we have some people who use this that can provide Tested-by
> > > > tags?
> > >
> > > Yes, tested-by's would be a really good idea, because my gut feeling
> > > is that this change has moderate risk of causing regressions. I'm
> > > not talking about "it works for me on the setup it's intended for"
> > > I'm talking about other platforms.
> > >
> > > I'm also wondering about distros, and what they're supposed to do
> > > with the config option with their "universal" kernel that's
> > > supposed to boot across as many platforms as possible, what they
> > > should set the config option to, and what impact it has when enabled
> > > on platforms that it isn't originally intended for.
> > >
> > > I haven't really read much of the patch because I've been so busy,
> > > so I may be being overly cautious. Given that I am quite busy, I
> > > would appreciate a summary of the situation rather than being fed
> > > with lots of results! In other words, the tested-bys, and "it works
> > > on all the xyz platforms that we've testsed, nothing appears to have
> > > regressed" would be ideal.
> >
> > The current patch are used downstream on the OpenWrt ipq806x target that
> > is a mix of legacy (what this affects) and non legacy targets. (old
> > bootloader support loading DTB from the image and older ones require it
> > to be appended)
> >
> > I think I need some help from the community to test this.
> >
> > I can also move these patches to our "generic" target on OpenWrt so that
> > they will be enabled by every arm target we support.
> >
> > Anyway thanks for the feedback, my only concern was that I messed
> > submitting the patch on the tracking system. Hope community can help
> > with this since it's a big feature for legacy devices that was broken
> > from a looong time (and only solution currently is to hardcode the PHY
> > offset values)
>
> FTR, I did provide my Tested-by for the first patch in [1].
> I still have this series in my local tree, which I test regularly on
> a variety of Renesas ARM32 platforms and on BeagleBone Black.
>
> In fact, I had completely forgotten about this series, to the point
> that I bisected a failure in booting mainline on one of my boards
> using my current .config to the absence of the first patch ;-)
> Apparently during the past years, I had modified my .config to make it
> more generic, and make better use of the DTB (incl. chosen/bootargs),
> which has a dependency on the first patch...
>

I mean we also use this patch from a long time on ipq806x on OpenWrt.
Would really love to have this merged as it does fix a big problem
and would permit full upstream support on all kind of """""legacy""""""
devices.

We just need more wide testing. Any clue how we can achieve this?

> The second patch is a different story (I don't need it ;-), and enabling
> the option may indeed not be suitable for distro kernels.
>

Yes the second patch is so minor it's both harmless and can also be
ignored. But it's really a 3 line change so can't see why it should be
problematic.

> Thank you!
>
> [1] https://lore.kernel.org/CAMuHMdX0dpQdZSCJGuOM0MgM3N-8OA29skARvXEkm87eOPEWBA@mail.gmail.com
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds