From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_* Date: Fri, 14 Dec 2018 19:35:09 +0100 Message-ID: <20181214183509.GA5247@lst.de> References: <20181214082515.14835-1-hch@lst.de> <20181214082515.14835-2-hch@lst.de> <20181214181056.GA17941@ravnborg.org> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20181214181056.GA17941@ravnborg.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sam Ravnborg Cc: Christoph Hellwig , iommu@lists.linux-foundation.org, Michal Simek , Ashutosh Dixit , linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-c6x-dev@linux-c6x.org, linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-kernel@vger.kernel.org On Fri, Dec 14, 2018 at 07:10:56PM +0100, Sam Ravnborg wrote: > Hi Christoph, > > I stumbled upon this one: > > #define __get_dma_pages(gfp_mask, order) \ > __get_free_pages((gfp_mask) | GFP_DMA, (order)) This isn't directly related to the dma mapping, but another place that hides GFP_DMA allocations. So no need for the treatment, but we really should kill this obsfucating wrapper.. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@lst.de (Christoph Hellwig) Date: Fri, 14 Dec 2018 19:35:09 +0100 Subject: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_* In-Reply-To: <20181214181056.GA17941@ravnborg.org> References: <20181214082515.14835-1-hch@lst.de> <20181214082515.14835-2-hch@lst.de> <20181214181056.GA17941@ravnborg.org> List-ID: Message-ID: <20181214183509.GA5247@lst.de> To: linux-snps-arc@lists.infradead.org On Fri, Dec 14, 2018@07:10:56PM +0100, Sam Ravnborg wrote: > Hi Christoph, > > I stumbled upon this one: > > #define __get_dma_pages(gfp_mask, order) \ > __get_free_pages((gfp_mask) | GFP_DMA, (order)) This isn't directly related to the dma mapping, but another place that hides GFP_DMA allocations. So no need for the treatment, but we really should kill this obsfucating wrapper.. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Fri, 14 Dec 2018 19:35:09 +0100 Subject: [OpenRISC] [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_* In-Reply-To: <20181214181056.GA17941@ravnborg.org> References: <20181214082515.14835-1-hch@lst.de> <20181214082515.14835-2-hch@lst.de> <20181214181056.GA17941@ravnborg.org> Message-ID: <20181214183509.GA5247@lst.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org On Fri, Dec 14, 2018 at 07:10:56PM +0100, Sam Ravnborg wrote: > Hi Christoph, > > I stumbled upon this one: > > #define __get_dma_pages(gfp_mask, order) \ > __get_free_pages((gfp_mask) | GFP_DMA, (order)) This isn't directly related to the dma mapping, but another place that hides GFP_DMA allocations. So no need for the treatment, but we really should kill this obsfucating wrapper.. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Fri, 14 Dec 2018 18:35:09 +0000 Subject: Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_* Message-Id: <20181214183509.GA5247@lst.de> List-Id: References: <20181214082515.14835-1-hch@lst.de> <20181214082515.14835-2-hch@lst.de> <20181214181056.GA17941@ravnborg.org> In-Reply-To: <20181214181056.GA17941@ravnborg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sam Ravnborg Cc: Christoph Hellwig , iommu@lists.linux-foundation.org, Michal Simek , Ashutosh Dixit , linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-c6x-dev@linux-c6x.org, linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-kernel@vger.kernel.org On Fri, Dec 14, 2018 at 07:10:56PM +0100, Sam Ravnborg wrote: > Hi Christoph, > > I stumbled upon this one: > > #define __get_dma_pages(gfp_mask, order) \ > __get_free_pages((gfp_mask) | GFP_DMA, (order)) This isn't directly related to the dma mapping, but another place that hides GFP_DMA allocations. So no need for the treatment, but we really should kill this obsfucating wrapper..