[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <4479d851-33be-4559-b998-fdd0480d9f78@app.fastmail.com>
Date: Fri, 12 Sep 2025 15:24:23 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Mikko Rapeli" <mikko.rapeli@...aro.org>
Cc: Heiko Stübner <heiko@...ech.de>,
"Ulf Hansson" <ulf.hansson@...aro.org>,
"linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
linux-kernel@...r.kernel.org, "Adrian Hunter" <adrian.hunter@...el.com>,
"Victor Shih" <victor.shih@...esyslogic.com.tw>,
"Ben Chuang" <ben.chuang@...esyslogic.com.tw>,
"Geert Uytterhoeven" <geert+renesas@...der.be>,
"AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
"Yixun Lan" <dlan@...too.org>, "Binbin Zhou" <zhoubinbin@...ngson.cn>
Subject: Re: [PATCH] mmc: dw_mmc-rockchip: add dependency to ROCKCHIP_PM_DOMAINS
On Fri, Sep 12, 2025, at 13:30, Mikko Rapeli wrote:
> On Fri, Sep 12, 2025 at 10:47:29AM +0200, Arnd Bergmann wrote:
>> On Thu, Sep 11, 2025, at 18:05, Heiko Stübner wrote:
>>
>> depends on (ARCH_ROCKCHIP || COMPILE_TEST)
>>
>> after you check that this actually builds on x86 with COMPILE_TEST
>> enabled, as there may be other compile-time dependencies.
>
> Ok so a lot of mmc driver set this correctly but few don't:
>
> * MMC_PXA
> * MMC_OMAP
> * MMC_ATMELMCI
> * MMC_MXC
> * MMC_MXS
> * MMC_DW_ROCKCHIP
> * MMC_WMT
>
> Maybe there are good reasons why these are not part of COMPILE_TEST.
> I can try adding MMC_DW_ROCKCHIP. Did not yet find out how to start
> the COMPILE_TEST build. Hints welcome. Which top level Makefile
> target or script to run?
I see that Krzysztof went through the subsystem five years ago
and enabled everything he could in commit 54d8454436a2 ("mmc: host:
Enable compile testing of multiple drivers").
The set you found above is probably a combination of drivers
that were added after that without the COMPILE_TEST check,
and drivers that fail to build on x86.
>> I think in this case a 'default ARCH_ROCKCHIP' in the
>> ROCKCHIP_PM_DOMAINS definition is sufficient to have it
>> normally enabled, and still allows someone to try turning
>> it into a loadable module later, which would be a requirement
>> e.g. for Android GKI.
>
> Ok I can test this out.
Thanks!
> kernel.org defconfigs have ROCKCHIP_PM_DOMAINS
> enabled so they don't see any issues but when users/distros configure
> kernels, then ROCKCHIP_PM_DOMAINS is needed for MMC_DW_ROCKCHIP to work.
> To me a warning is sufficient from kernel config tooling since yocto
> side tooling picks this up but enabling by default is even better.
> These runtime dependencies hard to track down. Kernel modules would
> be sufficient if support was there since in my case there is always
> an initrd with udev and modules.
There is no good answer in general here. Adding a lot of
dependencies for each run-time requirement would make Kconfig
overly complicated and introduce circular dependencies
everywhere, so generally I recommend to only have either
compile-time dependencies specified, or dependencies on specific
platforms that can then be turned off when you know you are
building for another one,
Arnd
Powered by blists - more mailing lists