linux-kernel - Re: [PATCH v1 0/9] Fix Allwinner D1 boot regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87jzgjnh9z.ffs@tglx>
Date: Wed, 14 Aug 2024 19:30:48 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Emil Renner Berthing <emil.renner.berthing@...onical.com>,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org, Anup Patel
 <apatel@...tanamicro.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>, Samuel Holland
 <samuel.holland@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert
 Ou <aou@...s.berkeley.edu>, Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: Re: [PATCH v1 0/9] Fix Allwinner D1 boot regression

On Wed, Aug 14 2024 at 16:56, Emil Renner Berthing wrote:
> As described in the thread below[1] I haven't been able to boot my
> boards based on the Allwinner D1 SoC since 6.9 where you converted the
> SiFive PLIC driver to a platform driver.
>
> This is clearly a regression and there haven't really been much progress
> on fixing the issue since then, so here is the revert that fixes it.
>
> If no other fix is found before 6.11 I suggest we apply this.

So this mess has been ignored for two month now?

>From the pastebin in the initial report:

[    0.000000] irq: no irq domain found for interrupt-controller@...00000 !
[    0.000000] Failed to map interrupt for /soc/timer@...0000
[    0.000000] Failed to initialize '/soc/timer@...0000': -22

This comes back with -EINVAL. So the timer cannot find an interrupt,
which makes it pretty obvious why the system stops to boot, unless there
is some other timer available.

This is obviously related to the SUN4I_TIMER because that message went
away when it was disabled according to the next pastebin.

Obviously that can't work because the SUN4I timer driver is using
timer_of_init() which cannot handle deferred probing.

Daniel: There was a partial fix for the sun4i driver, which you said you
applied:

  https://lore.kernel.org/all/20240312192519.1602493-1-samuel.holland@sifive.com

But that thing never materialized in a pull request.

And of course everyone involved ignored the problem since March 13th
2024, i.e. almost half a year.

Seriously?

Can you RISCV folks get your act together and ensure to fix things you
broke on the way? Especially when Emil reported this nobody pointed him
to this patch and nobody noticed that it's still not merged?

It took me less than 15 minutes to find that patch and the correlation,
but this is absolutely not my job.

I'm seriously grumpy about that. This is not how it works. If you break
stuff, then you take care to fix it before you shove more changes into
the tree and waste my time.

I'm very much inclined to take the reverts right now, send them to Linus
for -rc5 tagged with cc: stable and ignore/nak any irqchip related riscv
patches until the next merge window is over.

Emil, can you give that sun4i fix a test ride please?

Thanks,

        tglx