linux-kernel - Re: [GIT PULL] omap changes for v2.6.39 merge window

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

Message-ID: <20110330223946.GL18334@atomide.com>
Date:	Wed, 30 Mar 2011 15:39:46 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	David Brown <davidb@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-omap@...r.kernel.org, Nicolas Pitre <nico@...xnic.net>,
	Catalin Marinas <catalin.marinas@....com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

* Linus Torvalds <torvalds@...ux-foundation.org> [110330 15:18]:
> On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren <tony@...mide.com> wrote:
> 
> But for ARM, I suspect even ACPI would actually be an improvement.
> Because on ARM, the crazy non-platform hw people already happened, and
> took over the insane asylum.  So having a complicated description
> language with an interpreter wouldn't be worse than what we already do
> there.
> 
> I'm only half kidding. I wouldn't wish for ACPI even on ARM. But..

Heh I think the device tree is saner here than ACPI :)
 
> > Anyways, let's plan on kicking out per-SoC and per-board data from
> > the kernel and get it from the bootloader via device tree in the
> > long run. Most of the data is already separate from the code, so
> > it should not be that hard to do, just takes some time.
> 
> This is basically my hope for the future. I just think that ARM people
> should be very very aggressive about it, because the longer it isn't
> done, the more crud there will be to convert.

At least now all that data is in one place in convertable format instead
of direct register tinkering of shared registers in each device driver
probe function..
 
> I bet it will be painful to do. But it will be even more painful to
> _not_ do it, and then five years from now realize that it should have
> been done ten years ago.

Something needs to be done for sure.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/