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]
Date:	Wed, 3 Feb 2010 07:16:53 -0800
From:	Eric Miao <eric.y.miao@...il.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>,
	Eric Miao <eric.y.miao@...il.com>,
	List Linux Kernel <linux-kernel@...r.kernel.org>,
	linux@....linux.org.uk, Dinh.Nguyen@...escale.com,
	grant.likely@...retlab.ca, r.herring@...escale.com,
	linux-arm-kernel@...ts.infradead.org, daniel@...aq.de,
	bryan.wu@...onical.com, valentin.longchamp@...l.ch
Subject: Re: [PATCHv2 04/11] mxc: changes to common plat-mxc code to add 
	support for i.MX5

On Wed, Feb 3, 2010 at 5:38 AM, Amit Kucheria
<amit.kucheria@...onical.com> wrote:
> On 10 Feb 03, Sascha Hauer wrote:
>> On Tue, Feb 02, 2010 at 10:43:33PM -0800, Eric Miao wrote:
>> >
>> > Mmm.... this should be something that we really need to get rid of, it just
>> > makes a single kernel for both TZIC and AVIC together impossible, if that's
>> > so designed by HW, I'm thinking about keeping this into plat-mxc/ is a good
>> > way to go ...
>> >
>> > Sascha, you have any better idea? Provided the other file debug-macro.S in
>> > the same directory already seems to break the support for multiple arches?
>> >
>>
>> I have the following patch which I'm not sure I like better. It can
>> support both irq controller types and does not add overhead if only one
>> of them is compiled in. It might need some refactoring to fit into Amits
>> patch stack.
>
> Is co-existence of TZIC and AVIC a blocker to merging i.MX5 code? I've
> already made changes so that i.MX5 doesn't explode if AVIC is compiled in.
>
> Admittedly the assembly is a bit hard to rid, but we can fix in another set
> of patches geared towards unification of an i.MX kernel. IMHO, making these
> changes along with introducing a new SoC will make things a bit hard to
> follow/merge.
>

I personally don't feel that's a hard requirement, as long as it can be fixed.
--
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