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  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, 8 Apr 2021 13:00:47 +0200
From:   David Hildenbrand <>
To:     Arnd Bergmann <>
Cc:     Linux Kernel Mailing List <>,
        Linux-MM <>, Joel Stanley <>,
        David Airlie <>,
        Daniel Vetter <>,
        Andrew Jeffery <>,
        Lucas Stach <>,
        Russell King <>,
        Christian Gmeiner <>,
        Mike Rapoport <>,
        Bartlomiej Zolnierkiewicz <>,
        Linus Walleij <>,
        Michal Simek <>,
        Masahiro Yamada <>,
        Randy Dunlap <>,
        Peter Collingbourne <>,
        linux-aspeed <>,
        dri-devel <>,
        Linux ARM <>,
        The etnaviv authors <>,
        Linux Fbdev development list <>
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.



David / dhildenb

Powered by blists - more mailing lists