linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Gao Xiang <xiang@kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>
Subject: Re: [RFC PATCH 0/3] watchdog servicing during decompression
Date: Thu, 24 Oct 2019 14:38:44 +0200	[thread overview]
Message-ID: <CACRpkdZJpJj7FVv25enweO3_cEdGLrJib3nzgCSDn8jY888AWQ@mail.gmail.com> (raw)
In-Reply-To: <c4b6805b-67fe-6bce-1777-2d81e96b4ac9@rasmusvillemoes.dk>

On Thu, Oct 17, 2019 at 2:34 PM Rasmus Villemoes
<linux@rasmusvillemoes.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

      parent reply	other threads:[~2019-10-24 12:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 11:49 [RFC PATCH 0/3] watchdog servicing during decompression Rasmus Villemoes
2019-10-17 11:49 ` [RFC PATCH 1/3] decompress/keepalive.h: prepare for watchdog keepalive during kernel decompression Rasmus Villemoes
2019-10-17 11:49 ` [RFC PATCH 2/3] lib: lz4: wire up watchdog keepalive during decompression Rasmus Villemoes
2019-10-17 11:49 ` [RFC PATCH 3/3] decompress/keepalive.h: add config option for toggling a set of bits Rasmus Villemoes
2019-10-24 12:17   ` Linus Walleij
2019-10-24 13:45     ` Rasmus Villemoes
2019-10-17 12:03 ` [RFC PATCH 0/3] watchdog servicing during decompression Russell King - ARM Linux admin
2019-10-17 12:34   ` Rasmus Villemoes
2019-10-17 12:48     ` Russell King - ARM Linux admin
2019-10-24 12:38     ` Linus Walleij [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACRpkdZJpJj7FVv25enweO3_cEdGLrJib3nzgCSDn8jY888AWQ@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rasmusvillemoes.dk \
    --cc=olof@lixom.net \
    --cc=xiang@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).