On 2018-05-25 10:41 AM, Christoph Hellwig wrote:
> On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
>> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
>> No. _
On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
>>> On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong
Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface
for dma allocations and just cause problems. I actually plan to
g
On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
> On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
>>> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface
>>> for dma allocations and just cause problems. I actually plan to
>>> get rid of the gfp_t argument in dma_
On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
> > No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface
> > for dma allocations and just cause problems. I actually plan to
> > get rid of the gfp_t argument in dma_alloc_attrs sooner, and only
> > allow either GFP_K
On 2018-05-02 02:41 PM, Christoph Hellwig wrote:
> On Wed, May 02, 2018 at 02:18:56PM +0200, Daniel Vetter wrote:
>> Other dma-api backends like cma just shut up when __GFP_NOWARN is
>> passed. And afaiui Christoph Hellwig has plans to nuke the DMA_ATTR
>> stuff (or at least clean it up) - should w
On Tue, May 01, 2018 at 03:24:11PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The result was printing the warning only when we were explicitly asked
> not to.
Thanks, applied to the dma-mapping tree for 4.17.
On Wed, May 02, 2018 at 02:18:56PM +0200, Daniel Vetter wrote:
> Other dma-api backends like cma just shut up when __GFP_NOWARN is
> passed. And afaiui Christoph Hellwig has plans to nuke the DMA_ATTR
> stuff (or at least clean it up) - should we just remove
> DMA_ATTR_NO_WARN and instead only look
On Wed, May 2, 2018 at 11:49 AM, Christian König
wrote:
> Am 01.05.2018 um 15:24 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>>
>> The result was printing the warning only when we were explicitly asked
>> not to.
>>
>> Cc: sta...@vger.kernel.org
>> Fixes: 0176adb004065d6815a8e67946752df4cd94
Am 01.05.2018 um 15:24 schrieb Michel Dänzer:
From: Michel Dänzer
The result was printing the warning only when we were explicitly asked
not to.
Cc: sta...@vger.kernel.org
Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation"
Signed-off-by: Michel Dän
From: Michel Dänzer
The result was printing the warning only when we were explicitly asked
not to.
Cc: sta...@vger.kernel.org
Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation"
Signed-off-by: Michel Dänzer
---
lib/swiotlb.c | 2 +-
1 file changed, 1
11 matches
Mail list logo
