[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 May 2015 11:24:03 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Suravee Suthikulanit <suravee.suthikulpanit@....com>,
Arnd Bergmann <arnd@...db.de>, <linaro-acpi@...ts.linaro.org>
CC: <rjw@...ysocki.net>, <herbert@...dor.apana.org.au>,
<catalin.marinas@....com>, <will.deacon@....com>,
<linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
<linux-crypto@...r.kernel.org>, <netdev@...r.kernel.org>,
<davem@...emloft.net>, <linux-arm-kernel@...ts.infradead.org>,
<lenb@...nel.org>
Subject: Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI
_CCA object
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.
Thanks,
Tom
>>
>> Arnd
>>
>
> Ah, got it. Sorry for confusion.
>
> Suravee
>
> _______________________________________________
> Linaro-acpi mailing list
> Linaro-acpi@...ts.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-acpi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists