[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a2BSN7sUvRLgbpJTFws-=-Va30LNLvLEXbN46KewOy2dQ@mail.gmail.com>
Date: Sat, 5 Dec 2020 13:03:03 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Georgi Djakov <georgi.djakov@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Sibi Sankar <sibis@...eaurora.org>,
Evan Green <evgreen@...omium.org>,
Jonathan Marek <jonathan@...ek.ca>,
Odelu Kukatla <okukatla@...eaurora.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
David Dai <daidavid1@...eaurora.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] interconnect: qcom: fix rpmh link failures
On Sat, Dec 5, 2020 at 12:27 AM Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
> On Fri 04 Dec 10:50 CST 2020, Arnd Bergmann wrote:
>
> Your patch looks correct to me, so:
> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
>
>
> But we're going to have to sprinkle a handful of these throughout the
> tree and we're not a lot of people who "understand" what it does (and at
> least I keep getting them wrong...)
Right, I already ran into another one.
> Perhaps it would be more reasonable to maintain this long term if we
> drop the possibility of compile testing these drivers independently of
> rpmh and command db? (I.e. drop the function stubs and rely on
> RPMH/COMMAND_DB to enable building under COMPILE_TEST)?
Agreed, I think that would be best. As long as RPMH and COMMAND_DB
can individually be enabled for CONFIG_COMPILE_TEST, all the
drivers will get enabled in an allmodconfig build, and we can just
list the dependencies.
I don't really like the headers too much that have an
#ifdef CONFIG_SUBSYSTEM with an alternative set of
inline functions, unless there is a reasonable expectations that
drivers work fine if that subsystem is disabled.
E.g. having the option to disable IPv6 makes sense despite
the complexity that adds, but compile-testing a driver without
a required subsystem that can also be enabled for compile-testing
hurts more than it helps.
> And just to make it clear, I think we should merge your patch to fix
> v5.11; then consider to simplify this past that.
Yes, sounds good.
Arnd
Powered by blists - more mailing lists