Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3455760ybg; Fri, 25 Oct 2019 04:30:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqxI7S+RMtY3HoxI+FLPL354L21d311rC8GD41Q82H9+uHaWPxxNN+h4Y6bkQE8MIoUPKGdt X-Received: by 2002:a17:906:3049:: with SMTP id d9mr2912331ejd.288.1572003033038; Fri, 25 Oct 2019 04:30:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572003033; cv=none; d=google.com; s=arc-20160816; b=uTVRHob9aTOVvGkVrslcnA6GNxetmf0ry03DV/mcum5XlhCyczEKlbclyEKQT70Ke6 tSaUu52tXhOO0MPDkHc98D1oLy9EELZLMJMpaUsxE4+eOUVkfVoHAP3tcVvwlh+qgJ2e fDn0M5m842qblVZwH1WPLXYF3dQlCCkAXkVwPDHN+RgRiLldX/4Z3OWV/2fWv36JO1wK 7h/PXom4PArOmpXcDKGfqFg8eWPMCSf+MpImDXpYO+1W9wMky7nkJhxeFAcujT9Mb3NO SFkq413bF4QbF5CnvhWMC/uwIb99WiEzirhWYoIsAy/DnBhbsFq+WTVJ0SZCT9OIfzyv nW+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IDVS1e9hyUEZF9b7Qqy5YnFhITXSjbGZRVGhTJdweek=; b=WfnBV/r2PEQDaJgdJioqzJRaZCU8F90t3baHcc2L/wXDgcb0N9vHYZoLBZaYYRrtiG yjbKP/5LXQZk+7ZIzJ1I3vmbS+NMlKrC5g6GEes38niZTLhdHILC171QFYKFwnXcSi0B oOHmfhy7HbGsxIRsRN4GtExvznWXJIQ49GikFPWaqDQASAIHjeAK+ZrumV63eKS5RQ4s a8FAveHKw15KSUyDptZ4yTuEZNARq7ku9wGe0V3x5PW9dgrfPUBgmkwqyDBToYuFavRb oSHZ3B6gg6ZcpkTtyDltn9Zz8wkD0ZveD7LqeJd/GWy7xKF3PLN1Q3aYVeDzoSXOLoFp Xrig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MQcij3Hn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si1064738ejb.44.2019.10.25.04.30.08; Fri, 25 Oct 2019 04:30:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MQcij3Hn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2501950AbfJXMi6 (ORCPT + 99 others); Thu, 24 Oct 2019 08:38:58 -0400 Received: from mail-ua1-f68.google.com ([209.85.222.68]:34864 "EHLO mail-ua1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727154AbfJXMi5 (ORCPT ); Thu, 24 Oct 2019 08:38:57 -0400 Received: by mail-ua1-f68.google.com with SMTP id n41so7101271uae.2 for ; Thu, 24 Oct 2019 05:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IDVS1e9hyUEZF9b7Qqy5YnFhITXSjbGZRVGhTJdweek=; b=MQcij3HnHK2jhBapvsLcbnyU0UuOTDO6+/fUMv5+ZYQ/svdkPAO8dOlLI2ab0GyqA6 GqIb8QkWf/FqsUv056i6jSnyug9+WZpSaobr+itNAD+MqNDC0GrkJG0JIe9Tu8aAqAk9 f69ncKQj0R770e8Yk05r/N2CrcHO+53N5G1GYIuczrAPdprJcw6CiPhT4Wgv19i/JmMj EJ2p/5saMFxfIE969G4ZVxgqXpRFa0ngLa2TufQoF7wp96n4YSl0+PjF6BhnBE716ntb cfeUAjX2Es4kJDzUnWsv9m3FlSga+JZAA3Pyxcwbkl0pJtKh8LW54atUoyEaxC6BL8YG wP2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IDVS1e9hyUEZF9b7Qqy5YnFhITXSjbGZRVGhTJdweek=; b=st7PsAHocX8/u037x2Y1TaXKSKKqohlBAXuEqbuZbfcQFamLBOz890V4SVqP4pK7m8 oSXv8qTTNTmfY+UGQrlSqhMCXC+0lYerkVkNv2APkYXcmHZQAGzWbpz9TlW4VHkUlemT Fs12zyopGErXNoXGFFUTfuFYIvPhWtN4601+MbRCUj1JsI2IZMEgichgZrJCtEHWXDih IcGh1p4D1sMDb+zlVg1CtsTX4pDzfJ5RRz+Ohn6SuJP1wvoEzEJUKcBA/UCNMDh5KS3I UNOzjFgXA8jbk7p6IK+o/nxQVAmrOTdD4v/bYf6i45lboyb1yCgGzylk5DpuwZ+MEbVY 19Aw== X-Gm-Message-State: APjAAAW62WHU/FlqhNbBi52gMiW8XOeX7ZgmaF0eVdw8nL585DVdCKmE g99JuHWslTWlvlCpXdU486oUz2MYEdEPzMAkG5FFpjSc X-Received: by 2002:ab0:30a1:: with SMTP id b1mr8030843uam.40.1571920736115; Thu, 24 Oct 2019 05:38:56 -0700 (PDT) MIME-Version: 1.0 References: <20191017114906.30302-1-linux@rasmusvillemoes.dk> <20191017120310.GD25745@shell.armlinux.org.uk> In-Reply-To: From: Linus Walleij Date: Thu, 24 Oct 2019 14:38:44 +0200 Message-ID: Subject: Re: [RFC PATCH 0/3] watchdog servicing during decompression To: Rasmus Villemoes Cc: Russell King - ARM Linux admin , Masahiro Yamada , Andrew Morton , Gao Xiang , Sascha Hauer , "linux-kernel@vger.kernel.org" , Linux ARM , Arnd Bergmann , Olof Johansson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 17, 2019 at 2:34 PM Rasmus Villemoes 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