linux-kernel - Re: pinctrl-amd: What hardware does it apply to?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdaSxJLbk_hN0mgURLk4u4ATbE-HvmX1yM+BWjcrzcKjXA@mail.gmail.com>
Date:   Fri, 22 Dec 2017 08:48:22 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andrew Cooks <andrew.cooks@...ngear.com>
Cc:     Christian Lamparter <chunkeey@...il.com>,
        linux-gpio@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nehal Shah <Nehal-bakulchandra.Shah@....com>,
        Shyam Sundar S K <Shyam-sundar.S-k@....com>,
        Ken Xue <Ken.Xue@....com>,
        Tobias Diedrich <ranma+kernel@...edrich.de>,
        Sudheesh Mavila <sudheesh.mavila@....com>,
        platypus-sw <platypus-sw@...ngear.com>, alan@...rahi.com.ve
Subject: Re: pinctrl-amd: What hardware does it apply to?

On Fri, Dec 22, 2017 at 2:17 AM, Andrew Cooks <andrew.cooks@...ngear.com> wrote:
> On 21/12/17 23:02, Christian Lamparter wrote:

>> Just a FYI: due to these difficulties with getting a gpio driver
>> upstream, Alan Mizrahi upstreamed an in-kernel led-apu.c driver [0]
>> that sort of bypasses the whole pinctrl vs gpio issue.
>
> Thanks, I saw that and was somewhat surprised to see it accepted.

I looked at the driver and it seems actually good and doing the
right thing. If I understand it right:

- It does a bunch of magic dmi_match() on DMI_BOARD_NAME
  to figure out what board this is.

- It then proceeds to register LEDs using some bits in the MMIO
  area that are used for LEDs.

So these bits/lines are actually not GPIO, since GPIO means
"general purpose input/output" - they are specific purpose and the
specific purpose can be detected.

So I don't have any objections from an architectural point of view.

Some may expose the register as GPIO and add LEDs on top but
it (using drivers/leds/leds-gpio.c) but that may be pointless extra
abstraction.

It has a deeper problem though. It is writing these GPIO registers
without any thought of someone else possibly accessing them and
without any shared locks.

This problem is usually solved by either using GPIO inbetween if
the GPIO driver takes care of protecting the register, or using
regmap, preferably with drivers/mfd/syscon.c, so that regmap will
protect the MMIO register.

So there may be technical reasons to use GPIO or syscon abstractions
that are not architectural reasons if you see what I mean.

If only these few GPIO lines are actually used and only used for
these LEDs, (the rest of the bits in the register unused) then this
driver is as good as any.

Yours,
Linus Walleij