linux-kernel - Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC

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

Message-ID: <CACRpkdbTaekF=VYP6-tjotTSYgVFtayM7A=eSu_=JGWEiZpczQ@mail.gmail.com>
Date:   Thu, 26 Jan 2017 11:03:47 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Andre Przywara <andre.przywara@....com>,
        ext Tony Lindgren <tony@...mide.com>,
        Icenowy Zheng <icenowy@...c.xyz>,
        Catalin Marinas <catalin.marinas@....com>,
        Chen-Yu Tsai <wens@...e.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for
 Allwinner H5 SoC

On Thu, Jan 19, 2017 at 6:41 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:

> That's not true anymore. And while it's true that it reduces the
> amount of maintainance on the kernel side and more on the DT side. And
> from what you're constantly saying, the thing we can't plan on fixing
> / upgrading is the DT, while the kernel is easy to change.
>
> Which means that if we ever want to fix a non-upgradable DT, the only
> way to do that would be to add quirks fixing it in the kernel
> itself. Adding more maintainance burden to the kernel.

This is a good argument to not put groups and functions into the
DT at all. If the following propositions hold:

- Functions and group definitions will contain bugs

- Those bugs will need to be fixed by changing the buggy
  definitions

- It is hard to change the DTB, it is easy to change the zImage

Then by logical deduction the definitions should be in the kernel
to minimize maintenance burden.

There is a pattern amongst firmware people that they think that
they always get the group and function definitions right on first
try. As long as there are humans involved in the process, this
stance is provedly wrong, just use git log and you will see how
much of such bugs we fix, even in drivers and DTSes produced
by the vendors themselves.

Yours,
Linus Walleij