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: <CANqRtoTYWGhto7Zf=C=WHrT5fjc1p=6GE0cnozYLUuqbz=+LhA@mail.gmail.com>
Date:	Tue, 15 May 2012 05:49:18 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	linux-arm-kernel@...ts.infradead.org, arnd@...db.de,
	linux-sh@...r.kernel.org, lethal@...ux-sh.org,
	linux-kernel@...r.kernel.org, rjw@...k.pl, horms@...ge.net.au,
	olof@...om.net
Subject: Re: [PATCH 03/03] ARM: Undelete KZM9D mach-type

On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@...nsource.se>
>>
>> Undelete the KZM9D mach-type to allow build of board
>> for EMEV2 SoC support.
>
> If you've converted to use DT for KZM9D, do you still need this?

Good question. I guess it depends on how we want to make use of DT on
that piece of hardware. I do intend to convert the KZM9D board (not to
be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
unless someone really wants it at this timing), but I'm still not sure
if the SMP code in V2 is the way we want to do it. I suspect that
there is no way to support SMP without static entity mappings, so
perhaps I should rework that part and redo a V3? Or perhaps I should
interpret the EMEV2 silence as a good thing. =)

Unfortunately the KZM9D board only takes uImages, but good news is
that it actually feeds us the correct mach-type. This seems to be a
pretty common thing around here these days. I'm trying to get people
to actually store the DTB in the boot loader and pass it along, but
that seems rather far away at this point.

So with our current boot loader situation in mind I've been thinking
about adjusting the code in arch/arm/boot/compressed/head-shmobile.S
to check for the mach-type id and pass on a compiled-in DTB depending
on board type. This to allow us to build an uImage as usual and also
support multiple boards with a single kernel.

As you understand, the above plan will still make use of the mach-type
even now when we make more heavy use of DT. It seems like a rather
straightforward way to remain backwards compatible and still do DT,
but I'm not sure if such a solution would be acceptable by you, Arnd
and Olof. My plan right now is to try to cook up some code for the
above and see what feedback I get.

So yes, I'd like to make use of that mach-type entry unless there are
any objections.

Thanks for your help!

/ magnus
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ