From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF75CC433EF for ; Sun, 30 Jan 2022 19:00:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C565F6B0071; Sun, 30 Jan 2022 14:00:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C06566B0073; Sun, 30 Jan 2022 14:00:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF5C16B0074; Sun, 30 Jan 2022 14:00:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay040.a.hostedemail.com [64.99.140.40]) by kanga.kvack.org (Postfix) with ESMTP id A09076B0071 for ; Sun, 30 Jan 2022 14:00:35 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2B76C2256B for ; Sun, 30 Jan 2022 19:00:35 +0000 (UTC) X-FDA: 79087869630.01.5340660 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id 52737160007 for ; Sun, 30 Jan 2022 19:00:34 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 388E4612BE; Sun, 30 Jan 2022 19:00:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 326F0C340E4; Sun, 30 Jan 2022 19:00:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643569232; bh=J5VGqQOy6MMXL8J5ar+eI2vqjBOz9iohKVb1BM9GqWk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LMoMrALaOnlYPLk7kPn8+j8QUdsjt0NDubYijeeh/x71chGgfwIB8tedapUb8YnDs TCrvsGAJuTHcUzkHEDwWcLRZ5keYw0ZaAnJZEZ7VcXpZ19aaFuITeGnF+UilU8kq1t fibdXm1SJpWMAqWukPgz7546YKFQbqE0EJjrwUzmDjoDWhfTARFrER8bP2a5f4FGEA Fja7j0iccIi7zvRztUsWE+EptEb9pnJn/CXr3VgfD7pPt5iqFP3HCnuVAlcAXHTJfE pfXZMmvt98W+DBLGvIPd/+sy7h/nJkRTbiIiz2cwHKpe9PpLuxRFxXOUWxglGPwO/W mVhW4c92Wv6ww== Date: Sun, 30 Jan 2022 21:00:22 +0200 From: Mike Rapoport To: Matthew Wilcox Cc: Karolina Drobnik , linux-mm@kvack.org, akpm@linux-foundation.org, mike.rapoport@gmail.com, linux-kernel@vger.kernel.org, Arnd Bergmann Subject: Re: [PATCH 07/16] tools/include: Add io.h stub Message-ID: References: <2d9aa000afe81b45157617664134b871207c2067.1643206612.git.karolinadrobnik@gmail.com> <48499a57afb3d27df26b39aa4255b4ba583c1148.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 52737160007 X-Rspam-User: nil Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LMoMrALa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Stat-Signature: jd8i1qeokrsj7topu3pdyfz5mdf66rgj X-Rspamd-Server: rspam08 X-HE-Tag: 1643569234-623112 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Jan 30, 2022 at 05:53:24PM +0000, Matthew Wilcox wrote: > On Sun, Jan 30, 2022 at 06:10:00PM +0200, Mike Rapoport wrote: > > On Fri, Jan 28, 2022 at 12:21:59PM +0100, Karolina Drobnik wrote: > > > On Thu, 2022-01-27 at 14:09 +0000, Matthew Wilcox wrote: > > > > On Thu, Jan 27, 2022 at 02:21:25PM +0100, Karolina Drobnik wrote: > > > > > Add a dummy io.h header. > > > > > > > > Rather begs the question of what memblock.c needs from linux/io.h. > > > > > > > > Wouldn't it be better to: > > > > > > > > +++ b/mm/memblock.c > > > > @@ -18,7 +18,6 @@ > > > >  #include > > > > > > > >  #include > > > > -#include > > > > > > > >  #include "internal.h" > > > > > > > > > > That was something I considered in the very beginning, but didn't have > > > a chance to verify it works for all architectures. I can take a look > > > after I'm finished with other v2 changes. > > > > > > > (allmodconfig on x86-64 builds fine with this; I have not done an > > > > extended sweep of other arches / build options). > > > > I did a sweep for defconfigs for all arches and all were fine. > > Thanks for doing the sweep, Mike. > > I think I found a deeper problem which is masked due to our maze of > header files: > > include/asm-generic/io.h:#ifndef virt_to_phys > include/asm-generic/io.h:#define virt_to_phys virt_to_phys > > so there's an assumption that defines virt_to_phys(). > You can see that in a number of architectures, eg: > > arch/alpha/include/asm/io.h:static inline unsigned long virt_to_phys(volatile void *address) > arch/ia64/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/mips/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/nios2/include/asm/io.h:#define virt_to_phys(vaddr) \ > arch/parisc/include/asm/io.h:#define virt_to_phys(a) ((unsigned long)__pa(a)) > arch/powerpc/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/sh/include/asm/io.h:#define virt_to_phys(address) ((unsigned long)(address)) > arch/x86/include/asm/io.h:#define virt_to_phys virt_to_phys > > That's clearly not the right place to define it. Two architectures > put it in asm/memory.h: > > arch/arm/include/asm/memory.h:#define virt_to_phys virt_to_phys > arch/arm64/include/asm/memory.h:#define virt_to_phys virt_to_phys > > then: > > arch/m68k/include/asm/virtconvert.h:#define virt_to_phys virt_to_phys > arch/sparc/include/asm/page_32.h:#define virt_to_phys __pa > arch/sparc/include/asm/page_64.h:#define virt_to_phys __pa I'd say sparc picked the most appropriate header for it. memory.h could also work fine, but it's only present on some arches. I'll take a deeper look, thanks for checking this. > This needs to be properly sorted out, but I don't want to tell Karolina > that's now her job as a prerequisite for merging this patchset; that > would be unfair. Totally agree. > Cc'ing Arnd. This is the kind of awful mess that he loves fixing ;-) Heh, me too :) -- Sincerely yours, Mike.