linux-kernel - Re: [PATCH] ARM: uniphier: drop code for old DT binding

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, 01 Jun 2016 09:49:51 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	arm@...nel.org, Russell King <linux@...linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: uniphier: drop code for old DT binding

On Wednesday, June 1, 2016 3:30:03 PM CEST Masahiro Yamada wrote:
> Hi Arnd.
> 
> 2016-05-31 18:21 GMT+09:00 Arnd Bergmann <arnd@...db.de>:
> > On Tuesday, May 31, 2016 5:17:08 PM CEST Masahiro Yamada wrote:
> >> Commit 307d40c56b0c ("ARM: uniphier: rework SMP code to support new
> >> System Bus binding") added a new DT binding for SMP code, but still
> >> kept old code for the backward compatibility.
> >>
> >> Linux 4.6 was out with both bindings supported, so it should not
> >> hurt to drop the old code now.
> >>
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> >>
> >
> > That explanation is in general not sufficient. Are you sure that
> > nobody is shipping a machine with their own dts file that is not
> > merged upstream, and that there are no bootloaders that have a
> > hardcoded dtb file that we need to support indefinitely?
> >
> 
> I have to confess that almost no one (except me) uses this upstreamed
> code directly.
> It can boot, but it is almost useless for practical uses (at least for
> production level)
> because it still lacks lots of drivers.
> 
> Our products based on ARM 32bit SoCs were shipped with old kernel
> (without device tree) that were never upstreamed.

That's fine, a lot of companies work like this when the upstreaming
starts, just mention this in the changelog.

> Socionext is now trying to change the development procedure
> and the situation will be much better for ARM64 SoC products; it will be
> more community-based development, although they are not shipped yet.
> 
> So, the answer is,  nobody is shipping ARM32 products using this upstream code.
> Device Tree is not used in the first place.
> (But, I still believe I should keep upstreaming.)

Ok.

	Arnd