[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZJpJj7FVv25enweO3_cEdGLrJib3nzgCSDn8jY888AWQ@mail.gmail.com>
Date: Thu, 24 Oct 2019 14:38:44 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Gao Xiang <xiang@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>
Subject: Re: [RFC PATCH 0/3] watchdog servicing during decompression
On Thu, Oct 17, 2019 at 2:34 PM Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
> On 17/10/2019 14.03, Russell King - ARM Linux admin wrote:
> > We used to have this on ARM - it was called from the decompressor
> > code via an arch_decomp_wdog() hook.
> >
> > That code got removed because it is entirely unsuitable for a multi-
> > platform kernel. This looks like it takes an address for the watchdog
> > from the Kconfig, and builds that into the decompressor, making the
> > decompressor specific to that board or platform.
> >
> > I'm not sure distros are going to like that given where we are with
> > multiplatform kernels.
That's a very good point.
What we have for debug UART etc is explicitly just for
debugging on one specific platform and not for production
code.
But as pointed out there is code like this already.
> This is definitely not for multiplatform kernels or general distros,
> it's for kernels that are built as part of a BSP for a specific board -
> hence the "Say N unless you know you need this.".
Not much to do about that, we need to support it already and
adding another usecase just makes it more reasonable to
support I think.
What we need to think about is whether we can imagine some
solution that would work with multiplatform.
At one point we discussed putting some easily accessible
values in the device tree for the "decompressing...." message,
so easy to get at that the decompressor could access them
easily, or even providing a small binary code snippet in the
DTB file to write to the UART. None of this worked out
IIUC.
I think nothing really materialized from this and the problem
is swept under the carpet: no decompress messages for
multiplatform. I tried to think about something and just feel
I would be reinventing mach-types.
Do we have an idea of whether it is possible to dig into
a DTB in early boot and find the node for the UART and
watchdog and use the physical address from there?
Is it really hard or is it just that no-one tried?
(Sorry if this is a naive question...)
Yours,
Linus Walleij
Powered by blists - more mailing lists