linux-kernel - Re: [PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS

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: <20140831130516.GH29327@sirena.org.uk>
Date:	Sun, 31 Aug 2014 14:05:16 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	linux-spi <linux-spi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] spi/drivers: Restrict COMPILE_TEST by HAS_DMA where
 needed

On Sun, Aug 31, 2014 at 10:39:09AM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 29, 2014 at 9:13 PM, Geert Uytterhoeven

> >> I'm wondering if it isn't better to have the non-DMA platforms define
> >> stub (always error) DMA functions instead - it's less error prone and
> >> with SPI there's a bunch of drivers which can run perfectly usefully
> >> without DMA while optionally supporting DMA.

> > The SPI problem will sort itself out once all SPI master drivers have been
> > converted to use the SPI DMA core ;-)

> BTW, the dmaengine API has stubs, only the low-level dma-mapping API
> doesn't. That's why e.g. spi-rspi doesn't need a dependency on HAS_DMA.
> So it's indeed a good thing to handle the low-level DMA mapping in the
> subsystem's core, as only that part can be optional and depend on HAS_DMA.

Yeah, but I'd expect there's other subsystems which will be in a similar
boat here and with dmaengine having stubs it seems strange that the
mapping API doesn't.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)