From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20160927170115.GD7509@tuxbot> References: <1473081421-16555-1-git-send-email-peter.griffin@linaro.org> <1473081421-16555-18-git-send-email-peter.griffin@linaro.org> <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd> <20160927170115.GD7509@tuxbot> From: Emil Velikov Date: Thu, 6 Oct 2016 11:10:17 +0100 Message-ID: Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue. Content-Type: text/plain; charset=UTF-8 To: Bjorn Andersson Cc: Peter Griffin , Arnd Bergmann , LAKML , "Linux-Kernel@Vger. Kernel. Org" , kernel@stlinux.com, vinod.koul@intel.com, patrice.chotard@st.com, dan.j.williams@intel.com, David Airlie , Gerd Hoffmann , Ohad Ben-Cohen , devicetree , linux-remoteproc@vger.kernel.org, ML dri-devel , "open list:VIRTIO GPU DRIVER" , dmaengine@vger.kernel.org, Lee Jones List-ID: Hi Bjorn, On 27 September 2016 at 18:01, Bjorn Andersson wrote: > On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote: > >> On 20 September 2016 at 09:32, Peter Griffin wrote: >> > Hi Emil, >> > >> > On Tue, 20 Sep 2016, Emil Velikov wrote: >> > >> >> On 5 September 2016 at 14:16, Peter Griffin 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 >> > >> Might be worth taking a closer look into these at some point. >> > > The general idea here is that VIRTIO provides the "framework" and as > such drivers implementing VIRTIO do select and drivers using virtio use > depends. > > This is found in several places around the kernel. > >> > >> >> 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 ? >> >> > > There's nothing unusual in remoteproc that forces us to stay with this > model; however the parts related to the REMOTEPROC config is useless by > themselves. > I'm afraid that the "supporting" arguments you're using are generic and not specific to remoteproc. Although as Jani mentioned and pointed to the documentation, remoteproc is {mis,ab}using 'select' leading to issues elsewhere. In the long term we might want to switch to 'select' and attribute kconfig like Jani suggested. But in the short term we want to avoid select-ing things just for our "convenience". Thanks Emil From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941791AbcJFKKZ (ORCPT ); Thu, 6 Oct 2016 06:10:25 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36165 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936003AbcJFKKU (ORCPT ); Thu, 6 Oct 2016 06:10:20 -0400 MIME-Version: 1.0 In-Reply-To: <20160927170115.GD7509@tuxbot> References: <1473081421-16555-1-git-send-email-peter.griffin@linaro.org> <1473081421-16555-18-git-send-email-peter.griffin@linaro.org> <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd> <20160927170115.GD7509@tuxbot> From: Emil Velikov Date: Thu, 6 Oct 2016 11:10:17 +0100 Message-ID: Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue. To: Bjorn Andersson Cc: Peter Griffin , Arnd Bergmann , LAKML , "Linux-Kernel@Vger. Kernel. Org" , kernel@stlinux.com, vinod.koul@intel.com, patrice.chotard@st.com, dan.j.williams@intel.com, David Airlie , Gerd Hoffmann , Ohad Ben-Cohen , devicetree , linux-remoteproc@vger.kernel.org, ML dri-devel , "open list:VIRTIO GPU DRIVER" , dmaengine@vger.kernel.org, Lee Jones Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On 27 September 2016 at 18:01, Bjorn Andersson wrote: > On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote: > >> On 20 September 2016 at 09:32, Peter Griffin wrote: >> > Hi Emil, >> > >> > On Tue, 20 Sep 2016, Emil Velikov wrote: >> > >> >> On 5 September 2016 at 14:16, Peter Griffin 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 >> > >> Might be worth taking a closer look into these at some point. >> > > The general idea here is that VIRTIO provides the "framework" and as > such drivers implementing VIRTIO do select and drivers using virtio use > depends. > > This is found in several places around the kernel. > >> > >> >> 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 ? >> >> > > There's nothing unusual in remoteproc that forces us to stay with this > model; however the parts related to the REMOTEPROC config is useless by > themselves. > I'm afraid that the "supporting" arguments you're using are generic and not specific to remoteproc. Although as Jani mentioned and pointed to the documentation, remoteproc is {mis,ab}using 'select' leading to issues elsewhere. In the long term we might want to switch to 'select' and attribute kconfig like Jani suggested. But in the short term we want to avoid select-ing things just for our "convenience". Thanks Emil From mboxrd@z Thu Jan 1 00:00:00 1970 From: emil.l.velikov@gmail.com (Emil Velikov) Date: Thu, 6 Oct 2016 11:10:17 +0100 Subject: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue. In-Reply-To: <20160927170115.GD7509@tuxbot> References: <1473081421-16555-1-git-send-email-peter.griffin@linaro.org> <1473081421-16555-18-git-send-email-peter.griffin@linaro.org> <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd> <20160927170115.GD7509@tuxbot> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Bjorn, On 27 September 2016 at 18:01, Bjorn Andersson wrote: > On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote: > >> On 20 September 2016 at 09:32, Peter Griffin wrote: >> > Hi Emil, >> > >> > On Tue, 20 Sep 2016, Emil Velikov wrote: >> > >> >> On 5 September 2016 at 14:16, Peter Griffin 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 >> > >> Might be worth taking a closer look into these at some point. >> > > The general idea here is that VIRTIO provides the "framework" and as > such drivers implementing VIRTIO do select and drivers using virtio use > depends. > > This is found in several places around the kernel. > >> > >> >> 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 ? >> >> > > There's nothing unusual in remoteproc that forces us to stay with this > model; however the parts related to the REMOTEPROC config is useless by > themselves. > I'm afraid that the "supporting" arguments you're using are generic and not specific to remoteproc. Although as Jani mentioned and pointed to the documentation, remoteproc is {mis,ab}using 'select' leading to issues elsewhere. In the long term we might want to switch to 'select' and attribute kconfig like Jani suggested. But in the short term we want to avoid select-ing things just for our "convenience". Thanks Emil