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 D3B7CC43334 for ; Tue, 14 Jun 2022 03:21:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48D4A8D0204; Mon, 13 Jun 2022 23:21:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EDE58D01EE; Mon, 13 Jun 2022 23:21:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28EEE8D0204; Mon, 13 Jun 2022 23:21:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1686D8D01EE for ; Mon, 13 Jun 2022 23:21:19 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DBFAF34770 for ; Tue, 14 Jun 2022 03:21:18 +0000 (UTC) X-FDA: 79575390636.17.92FB49F Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf23.hostedemail.com (Postfix) with ESMTP id BA02814008D for ; Tue, 14 Jun 2022 03:21:17 +0000 (UTC) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4LMYbw2jZQzDrDr; Tue, 14 Jun 2022 11:20:44 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 14 Jun 2022 11:21:08 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 14 Jun 2022 11:21:08 +0800 Message-ID: <9a6e61da-0a5c-02bb-d769-98cf1f602de8@huawei.com> Date: Tue, 14 Jun 2022 11:21:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v5 0/6] arm64: Cleanup ioremap() and support ioremap_prot() Content-Language: en-US To: , , , , CC: , , , References: <20220607125027.44946-1-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: <20220607125027.44946-1-wangkefeng.wang@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655176878; a=rsa-sha256; cv=none; b=y+gsAJ6+Y1P3MbrwxYUA3XJjrcreb9fIBK3AL5rJlheCRtaTm4CdNhg8W2PNP+Yth4DwbA VJDht0HkkSJlvfsDleCDRHBZK3yFNDz9Fcgu+xBuzwxtOp9GQCx2hsGOGOJWX2Aojlzq3b QyFCtO2umz1lJSYksWSCqzPP11g8JW8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655176878; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n4kEilfeqGzqBoqCommQLe4N/poHABDhLizc9nN1tgY=; b=CKMlSAZTBnJz5bD3ZWa0qofbm7leSD+QDSYcJzagyfr2iZUspzdEcGvVz3giBlMwScefuT nydD/6FaSycCB+sVs3Ey9KJF/Wv8/JOyc/aVUkjoITEJ639KsKNtl35n8P4fIK5QwSFVkM Gqy5UCu4QlM96Yv+ehZl34J8DlxOLJo= X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: BA02814008D X-Stat-Signature: 3n4eoxgd6jpzud6f4r3b6ykpegxizaw9 Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-Rspam-User: X-HE-Tag: 1655176877-993470 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: Hi Catalin, could you help to pick up it, thanks. On 2022/6/7 20:50, Kefeng Wang wrote: > 1. Enhance generic ioremap to make it more useful. > 2. Let's arm64 use GENERIC_IOREMAP to cleanup code. > 3. Support HAVE_IOREMAP_PROT on arm64, which enable generic_access_phys(), > it is useful when debug(eg, gdb) via access_process_vm device memory > infrastructure. > > v5: > - break long lines(> 80 cols), per Christoph Hellwig > - move is_vmalloc_addr() check from arm64 into generic ioremap, per > Christoph Hellwig > - make arm64's ioremap_cache as an inline function, per Christoph > - keep changes simple, make ioremap/iounmap_allowed return bool, per > Baoquan He > - simplify use 'void *' instead of 'void __iomem *' in iounmap, then > drop __force annotation > > v4: > - update based on v5.19-rc1 > - add generic arch_ioremap/arch_iounmap define, per Andrew Monrton > - simply return an int for arch_ioremap and rename arch_ioremap/arch_iounmap > to a better name, ioremap_allowed/iounmap_allowed, per Arnd Bergmann > - add __force annotation to slince sparse warning in vunmap() > > Note, > 1) after the renaming, the arm's change(patch1) is not the necessary > dependence for the following changes, but as a cleanup, still post > it here, hope it go in via the arm64 tree with reset of the series > directly if no object. > 2) the changes in this version only influence on patch4/5, so retain > the ack/review. > > v3: > - add cleanup patch to kill ARM's unused arch_iounmap(the naming will be > used in GENERIC_IOREMAP) and add comments for arch_ioremap/arch_iounmap > hooks, per Anshuman Khandual > - collect ack/review > > v2: > - s/addr/phys_addr in ioremap_prot, suggested by Andrew Morton > - rename arch_ioremap/iounmap_check to arch_ioremap/iounmap > and change return value, per Christoph Hellwig and Andrew Morton > - and use 'ifndef arch_ioremap' instead of weak function, per Arnd Bergmann > - collect ack/review > > Kefeng Wang (6): > ARM: mm: kill unused runtime hook arch_iounmap() > mm: ioremap: Use more sensibly name in ioremap_prot() > mm: ioremap: Setup phys_addr of struct vm_struct > mm: ioremap: Add ioremap/iounmap_allowed() > arm64: mm: Convert to GENERIC_IOREMAP > arm64: Add HAVE_IOREMAP_PROT support > > .../features/vm/ioremap_prot/arch-support.txt | 2 +- > arch/arm/include/asm/io.h | 4 +- > arch/arm/mm/ioremap.c | 9 +- > arch/arm/mm/nommu.c | 9 +- > arch/arm64/Kconfig | 2 + > arch/arm64/include/asm/io.h | 24 +++-- > arch/arm64/include/asm/pgtable.h | 10 +++ > arch/arm64/kernel/acpi.c | 2 +- > arch/arm64/mm/hugetlbpage.c | 10 --- > arch/arm64/mm/ioremap.c | 90 ++----------------- > include/asm-generic/io.h | 29 +++++- > mm/ioremap.c | 26 ++++-- > 12 files changed, 90 insertions(+), 127 deletions(-) >