linux-kernel - Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdbT3091MzAQ_hO5Hc9=gQz-eDNCDtEnVG-3G+jJ+eO+Fw@mail.gmail.com>
Date:   Wed, 29 Mar 2017 12:15:05 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     jacopo <jacopo@...ndi.org>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Chris Brandt <chris.brandt@...esas.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

On Wed, Mar 29, 2017 at 9:35 AM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> Me:

>> See for example:
>> include/dt-bindings/pinctrl/mt65xx.h
>>
>> And how that is used in:
>> arch/arm/boot/dts/mt2701-pinfunc.h
>> arch/arm/boot/dts/mt2701-evb.dts
>>
>> The docs are here:
>> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
>
> All of the above pack the information for a pin into a single 32-bit integer.
> Is that what you want us to use, too?
> Currently we use two integers: 1) pin index, and 2) function/flags combo.

I don't really know what you need, sorry. But some kind of figure, yes.
I would say whatever makes sense. 16+16 bits makes sense in most
combinatorial spaces does it not? If you split 32 bits  in 16 bits for
pin and 16 bits for function, do you have more than 2^16 pins or 2^16
functions?

If you really do we may need to go for u64 but ... really? Is there
a rational reason for that other than "we did it like this first"?

I do not understand the notion of "flags" here. I hope that is not referring
to pin config, because I expect that to use the standard pin config
bindings outside of the pinmux value which should just define the
pin+function combo:

node {
    pinmux = <PIN_NUMBER_PINMUX>;
    GENERIC_PINCONFIG;
};

Example from Mediatek:

i2c1_pins_a: i2c1@0 {
    pins {
        pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>,
                        <MT8135_PIN_196_SCL1__FUNC_SCL1>;
        bias-pull-up = <55>;
    };
};

So this allows for a combine pin+function number but pull ups,
bias etc are not baked into the thing, they have to be added on
separately with the generic bindings, which is nice and very readable.

Yours,
Linus Walleij