[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdYNjQaVFLDQWDFSWrtACi4+gkK9n4JEWSfpwkzW0G_Erw@mail.gmail.com>
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