linux-kernel - Re: [PATCH] interconnect: qcom: fix rpmh link failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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