Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2278844pxy; Tue, 3 Aug 2021 02:17:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzu5sKS2oSiUXXlPx4NHhkl/N4t8D2fH+ulygtu1VVrXXpAmUU6XeMmshPJCr71Rwl+tbF0 X-Received: by 2002:a5d:91c2:: with SMTP id k2mr1648088ior.117.1627982239847; Tue, 03 Aug 2021 02:17:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627982239; cv=none; d=google.com; s=arc-20160816; b=oae2tpeYZBhGiZ1Ijv96qwI2XRE6CGF1pN2+PjLlVT63hlqcm0514IMGBhJiRnMZo+ JuNzWwPnVXCiUs5kfBzFu9XFWVD++Av53SOUOdeVCxj4scAih0CSfNULpsVjd6hEJ/Lj 1Vay92yb24XRoL8VOJKTNmd7SitHwdRwUlwD9NOz7pilYg2gGsmdQpUbsCxQVzyVVQu4 48I3bHwOS80qyJ5GffR5wWLTn+4Z2exNww5SuaupkKUW148sfYEfy8NaKUv8gqOylW9m iV+ZGdZdrm1Y5VkwHxaKMlTYCPTxasrquwiE2KGYm35Hn/UyqSltZZywNfegRIYDR1z7 g4Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=tcwcvJqLKrGb+eDQcPgtysw5PwfF0PtRd4tI/45fHik=; b=X/3XylWv+RCi+lNrTxrpnXHY3eDkq8K9KthyPlyq6PBM7MAl5xMpW810d6XX3lvZQG kkV+F7mWd+HtGZtdIH550MSQ+h2XV9Ai2H70BQGM0H4nqr9eXVgLeh9G7JVFWNnxW1ex HeXu2tLBD+o0nrN6J5GkItiVxtXRBekX2lYxHMx3a5Z9+f5DjTHo8RN7BUeSeIwl7j23 t1po7bEvkbcfIjmlo5Zz+gPKeI6cfTj512yT3KbK42sRaQIDifK2KCn0pQ/ipWPu7fGa LMskyCeZImhgE5JM1Bi7ldZ15xQJdDUXPiHSJb9sfmgrDs1McwRTJr8mBbtLjm7NUC5/ qhwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v13si17174451ilj.65.2021.08.03.02.17.07; Tue, 03 Aug 2021 02:17:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234939AbhHCJQZ (ORCPT + 99 others); Tue, 3 Aug 2021 05:16:25 -0400 Received: from foss.arm.com ([217.140.110.172]:45196 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234805AbhHCJQX (ORCPT ); Tue, 3 Aug 2021 05:16:23 -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 83B5411D4; Tue, 3 Aug 2021 02:16:12 -0700 (PDT) Received: from lpieralisi (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 11A933F40C; Tue, 3 Aug 2021 02:16:10 -0700 (PDT) Date: Tue, 3 Aug 2021 10:16:05 +0100 From: Lorenzo Pieralisi To: Catalin Marinas , rjw@rjwysocki.net Cc: linux-kernel@vger.kernel.org, Hanjun Guo , Ard Biesheuvel , Will Deacon , Sudeep Holla , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Veronika kabatova , Robin Murphy Subject: Re: [PATCH v2 3/3] ACPI: Add memory semantics to acpi_os_map_memory() Message-ID: <20210803091605.GA9637@lpieralisi> References: <20210726100026.12538-1-lorenzo.pieralisi@arm.com> <20210802152359.12623-4-lorenzo.pieralisi@arm.com> <20210802164622.GJ18685@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210802164622.GJ18685@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 02, 2021 at 05:46:22PM +0100, Catalin Marinas wrote: > On Mon, Aug 02, 2021 at 04:23:59PM +0100, Lorenzo Pieralisi wrote: > > The memory attributes attached to memory regions depend on architecture > > specific mappings. > > > > For some memory regions, the attributes specified by firmware (eg > > uncached) are not sufficient to determine how a memory region should be > > mapped by an OS (for instance a region that is define as uncached in > > firmware can be mapped as Normal or Device memory on arm64) and > > therefore the OS must be given control on how to map the region to match > > the expected mapping behaviour (eg if a mapping is requested with memory > > semantics, it must allow unaligned accesses). > > > > Rework acpi_os_map_memory() and acpi_os_ioremap() back-end to split > > them into two separate code paths: > > > > acpi_os_memmap() -> memory semantics > > acpi_os_ioremap() -> MMIO semantics > > > > The split allows the architectural implementation back-ends to detect > > the default memory attributes required by the mapping in question > > (ie the mapping API defines the semantics memory vs MMIO) and map the > > memory accordingly. > > > > Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com > > Tested-by: Hanjun Guo > > Signed-off-by: Lorenzo Pieralisi > > Acked-by: Ard Biesheuvel > > Cc: Ard Biesheuvel > > Cc: Will Deacon > > Cc: Hanjun Guo > > Cc: Sudeep Holla > > Cc: Catalin Marinas > > Cc: "Rafael J. Wysocki" > > For the arm64 bits: > > Acked-by: Catalin Marinas > > I presume this will get merged via the ACPI tree? Thank you, I don't know what's the best option in Rafael's opinion (of course if he is OK with the patches which are mostly touching ACPI code). Lorenzo