Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Message-ID: <trinity-a3fa3f57-696b-44f1-9440-63cd249d1568-1655492096670@3c-app-gmx-bap03>
From:   Frank Wunderlich <frank-w@public-files.de>
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org,
        iommu@lists.linux-foundation.org,
        Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Aw: Re: helping with remapping vmem for dma
Content-Type: text/plain; charset=UTF-8
Date:   Fri, 17 Jun 2022 20:54:56 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <88080559-0c96-ec91-6f72-df05a2d0c5af@arm.com>
References: <trinity-2d26eb5e-6a3f-485a-aed7-134c1e164942-1655482643278@3c-app-gmx-bap03>
 <88080559-0c96-ec91-6f72-df05a2d0c5af@arm.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> Gesendet: Freitag, 17. Juni 2022 um 19:22 Uhr
> Von: "Robin Murphy" <robin.murphy@arm.com>
> An: "Frank Wunderlich" <frank-w@public-files.de>, "Christoph Hellwig" <h=
ch@lst.de>
> Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, "Mar=
ek Szyprowski" <m.szyprowski@samsung.com>
> Betreff: Re: helping with remapping vmem for dma
>
> On 2022-06-17 17:17, Frank Wunderlich wrote:
> > Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig <hch@lst.de>:
> >> On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote:
> >>> Put simply, if you want to call dma_map_single() on a buffer, then t=
hat
> >>> buffer needs to be allocated with kmalloc() (or technically alloc_pa=
ges(),
> >>> but then dma_map_page() would make more sense when dealing with enti=
re
> >>> pages.
> >>
> >> Yes.  It sounds like the memory here comes from the dma coherent
> >> allocator, in which case the code need to use the address returned
> >> by that and not create another mapping.
> >
> > Hi
> >
> > traced it to buffer allocated as simple uint8-array [1]:
> >
> > UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + sizeof(INIT_EVENT_CMD_=
RESULT)];
>
> Ah, so it's trying to do DMA with a stack variable? CONFIG_DMA_API_DEBUG
> is your friend; it should have screamed about that specifically.
> Allocate this buffer properly to begin with, and free it again on the
> way out of the function (it's surely not worth having to make a
> temporary copy further down the callchain). The kmalloc flags can
> probably be regular GFP_KERNEL, unless this can be called from more
> restrictive contexts like an IRQ handler - the fact that it might be
> mapped for DMA later is essentially irrelevant in that respect.

Hi,

simply replaced the stack-vars to uint_8-pointers and using kmalloc/kfree =
for
memory handling (needed to replace some returns to goto to always free mem=
ory).

Thanks very much for support, driver is now working again :)

https://github.com/frank-w/BPI-R2-4.14/commit/7f3a721d5b0d8ca44935c23d5513=
a19cc57786c0

> Thanks,
> Robin.