Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753096AbbEKQQh (ORCPT ); Mon, 11 May 2015 12:16:37 -0400 Received: from foss.arm.com ([217.140.101.70]:58673 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752407AbbEKQQe (ORCPT ); Mon, 11 May 2015 12:16:34 -0400 Date: Mon, 11 May 2015 17:16:27 +0100 From: Catalin Marinas To: "Rafael J. Wysocki" Cc: Suravee Suthikulpanit , thomas.lendacky@amd.com, linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, arnd@arndb.de, linaro-acpi@lists.linaro.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, al.stone@linaro.org, linux-acpi@vger.kernel.org, netdev@vger.kernel.org, leo.duran@amd.com, hanjun.guo@linaro.org, msalter@redhat.com, grant.likely@linaro.org, davem@davemloft.net, linux-arm-kernel@lists.infradead.org, lenb@kernel.org Subject: Re: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency Message-ID: <20150511161626.GI18655@e104818-lin.cambridge.arm.com> References: <1431045436-8690-1-git-send-email-Suravee.Suthikulpanit@amd.com> <1431045436-8690-2-git-send-email-Suravee.Suthikulpanit@amd.com> <3684853.vaQGhc4jR5@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3684853.vaQGhc4jR5@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2085 Lines: 57 On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote: > On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote: > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > > index ab2cbb5..7822149 100644 > > --- a/drivers/acpi/Kconfig > > +++ b/drivers/acpi/Kconfig > > @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > > config ACPI_SYSTEM_POWER_STATES_SUPPORT > > bool > > > > +config ACPI_CCA_REQUIRED > > + bool > > + > > +config ARM64_SUPPORT_ACPI_CCA_ZERO > > Hmm. I guess the Arnd's idea what to simply use CONFIG_ARM64 directly instead > of adding this new option. I agree. > > +static inline bool acpi_dma_is_supported(struct acpi_device *adev) > > +{ > > + /** > > + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1) > > + * This should be equivalent to specifyig dma-coherent for > > + * a device in OF. > > + * > > + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > > + * we would rely on arch-specific cache maintenance for > > + * non-coherence DMA operations if architecture specifies > > + * _XXX_SUPPORT_CCA_ZERO. Otherwise, we do not support > > + * DMA on this device and fallback to arch-specific default > > + * handling. > > + * > > + * For the case when _CCA is missing (i.e. cca_seen=0) but > > + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA, > > + * and fallback to arch-specific default handling. > > + */ > > + return adev && (adev->flags.is_coherent || > > + (adev->flags.cca_seen && > > + IS_ENABLED(CONFIG_ARM64_SUPPORT_ACPI_CCA_ZERO))); > > So what exactly would be wrong with using IS_ENABLED(CONFIG_ARM64) here? I'm not sure I follow why we need to check for ARM64 here at all. Can we not just have something like: return adev && (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) || adev->flags.cca_seen) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/