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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BL3PR11MB653276DFD3339ADAADC70CCFA2EE2@BL3PR11MB6532.namprd11.prod.outlook.com>
Date: Wed, 29 Jan 2025 09:17:29 +0000
From: "Rabara, Niravkumar L" <niravkumar.l.rabara@...el.com>
To: Miquel Raynal <miquel.raynal@...tlin.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

Hi Miquèl,


> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@...tlin.com>
> Sent: Tuesday, 21 January, 2025 5:52 PM
> To: Rabara, Niravkumar L <niravkumar.l.rabara@...el.com>
> Cc: Richard Weinberger <richard@....at>; Vignesh Raghavendra
> <vigneshr@...com>; linux@...blig.org; Shen Lichuan <shenlichuan@...o.com>;
> Jinjie Ruan <ruanjinjie@...wei.com>; u.kleine-koenig@...libre.com; linux-
> mtd@...ts.infradead.org; linux-kernel@...r.kernel.org; stable@...r.kernel.org
> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when
> DMA is not ready
> 
> 
> Typo (prob) in the title.
> 
> > From: Niravkumar L Rabara <niravkumar.l.rabara@...el.com>
> >
> > Use deferred driver probe in case the DMA driver is not probed.
> 
> Only devices are probed, not drivers.

I will fix the title and commit message in v3.
> 
> > --- a/drivers/mtd/nand/raw/cadence-nand-controller.c
> > +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
> > @@ -2908,7 +2908,7 @@ static int cadence_nand_init(struct cdns_nand_ctrl
> *cdns_ctrl)
> >  		if (!cdns_ctrl->dmac) {
> >  			dev_err(cdns_ctrl->dev,
> >  				"Unable to get a DMA channel\n");
> > -			ret = -EBUSY;
> > +			ret = -EPROBE_DEFER;
> 
> Does it work if there is no DMA channel provided? The bindings do not mention
> DMA channels as mandatory.
> 

The way Cadence NAND controller driver is written in such a way that it uses 
has_dma=1 as hardcoded value, indicating that slave DMA interface is connected
to DMA engine. However, it does not utilize the dedicated DMA channel information
from the device tree.

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. 

> Also, wouldn't it be more pleasant to use another helper from the DMA core
> that returns a proper return code? So we now which one among -EBUSY, -
> ENODEV or -EPROBE_DEFER we get?
> 

Agree.
I will change to "dma_request_chan_by_mask" instead of "dma_request_channel "
so it can return a proper error code. 
  
		cdns_ctrl->dmac = dma_request_chan_by_mask(&mask);
		if (IS_ERR(cdns_ctrl->dmac)) {
			ret = PTR_ERR(cdns_ctrl->dmac);
			if (ret != -EPROBE_DEFER)
				dev_err(cdns_ctrl->dev,
					"Failed to get a DMA channel:%d\n",ret);
			goto disable_irq;
		}

Is this reasonable? 

Thanks,
Nirav