linux-kernel - Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87msf8z5uu.fsf@bootlin.com>
Date: Thu, 30 Jan 2025 16:19:53 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Rabara, Niravkumar L" <niravkumar.l.rabara@...el.com>
Cc: Richard Weinberger <richard@....at>,  Vignesh Raghavendra
 <vigneshr@...com>,  "linux@...blig.org" <linux@...blig.org>,  Shen Lichuan
 <shenlichuan@...o.com>,  Jinjie Ruan <ruanjinjie@...wei.com>,
  "u.kleine-koenig@...libre.com" <u.kleine-koenig@...libre.com>,
  "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
  "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob
 when DMA is not ready

Hello,

>> > Driver works without external DMA interface i.e. has_dma=0.
>> > However current driver does not have a mechanism to configure it from
>> > device tree.
>> 
>> What? Why are you requesting a DMA channel from a dmaengine in this case?
>> 
>> Please make the distinction between the OS implementation (the driver) and
>> the DT binding which describe the HW and only the HW.
>> 
>
> Let me clarify from bindings(hw) and driver prospective. 
>
> Bindings :-
> Cadence NAND controller HW has MMIO registers, so called slave DMA interface
> for page programming or page read. 
>         reg = <0x10b80000 0x10000>,
>               <0x10840000 0x10000>;
>         reg-names = "reg", "sdma"; // sdma =  Slave DMA data port register set
>
> It appears that dt bindings has captured sdma interface correctly.

Slave DMA is very confusing because in Linux we make the distinction
between:
1- external DMA (generic DMA controller) driven
   through the dmaengine API, through which we interact using the so
   called slave API
2- peripheral DMA (DMA controller embedded in the NAND IP) when there is
   no "external/generic" engine. In this case we control DMA transfers
   using the registers of the NAND controller (or a nearby range, in
   this case), the same driver handles both the NAND and the DMA part.

You used the wording Slave DMA (#1), but it feels like you are talking
about the other (#2). Can you please confirm in which case we are?

> Linux Driver:-
> Driver can read these sdma registers directly or it can use the DMA.
> Existing driver code has hardcoded has_dma with an assumption that
> an external DMA is always used and relies on DMA API for data
> transfer.

I am sorry but DMA API does not mean much. There are 3 APIs:
- dma-mapping, for the buffers and the coherency
- dmaengine, used in case #1 only, to drive the external DMA controllers
- dma-buf to share buffers between areas in the kernel (out of scope)

> Thant is why it requires to use DMA channel from dmaengine.

If I understand it right, no :-)

Either you have an external DMA controller (#2) or an internal one (#1)
but in this second case there is no DMA channel request nor any
engine-related API. Of course you need to use the dma-mapping API for
the buffers.

> In my previous reply, I tried to describe this driver scenario but maybe I mixed up. 
> has_dma=0, i.e. accessing sdma register without using dmaengine is
> also working.

But do you have an external DMA engine in the end? Or is it specific to
the NAND controller?

> However, currently there is no option in driver to choose between using dmaengine and
> direct register access.
>

Thanks,
Miquèl