* [PATCH 0/2] Fix recursive Kconfig depedency issue
@ 2016-09-19 9:34 Peter Griffin
2016-09-19 9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-19 9:34 ` [PATCH 2/2] drm/virtio: kconfig: Fixup white space Peter Griffin
0 siblings, 2 replies; 17+ messages in thread
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kernel, airlied, kraxel,
vinod.koul, sfr, bjorn.andersson
Cc: peter.griffin, lee.jones, dri-devel, virtualization
Hi,
This series fixes a Kconfig recurssive depedency issue and also some
trivial white space. This was found when developing the fdma dmaegine
series [1], which has now been applied by Vinod.
These patchs were originally included as part of the fdma series [1],
but I've now sent it separately as requested by Vinod [2], and also
privately by Emil.
FYI not having this patch applied causes kbuild error emails [3].
[1] https://lkml.org/lkml/2016/9/13/191
[2] https://lkml.org/lkml/2016/9/15/562
[3] https://lkml.org/lkml/2016/9/15/850
Peter Griffin (2):
drm/virtio: kconfig: Fix recursive dependency issue.
drm/virtio: kconfig: Fixup white space.
drivers/gpu/drm/virtio/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-19 9:34 [PATCH 0/2] Fix recursive Kconfig depedency issue Peter Griffin
@ 2016-09-19 9:34 ` Peter Griffin
2016-09-20 7:20 ` [PATCH v9 17/19] " Emil Velikov
2016-09-19 9:34 ` [PATCH 2/2] drm/virtio: kconfig: Fixup white space Peter Griffin
1 sibling, 1 reply; 17+ messages in thread
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kernel, airlied, kraxel,
vinod.koul, sfr, bjorn.andersson
Cc: peter.griffin, lee.jones, dri-devel, virtualization
ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.
[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103: symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440: symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5: symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29: symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64: symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366: symbol FB_CYBER2000 depends on FB
which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.
Fix by dropping depend and switching to select VIRTIO.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/gpu/drm/virtio/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
- depends on DRM && VIRTIO
+ depends on DRM
+ select VIRTIO
select DRM_KMS_HELPER
select DRM_TTM
help
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-19 9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
@ 2016-09-20 7:20 ` Emil Velikov
2016-09-20 7:24 ` Emil Velikov
0 siblings, 1 reply; 17+ messages in thread
From: Emil Velikov @ 2016-09-20 7:20 UTC (permalink / raw)
To: Peter Griffin
Cc: sfr@canb.auug.org.au, kernel@stlinux.com, airlied@linux.ie,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
bjorn.andersson@linaro.org, vinod.koul@intel.com,
virtualization@lists.linux-foundation.org, lee.jones@linaro.org,
linux-arm-kernel@lists.infradead.org
[-- Attachment #1.1: Type: text/plain, Size: 296 bytes --]
On Monday, 19 September 2016, Peter Griffin <peter.griffin@linaro.org>
wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
> It must not select, it must depend? Did you miss my earlier
question/suggestion that mentions that ?
Regards,
Emil
[-- Attachment #1.2: Type: text/html, Size: 517 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-20 7:20 ` [PATCH v9 17/19] " Emil Velikov
@ 2016-09-20 7:24 ` Emil Velikov
0 siblings, 0 replies; 17+ messages in thread
From: Emil Velikov @ 2016-09-20 7:24 UTC (permalink / raw)
To: Peter Griffin
Cc: sfr@canb.auug.org.au, kernel@stlinux.com, airlied@linux.ie,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
bjorn.andersson@linaro.org, vinod.koul@intel.com,
virtualization@lists.linux-foundation.org, lee.jones@linaro.org,
linux-arm-kernel@lists.infradead.org
[-- Attachment #1.1: Type: text/plain, Size: 206 bytes --]
On Tuesday, 20 September 2016, Emil Velikov <emil.l.velikov@gmail.com>
wrote:
> Did you miss my earlier question/suggestion that mentions that ?
>
Please scratch that. Just noticed the timestamps.
Emil
[-- Attachment #1.2: Type: text/html, Size: 426 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/2] drm/virtio: kconfig: Fixup white space.
2016-09-19 9:34 [PATCH 0/2] Fix recursive Kconfig depedency issue Peter Griffin
2016-09-19 9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
@ 2016-09-19 9:34 ` Peter Griffin
1 sibling, 0 replies; 17+ messages in thread
From: Peter Griffin @ 2016-09-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kernel, airlied, kraxel,
vinod.koul, sfr, bjorn.andersson
Cc: peter.griffin, lee.jones, dri-devel, virtualization
Use tabs instead of spaces.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/gpu/drm/virtio/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
depends on DRM
select VIRTIO
- select DRM_KMS_HELPER
- select DRM_TTM
+ select DRM_KMS_HELPER
+ select DRM_TTM
help
This is the virtual GPU driver for virtio. It can be used with
- QEMU based VMMs (like KVM or Xen).
+ QEMU based VMMs (like KVM or Xen).
If unsure say M.
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-05 13:16 Peter Griffin
2016-09-05 13:16 ` [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
[not found] ` <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
0 siblings, 2 replies; 17+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
bjorn.andersson
Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
peter.griffin, dmaengine, lee.jones
Hi Vinod, Bjorn, Patrice,
This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.
After quite a few review rounds, I'm hoping this series can get taken for v4.9.
After some discussion with the DT maintainers I've removed the firmware
name from DT, and now generate the name based on the compatible string.
I've also dropped the dma xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added.
V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation
to make the doc align with the driver code. These patches have already been applied
and are now dropped from this series. Other changes included enabling the ASoC drivers
in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable ASoC
on STiH407/10 based platforms using the fdma driver.
v4 includes a new slim core rproc driver for loading the slim elf firmware. This
enables us to use the generic rproc elf loading code. This has deliberately not
been implemented as a platform_driver, to avoid having to have double mappings of
I/O memory from two device drivers, and also to ensure that the DT node reflects
the actual hardware rather than Linux subsystems. The slim core is the basis
for various pieces of IP in STi chipsets and the intention is that other drivers
(e.g. demux) can also be migrated over to using the slim rproc for their
elf firmware loading and start/stop control.
v5 includes various updates from Bjorn related to the slim rproc implementation.
It also includes a patch to make rsc_table optional in remoteproc_core and various
other cleanups and review feedback from Vinod to do with the actual fdma
implementation. It also fixes a regression introduced in v4 when all drivers are
built-in spotted by Aranud.
v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However
a change is still required in rproc core when all drivers are built-in as the initial
async firmware resource table parsing can fail when built-in, which causes subsequent calls
to rproc_boot() to also fail. V6 changes this behaviour to retry rproc_fw_config_virtio()
from rproc_boot(), in cases where it previously failed, as at this point we know the
irmwaref has been successfully obtained.
v7 removes all remoteproc core changes required to get -EPROBE_DEFER working properly
when firmware resides on a rootfs and compiling as built-in. The fdma driver now relies on
the firmware being available in the initramfs when building fdma as built-in. This has
been tested and works well. If remoteproc subsystem implements a new mechanism for
firmware on late mounted root filesystems, we can migrate this driver over to use it
at that point.
v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
slim_rproc driver. The series has also been rebased on v4.8-rc3.
v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
was found during testing now that the platform boots without clk_ignore_unused parameter
whereby the clocks would not be enabled properly before firmware loading was attempted.
regards,
Peter.
Changes since v8:
- Add MODULE_ALIAS (Vinod)
- devm_kzalloc to devm_kcalloc (Vinod)
- quisce tasklet initialised by vchan_init() (Vinod)
- Don't make SLIM rproc user selectable (Bjorn)
- slim_rproc: Ensure clocks enabled before firmware load (Peter)
- Various code style nits / commit message change (Lee)
- Separate patch for '\n' kconfig removal (Vinod)
Changes since v7:
- Rebase on v4.8-rc3 (Peter)
- Double check that len is <= mem[i].size (Bjorn)
- Remove if (!fw) checks (Bjorn)
- Omit reference from fw_ops struct (Bjorn)
- Call rproc_del() before rproc_put() (Bjorn)
- Fix some odd line breaks (Bjorn)
- Rename SLIM_* and slim_* with st prefix (Bjorn)
Changes since v6:
- Fix recursive Kconfig warning (Patrice)
- Fix various Intel zero day compiler warnings
- Remove all changes related to late firmware load (now relies on initramfs) (Peter)
Changes since v5:
- Remove optional rsc table and go back to dummy resource table (Bjorn)
- Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter)
- Fixup some kbuild warnings
- rebase on v4.7-rc5
- Remove some patches which were merged via ASoC tree
Changes since v4:
- Make rsc table optional in remoteproc (Peter)
- Various fixups to STi audio DT nodes (Arnaud)
- Bulk rename of xp70 to slim (Peter)
- Update my email to @linaro.org (Lee)
- rebase on v4.7-rc2 (Peter)
- Don't make ST_SLIM_REMOTEPROC user selectable (Bjorn)
- -EPROBE_DEFER if rproc_boot fails when allocating DMA channel (Arnaud / Peter)
- Drop some unnecessary headers (Vinod / Bjorn)
- Change to writel now we have several mappings (Bjorn)
- Remove io_res, rproc, and some unused structure fields / #define (Bjorn)
- put clks in error path, also put clks before rproc_put() (Bjorn)
- Make enum less generic (Bjorn)
- Make slim_rproc_alloc() return a st_slim_rproc reference (Bjorn)
- Alphabetical naming in Kconfig & Makefile (Vinod)
- Add FDMA prefix to REQ_CTRL* (Vinod)
- Print ret on some error paths (Vinod)
- Add some acked-by (Peter)
Changes since v3:
- Remove elf loading code from fdma driver (Vinod)
- Remove fdma_ prefix for clock names (Arnd)
- Make _xlate use dma_get_any_channel rather than request_channel (Arnd)
- Make a common function for _prep_ routines (Vinod)
- Make driver depend on COMPILE_TEST (Arnd)
- Remove unnecessary st_fdma_filter_fn (Arnd)
- Enable FDMA as a module (Arnd)
- Drop fdma_ clock prefix (Arnd)
- Fix description as well as example for st, prefix (Arnd)
- Remove string concatenation from fdma register macros to ease grep'ability (Arnd)
- Add a XP70 rproc driver for ELF firmware loading and start/stop control (Peter)
- Add myself as a author of the driver (Peter)
Changes since v2:
- Change to dma-controller (Arnd)
- Remove platform data header file and simplifiy code (Arnd)
- Remove FW_LOADER_USER_HELPER_FALLBACK and rework firmware loading to device config (Vinod)
- Use SET_RUNTIME_PM_OPS helpers (Vinod)
- Remove fdma-id dt prop and use compatibles to generate different fdma firmware names (Arnd / Lee)
- Add sti-asoc-card DT nodes and pinmux config for uniperif player & reader (Peter)
- Update sti-asoc-card DT binding documentation (Peter)
- Enable STi audio drivers in multi_v7_defconfig (Peter)
Changes since v1:
- split into smaller patches for easier / faster review (Vinod)
- new fill_hw_mode() with common code (Vinod)
- new config_reqctrl() called from *_prep() instead of device_config cb (Vinod)
- fdma-xbar support removed (Peter)
- rework firmware name mechanism so fwname isn't in DT (Peter / Lee)
- st_fdma_seg_to_mem can be static (Paul)
- EXPORT_SYMBOL st_fdma_filter_fn not required (Paul)
- s/channel/channels (vinod)
- better describe "Must be <3>" (vinod)
- sizeof(*ehdr) (vinod)
- print values on error debug (vinod)
- empty line (Vinod)
- Update to -EIO (Vinod)
- Make st_fdma tristate (Paul)
- Remove __exit tag from .remove (Maxime)
- Update MAINTAINERS rule to fdma* (Lee)
- Unit address should match reg property (Lee)
Peter Griffin (19):
remoteproc: st_slim_rproc: add a slimcore rproc driver
MAINTAINERS: Add st slim core rproc driver to STi section.
dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
documentation
dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
MAINTAINERS: Add FDMA driver files to STi section.
ARM: multi_v7_defconfig: Enable STi FDMA driver
ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
ARM: DT: STiH407: Add i2s_out pinctrl configuration
ARM: DT: STiH407: Add i2s_in pinctrl configuration
ARM: DT: STiH407: Add spdif_out pinctrl config
ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
ARM: STi: DT: STiH407: Add uniperif player dt nodes
ARM: STi: DT: STiH407: Add uniperif reader dt nodes
ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
drm/virtio: kconfig: Fix recursive dependency issue.
drm/virtio: kconfig: Fixup white space.
dmaengine: kconfig: Remove superfluous '\n'
Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++
MAINTAINERS | 3 +
arch/arm/boot/dts/stih407-family.dtsi | 167 ++++
arch/arm/boot/dts/stih407-pinctrl.dtsi | 55 ++
arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++
arch/arm/configs/multi_v7_defconfig | 4 +
drivers/dma/Kconfig | 14 +-
drivers/dma/Makefile | 1 +
drivers/dma/st_fdma.c | 899 ++++++++++++++++++++++
drivers/dma/st_fdma.h | 249 ++++++
drivers/gpu/drm/virtio/Kconfig | 9 +-
drivers/remoteproc/Kconfig | 4 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/st_slim_rproc.c | 364 +++++++++
include/linux/remoteproc/st_slim_rproc.h | 58 ++
15 files changed, 1955 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
create mode 100644 drivers/dma/st_fdma.c
create mode 100644 drivers/dma/st_fdma.h
create mode 100644 drivers/remoteproc/st_slim_rproc.c
create mode 100644 include/linux/remoteproc/st_slim_rproc.h
--
1.9.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-05 13:16 [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
@ 2016-09-05 13:16 ` Peter Griffin
[not found] ` <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
1 sibling, 0 replies; 17+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
bjorn.andersson
Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
peter.griffin, dmaengine, lee.jones
ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.
[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103: symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440: symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5: symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29: symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64: symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366: symbol FB_CYBER2000 depends on FB
which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.
Fix by dropping depend and switching to select VIRTIO.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/gpu/drm/virtio/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
- depends on DRM && VIRTIO
+ depends on DRM
+ select VIRTIO
select DRM_KMS_HELPER
select DRM_TTM
help
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread[parent not found: <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>]
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
[not found] ` <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
@ 2016-09-19 23:18 ` Emil Velikov
2016-09-20 8:32 ` Peter Griffin
0 siblings, 1 reply; 17+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
To: Peter Griffin
Cc: devicetree, kernel, vinod.koul, lee.jones, linux-remoteproc,
patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
David Airlie, dmaengine, dan.j.williams, bjorn.andersson,
open list:VIRTIO GPU DRIVER, LAKML
On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-19 23:18 ` Emil Velikov
@ 2016-09-20 8:32 ` Peter Griffin
2016-09-20 9:33 ` Jani Nikula
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Peter Griffin @ 2016-09-20 8:32 UTC (permalink / raw)
To: Emil Velikov, Arnd Bergmann
Cc: devicetree, kernel, vinod.koul, lee.jones, linux-remoteproc,
patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
David Airlie, dmaengine, dan.j.williams, bjorn.andersson,
open list:VIRTIO GPU DRIVER, LAKML
Hi Emil,
On Tue, 20 Sep 2016, Emil Velikov wrote:
> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-20 8:32 ` Peter Griffin
@ 2016-09-20 9:33 ` Jani Nikula
2016-09-21 12:09 ` Emil Velikov
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Jani Nikula @ 2016-09-20 9:33 UTC (permalink / raw)
To: Peter Griffin, Emil Velikov, Arnd Bergmann
Cc: devicetree, kernel, vinod.koul, linux-remoteproc, patrice.chotard,
ML dri-devel, Linux-Kernel@Vger. Kernel. Org, dmaengine,
dan.j.williams, bjorn.andersson, lee.jones,
open list:VIRTIO GPU DRIVER, LAKML
On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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?
Documentation/kbuild/kconfig-language.txt:
Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)
Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-20 8:32 ` Peter Griffin
2016-09-20 9:33 ` Jani Nikula
@ 2016-09-21 12:09 ` Emil Velikov
[not found] ` <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>
[not found] ` <8760pqncee.fsf@intel.com>
3 siblings, 0 replies; 17+ messages in thread
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
To: Peter Griffin
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, lee.jones,
linux-remoteproc, patrice.chotard, ML dri-devel,
Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
LAKML
On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
>
Might be worth taking a closer look into these at some point.
>
>> 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.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.
> 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?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.
Thanks
Emil
^ permalink raw reply [flat|nested] 17+ messages in thread[parent not found: <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>]
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
[not found] ` <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>
@ 2016-09-27 17:01 ` Bjorn Andersson
2016-10-06 10:10 ` Emil Velikov
2016-10-06 10:48 ` Peter Griffin
1 sibling, 1 reply; 17+ messages in thread
From: Bjorn Andersson @ 2016-09-27 17:01 UTC (permalink / raw)
To: Emil Velikov
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel, patrice.chotard,
Peter Griffin, David Airlie, dmaengine, dan.j.williams,
open list:VIRTIO GPU DRIVER, lee.jones, LAKML
On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
> >
> 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.
Regards,
Bjorn
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-09-27 17:01 ` Bjorn Andersson
@ 2016-10-06 10:10 ` Emil Velikov
0 siblings, 0 replies; 17+ messages in thread
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel, patrice.chotard,
Peter Griffin, David Airlie, dmaengine, dan.j.williams,
open list:VIRTIO GPU DRIVER, Lee Jones, LAKML
Hi Bjorn,
On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
>> >
>> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
[not found] ` <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>
2016-09-27 17:01 ` Bjorn Andersson
@ 2016-10-06 10:48 ` Peter Griffin
2016-10-06 11:31 ` Emil Velikov
1 sibling, 1 reply; 17+ messages in thread
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
To: Emil Velikov
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, lee.jones,
linux-remoteproc, patrice.chotard, ML dri-devel,
Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
LAKML
Hi Emil,
On Wed, 21 Sep 2016, Emil Velikov wrote:
> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
> >
> Might be worth taking a closer look into these at some point.
VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.
>
> >
> >> 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.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.
Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.
I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?
It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).
> > 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?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.
Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced.
regards,
Peter.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-10-06 10:48 ` Peter Griffin
@ 2016-10-06 11:31 ` Emil Velikov
0 siblings, 0 replies; 17+ messages in thread
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
To: Peter Griffin
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, Lee Jones,
linux-remoteproc, patrice.chotard, ML dri-devel,
Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
dan.j.williams, Bjorn Andersson, open list:VIRTIO GPU DRIVER,
LAKML
Hi Peter,
On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?
>>
>> >
>> >> 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.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > 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?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:
Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.
If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)
In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.
Thanks
Emil
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <8760pqncee.fsf@intel.com>]
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
[not found] ` <8760pqncee.fsf@intel.com>
@ 2016-10-06 9:37 ` Peter Griffin
2016-10-06 10:45 ` Emil Velikov
[not found] ` <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>
0 siblings, 2 replies; 17+ messages in thread
From: Peter Griffin @ 2016-10-06 9:37 UTC (permalink / raw)
To: Jani Nikula
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
Emil Velikov, patrice.chotard, ML dri-devel,
Linux-Kernel@Vger. Kernel. Org, dmaengine, dan.j.williams,
bjorn.andersson, lee.jones, open list:VIRTIO GPU DRIVER, LAKML
Hi Jani,
Sorry for the delay, I've been travelling last week.
On Tue, 20 Sep 2016, Jani Nikula wrote:
> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.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?
>
>
> Documentation/kbuild/kconfig-language.txt:
>
> Note:
> select should be used with care. select will force
> a symbol to a value without visiting the dependencies.
> By abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.
In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.
>
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)
I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.
>
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.
That sounds like it would be a useful addition.
Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?
regards,
Peter.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
2016-10-06 9:37 ` Peter Griffin
@ 2016-10-06 10:45 ` Emil Velikov
[not found] ` <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>
1 sibling, 0 replies; 17+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
To: Peter Griffin
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
Lee Jones, open list:VIRTIO GPU DRIVER
On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:
"This option is selected by any driver which implements the virtio _bus_"
REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.
>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?
This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?
>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.
$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.
Regards,
Emil
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread[parent not found: <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>]
* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
[not found] ` <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>
@ 2016-10-07 17:44 ` Peter Griffin
0 siblings, 0 replies; 17+ messages in thread
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
To: Emil Velikov
Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
Lee Jones, open list:VIRTIO GPU DRIVER
Hi Emil,
On Thu, 06 Oct 2016, Emil Velikov wrote:
> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
>
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
>
> "This option is selected by any driver which implements the virtio _bus_"
>
Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.
> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.
Yep OK.
>
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?
Your right I wasn't saying that :)
My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.
Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO.
>
> This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
> mean there is anything wrong with your feet."
If the shoe doesn't fit, chop off the leg :)
> You seem to be suggesting the opposite ?
>
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
>
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
>
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
>
If Bjorn is OK with it, then it is fine with me.
I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.
I can then send the whitespace cleanup patch separately to DRM ML.
regards,
Peter.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-10-07 17:44 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-19 9:34 [PATCH 0/2] Fix recursive Kconfig depedency issue Peter Griffin
2016-09-19 9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-20 7:20 ` [PATCH v9 17/19] " Emil Velikov
2016-09-20 7:24 ` Emil Velikov
2016-09-19 9:34 ` [PATCH 2/2] drm/virtio: kconfig: Fixup white space Peter Griffin
-- strict thread matches above, loose matches on Subject: below --
2016-09-05 13:16 [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
2016-09-05 13:16 ` [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
[not found] ` <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
2016-09-19 23:18 ` Emil Velikov
2016-09-20 8:32 ` Peter Griffin
2016-09-20 9:33 ` Jani Nikula
2016-09-21 12:09 ` Emil Velikov
[not found] ` <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>
2016-09-27 17:01 ` Bjorn Andersson
2016-10-06 10:10 ` Emil Velikov
2016-10-06 10:48 ` Peter Griffin
2016-10-06 11:31 ` Emil Velikov
[not found] ` <8760pqncee.fsf@intel.com>
2016-10-06 9:37 ` Peter Griffin
2016-10-06 10:45 ` Emil Velikov
[not found] ` <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>
2016-10-07 17:44 ` Peter Griffin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).