linux-kernel - Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

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: <CAMuHMdXK7YB2zN4fz9XiqTuydxp7VvVV+wSgXWUYBB0evkp8dw@mail.gmail.com>
Date:   Fri, 12 May 2017 13:11:52 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     jmondi <jacopo@...ndi.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Chris Brandt <Chris.Brandt@...esas.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

Hi Linus,

On Fri, May 12, 2017 at 11:04 AM, Linus Walleij
<linus.walleij@...aro.org> wrote:
> On Tue, May 9, 2017 at 12:54 PM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>
> Oops missed this:
>
>> Hence I think we should not use generic pin properties, but consider these
>> settings to be part of pinmux configuration.
>> As having large tables in the driver is undesirable, I think storing the
>> settings in the "pinmux" property (by encoding them as flags passed to the
>> RZA1_PINMUX() macro) is our best option.
>
> I think it is better to have large tables in the driver in this case.

Jacopo, Chris: Would two bits per pin/function (none, input, output, bidir)
be sufficient?
That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes.
Plus code to handle it. After all not that bad...

> It is the lesser evil.
>
> Having unintelligible and hard to grasp stuff in the device tree that
> no user will understand or dare to touch is not good, then it is better
> to have it with the code, where it is being used, so the developers of
> the driver can see it when they are dealing with this (quirky) hardware.
>
> As you say this is actually fixing hardware bugs, we can expect these
> quirky tables to be gone in the next hardware generation, right?

Let's hope so. Chris has a better crystal ball than I have ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds