Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5556306pxj; Wed, 26 May 2021 13:29:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdaC8uvUeT9Ekxjl4zT5SZyvd6wbmB7IaRIMdBcTcZss6hgNYHiRU0GMyhbi3kWu1OArjO X-Received: by 2002:a17:906:d285:: with SMTP id ay5mr137260ejb.332.1622060983632; Wed, 26 May 2021 13:29:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622060983; cv=none; d=google.com; s=arc-20160816; b=dTBGjTCYY22i8QTyFFMjCc1WiODqIMNauD6yd69+dWKQ+ESAOu/qDxk1pl+sbFs9ji xWSOjPNtfP1qvdPdwf94A1gc19Fv9vVDNMvNaoTdV9HLfM7DEaC7imlET7p3DGvYH2cG +jAbZaQGEWhRLt6aGyyUwjE2kJASy5Z6MZCIbXVe5uzpQUp+KMtZudiKKzq7OtemxKfj WJVZJFMI2XSIaIZVnvPebP/g81gqkvlXdl4wCQpYadBmoQ7esXHDyXtQmnRD9jSApWY7 wxSWkWuXQokhxyDmURPj+K3zq4OX0IE2H0C+EcDuNkJOIVf+T9Kpi18mrzpnZOix/1qS AxVw== 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=Gboqc7s5M7oyp6AwSlSQ7/DdUvTZezwoWO4/26kgzgY=; b=Zi/welb6Va9wPJdrOLWmjuokJJd3x+QKJYxfytf0teUL7GaX/eSsODltgx6uOW/hMn gbtbL8NBzw8JPhne7Tzbfg0Fyeg1jyszynqvAdppzkOFcJJvOyBIs9QkAUOSnd/kteaZ QS95duIoqYqJC+ZjhHlt4AY/ksAIjPEQc/g8x95dcPRzzoqTD6GVqSlGA8OzEmtpqw0g St8gK7aTmPhSil9p6PcYrQZ+uGo6Wk7Usu4kfMmCtdk8wiZNKCkjrjmKT7QvDS6DTDD7 j/PT2jUe2rPAAwbeY1quPy6DgKLnaPdC2bA4ir8ZdOFkgRo2AfH/+KAkW9z7rJhqinVF cr2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UlIeMsrt; 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 y59si273212ede.390.2021.05.26.13.29.19; Wed, 26 May 2021 13:29:43 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UlIeMsrt; 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 S231911AbhEZTIb (ORCPT + 99 others); Wed, 26 May 2021 15:08:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:43314 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231968AbhEZTI3 (ORCPT ); Wed, 26 May 2021 15:08:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0DA8A610A8; Wed, 26 May 2021 19:06:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622056018; bh=ArzjRoIQImcLyGoAFNv7HeB9ZnbpJBh6UdALpi14PnQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UlIeMsrtCkRRoFYoaTtfuyX12NysJpx7L5iKXkP4Bb6IvhF7skLg91u77ZAebW05t B2waKvnSuRUS8jNXa9GVY9hQtQsvKNn/APfrUnLS34BU+88QCL71u7clW/AyVWaseo KFnn2P86zWG8wULvsJ+2vY1nuk7cMMzpJvggdViF+LgZ5lM3UJzEpAKZe7mpWzZcTK eLacnOlpQ2a2TaEuN7prl+OPFeihBrjjgrY+PKl6ggUaZGz1BHHsa46bXsi1PXHbZX 3I7IBv5s/hxMnMofvxMLimBvsY1jvIHEFmxj1VzSQDG2OMClDx0RKOzAysaez98QHM vhKnDm758oh8Q== Received: by mail-ej1-f50.google.com with SMTP id k14so4172675eji.2; Wed, 26 May 2021 12:06:57 -0700 (PDT) X-Gm-Message-State: AOAM532YYGhzqCXfLO6T0VcvY9YJmbHtTUjMfeBL99tkzLIQ4uJ0n0lb p4lBa37tPeysuUM+6CqdWrj2xeGHM7H1SZxreQ== X-Received: by 2002:a17:907:724b:: with SMTP id ds11mr34749764ejc.108.1622056016641; Wed, 26 May 2021 12:06:56 -0700 (PDT) MIME-Version: 1.0 References: <20210524190919.2616-1-rdunlap@infradead.org> In-Reply-To: <20210524190919.2616-1-rdunlap@infradead.org> From: Rob Herring Date: Wed, 26 May 2021 14:06:44 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] OF: of_address: clean up OF stub & extern functions To: Randy Dunlap Cc: "linux-kernel@vger.kernel.org" , Frank Rowand , devicetree@vger.kernel.org, Laurent Pinchart , kernel test robot Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021 at 2:09 PM Randy Dunlap wrote: > > Adjust so that stubs are present when > CONFIG_OF is not set *or* OF is set but OF_ADDRESS is not set. > > This eliminates 2 build errors on arch/s390/ when HAS_IOMEM > is not set (so OF_ADDRESS is not set). > I.e., it provides a stub for of_iomap() when one was previously > not provided as well as removing some duplicate externs. Personally, I think we should get rid of HAS_IOMEM or at least most of its usage in kconfig. It has little purpose beyond hiding drivers in kconfig and mainly for UML though I think UML no longer needs that IIRC. (I'm not wild about 'depends on OF' either). > s390-linux-ld: drivers/irqchip/irq-al-fic.o: in function `al_fic_init_dt': > irq-al-fic.c:(.init.text+0x7a): undefined reference to `of_iomap' > s390-linux-ld: drivers/clocksource/timer-of.o: in function `timer_of_init': > timer-of.c:(.init.text+0xa4): undefined reference to `of_iomap' > > Tested with many randconfig builds, but there could still be some > hidden problem here. > > Fixes: 4acf4b9cd453 ("of: move of_address_to_resource and of_iomap declarations from sparc") > Signed-off-by: Randy Dunlap > Cc: Rob Herring > Cc: Frank Rowand > Cc: devicetree@vger.kernel.org > Cc: Laurent Pinchart > Reported-by: kernel test robot > --- > v2: handle SPARC as a special case since it provides its own versions of > of_address_to_resource() and of_iomap(); > fix build errors reported by lkp/ktr and address comments from Laurent; > do more randconfig build testing; > > include/linux/of_address.h | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > --- linux-next-20210524.orig/include/linux/of_address.h > +++ linux-next-20210524/include/linux/of_address.h > @@ -106,11 +106,12 @@ static inline bool of_dma_is_coherent(st > } > #endif /* CONFIG_OF_ADDRESS */ > > -#ifdef CONFIG_OF > +#ifdef CONFIG_SPARC /* SPARC has its own versions of these */ The whole point of CONFIG_OF_ADDRESS is really just for SPARC. So I don't really like the mixture of the ifdefs here and in kconfig. It looks only more fragile. Can we drop the HAS_IOMEM dependency from CONFIG_OF_ADDRESS and then fix the fallout from that? That would also remove all the other build time dependencies on HAS_IOMEM. > extern int of_address_to_resource(struct device_node *dev, int index, > struct resource *r); > -void __iomem *of_iomap(struct device_node *node, int index); > -#else > +extern void __iomem *of_iomap(struct device_node *device, int index); > +#else /* !CONFIG_SPARC */ > +#if (defined(CONFIG_OF) && !defined(CONFIG_OF_ADDRESS)) || !defined(CONFIG_OF) > static inline int of_address_to_resource(struct device_node *dev, int index, > struct resource *r) > { > @@ -121,7 +122,9 @@ static inline void __iomem *of_iomap(str > { > return NULL; > } > -#endif > +#endif /* (defined(CONFIG_OF) && !defined(CONFIG_OF_ADDRESS)) || !defined(CONFIG_OF) */ > +#endif /* CONFIG_SPARC */ > + > #define of_range_parser_init of_pci_range_parser_init > > #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)