[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110312014254.6133.43079.stgit@mike.mtv.corp.google.com>
Date: Fri, 11 Mar 2011 17:42:55 -0800
From: Mike Waychison <mikew@...gle.com>
To: Greg KH <greg@...ah.com>, Matt Domsch <Matt_Domsch@...l.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Duncan Laurie <dlaurie@...gle.com>,
Aaron Durbin <adurbin@...gle.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>,
San Mehat <san@...gle.com>
Subject: [PATCH v2 00/12] google firmware support
This patchset applies to v2.6.38-rc8.
The following series implements some support for interfaces exposed by
google's servers' firmware. Unlike the previous send-out, it only
includes two of the three drivers as I'm not yet finished fixing the
"bootlog" driver from the last send-out (and I've discovered more
"undocumented" firmware functionality that I'd rather unravel before
sending out again).
In order to address various concerns had with the previous patchset,
I've changed the user ABI significantly:
Instead of messing with the dmesg log_buf ring-buffer, we now expose
firmware logs via /sys/firmware/log.
As well, instead of using a ioctl interface the gsmi driver, I've
changed it completely to use sysfs instead (rooted at
/sys/firmware/gsmi). gsmi provides access to EFI variables through a
means other than through the EFI runtime services page, so I've reused
the bulk of the code exposed by the efivars driver. To make this work,
I had to refactor a bit of the efivars driver. The only user-visible
change here is that the module will successfully load now even if you
aren't on an EFI system (which is much more consistent with other
drivers anyway).
I'd like to have these small drivers included as they are required for
proper use of the kernel in our infrastructure. They may not seem like
much, but a lot of our health automation as well as our human debugging
efforts are dependent on the functionality herein. Getting these in the
public Linux tree would bring us closer to being able to easily test
kernels as they are released.
Thanks,
Patchset summary
================
Patches [1 through 6] refactor the 'efivars' module to let the "gsmi"
driver in patch [11] re-use the variable functionality.
Patch [7] documents existing 'efivars' functionality that has been
present in the tree since 2004.
Patches [8] and [9] add sanity checking for accessing the EBDA.
Patch [10] introduces CONFIG_GOOGLE_FIRMWARE that is disabled by
default and which gates Google-specific drivers.
Patch [11] adds the "gsmi" driver that we use to make calls into our
firmware.
Patch [12] adds the "memconsole" driver that finds the firmware's logs
and exposes them on /sys/firmware/log.
Diffstat
========
Documentation/ABI/stable/sysfs-firmware-efi-vars | 75 +
Documentation/ABI/testing/sysfs-firmware-gsmi | 58 +
Documentation/ABI/testing/sysfs-firmware-log | 7
arch/x86/include/asm/bios_ebda.h | 28
drivers/firmware/Kconfig | 2
drivers/firmware/Makefile | 2
drivers/firmware/efivars.c | 343 +++++---
drivers/firmware/google/Kconfig | 33
drivers/firmware/google/Makefile | 3
drivers/firmware/google/gsmi.c | 927 +++++++++++++++++++++++
drivers/firmware/google/memconsole.c | 151 +++
include/linux/efi.h | 37
12 files changed, 1526 insertions(+), 140 deletions(-)
ChangeLog:
==========
- v2
- Efivars can now be used by other drivers.
- Documentation added for /sys/firmware/efi/vars
- Memory console no longer touches log_buf ring buffer.
- The firmware log is exported to userland as /sys/firmware/log
- Ioctls for accessing nvram variables in gsmi driver replaced with
efivars at /sys/firmware/gsmi/vars.
- die_notifier is used instead of adding new notifer_lists.
- EBDA scrubbing for memconsole now checks that we aren't walking
into 0xA0000.
- Documentation added for /sys/firmware/log
- Documentation added for /sys/firmware/gsmi
- Use kernel fixed width types instead of C99 types.
- v1
- Initial public send-out.
--
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