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:   Tue, 20 Sep 2016 09:32:51 +0100
From:   Peter Griffin <peter.griffin@...aro.org>
To:     Emil Velikov <emil.l.velikov@...il.com>,
        Arnd Bergmann <arnd@...db.de>
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.

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> 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.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


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

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

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

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ