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

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

Date:   Fri, 12 May 2017 11:04:43 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.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

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.

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?

Then the right place for it is in the quirky driver for the quirky
first-generation
hardware.

Yours,
Linus Walleij