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:	Thu, 20 Dec 2012 11:19:22 -0800
From:	Olof Johansson <>
To:	Tony Lindgren <>
Cc:	Linus Walleij <>,
	Loic Pallardy <>,, Greg Kroah-Hartman <>,
	Russell King <>,
	Janusz Krzysztofik <>,
	Omar Ramirez Luna <>,
	Loic PALLARDY <>,
	Arnd Bergmann <>,
	Ohad Ben-Cohen <>,
	Mark Brown <>,
	Dom Cobley <>,
	Wim Van Sebroeck <>, Suman Anna <>,
	Juan Gutierrez <>,
	Felipe Contreras <>,
	Tejun Heo <>,,,,
	STEricsson_nomadik_linux <>,
	Omar Ramirez Luna <>
Subject: Re: [PATCH 0/9] drivers: mailbox: framework creation

On Thu, Dec 20, 2012 at 10:28 AM, Tony Lindgren <> wrote:
> * Linus Walleij <> [121220 10:19]:
>> On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
>> <> wrote:
>> > OMAP and ST-Ericsson platforms are both using mailbox to communicate
>> > with some coprocessors.
>> > Based on OMAP existing mailbox framework, this series proposes a
>> > generic framework, living under drivers/mailbox.
>> I like this patch series so you have my Acked-by.
>> Since it's a new subsystem and affects a few ARM architectures can
>> we merge this into the ARM SoC tree once we have consensus,
>> so we get some rotation in linux-next that way?
> Yes good idea.
>> Olof/Arnd?
> I suggest we set up an immutable branch against
> v3.8-rc1 when it's out with only these patches in it.
> Then we can all merge it in as needed. Maybe Arnd or
> Olof can set up the branch?

I haven't reviewed the patches yet, but this flow sounds reasonable to me.

> FYI, looks like I need to merge in this branch too to
> avoid build errors with remoteproc enabled once I flip
> on the multiplatform support for omap2+.

While we can make the branch stable, would it make sense to make
remoteproc for omap depend on !multiplatform during the transition, to
reduce dependencies a little? Either way works, but it'd be nice to
keep them independent if we can.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists