Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2995212pxb; Tue, 12 Jan 2021 03:53:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJw5jERn2IZcYEsxFtfysDJAtQBErpwHPGkyBAHKKE6kjED89xITg9CezjGps3ewLcS7Rr0Q X-Received: by 2002:a17:907:389:: with SMTP id ss9mr3031772ejb.158.1610452438465; Tue, 12 Jan 2021 03:53:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610452438; cv=none; d=google.com; s=arc-20160816; b=X0ALMZ7dKsUDL9WDeL6n8bNQP0qqa/TxzF4yM/tAp/R5KzYbC9kq0sTQD05ucJQcCH smQNtO2fJtt/s3aHzTeWjipkse1wp/JLN/RKxDf4DnOI4A3sweM0JnttOl1Pmdluf/Nj 2uPV5kz/m8htg27ouS9JfXWJkI46I6X/f8OCCg3Qp7WsUGEtSwhu/NL7p+Uww195/U48 4zCoLwjtvck+A+d9dFm/9qQzklZpZWUNl9K5QTTZ68PzbOWpSVQbq5XCxAHFVyn8bBik jqlHKSvuCwhaUEJDczMiPmKGf6q8C3ffHHPJ23kVnX6idBuBn3uh6YSmWQsg3HhjI3Qz NaeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=sNacm9ehhXHDD+E+vM/v4BSvqULuhqFVBF88cmNDIFo=; b=QqcL/Yb0OCBUc/JqUvvkwolbvVlOgs7UbXAy7+VX4zFvkH7oPadNl52YHlpr07EC7J SfgYiCt/lgiDz9ir02d9Zfb+BJun9XPito/W9z0dPhxjePSbtn69FmmDhRjRrnO7vfHF 9/ndA03koqSUv+X8sblnKB2VGsnLFUh7gSx3h4kc/yVA2EYiQ1RXJOmnMD1GwHQJGoui Eu5CDWwic1pu3xTUYQ82M11PZY6+Q98uqT1t7GvTGzn7pGLD9crJmgb2mKoqgi2tsdib 9eKcEHHE6v4Xjd8ipcd5cFFA6BGTVgJ/eWEkxUz0PeIJ+d7BHhKQecob9THj3B9qC3V2 TGNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="DDMq/obY"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y12si1028213ejb.78.2021.01.12.03.53.34; Tue, 12 Jan 2021 03:53:58 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b="DDMq/obY"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733276AbhALIhr (ORCPT + 99 others); Tue, 12 Jan 2021 03:37:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728310AbhALIhr (ORCPT ); Tue, 12 Jan 2021 03:37:47 -0500 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7D99C061575 for ; Tue, 12 Jan 2021 00:37:06 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id j13so1213207pjz.3 for ; Tue, 12 Jan 2021 00:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sNacm9ehhXHDD+E+vM/v4BSvqULuhqFVBF88cmNDIFo=; b=DDMq/obY0QRg81EH+vwR4Kgm7tPTFPl/QX9l02SSYrbXsJ99XvqoZTeFYfzkiZpX+U lZsNY3XGyTFluu9B6DC0Ysf0LMEg3zK3rWzqePz34pghQ8c/qAEI0yYfNPX1VkfnPiWB 96vjwX9nlQ0wF95bAc0MLMNYyfiP1htNj59GdGbkfoALVg9ZFCojWWNkg83OlEU+NycE 8tVX76MB6J1ONXV51AcASm4IWBtL6zuECHYdo1Prwq+UaSYLC6RLq4Th2hSrtGSmLbVt ifCq5JIBU/PaUXj++wHGKfmhC5XNtwjxIqsIje5q6ZfDOpzSNo5fGxScY3VLW+q54nyK do7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sNacm9ehhXHDD+E+vM/v4BSvqULuhqFVBF88cmNDIFo=; b=cO2WxZarcXWAIEvVlffoYg/y/7eczTdjfY8Ru93ZmbKaa1PpbqGMFMvPTuR13iOfD4 XRHs4Yuki9bu2hkiBKBB1+HdvDJdJuEDiECFpOOZoNlwhJbMEYbtFwJGzlMlbwMnKXcJ X9BVekrb3HDK0zVJ7wOI8bg6t66+uuim173dsccJIhk4viP9dRE9gF/Fv3XBbfpSB3LV xs0YJjFYvS2CfL6dGa8wVWYtI/JW0YnmXy/YsXG9f5VJRfAMkLeS0jFDv3CSgQGhORI+ Hsnjf8anfVn869bx3R8mCiTeTRtBXN07Q+xjgvT67DJu6JiZ74z3ffnIiffZKJVyqpyN SXMw== X-Gm-Message-State: AOAM533XPwS+cKqBtSE0jSw+wjdDimzdFF+FrYMKaBOTSSgq+3UgUbFZ rDzYgmhVKKEcqTZ1QEe/5736LhuVoXRZ0A== X-Received: by 2002:a17:902:8203:b029:dc:3371:6b04 with SMTP id x3-20020a1709028203b02900dc33716b04mr3692078pln.81.1610440626102; Tue, 12 Jan 2021 00:37:06 -0800 (PST) Received: from localhost ([122.172.85.111]) by smtp.gmail.com with ESMTPSA id b1sm2112101pjh.54.2021.01.12.00.37.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 00:37:05 -0800 (PST) Date: Tue, 12 Jan 2021 14:07:03 +0530 From: Viresh Kumar To: Bill Mills Cc: Frank Rowand , Pantelis Antoniou , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, Vincent Guittot , anmar.oueja@linaro.org, Masahiro Yamada Subject: Re: [PATCH] of: unittest: Statically apply overlays using fdtoverlay Message-ID: <20210112083703.yfpicoi4zrddeykd@vireshk-i7> References: <1e42183ccafa1afba33b3e79a4e3efd3329fd133.1610095159.git.viresh.kumar@linaro.org> <23e16d20-36eb-87d9-4473-142504ad8a95@gmail.com> <31611390-eded-d290-36a7-0b1e8465f71e@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31611390-eded-d290-36a7-0b1e8465f71e@linaro.org> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11-01-21, 20:22, Bill Mills wrote: > On 1/11/21 5:06 PM, Frank Rowand wrote: > > NACK to this specific patch, in its current form. > > > > There are restrictions on applying an overlay at runtime that do not apply > > to applying an overlay to an FDT that will be loaded by the kernel during > > early boot. Thus the unittest overlays _must_ be applied using the kernel > > overlay loading methods to test the kernel runtime overlay loading feature. > > > > I agree that testing fdtoverlay is a good idea. I have not looked at the > > parent project to see how much testing of fdtoverlay occurs there, but I > > would prefer that fdtoverlay tests reside in the parent project if practical > > and reasonable. If there is some reason that some fdtoverlay tests are > > more practical in the Linux kernel repository then I am open to adding > > them to the Linux kernel tree. I wasn't looking to add any testing for fdtoverlay in the kernel, but then I stumbled upon unit-tests here and thought it would be a good idea to get this built using static tools as well, as we aren't required to add any new source files for this and the existing tests already cover a lot of nodes. And so I am fine if we don't want to do this stuff in kernel. > I thought we were aligned that any new overlays into the kernel today would > only be for boot loader applied case. Applying overlays at kernel runtime > was out of scope at your request. > > Rob had requested that the overlays be test applied at build time. I don't > think there is any way to test the kernel runtime method at build time > correct? > > Please clarify your concern and your suggested way forward. The kernel does some overlay testing currently (at kernel boot only, not later), to see if the overlays get applied correctly or not, these are the unit tests. What Frank is probably saying is that the unit-tests dtbs shouldn't get used for testing fdtoverlay stuff. He isn't asking to support runtime application of overlays, but to not do fdtoverlay testing in the kernel. -- viresh