Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1659985ybz; Thu, 16 Apr 2020 13:09:40 -0700 (PDT) X-Google-Smtp-Source: APiQypL6hmgOpWVB6lcD4KLDGRR93P01CQ3vebZzlbIbJvv90dKSPucmQpGJV23yPKyLDdoxDS2D X-Received: by 2002:aa7:db41:: with SMTP id n1mr30993539edt.260.1587067779874; Thu, 16 Apr 2020 13:09:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587067779; cv=none; d=google.com; s=arc-20160816; b=dTfqbs9a2fxguuwIpoC6z4/F/mqv3HHyHkXVdtNLEXD0jBRGP4zJ90HSuOoZlgwXLv lyJ2wyrSUMe4fFX5SUNrQS6AxkJ2eyJJH2Lep8184h5iPOtksIg6Mh5NVrvy6rwDLeS5 PvkpQVOJk1Ds0ga5fzVUgGks5F7pMkGx86S7rEYLe3VNymLb4MayNquIC/2NWE9KiXmE +S6/Tz2jhlTY9Dh8s4BreqmMTmhl1pxHzWWm+fHPqR0HlPQWh0kroAO/cpJMj8m1kEMT w1O21C0Ut0CvPp4GOY5tVQTP/pTrEzJZqOCclC5dZ+XRrfA5Oyy/o0xYYE6z6d1msgEd x1tg== 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; bh=hzUceZBEPAyjjIPFRn2ktroAqPPOOAxcNrlKSRJ0zfg=; b=QvW/NW1RwlFL+y88M3DDSSCGxa06jPiifQiZZSZ5xVffuQOZrv2K2ikQodusOWe53B zlb634epg5b6CW5I3el5BKkaCzTtY2c9dpDg+sustW5PUNIK0e4Ht+lijazPHBqzkVuf /GmIWYz/opzfvEbP3KwUMLwwHqhwNtNszEhKNnhC/BkVofZ1AtiwGXQO5olDarK+Dgix lP3K9ZZiHNWtRFhc6vz/uesCpQKx0F+WCMn27Mx5Wu4tWgzwovN8jh/RB1CODq5kUuKL mCMtQzsODrAAuUG7GoSwzdLXdQj7x8h/lRAAyr5ZgvS/pQen9ekaPn66RZUKksm4wDC7 OY1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d1si4937915edr.360.2020.04.16.13.09.17; Thu, 16 Apr 2020 13:09:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439654AbgDPNwb (ORCPT + 99 others); Thu, 16 Apr 2020 09:52:31 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:38091 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897390AbgDPNhA (ORCPT ); Thu, 16 Apr 2020 09:37:00 -0400 Received: from mail-qk1-f179.google.com ([209.85.222.179]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N79q8-1jAqgf0EW4-017YmP; Thu, 16 Apr 2020 15:36:57 +0200 Received: by mail-qk1-f179.google.com with SMTP id j4so21187396qkc.11; Thu, 16 Apr 2020 06:36:56 -0700 (PDT) X-Gm-Message-State: AGi0PuZjfQOakkBeJhSdzg1EQ4Yni8buejfx9qHBBF5n5sgs2SjRWb8c slfbla8MWhx1viB09XWLFEWqV1uSewhZje81w0Y= X-Received: by 2002:a37:851:: with SMTP id 78mr31807202qki.352.1587044215844; Thu, 16 Apr 2020 06:36:55 -0700 (PDT) MIME-Version: 1.0 References: <20200416115658.20406-1-geert+renesas@glider.be> <20200416115658.20406-3-geert+renesas@glider.be> <20200416125630.GF4987@lakrids.cambridge.arm.com> In-Reply-To: <20200416125630.GF4987@lakrids.cambridge.arm.com> From: Arnd Bergmann Date: Thu, 16 Apr 2020 15:36:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] [RFC] arm64: Add dependencies to vendor-specific errata To: Mark Rutland Cc: Geert Uytterhoeven , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , linux-arm-msm , Andy Gross , Wei Xu , Bjorn Andersson , Masahiro Yamada , Robert Richter , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:zICuUsxQPPQJD0mFrfj74gKDbR2oFM2uttNnB1Q9C3oNdi5LUtv 5D6vxZFGM/iFgzEoQ5IUx5wa/5KVR2w0jlyVvP4fg+H74Ianhbu1TbcYM3puwlF/LOmYA1g ipQbQGngZ9ulwoqwP43Iy+D+FiperRfFB1lS5OwY7cFdRnKwHSy9XcKbs6ze/eAmuhzbQc6 ba3Xk7hYzVpNGelRS4umw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lWGfSsnYJZU=:cg0dI2jhukpt3KneC3m51U 4dp48keK9naDXcPzv+ZxDaUthdtZZp4jiK2p0jlHlQ/hlS9LIoR70Lzo7xxWdY1TVM1NcUOFz 4DEk7JN2+Oiv8O83Xc3f9BtleBV6Le8MWI8+ESBu1OIqv4Yw4N49W0jUfZDbQaPmJbFhyUtgH E8Ik75fnVMl74xDRoHroFqVKTcisthkw5epvHqyMdGS5ct1i15TCz00X3NOZMdzUWG7xmM2Th jv3JObSm9NpoD+sA+zxmZaHgtX0tKtdQQfr+Tfsje34OaftldJnj3kmJIe3JtssyAprc8Ru8o LKw876ziLaoncBv6AM5asEyOcJMFgiG/0jmSKSsUmZK/SoVZXYgoBp5e1QUPVEJ7Xqalkgz1x 36pneyTABXBkzAjuPivkDEslewaUIMj0k2LEtXlWSGW6WqDKpvGlXm/IGHJlfi0DF0uJ8usgk 8Q+AV3nSGobnvvsEMBIdEwjl28qLflaLCzVkV/BPXvZnO2cHNt+kDJcQYMWvynGCktgZuXpTf +mplQBjiPq5Narv2crbmgINc/PSxY3AfmYWBjEHjzuO6EsooFIjNUJbFNgAzSvTw+72KRmuAo F+LIXifeAZ6NZLqH+Hc3KOTy2DlKihNwmjvFt0YGQiR8Mbxgi4qVdlKQXlvn4K7kcDjh7k0Gt RDxQjsN5zeUYPOYeJ32hFtZu/+hfKsMsb+BvMnzH6JmPuwVkqpAfN0FPCXVgr7naD0edb2p2Q k+0n1j1v6GHyuZkYxrCBTTlDxJYYLsukDlDEIoGb7XqlIBY6FzG3+UeR9ntO/xMNLfmVcRgsQ itFMpk7bMYhDtLr+NI7ueNyh/Ficmo9MbEXhlxqRfH5QyoCMmo= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 16, 2020 at 2:56 PM Mark Rutland wrote: > On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote: > > Currently the user is asked about enabling support for each and every > > vendor-specific erratum, even when support for the specific platform is > > not enabled. > > > > Fix this by adding platform dependencies to the config options > > controlling support for vendor-specific errata. > > > > Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol > > exists for the Fujitsu A64FX platform. > > > > Signed-off-by: Geert Uytterhoeven > > I'm not su1re that it makes sense to do this in general, becaose the > ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl > drivers), and these are (mostly) CPU-local and/or VM-visible. > > I think that it makes sense for those to be independent because: > > * future SoCs in the same family might not need the same CPU errata > workarounds, and it's arguably just as confusing to have the option > there. > > * It prevents building a minimal VM image with all (non-virtualized) > platform support disabled, but all possible (VM-visible) errata > options enabled. I do that occassionally for testing/analysis, and I > can imagine this is useful for those building images that are only > intended to be used in VMs. Most architectures over time grow a CPU selection option that is at least somewhat orthogonal to the platform selection. I think so far arm64 has intentionally resisted this based on the idea that the CPUs are mostly equal and differences are better handled at runtime. If we decide to revisit this in the future that might help both the errata selection and give a way to e.g. build for an ARMv8.2 baseline. This does seem pretty far out at the moment of course, given that most SoCs we work on are still based on Cortex-A53 or A72 ;-) > I think the change to SOCIONEXT_SYNQUACER_PREITS makes sense given > that's a platform-level detail. Arguably that should be moved into > drivers/irqchip/Kconfig. Agreed Arnd