linux-kernel - Re: [PATCH v3 7/7] spi: imx: defer spi initialization, if DMA engine is pending

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:	Thu, 5 Nov 2015 17:18:31 +0100
From:	Anton Bondarenko <anton.bondarenko.sama@...il.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	broonie@...nel.org, b38343@...escale.com,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	vladimir_zapolskiy@...tor.com, jiada_wang@...tor.com
Subject: Re: [PATCH v3 7/7] spi: imx: defer spi initialization, if DMA engine
 is pending

On 05.11.2015 09:59, Sascha Hauer wrote:
> On Sun, Nov 01, 2015 at 03:41:41PM +0100, Anton Bondarenko wrote:
>> From: Anton Bondarenko <anton_bondarenko@...tor.com>
>>
>> If SPI device supports DMA mode, but DMA controller is not yet
>> available due to e.g. a delay in the corresponding kernel module
>> initialization, retry to initialize SPI driver later on instead of
>> falling back into PIO only mode.
>>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
>> Signed-off-by: Anton Bondarenko <anton_bondarenko@...tor.com>
>
> Ok, so 6/7 is only part of the deferral story. Maybe squash the two
> patches into one?
>
> Sascha

I would like to keep these two changes separately since I have a small 
concern about this exact change.

Let's assume such scenario:
- ECSPI configured to use DMA in device tree and DMA controller 
description specified. But there is no driver for this controller in kernel.
In this case dmaengine will always return -EDEFER and driver postpone 
spi-imx initialization. So finally there will be no SPI support even in 
PIO mode.
Or for example spi-imx will be compiled into kernel, but DMA controller 
driver will be on SPI-NOR based rootfs.

So the question is "Should we allow user to use incorrect combination of 
kernel configuration and DTS and work at least with some limitation?" Or 
should we try to guarantee device tree file requirement to use DMA.

Any thoughts?

Regards, Anton
--
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/