[PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and appended DTB
Christian Marangi
ansuelsmth at gmail.com
Thu Jun 13 06:42:45 PDT 2024
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)
--
Ansuel
More information about the linux-arm-kernel
mailing list