[PATCH] x86: Correct condition for init_cache_f_r()

[Tom Rini]

On Wed, Jun 04, 2025 at 12:20:17PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 4 Jun 2025 at 11:23, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Jun 04, 2025 at 10:17:32AM -0600, Simon Glass wrote:
> > > Hi Jerome,
> > >
> > > On Wed, 4 Jun 2025 at 07:15, Jerome Forissier
> > > <jerome.forissier at linaro.org> wrote:
> > > >
> > > > On 6/4/25 15:09, Simon Glass wrote:
> > > > > The condition here is reversed, which makes link and coral very slow,
> > > > > leading to lab failures.
> > > > >
> > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > Fixes 6c171f7a184 ("common: board: make initcalls static")
> > > > > ---
> > > > >
> > > > >  common/board_f.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/common/board_f.c b/common/board_f.c
> > > > > index bff465d9cb2..c8a612d6070 100644
> > > > > --- a/common/board_f.c
> > > > > +++ b/common/board_f.c
> > > > > @@ -1079,7 +1079,7 @@ void board_init_f(ulong boot_flags)
> > > > >   */
> > > > >  static void initcall_run_f_r(void)
> > > > >  {
> > > > > -#if CONFIG_IS_ENABLED(X86_64)
> > > > > +#if !CONFIG_IS_ENABLED(X86_64)
> > > > >       INITCALL(init_cache_f_r);
> > > > >  #endif
> > > > >  }
> > > >
> > > > Sorry for that mistake.
> > > >
> > > > Reviewed-by: Jerome Forissier <jerome.forissier at linaro.org>
> > >
> > > It's fine. I only noticed it because the lab tests started failing (I
> > > have a short boot timeout on one of the boards).
> > >
> > > Do you think some of the conditions could use if() instead of #if now?
> >
> > I'm not sure the readability nor code coverage will be improved by that
> > in this file.
> 
> In some cases it would help, I think, but I suppose it would be better
> to remove more or them, or replace with events.
> 
> > And please find the time to reply to my thread about your
> > future in the project before making further suggestions about the
> > overall code base, thanks.
> 
> On that front, we'll need to discuss the options. We could find a bit
> of time in the next call perhaps, or set up some specially.

No, the first step is that I want you to say, in public and in writing,
what your intentions are. For the public record and so the community at
large knows and can see. Until that point, I'm not going to engage
further with you. This thread was about a regression fix, so I took it.
Your PR for -next was changes that I would have taken anyhow, and I took
as an act of good faith. But that's it.

-- 
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/20250604/e09f5a13/attachment.sig>