linux-kernel - Re: [PATCH V1 2/2] pinctrl: qcom: spmi-gpio: Set is_enabled flag in set

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]

Message-ID: <CACRpkdZ65Myn7QdFwAqTrt9T+7-1FDu9DBqCz0VZizSY7BRctA@mail.gmail.com>
Date:   Fri, 20 Oct 2017 11:51:50 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Fenglin Wu <fenglinw@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        David Collins <collinsd@...eaurora.org>,
        aghayal@...eaurora.org, wruan@...eaurora.org,
        subbaram@...eaurora.org, kgunda@...eaurora.org
Subject: Re: [PATCH V1 2/2] pinctrl: qcom: spmi-gpio: Set is_enabled flag in set_mux()

On Tue, Oct 17, 2017 at 6:36 AM, Fenglin Wu <fenglinw@...eaurora.org> wrote:

> I am not sure if this is valid case but it would happen: The
> hardware or the sw prior to linux kernel has the default setting of the
> function and config for one GPIO but we need to keep it disabled until
> the consumer request it, in this case, we just need to define the pinmux
> and ignore the pinconf definition in its device node.

This firmware-kernel partitioning of responsibilities makes me nervous
every time it happens. Who's in charge really? Who fixes bugs? Firmware?
Linux? Linux overriding firmware? Linux overriding firmware on special
firmware revisions? Linux overriding firmware on special firmware revisions
that cannot be detected and instead needs to be passed as cmdline
parmeters?

This kind of stuff gives me the creeps and just a general feeling of not
being in control having very little clue as to what is really going on in
the system.

But I guess that is essentially the working assumption for things like
ACPI and other behind-my-back firmware: don't worry be happy.

Anyways, it's up to Björn to establish what is best for the qcom pin control,
I'm just gonna accept whatever he ACKs. Just rambling.

Yours,
Linus Walleij