Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965985AbbEESDM (ORCPT ); Tue, 5 May 2015 14:03:12 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:53348 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965923AbbEESDF (ORCPT ); Tue, 5 May 2015 14:03:05 -0400 From: Arnd Bergmann To: Tom Lendacky Cc: Suravee Suthikulanit , linaro-acpi@lists.linaro.org, rjw@rjwysocki.net, herbert@gondor.apana.org.au, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-crypto@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net, linux-arm-kernel@lists.infradead.org, lenb@kernel.org Subject: Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object Date: Tue, 05 May 2015 20:02:53 +0200 Message-ID: <9405327.TMH3y4SfqS@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5548EEA3.8010101@amd.com> References: <1430838729-21572-1-git-send-email-Suravee.Suthikulpanit@amd.com> <5548EC47.3020501@amd.com> <5548EEA3.8010101@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:hAgWjbWBzIBrp+Zat1DBGS2XypxUfO0Leb3Ke5ycWhgpVpySQ1t KdXhOfXY8+YkhnHZz1fHaWdYMLJWRBPECZtXKsBYtC6eovgLo4rkcNqssK3+angZIoRzfZC e3Zc7F02ci6u94Gv45qImFKTFU/mxphHcuaZtvVWa0186upYR0U7xwsRELMLFfn+xyCDPqP JajY8ywb/6VzPxVDOckPg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1497 Lines: 34 On Tuesday 05 May 2015 11:24:03 Tom Lendacky wrote: > On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: > >>> > >>> However, codes in several places are making use of dma_map_ops without > >>> checking if the ops are NULL (i.e. > >>> include/asm-generic/dma-mapping-common.h and in arch-specific > >>> implementation). If setting it to NULL is what we are planning to > >>> support, we would need to scrub the current code to put NULL check. > >>> Also, would you consider if that is safe to do going forward? > >>> > >>> > >> > >> I mean the dma_mask pointer, not dma_map_ops. > > Except a lot of drivers will actually set the dma_mask pointer during > probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by > calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops > might be the safest way to go. Those drivers are broken already, I don't think we should worry about them. Let's just fix them properly when we run into problems with them. Basically any use of dma_coerce_mask_and_coherent() is an annotation for a bug where a driver used to set dev->dma_mask = &dev->coherent_dma_mask manually. Arnd -- 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/