linux-kernel - Re: [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies

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]

Date:	Tue, 1 Dec 2015 14:58:35 +0200
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	Vinod Koul <vinod.koul@...el.com>, Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Sekhar Nori <nsekhar@...com>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

On Tue, Dec 1, 2015 at 11:47 AM, Peter Ujfalusi <peter.ujfalusi@...com> wrote:
> On 11/30/2015 04:35 PM, Andy Shevchenko wrote:
>> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi <peter.ujfalusi@...com> wrote:
>>> Treat as true condition the case when the mask is NULL.
>>
>> What do you think about setting some default (all "on") mask when mask
>> is not supplied?
>
> Probably rephrasing the commit message to say that when the mask is NULL it
> means that the caller does not care about the capabilities of the dma device
> thus return with true in such a case.
>
> We could also drop this patch and in private_candidate() :
>
> -       if (!__dma_device_satisfies_mask(dev, mask)) {
> +       if (mask && !__dma_device_satisfies_mask(dev, mask)) {
>                 pr_debug("%s: wrong capabilities\n", __func__);
>                 return NULL;
>         }

Between patch and above proposal I would choose the latter one.

>> I don't know for sure but there might be cases when you don't want
>> literally *any* channel to satisfy.
>
> Or set DMA_SLAVE only in dma_request_chan()? What happens if we have cases
> when we are able to request channel for memcpy via dma_request_chan()
> (dedicated memcpy channel/DMA engine?) in that case we will have the SLAVE
> set, but not MEMCPY, or any other variation we do not know yet?

Frankly, have no idea.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/