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]
Date:   Wed, 11 Jan 2017 15:41:10 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     André Przywara <andre.przywara@....com>,
        Chen-Yu Tsai <wens@...e.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings

On Mon, Jan 9, 2017 at 12:16 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:
> On Fri, Jan 06, 2017 at 01:17:21AM +0000, André Przywara wrote:
>> > On Wed, Jan 04, 2017 at 02:16:23AM +0000, André Przywara wrote:
>> >> So can I ask that we start taking this seriously and stop doing things
>> >> which prevent Allwinner boards from being supported properly?
>> >> Which would first involve dropping this very patch?
>> >
>> > The driver still supports the old binding.
>>
>> Yes, a _current_ version of the driver supports both bindings, but older
>> versions *require* the older binding and bail out if various
>> allwinner,xxx properties are missing - as in those proposed new DTs:
>>
>> 4.9 kernel with sunxi/for-next .dtb:
>> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
>> node uart0
>> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
>> node mmc0
>> sunxi-mmc: probe of 1c0f000.mmc failed with error -22
>
> This is seriously getting out of control. We already come to great
> length (and sometimes a painful amount of hacks) to satisfy a few
> individuals with a theorical interest in backward compatibility (and
> apparently, we're even the only one doing so, even more platforms
> choosing to not support that as we speak), there's seriously no reason
> to support forward compatibility as well. This has *never* been a
> thing, never has been documented nor advertised, I don't know why it
> should be one more thing to carry on our shoulders.

I agree.

We have too much standardization burden to maintain already as it is.

And AFAICT the Allwinner support is a hacker/community/enthusiast
effort without vendor backing.

We should be aware that the strong push toward DT standardization
was due to mess in the vendor trees, and as for the ambition to ship
DTBs with products, that is for people producing products to do,
not for the community. Community support can very well use attached
DTB files on the kernel from my point of view, I don't see why
ArchLinuxARM and others should have to standardize and support
DTB file in flash images, very ambitious if they do but definately
not their problem.

Yours,
Linus Walleij

Powered by blists - more mailing lists