Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3359490rwb; Sun, 9 Oct 2022 03:53:09 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4WQ1R0kHV+Mycy+D4KO+UTB2aVLZtdlMdJoQcPafkCvMJt2Qg7wLKVZMu9cfp2i77MjDcB X-Received: by 2002:a17:906:36d1:b0:76c:a723:9445 with SMTP id b17-20020a17090636d100b0076ca7239445mr10351244ejc.548.1665312789073; Sun, 09 Oct 2022 03:53:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665312789; cv=none; d=google.com; s=arc-20160816; b=JJV1tMT3oNEk238e6c9QxKFn3kvwC6LqyclCPb+c4/FlbAntARZykxg6XwoHgnI70r GN2eNnkxxO2VUDQXQ5oe7j3v77I7z4QS4uUmtOn9Sm+4grD/rUTXnKhumPsVKemTuT38 xwiXD3JzkELi/PlYdsbPpUF5sdjBfH4C6U+3S1qOP5zff9MFwJOqj8ImjHGntD6Pyb+0 Ab2/PpEaVFR1VT0DAl7GUlAxRCQd2zhfYDVKHf4n1Dvlj+KNMMin9g4Oa1AlnJiQbvzJ lRxnlaaZ8hluGlYmfqFd+qqGVMglWl1HusXOxI0WwKZ/5KcnEJ/j3RuNgAMTHr/HUHDl 11EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=KxegBGCY4AqOzRwM7tNubdONObE84AmZTumb3T1RzAM=; b=VkDZQ9aFLz8cS+SqjOlmgGshao9mUmUUdrpmzLrFthDt+tEdyF3c3oQYUneFZXb0GO HJa3PIOKAA+6/ulEt5UgBjVeto2yUdzxhdIuYAiPpwTuAaH/vi8qtyBiSOYVq30E0WrH O0cmP55G1sAhUWbTA5Oca2Zc6u5GaQ4Jy27Yv5lhujXe1ZEm6OOkkwN3/yBMODaHBJRX kapf8ROBfmMP6TjP4Zu0oC8q3huVPsKqZOpGJB8Fy0Q1LUjRsz68S68GXOlmYCGts1YR TimL7Xn7+8Da2NTWKVSFg1oa/qyAy1npk+tYwtbVXIfT7WlTOEhF4mtpUgt6yDYSkMbN 7EQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TEkNcMLQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z14-20020a170906434e00b0078aefaf3910si6963751ejm.362.2022.10.09.03.52.43; Sun, 09 Oct 2022 03:53:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TEkNcMLQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230141AbiJIKdO (ORCPT + 99 others); Sun, 9 Oct 2022 06:33:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230044AbiJIKcj (ORCPT ); Sun, 9 Oct 2022 06:32:39 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C6C62AE20 for ; Sun, 9 Oct 2022 03:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665311557; h=from:from: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=KxegBGCY4AqOzRwM7tNubdONObE84AmZTumb3T1RzAM=; b=TEkNcMLQ8n5sS49gmqb1WJcUaVdOiNMbiUDgbojfkRdDs/AMicrDcMxGjGioSvZw4Jmv1E vNk/SdoXOdHGnFUJ42OsQOUYzry+MskjgulMG+qkyN3gH0CL3GDWKYJgYrgN8TLbiFEzx7 0bkwVT8nZHwYe5eNiUS7Yk4P1+50U5w= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-102-HH8FxDx4OlGuEkOaYzjZFw-1; Sun, 09 Oct 2022 06:32:32 -0400 X-MC-Unique: HH8FxDx4OlGuEkOaYzjZFw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9CD85800186; Sun, 9 Oct 2022 10:32:31 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-36.pek2.redhat.com [10.72.12.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 113DB40D298B; Sun, 9 Oct 2022 10:32:24 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@infradead.org, agordeev@linux.ibm.com, wangkefeng.wang@huawei.com, christophe.leroy@csgroup.eu, schnelle@linux.ibm.com, David.Laight@ACULAB.COM, shorne@gmail.com, bhe@redhat.com, Jonas Bonn , Stefan Kristiansson , openrisc@lists.librecores.org Subject: [PATCH v3 07/11] openrisc: mm: Convert to GENERIC_IOREMAP Date: Sun, 9 Oct 2022 18:31:10 +0800 Message-Id: <20221009103114.149036-8-bhe@redhat.com> In-Reply-To: <20221009103114.149036-1-bhe@redhat.com> References: <20221009103114.149036-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org By taking GENERIC_IOREMAP method, the generic ioremap_prot() and iounmap() are visible and available to arch. Arch only needs to provide implementation of arch_ioremap() or arch_iounmap() if there's arch specific handling needed in its ioremap() or iounmap(). This change will simplify implementation by removing duplicated codes with generic ioremap() and iounmap(), and has the equivalent functioality as before. For openrisc, the duplicated ioremap() can be perfectly removed, and no arch_ioremap() is needed. Add arch_iounmap() to openrisc's special operation when iounmap(). Signed-off-by: Baoquan He Cc: Stafford Horne Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: openrisc@lists.librecores.org --- v2->v3: - Remove the early ioremap handling code in previous patch as Christoph and Stafford suggested. With this, arch_ioremap() is not needed in v3 post. - adjust the order of including and in , this fix an compiling error of virt_defconig building, Stafford suggested this. arch/openrisc/Kconfig | 1 + arch/openrisc/include/asm/io.h | 12 +++++--- arch/openrisc/mm/ioremap.c | 50 ++-------------------------------- 3 files changed, 12 insertions(+), 51 deletions(-) diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig index c7f282f60f64..fd9bb76a610b 100644 --- a/arch/openrisc/Kconfig +++ b/arch/openrisc/Kconfig @@ -21,6 +21,7 @@ config OPENRISC select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW select GENERIC_PCI_IOMAP + select GENERIC_IOREMAP select GENERIC_CPU_DEVICES select HAVE_PCI select HAVE_UID16 diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h index ee6043a03173..c2df089a10c4 100644 --- a/arch/openrisc/include/asm/io.h +++ b/arch/openrisc/include/asm/io.h @@ -15,6 +15,8 @@ #define __ASM_OPENRISC_IO_H #include +#include +#include /* * PCI: We do not use IO ports in OpenRISC @@ -27,11 +29,13 @@ #define PIO_OFFSET 0 #define PIO_MASK 0 -#define ioremap ioremap -void __iomem *ioremap(phys_addr_t offset, unsigned long size); +/* + * I/O memory mapping functions. + */ +bool arch_iounmap(void __iomem *addr); +#define arch_iounmap arch_iounmap -#define iounmap iounmap -extern void iounmap(volatile void __iomem *addr); +#define _PAGE_IOREMAP (pgprot_val(PAGE_KERNEL) | _PAGE_CI) #include diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c index 90b59bc53c8c..bac2348b1737 100644 --- a/arch/openrisc/mm/ioremap.c +++ b/arch/openrisc/mm/ioremap.c @@ -22,50 +22,7 @@ extern int mem_init_done; -/* - * Remap an arbitrary physical address space into the kernel virtual - * address space. Needed when the kernel wants to access high addresses - * directly. - * - * NOTE! We need to allow non-page-aligned mappings too: we will obviously - * have to convert them into an offset in a page-aligned mapping, but the - * caller shouldn't need to know that small detail. - */ -void __iomem *__ref ioremap(phys_addr_t addr, unsigned long size) -{ - phys_addr_t p; - unsigned long v; - unsigned long offset, last_addr; - struct vm_struct *area = NULL; - - /* Don't allow wraparound or zero size */ - last_addr = addr + size - 1; - if (!size || last_addr < addr) - return NULL; - - /* - * Mappings have to be page-aligned - */ - offset = addr & ~PAGE_MASK; - p = addr & PAGE_MASK; - size = PAGE_ALIGN(last_addr + 1) - p; - - area = get_vm_area(size, VM_IOREMAP); - if (!area) - return NULL; - v = (unsigned long)area->addr; - - if (ioremap_page_range(v, v + size, p, - __pgprot(pgprot_val(PAGE_KERNEL) | _PAGE_CI))) { - vfree(area->addr); - return NULL; - } - - return (void __iomem *)(offset + (char *)v); -} -EXPORT_SYMBOL(ioremap); - -void iounmap(volatile void __iomem *addr) +bool arch_iounmap(void __iomem *addr) { /* If the page is from the fixmap pool then we just clear out * the fixmap mapping. @@ -85,12 +42,11 @@ void iounmap(volatile void __iomem *addr) * ii) invalid accesses to the freed areas aren't made */ flush_tlb_all(); - return; + return false; } - return vfree((void *)(PAGE_MASK & (unsigned long)addr)); + return true; } -EXPORT_SYMBOL(iounmap); /** * OK, this one's a bit tricky... ioremap can get called before memory is -- 2.34.1