linux-kernel - Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

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: <87ponu931e.fsf@eliezer.anholt.net>
Date:   Fri, 23 Sep 2016 16:08:45 +0300
From:   Eric Anholt <eric@...olt.net>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     linux-rpi-kernel <linux-rpi-kernel@...ts.infradead.org>,
        "linux-arm-kernel\@lists.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Stephen Warren <swarren@...dotorg.org>,
        Lee Jones <lee@...nel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Alexandre Courbot <gnurou@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.

Linus Walleij <linus.walleij@...aro.org> writes:

> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@...olt.net> wrote:
>
>> The RPi firmware exposes all of the board's GPIO lines through
>> property calls.  Linux chooses to control most lines directly through
>> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
>> need to access them through the firmware.
>>
>> Signed-off-by: Eric Anholt <eric@...olt.net>
>
> Aha
>
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>> @@ -0,0 +1,22 @@
>> +Raspberry Pi power domain driver
>
> Really? :)

Thanks.

>> +Required properties:
>> +
>> +- compatible:          Should be "raspberrypi,firmware-gpio"
>
> Usually this is vendor,compat, is the vendors name "raspberrypi"?

Yes, this driver is for part of the Raspberry Pi Foundation's firmware
code (you can find the same pattern in the firmware and firmware power
domain drivers).

>> +- gpio-controller:     Marks the device node as a gpio controller
>> +- #gpio-cells:         Should be <2> for GPIO number and flags
>> +- ngpios:              Number of GPIO lines to control.  See gpio.txt
>
> Is this ever anything else than 8? Else omit it and hardcode
> 8 in the driver instead.

(see below)

>> +- firmware:            Reference to the RPi firmware device node
>
> Reference the DT binding for this.
>
>> +- raspberrypi,firmware-gpio-offset:
>> +                       Number the firmware uses for the first GPIO line
>> +                         controlled by this driver
>
> Does this differ between different instances of this hardware or
> can it just be open coded in the driver instead?

This is which range (128-135) of the firmware's GPIOs we're controlling.
If another GPIO expander appears later (quite believable, I think
they're down to 1 spare line on this expander), then we would just make
another node with a new offset and ngpios for that expander.

Sort of related: I also worry that we have races with the firmware for
the platform GPIO bits, since both ARM and firmware are doing RMWs (or,
even worse, maybe just Ws?) of the registers controlled by the pinctrl
driver.  Hopefully I can get the firmware to pass control of devices
like this over to Linux, with firmware making requests to us, but I
don't know if that will happen and we may need to access other GPIOs
using this interface :(

Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)