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
| ||
|
Date: Thu, 8 Apr 2021 13:00:47 +0200 From: David Hildenbrand <david@...hat.com> To: Arnd Bergmann <arnd@...db.de> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, Joel Stanley <joel@....id.au>, David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>, Andrew Jeffery <andrew@...id.au>, Lucas Stach <l.stach@...gutronix.de>, Russell King <linux+etnaviv@...linux.org.uk>, Christian Gmeiner <christian.gmeiner@...il.com>, Mike Rapoport <rppt@...nel.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>, Linus Walleij <linus.walleij@...aro.org>, Michal Simek <michal.simek@...inx.com>, Masahiro Yamada <masahiroy@...nel.org>, Randy Dunlap <rdunlap@...radead.org>, Peter Collingbourne <pcc@...gle.com>, linux-aspeed <linux-aspeed@...ts.ozlabs.org>, dri-devel <dri-devel@...ts.freedesktop.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, The etnaviv authors <etnaviv@...ts.freedesktop.org>, Linux Fbdev development list <linux-fbdev@...r.kernel.org> Subject: Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv >>> In particular, it does not prevent a configuration with 'DRM_CMA=m' >> >> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module. > > Ok, at least that makes it easier. > >>> and 'DRMA_ASPEED_GFX=y', or any build failures from such >>> a configuration. >> >> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work >> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing? > > I thought you were trying to solve the problem where DRMA_ASPEED_GFX > can optionally link against CMA but would fail to build when the CMA code > is in a loadable module. Yes. I was trying to say: it works with this patch just fine. The issue you described does not seem to apply (DRM_CMA=m). > >> Your example looks more like a NOP - no? >> Or will it have the same effect? > > The example I gave is only meaningful if both are tristate, which is > not the case here as you explain. Okay, thanks. > > It is a somewhat awkward way to say "prevent this symbol from > being =y if the dependency is =m". What would be the right thing to do in the case here then to achieve the "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"? One approach could be to have for DMA_CMA default y if DRMA_ASPEED_GFX but it feels like the wrong way to tackle this. Thanks! -- Thanks, David / dhildenb
Powered by blists - more mailing lists