On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
On Tue, Apr 14, 2015 at 10:08 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 05:44:55PM +0800, Kweh, Hock Leong wrote:
From: Kweh, Hock Leong hock.leong.k...@intel.com
Introduce this new
On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
From: Kweh, Hock Leong hock.leong.k...@intel.com
Introducing a kernel
On Apr 15, 2015 6:20 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong
[Bah, I'm really bad at email today. Trying again.]
On Apr 15, 2015 6:15 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
On Tue, Apr 14, 2015 at 10:08 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On
On Wed, 15 Apr, at 11:56:05AM, Roy Franz wrote:
Yeah, I guess it shouldn't surprise me that there is support for 64
bit addresses there :)
I'l spin another patch that sets boot_params-ext_cmd_line_ptr with
the upper 32 bits of the address.
Should I conditionalize this with #ifdef
On Wed, Apr 15, 2015 at 6:18 AM, Matt Fleming m...@codeblueprint.co.uk wrote:
On Tue, 14 Apr, at 05:45:52PM, Roy Franz wrote:
The boot_params structure has a 32 bit field for storing the address of
the kernel command line. When the EFI stub allocates memory for the command
line, it allocates
On Wed, Apr 15, 2015 at 8:45 AM, Andy Lutomirski l...@amacapital.net wrote:
On Apr 15, 2015 6:20 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
On 15 April 2015 at 11:55, Matt Fleming m...@codeblueprint.co.uk wrote:
On Fri, 10 Apr, at 07:14:34PM, Ard Biesheuvel wrote:
It is not such a big deal: the memory is reclaimed anyway, I was just
trying to reduce the fragmentation a bit, and trying to avoid
efi_xxx_alloc() which are
On Fri, 10 Apr, at 07:14:34PM, Ard Biesheuvel wrote:
It is not such a big deal: the memory is reclaimed anyway, I was just
trying to reduce the fragmentation a bit, and trying to avoid
efi_xxx_alloc() which are substantially heavier than calling
allocate_pool() or allocate_pages() directly.
On Tue, 14 Apr, at 06:18:33PM, Borislav Petkov wrote:
On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
This is why I think that the right approach would be to avoid using
firmware_class entirely for this. IMO a simple_char device would be
the way to go (hint hint...) but
On Wed, Apr 15, 2015 at 11:14:55AM +0100, Matt Fleming wrote:
Well, I haven't come across a scenario where you need a brand new
interface for getting it *out* of the kernel again.
Well, how are we going to read crash data on next boot then? EFI var or
what? Are we going to have a generic
On Wed, 15 Apr, at 12:18:05PM, Borislav Petkov wrote:
On Wed, Apr 15, 2015 at 11:14:55AM +0100, Matt Fleming wrote:
Well, I haven't come across a scenario where you need a brand new
interface for getting it *out* of the kernel again.
Well, how are we going to read crash data on next boot
-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, April 14, 2015 10:09 PM
On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
From: Kweh, Hock Leong hock.leong.k...@intel.com
Introducing a kernel module to expose
13 matches
Mail list logo
