lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 28 Feb 2016 16:15:06 -0300
From:	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
Cc:	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization

On 27 February 2016 at 07:45, Robert Jarzmik <robert.jarzmik@...e.fr> wrote:
> Ezequiel Garcia <ezequiel@...guardiasur.com.ar> writes:
>
>> On 12 February 2016 at 19:29, Robert Jarzmik <robert.jarzmik@...e.fr> wrote:
>>> When the driver is initialized in a pure device-tree platform, the
>>> driver's probe fails allocating the dma channel :
>>> [  525.624435] pxa3xx-nand 43100000.nand: no resource defined for data DMA
>>> [  525.632088] pxa3xx-nand 43100000.nand: alloc nand resource failed
>>>
>>> The reason is that the DMA IO resource is not acquired through platform
>>> resources but by OF bindings.
>>>
>>> Fix this by ensuring that DMA IO resources are only queried in the non
>>> device-tree case.
>>>
>>> Fixes: 8f5ba31aa565 ("mtd: nand: pxa3xx-nand: switch to dmaengine")
>>> Signed-off-by: Robert Jarzmik <robert.jarzmik@...e.fr>
>>> ---
>>>  drivers/mtd/nand/pxa3xx_nand.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
>>> index a168cbcc1086..afd487d4b67f 100644
>>> --- a/drivers/mtd/nand/pxa3xx_nand.c
>>> +++ b/drivers/mtd/nand/pxa3xx_nand.c
>>> @@ -1750,7 +1750,7 @@ static int alloc_nand_resource(struct platform_device *pdev)
>>>         if (ret < 0)
>>>                 return ret;
>>>
>>> -       if (use_dma) {
>>> +       if (!np && use_dma) {
>>>                 r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
>>>                 if (r == NULL) {
>>>                         dev_err(&pdev->dev,
>>
>> Looking through the kernel tree, this change seems to be correct.
>>
>> However, I'm still wondering how DMA resources are obtained in the
>> device-tree case. Can you explain it to me?
>
> In the pxa case, look at my extract in [1].
> The lines to consider are :
>                         dmas = <&pdma 97 3>;
>                         dma-names = "data";
>
> Now have a look at the function pxad_dma_xlate() in drivers/dma/pxa_dma.c.
> You'll see that the "97" ends up in the chanel drcmr, and the "3" in the
> channel's prio, when the chanel is requested in the nand driver by calling
> dma_request_slave_channel_compat(). In the latter case, pxad_filter_fn() is not
> used, it's the pxad_dma_xlate() which is used instead.
>
> Is this what you were looking for ?
>

I see. That's exactly what I was missing.

Acked-by: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>

Thanks,
-- 
Ezequiel GarcĂ­a, VanguardiaSur
www.vanguardiasur.com.ar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ