Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp8052032pxb; Fri, 19 Feb 2021 06:20:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJxP/1Y8ZsGTRGMFkewhBxq5JWvdt5XB/Vs84D9PNjP5H3vo62X3SjNbIXP6ryfZTr4Og0Tg X-Received: by 2002:aa7:d1c2:: with SMTP id g2mr1243739edp.46.1613744402279; Fri, 19 Feb 2021 06:20:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613744402; cv=none; d=google.com; s=arc-20160816; b=fma75CkvjG1yCfyFbldK/LrDn+kFmqz47pb6Utoyp/bhsiF2H1kOM/85wmJH7IhM8K ZWuOL79fBJ0M8g6DhvYF++Zf2uQSdfppvlgxD0uTvPaAtOsEwtzmTBe6TuIRFbWq2iBe mdd8Qqi1QYm4Djo0/r96SgfmwDyP0PWH1Ykx3lU/1L6fHybQZlxyD6T+g2Q8a/yofdQN lSsBkXZVYF9bmzPvKrWL713U6AGanjTVWSgXXAWv+Hv91uviv08uOjpg0zvIsk0ep4yh 0hruz20QSSreNAmSGGUyG1o9sSfoeZWJVUCyC6l4ifvvtX3ajDwN8rOKMcMHZ+iztRoi WFgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Glf6s3Fv7LyzZsufhuUiYYI8eUz9bqu/mDgIZl6DWyc=; b=WW27frIbbU3SoZTPoY7xkYyz5GL8YF0WJjtKBHOxRaAMm3H2NA6pO8fUeiSxlvNlaD xoU83GXeoT178N3HSYhVdigKOPp9leY/HCBVL5Jp1eSgnttNlFaq94brRRYgBwEbQeo8 ylbN9EwavPMS09V80Qv4MqdcgI1uLL4zJ7mTvPrPRJXuRTWJ92KcgtksnY+72H5w7hbL Yt2R2AOdW6QPkmqBEelzH2BW+saF+w29uUxGCBVxL01OM+LrW1E+Mf8G01CUXMbdfjvU BDDlB2XARqZ4s0ufWvmS9RuTzSHVQKZ7r+4NSGiDEfnMgY+FBBVLgkIYbuR1nZ8pxxY1 vKqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hpkdWLkX; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r13si6044303edd.388.2021.02.19.06.19.36; Fri, 19 Feb 2021 06:20:02 -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=@kernel.org header.s=k20201202 header.b=hpkdWLkX; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230196AbhBSORx (ORCPT + 99 others); Fri, 19 Feb 2021 09:17:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:57854 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229808AbhBSORw (ORCPT ); Fri, 19 Feb 2021 09:17:52 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5D2AC64E46; Fri, 19 Feb 2021 14:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613744231; bh=/+2b2FPgpVlufmh4ou91Mqrxg25dANUoad9GzuPY3QM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hpkdWLkXS4r9zMnMbRgfiAqJUL/KX6NZRfDUz5f24bqhOJAvuNQpG2eR3cqSV4FPP X0+GeMRwnTShjEsTP3+zqR1wrAXn1CNjRGFjK1/zI+wJc3UGOX54Pxat+7NKkWxuUS Ms2w+MsTo3JMUtRhZll9QYsSTorsSO7MOoT4l6DTGTRc+sYLiO3suZYOmK8ktSRz4i 9JcuWqm6WZwELL56dxvs54v7F9+UGjNl4nvuy4AlHsgCi18iFryaiBbHaiVK3VuDq1 xl8uf2dwcNNrgMNtZ5NpC7Z6bNyqdcSZa24H9G5LXRygMG+ZcaDbgvb5Omvc7rUKIY Yr4w6lIhJdMAQ== Received: by mail-ed1-f53.google.com with SMTP id c6so10310845ede.0; Fri, 19 Feb 2021 06:17:11 -0800 (PST) X-Gm-Message-State: AOAM530L6OwA0vnSAU//a6Ie5eEQigsoEdLrARfX6ECwk5NnYyi8IBEn km2zkVhTAvLb1Ozkk4/wfXHuDD3NrkAlnwuZvA== X-Received: by 2002:aa7:c7c8:: with SMTP id o8mr9390177eds.137.1613744229946; Fri, 19 Feb 2021 06:17:09 -0800 (PST) MIME-Version: 1.0 References: <20210218223305.2044-1-nramas@linux.microsoft.com> <8b8c0b70-c7ab-33f3-b66c-9ea03388497b@linux.microsoft.com> <87k0r4yi4s.fsf@manicouagan.localdomain> <3ca0aa87-ca83-8024-4067-c2382a360db9@linux.microsoft.com> In-Reply-To: <3ca0aa87-ca83-8024-4067-c2382a360db9@linux.microsoft.com> From: Rob Herring Date: Fri, 19 Feb 2021 08:16:46 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] of: error: 'const struct kimage' has no member named 'arch' To: Lakshmi Ramasubramanian Cc: Thiago Jung Bauermann , Mimi Zohar , "AKASHI, Takahiro" , Greg Kroah-Hartman , Will Deacon , Joe Perches , Catalin Marinas , Michael Ellerman , Stephen Rothwell , James Morse , Sasha Levin , Benjamin Herrenschmidt , linux-integrity@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-arm-kernel , devicetree@vger.kernel.org, linuxppc-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 18, 2021 at 8:53 PM Lakshmi Ramasubramanian wrote: > > On 2/18/21 5:13 PM, Thiago Jung Bauermann wrote: > > > > Lakshmi Ramasubramanian writes: > > > >> On 2/18/21 4:07 PM, Mimi Zohar wrote: > >> > >> Hi Mimi, > >> > >>> On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote: > >>>> of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds > >>>> a new device tree object that includes architecture specific data > >>>> for kexec system call. This should be defined only if the architecture > >>>> being built defines kexec architecture structure "struct kimage_arch". > >>>> > >>>> Define a new boolean config OF_KEXEC that is enabled if > >>>> CONFIG_KEXEC_FILE and CONFIG_OF_FLATTREE are enabled, and > >>>> the architecture is arm64 or powerpc64. Build drivers/of/kexec.c > >>>> if CONFIG_OF_KEXEC is enabled. > >>>> > >>>> Signed-off-by: Lakshmi Ramasubramanian > >>>> Fixes: 33488dc4d61f ("of: Add a common kexec FDT setup function") > >>>> Reported-by: kernel test robot > >>>> --- > >>>> drivers/of/Kconfig | 6 ++++++ > >>>> drivers/of/Makefile | 7 +------ > >>>> 2 files changed, 7 insertions(+), 6 deletions(-) > >>>> > >>>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > >>>> index 18450437d5d5..f2e8fa54862a 100644 > >>>> --- a/drivers/of/Kconfig > >>>> +++ b/drivers/of/Kconfig > >>>> @@ -100,4 +100,10 @@ config OF_DMA_DEFAULT_COHERENT > >>>> # arches should select this if DMA is coherent by default for OF devices > >>>> bool > >>>> +config OF_KEXEC > >>>> + bool > >>>> + depends on KEXEC_FILE > >>>> + depends on OF_FLATTREE > >>>> + default y if ARM64 || PPC64 > >>>> + > >>>> endif # OF > >>>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile > >>>> index c13b982084a3..287579dd1695 100644 > >>>> --- a/drivers/of/Makefile > >>>> +++ b/drivers/of/Makefile > >>>> @@ -13,11 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o > >>>> obj-$(CONFIG_OF_RESOLVE) += resolver.o > >>>> obj-$(CONFIG_OF_OVERLAY) += overlay.o > >>>> obj-$(CONFIG_OF_NUMA) += of_numa.o > >>>> - > >>>> -ifdef CONFIG_KEXEC_FILE > >>>> -ifdef CONFIG_OF_FLATTREE > >>>> -obj-y += kexec.o > >>>> -endif > >>>> -endif > >>>> +obj-$(CONFIG_OF_KEXEC) += kexec.o > >>>> obj-$(CONFIG_OF_UNITTEST) += unittest-data/ > >>> Is it possible to reuse CONFIG_HAVE_IMA_KEXEC here? > >>> > >> > >> For ppc64 CONFIG_HAVE_IMA_KEXEC is selected when CONFIG_KEXEC_FILE is enabled. > >> So I don't see a problem in reusing CONFIG_HAVE_IMA_KEXEC for ppc. > >> > >> But for arm64, CONFIG_HAVE_IMA_KEXEC is enabled in the final patch in the patch > >> set (the one for carrying forward IMA log across kexec for arm64). arm64 calls > >> of_kexec_alloc_and_setup_fdt() prior to enabling CONFIG_HAVE_IMA_KEXEC and hence > >> breaks the build for arm64. > > > > One problem is that I believe that this patch won't placate the robot, > > because IIUC it generates config files at random and this change still > > allows hppa and s390 to enable CONFIG_OF_KEXEC. > > I enabled CONFIG_OF_KEXEC for s390. With my patch applied, > CONFIG_OF_KEXEC is removed. So I think the robot enabling this config > would not be a problem. > > > > > Perhaps a new CONFIG_HAVE_KIMAGE_ARCH option? Not having that option > > would still allow building kexec.o, but would be used inside kexec.c to > > avoid accessing kimage.arch members. > > > > I think this is a good idea - a new CONFIG_HAVE_KIMAGE_ARCH, which will > be selected by arm64 and ppc for now. I tried this, and it fixes the > build issue. > > Although, the name for the new config can be misleading since PARISC, > for instance, also defines "struct kimage_arch". Perhaps, > CONFIG_HAVE_ELF_KIMAGE_ARCH since of_kexec_alloc_and_setup_fdt() is > accessing ELF specific fields in "struct kimage_arch"? > > Rob/Mimi - please let us know which approach you think is better. I'd just move the fields to kimage. Rob