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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B44CEC433F5 for ; Sat, 21 May 2022 20:30:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343968AbiEUUa0 (ORCPT ); Sat, 21 May 2022 16:30:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233059AbiEUUaW (ORCPT ); Sat, 21 May 2022 16:30:22 -0400 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71D005A2C4 for ; Sat, 21 May 2022 13:30:21 -0700 (PDT) Received: from mail-yw1-f175.google.com ([209.85.128.175]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MuDTn-1nZbF8223R-00ud5b for ; Sat, 21 May 2022 22:30:19 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-2ff39b44b06so115437057b3.13 for ; Sat, 21 May 2022 13:30:19 -0700 (PDT) X-Gm-Message-State: AOAM531apC9iUp6ehTXbLxO0zX4vum9NEiWALnO3qI5cnPPpuKeymKxJ HiMinqAeZAxD0F37HOJdkHRtp1iOJ7OISMuz+qM= X-Google-Smtp-Source: ABdhPJxdzeQ8ppWmG4FaNugj1IVJL8hVon5ICr2txVNKnWSwzCAfUIa/u3XB2kovYWtRi5zFhQ8P1BD7cK9iFDjy8rQ= X-Received: by 2002:a81:950:0:b0:2fe:d88e:5529 with SMTP id 77-20020a810950000000b002fed88e5529mr16185220ywj.320.1653165018339; Sat, 21 May 2022 13:30:18 -0700 (PDT) MIME-Version: 1.0 References: <20220519082552.117736-1-wangkefeng.wang@huawei.com> <20220519082552.117736-2-wangkefeng.wang@huawei.com> In-Reply-To: <20220519082552.117736-2-wangkefeng.wang@huawei.com> From: Arnd Bergmann Date: Sat, 21 May 2022 22:30:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/6] ARM: mm: kill unused runtime hook arch_iounmap() To: Kefeng Wang Cc: Catalin Marinas , Will Deacon , Andrew Morton , Linux ARM , Linux Kernel Mailing List , Linux-MM , Christoph Hellwig , Arnd Bergmann , Anshuman Khandual , Russell King Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:EyHYTdRf6fVBn4QH+OGG17POm2ylUgIsX3SJ886CzOZYeKjc15D krzAaAWjsrKunYBRBFP9SttUpBW3GZAqV94vn7Qb0BLs/3rlIxb8T6V43Ckb512GXpbENmj S/oqUcX0bkPLforyIAUCK3i9GrLb1+QGvC8sGVKMGTaDiYDYr/OTvTmUWgM7ilTSwfw6m9z Hoj4/b1qCZvlQmBZBlyrA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Vo1Z3ZuSZUo=:vrhxz5YVbXAXV6/4I56+O3 ws0Ba4m0X5sSPrOoejBrejsaav/QcwkSFTvwb0i6d8Q27eF3ir4i7Cbk9vFRZ3FxI7XkR6OnZ nugI8p3Xa1VTrDPqLqNQedtty+LckNnnYGacfqbdNeXpRysIH+HcmvJgxnD8tLrXv/o1tXCpB +AnrmrCEwLLNnGpDX4l5SJ/nKlPqWBgyBV+58ZNKilxkoddSUFIxChvLHr2TqxqIfQIUCS8Ts ikMi2sDE6q2qOmNGOt/aKPhJDNNA0IdwFeK/3fT6eorIk1Gl86/lcH0k63SuvxI6QdQg+YZrX JySl5j5Ou0SN9hwE7+I7bBSsrHay6G6wpRhYrEYmZqORimqIAhVLFkmvcebta6XF1u+LZQIhR 375RfEwloLoXdf+DaZ8SY7lqCIKrkEl/BRNBP6Hd99ypRJ5r4ILys8zWgtuYzd9L1tAJeY9H/ TSvqx/+kvBNX6vE//qtO95+DZL0+C7p8imNPCAp1/DqHuJSK3gzNW/LE0jGNCkrelUfTpjlmC zXn6awZA0zo0kgaWPOy9VC81lNEv085/wLLJobVsdEsO5o1NHERuop2h3TFBcPF7ro2Uspv+W ccNePwTPWHtkz1wa0zbglXSVDBuu8Yiwr9wCyXCvyiez8FPD6HxPte73pYm/Vk30/OTx6hXrB VKq/z2+FY1Rpo4K3TEhttBwEDuvqNEYQx6ar24hvjbKfZ9h+X1pjG2HkCLxSt+S+Kd80AbnzV RHqVVGJ8PZT/A7PHLLUWuZ/wgReacPOkPZdhbkPbPjP2VNm+P0cAIy0js+n+6dhryL17WG0Zl vIdOLfDntmzg7/srIxKdVLOFYQ8OOAdPM5AT++gdl5zZTSrM3kaC1gwLNH/Q3tlKnl8wlBi4r +MF7qRPncSkG/d5F0Orw== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2022 at 10:25 AM Kefeng Wang wrote: > > Since the following commits, > > v5.4 > commit 59d3ae9a5bf6 ("ARM: remove Intel iop33x and iop13xx support") > v5.11 > commit 3e3f354bc383 ("ARM: remove ebsa110 platform") > > The runtime hook arch_iounmap() on ARM is useless, kill arch_iounmap() > and __iounmap(), and the naming of arch_iounmap will be used in > GENERIC_IOREMAP with the later patch. > > Cc: Russell King > Signed-off-by: Kefeng Wang I had a very similar patch prototyped recently, Reviewed-by: Arnd Bergmann It would be nice to do the same for arch_ioremap_caller(), which now has two implementations left for mvebu and imx3, previously we had more for iop13xx, ebsa110, ixp4xx and msm. For both armada37x/380 and imx3, the only purpose is to override the mtype argument, and it feels like there should be a better way to do this, though I'm not sure what that is. Having an overridable mtype value per 256MB section of physical address space would be sufficient for both, but I don't know if that's any better than what we have. Arnd 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9681C433EF for ; Sat, 21 May 2022 20:31:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qdZojvk1z7qmrfFY2XtaimOIxJLQBCd8OwgIt5DIVWE=; b=1RldNq07Hdcfwg OXZB/HwIYt/zpKLnr7rAZ0JI4paNsUc2czi+ChGAVlE26eKv5mt+ItffQU09VcoNnT2j9CGqz2+vx HbGcJm6/NY229mzDksZAIY4Kt6AfCBlmnNn2hSF3PE9PMzp5FOWiYMxGsbpeGExe8g4EMqFhQ5sG1 FFYFVDLKhWbjjvrQdmReDoorLbLlExiIpDmTjZEZoJ1P40om8TFztPszm8dgn3ie3HRTN1nTSoV3Z t0gOWbdtVE146YxVstow01zWpLbLJXet9zGxE58D1QQ9CBDur5oXBqxnPiA0rURvg77o66LXMdgJq euBuGQzp4IB74YC4pktg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nsVk4-00HSG1-BX; Sat, 21 May 2022 20:30:28 +0000 Received: from mout.kundenserver.de ([212.227.17.24]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nsVjz-00HSEJ-VF for linux-arm-kernel@lists.infradead.org; Sat, 21 May 2022 20:30:25 +0000 Received: from mail-yw1-f174.google.com ([209.85.128.174]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Mk1BG-1nQ4kV3GhM-00kSoH for ; Sat, 21 May 2022 22:30:20 +0200 Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-2fedd26615cso115640847b3.7 for ; Sat, 21 May 2022 13:30:19 -0700 (PDT) X-Gm-Message-State: AOAM532a1reNj+y5sGzsqJ0GDCbCeHOiJdFzq1SZ8G+Y9mbYtC7XDeZ9 AuPIaTDpe0eJYpkVx8AavbYYO96u7wDXtmrsx0k= X-Google-Smtp-Source: ABdhPJxdzeQ8ppWmG4FaNugj1IVJL8hVon5ICr2txVNKnWSwzCAfUIa/u3XB2kovYWtRi5zFhQ8P1BD7cK9iFDjy8rQ= X-Received: by 2002:a81:950:0:b0:2fe:d88e:5529 with SMTP id 77-20020a810950000000b002fed88e5529mr16185220ywj.320.1653165018339; Sat, 21 May 2022 13:30:18 -0700 (PDT) MIME-Version: 1.0 References: <20220519082552.117736-1-wangkefeng.wang@huawei.com> <20220519082552.117736-2-wangkefeng.wang@huawei.com> In-Reply-To: <20220519082552.117736-2-wangkefeng.wang@huawei.com> From: Arnd Bergmann Date: Sat, 21 May 2022 22:30:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/6] ARM: mm: kill unused runtime hook arch_iounmap() To: Kefeng Wang Cc: Catalin Marinas , Will Deacon , Andrew Morton , Linux ARM , Linux Kernel Mailing List , Linux-MM , Christoph Hellwig , Arnd Bergmann , Anshuman Khandual , Russell King X-Provags-ID: V03:K1:3i/9KByKlDzwNr6qsO+uTQFybBGqudmOwcgU6qGSvUejBAmWMDv hV9RVk9EZeYrG/3z4RdiVEpnJoZpM2/Kg7QL2G4NE5fi101HC68tU2dcg1/FanE7FBxOIUk wJTjbcgCzEY3He+eb4THUwjxP6wrDvcoanFpH3FY6RNkMHPK0GOpNm61xUr5uEXgbrpETXP 6pT6vIiGMRSmhvRgvvhnw== X-UI-Out-Filterresults: notjunk:1;V03:K0:t8PwlA67hT0=:UNtEMNlt881WA++gGUyjo9 gE5bUbh52AovlCDXFyftoVYlMkGtLitmA/XH9qcENX68VtbY384iHpIaPqj4iy+9DwLLBggHI 80E0jWU0n6SWHWFP4HnpTAcV6NsHYab5txcSO9Un4gvhIHR3gbfn7ufvH4mZATKozEQHr2yfP PHlkYY8gBTCOh3D9CouivnUcOuqrk99ov1XZ4iJZnWkzv3V/tmyKGxI4ArlA5IE7msSAmYEVn moQJl9/tb4dSgGNtvAEhjSaoUNOmFmXiAQf17joiAknfzPPm3SX0Df7bZGPlkwDgr+13IrJL6 TWE3ohJT86DmipomfuETgwztGouwvMs0ZW8+E6NIEW8NoT3bcWsTQjV4G5SeFQgP3GTgMrkX2 6D/XwWocKob7gFjvG7FILHr+k9iRy1mmnI4nx9iWIojxp2iWMkyd83h1UDtRWJ5FeYA8lqn7i CpVKlNYd6MHZmiJG7QPbVNspl+yKJHQCz47/0zNvwa2ilqnI+GAjbfovcT3H4ZCovsWgHQTbi VpHQ7HpF7Iej+en4dtoq/ne45TGIuoP4VAi8L4/9VDgJKRiaZwvSYP7RY5FzofJxgD6oj9Wj5 Nx/T49obJ3wL9aLATpctoRZXtB+/uImpG0+QBBYoQrmQvai0GyY0s4d9UKXfmUTeicGW01C/x TfEErltGQVZtkqAdX61mGrn4+mzol5j3Mg74/G8JycSZx2kjKyXbWlQ5KjaQMFKZMGa5zAqU2 IR/mCbsNGSxpX+nwJAw3xbdt4zHGNx01PGOSleJQar/NgQ3w0XmudLHvC/9SinZ+/dNxy92TU 3TqqyWI/gaP2mowPAMkeMa+hkv2aqb7zVqnIEFfOsPhU32ul0HrTOyowTRLHOmrevr8iE8B/o QQkE0gYGK2BWBLDg0GKA== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220521_133024_334997_05E50B78 X-CRM114-Status: GOOD ( 18.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 19, 2022 at 10:25 AM Kefeng Wang wrote: > > Since the following commits, > > v5.4 > commit 59d3ae9a5bf6 ("ARM: remove Intel iop33x and iop13xx support") > v5.11 > commit 3e3f354bc383 ("ARM: remove ebsa110 platform") > > The runtime hook arch_iounmap() on ARM is useless, kill arch_iounmap() > and __iounmap(), and the naming of arch_iounmap will be used in > GENERIC_IOREMAP with the later patch. > > Cc: Russell King > Signed-off-by: Kefeng Wang I had a very similar patch prototyped recently, Reviewed-by: Arnd Bergmann It would be nice to do the same for arch_ioremap_caller(), which now has two implementations left for mvebu and imx3, previously we had more for iop13xx, ebsa110, ixp4xx and msm. For both armada37x/380 and imx3, the only purpose is to override the mtype argument, and it feels like there should be a better way to do this, though I'm not sure what that is. Having an overridable mtype value per 256MB section of physical address space would be sufficient for both, but I don't know if that's any better than what we have. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel