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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5678AC4338F for ; Mon, 16 Aug 2021 10:59:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 35ACD60F42 for ; Mon, 16 Aug 2021 10:59:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235784AbhHPLAD (ORCPT ); Mon, 16 Aug 2021 07:00:03 -0400 Received: from foss.arm.com ([217.140.110.172]:42872 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232390AbhHPLAC (ORCPT ); Mon, 16 Aug 2021 07:00:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 583B36D; Mon, 16 Aug 2021 03:59:31 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 76F743F40C; Mon, 16 Aug 2021 03:59:29 -0700 (PDT) Subject: Re: [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast To: Ard Biesheuvel , Lorenzo Pieralisi Cc: Christoph Hellwig , Linux Kernel Mailing List , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux ARM , Veronika kabatova , Will Deacon , Hanjun Guo , Sudeep Holla , Catalin Marinas References: <20210726100026.12538-1-lorenzo.pieralisi@arm.com> <20210802152359.12623-2-lorenzo.pieralisi@arm.com> <20210811145508.GA3650@lpieralisi> <20210816095854.GA2599@lpieralisi> From: Robin Murphy Message-ID: <381418c8-5302-6991-b3aa-df6378dd1c64@arm.com> Date: Mon, 16 Aug 2021 11:59:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 2021-08-16 11:21, Ard Biesheuvel wrote: > On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi > wrote: >> >> On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote: >>> On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote: >>>> On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote: >>>>> The whole problem we are solving here is that ACPI, being based on >>>>> x86, conflates MMIO mappings with memory mappings, and has been using >>>>> the same underlying infrastructure for either. >>>> >>>> So let's fix that problem instead of papering over it. >>> >>> Patch (3) in this series is a fix - I would ask whether it makes >>> sense to merge patches (2-3) now and think about reworking the current >>> ACPI IO/MEM mapping API later, it can be an invasive change for a fix, >>> assuming we agree on how to rework the ACPI IO/MEM mapping API. >> >> What should we do then with this series ? >> > > It is not even clear that reworking the ACPI core is feasible to begin > with, OTOH, fixing a sparse warning is arguably not a critical bug fix > either, so I'd suggest we just drop that bit. Indeed, the only way to truly fix the issue is to fire up the time machine and rewrite the ACPI and EFI specs to not define that tables and data may or may not be required to be mapped as Device memory depending on the whims of the firmware. Otherwise we're basically always going to have one or more casts *somewhere*, even if we were to play it safe and return everything as iomem instead. I guess for read-only access to tables, the core code might be able to maintain a shadow copy of anything device-memory-mapped in normal memory and expose that instead, but if anything has to be writeable I'm not sure how we could abstract that "properly". Robin. 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 X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EB64C4338F for ; Mon, 16 Aug 2021 11:02:03 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 46F1F60EFF for ; Mon, 16 Aug 2021 11:02:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 46F1F60EFF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aAYouRs9sxQN/vmuTVxZV8IdR8IudTfmpIezMEyMSrU=; b=cEDZ+MaKvEj1JK8UT76QJXOCB6 otz5Y4DDeo4QHa51h2SGnYV4aSl5uZ34uwzPE8u/sh/t4yhHpboCRGT3VJ6bsMHhv8BshWkf2/95k R2Ia3BDrGg2H7PPBXtuOXuRDjdQujd+pTS8VOvGKrzhMOr3BP1n0Ak5MPORau9VvP5n5G4kkuZB8R urnh+SGaraAD6kKgtldC9tU6ljrpGbptk9fOd+eYPGu1L7RzhKQ1OFJT1StFuTQ4C6IXzUst49Cfg GVi5X4yNtof2cuVf7sVROHpVq8lZPnAMcEqFUiQQGZ32y4oW3Bx8uHu4po8lwqrpysp7OnKfMkyVw zH4G6hbw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFaLD-00Gnew-QN; Mon, 16 Aug 2021 10:59:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFaL8-00Gnd1-K0 for linux-arm-kernel@lists.infradead.org; Mon, 16 Aug 2021 10:59:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 583B36D; Mon, 16 Aug 2021 03:59:31 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 76F743F40C; Mon, 16 Aug 2021 03:59:29 -0700 (PDT) Subject: Re: [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast To: Ard Biesheuvel , Lorenzo Pieralisi Cc: Christoph Hellwig , Linux Kernel Mailing List , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux ARM , Veronika kabatova , Will Deacon , Hanjun Guo , Sudeep Holla , Catalin Marinas References: <20210726100026.12538-1-lorenzo.pieralisi@arm.com> <20210802152359.12623-2-lorenzo.pieralisi@arm.com> <20210811145508.GA3650@lpieralisi> <20210816095854.GA2599@lpieralisi> From: Robin Murphy Message-ID: <381418c8-5302-6991-b3aa-df6378dd1c64@arm.com> Date: Mon, 16 Aug 2021 11:59:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210816_035934_773042_20E2C290 X-CRM114-Status: GOOD ( 24.40 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-08-16 11:21, Ard Biesheuvel wrote: > On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi > wrote: >> >> On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote: >>> On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote: >>>> On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote: >>>>> The whole problem we are solving here is that ACPI, being based on >>>>> x86, conflates MMIO mappings with memory mappings, and has been using >>>>> the same underlying infrastructure for either. >>>> >>>> So let's fix that problem instead of papering over it. >>> >>> Patch (3) in this series is a fix - I would ask whether it makes >>> sense to merge patches (2-3) now and think about reworking the current >>> ACPI IO/MEM mapping API later, it can be an invasive change for a fix, >>> assuming we agree on how to rework the ACPI IO/MEM mapping API. >> >> What should we do then with this series ? >> > > It is not even clear that reworking the ACPI core is feasible to begin > with, OTOH, fixing a sparse warning is arguably not a critical bug fix > either, so I'd suggest we just drop that bit. Indeed, the only way to truly fix the issue is to fire up the time machine and rewrite the ACPI and EFI specs to not define that tables and data may or may not be required to be mapped as Device memory depending on the whims of the firmware. Otherwise we're basically always going to have one or more casts *somewhere*, even if we were to play it safe and return everything as iomem instead. I guess for read-only access to tables, the core code might be able to maintain a shadow copy of anything device-memory-mapped in normal memory and expose that instead, but if anything has to be writeable I'm not sure how we could abstract that "properly". Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel