From: "Arnd Bergmann" <arnd@arndb.de>
To: "Martin Tůma" <tumic@gpxsee.org>,
"Arnd Bergmann" <arnd@kernel.org>,
"Martin Tuma" <martin.tuma@digiteqautomotive.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Hans Verkuil" <hverkuil-cisco@xs4all.nl>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: pci: mgb4: remove bogus 'select' statements
Date: Fri, 10 Nov 2023 15:37:04 +0100 [thread overview]
Message-ID: <2c56410f-2762-4b3c-b37e-e8db75d30560@app.fastmail.com> (raw)
In-Reply-To: <49c002db-fb3e-4e2c-adb4-0be05d4b27e6@gpxsee.org>
On Wed, Nov 8, 2023, at 19:33, Martin Tůma wrote:
> On 08. 11. 23 17:13, Arnd Bergmann wrote:
>> On Fri, Oct 27, 2023, at 16:17, Martin Tůma wrote:
>>> On 23. 10. 23 18:05, Arnd Bergmann wrote:
>>>> From: Arnd Bergmann <arnd@arndb.de>
>
> On SoCs you probably get a kernel configuration that is missing some
> feature but still boots up when you do not select/depend on the exact
> controller, but in the case of the mgb4 PCIe card you get a driver that
> does not work at all (The SPI_XILINX dependency could theoretically be
> made configurable, but you would lose the ability to flash the correct
> FW for the current HW module and the access to the card's serial number.
> I2C and XDMA are crucial.).
My point was that we do this all the time for things that are
essential: if your clock controller or the irqchip have
no driver, then the camera device won't work, but neither
would anything else.
So in a SoC setting, you really just need to enable all
the drivers for devices on that chip through the .config.
>> Since this is a PCI device, it's a bit different, so maybe
>> something like this would work to correctly document which
>> dependencies are required at build time vs run time:
>>
>> --- a/drivers/media/pci/mgb4/Kconfig
>> +++ b/drivers/media/pci/mgb4/Kconfig
>> @@ -1,15 +1,13 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> config VIDEO_MGB4
>> tristate "Digiteq Automotive MGB4 support"
>> - depends on VIDEO_DEV && PCI && I2C && DMADEVICES && SPI && MTD && IIO
>> + depends on VIDEO_DEV && PCI && I2C && SPI && MTD && IIO
>> depends on COMMON_CLK
>> + depends on XILINX_XDMA
>> + depends on (I2C_XILINX && SPI_XILINX) || COMPILE_TEST
>> select VIDEOBUF2_DMA_SG
>> select IIO_BUFFER
>> select IIO_TRIGGERED_BUFFER
>> - select I2C_XILINX
>> - select SPI_XILINX
>> - select MTD_SPI_NOR
>> - select XILINX_XDMA
>> help
>> This is a video4linux driver for Digiteq Automotive MGB4 grabber
>> cards.
>>
>
> My motivation when using "select" was to help people using "make
> menuconfig" to get the module selected/configured as they will usually
> not know that there are some Xilinx IP cores used that need separate
> drivers and the menuconfig GUI simply hides the mgb4 option making it
> almost impossible just from the menus to find out what has to be selected.
>
> But when there are reasons, why to chose "depends on" (like various
> configurations, tests or the "readability" of the dependencies) than I'm
> ok with your patch proposal.
The main reason to use 'depends on' over 'select' here is that
mixing the two is a common source of dependency loops that end
up breaking the build. As a rule of thumb, I would use 'select'
only for symbols that others already select, or that are hidden
from visibility.
Arnd
next prev parent reply other threads:[~2023-11-10 17:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 16:05 [PATCH 1/2] media: pci: mgb4: add COMMON_CLK dependency Arnd Bergmann
2023-10-23 16:05 ` [PATCH 2/2] media: pci: mgb4: remove bogus 'select' statements Arnd Bergmann
2023-10-24 13:27 ` Arnd Bergmann
2023-10-24 16:18 ` Lizhi Hou
[not found] ` <25173a48-529c-463b-88aa-2ee75dd604ff@gpxsee.org>
2023-11-08 16:13 ` Arnd Bergmann
2023-11-08 18:33 ` Martin Tůma
2023-11-10 14:37 ` Arnd Bergmann [this message]
2023-11-13 14:57 ` Hans Verkuil
2023-12-06 9:18 ` Hans Verkuil
2023-11-06 10:45 ` [PATCH 1/2] media: pci: mgb4: add COMMON_CLK dependency Martin Tůma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c56410f-2762-4b3c-b37e-e8db75d30560@app.fastmail.com \
--to=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=martin.tuma@digiteqautomotive.com \
--cc=mchehab@kernel.org \
--cc=tumic@gpxsee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox