linux-kernel - Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACvgo52_g7anGBd9HTUyYsbp5QmQEk9LR3nNHgSTgjQ29G3ViA@mail.gmail.com>
Date:   Tue, 20 Sep 2016 00:18:48 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Peter Griffin <peter.griffin@...aro.org>
Cc:     LAKML <linux-arm-kernel@...ts.infradead.org>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        kernel@...inux.com, vinod.koul@...el.com, patrice.chotard@...com,
        dan.j.williams@...el.com, David Airlie <airlied@...ux.ie>,
        Gerd Hoffmann <kraxel@...hat.com>, ohad@...ery.com,
        bjorn.andersson@...aro.org,
        devicetree <devicetree@...r.kernel.org>,
        linux-remoteproc@...r.kernel.org,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        "open list:VIRTIO GPU DRIVER" 
        <virtualization@...ts.linux-foundation.org>,
        dmaengine@...r.kernel.org, lee.jones@...aro.org
Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@...aro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil