Add ACPI driver for ChromeOs. It attaches to chromeos device and creates a
sys fs directory tree. Tested by using an ST8 BIOS supplying mock ACPI values.

Used toshiba_acpi.c and thinkpad_acpi.c from the same directory as a very
loose reference

This driver attaches to the Chromeos ACPI device and the exports the values
reported by the ACPI in a sysfs directory
(/sys/devices/platform/chromeos_acpi).

The first version of the driver provides only static information, the values
reported by the driver are the snapshot reported by the ACPI at driver
installation time.

All ACPI values are presented in the string form (numbers as decimal values)
and can be accessed as the contents of the appropriate read only files in the
sysfs directory tree originating in /sys/devices/platform/chromeos_acpi.

Tested on an ST8 with a BIOS mocking ACPI data:

localhost tmp # for f in $(find \
  /sys/devices/platform/chromeos_acpi -type f -name '[A-Z]*');
do
  echo -n " $f : "
  cat $f
  echo
done
 /sys/devices/platform/chromeos_acpi/CHSW : 0
 /sys/devices/platform/chromeos_acpi/HWID : 583CFAC2-D798-45B0-8C52-1397E3717893
 /sys/devices/platform/chromeos_acpi/BINF.0 : 1
 /sys/devices/platform/chromeos_acpi/BINF.1 : 1
 /sys/devices/platform/chromeos_acpi/BINF.2 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.0/GPIO.0 : 1
 /sys/devices/platform/chromeos_acpi/GPIO.0/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.0/GPIO.2 : 5
 /sys/devices/platform/chromeos_acpi/GPIO.0/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.0 : 2
 /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.1 : 1
 /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.2 : 6
 /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.0 : 3
 /sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.2 : 7
 /sys/devices/platform/chromeos_acpi/GPIO.2/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.3/GPIO.0 : 256
 /sys/devices/platform/chromeos_acpi/GPIO.3/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.3/GPIO.2 : 10
 /sys/devices/platform/chromeos_acpi/GPIO.3/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.4/GPIO.0 : 257
 /sys/devices/platform/chromeos_acpi/GPIO.4/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.4/GPIO.2 : 11
 /sys/devices/platform/chromeos_acpi/GPIO.4/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.5/GPIO.0 : 258
 /sys/devices/platform/chromeos_acpi/GPIO.5/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.5/GPIO.2 : 12
 /sys/devices/platform/chromeos_acpi/GPIO.5/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/GPIO.6/GPIO.0 : 259
 /sys/devices/platform/chromeos_acpi/GPIO.6/GPIO.1 : 0
 /sys/devices/platform/chromeos_acpi/GPIO.6/GPIO.2 : 13
 /sys/devices/platform/chromeos_acpi/GPIO.6/GPIO.3 : NM10
 /sys/devices/platform/chromeos_acpi/CHNV : 108
localhost tmp #

Also installed/removed the driver several times, no problems observed.

Review URL: http://codereview.chromium.org/2228001

Conflicts:
	chromeos/config/i386/config.common.i386
	drivers/platform/x86/Kconfig
	drivers/platform/x86/Makefile
ACPI update to support the latest firmware.

Pick up FWID value provided by the BIOS now and use
the proper Google assigned ACPI device name.

Tested by installing the new driver on a ZGA machine with
the latest firmware.

Review URL: http://codereview.chromium.org/2870021
CHROMIUM: Fix build warning in chromeos_acpi

drivers/platform/x86/chromeos_acpi.c: In function ‘create_sysfs_attribute’:
drivers/platform/x86/chromeos_acpi.c:179: warning: ‘return’ with no value, in function returning non-void

Signed-off-by: Olof Johansson <olof@lixom.net>

Review URL: http://codereview.chromium.org/3048028
CHROMIUM: chromeos_acpi: Add FRID to the list of acpi items the driver looks for.

Change-Id: I3989bfe83ba1d57fe188e82568889d0c2791f9ac

BUG=chrome-os-partner:536
TEST=manual

Brought up the new kernel on a DVT target. Observed all ACPI
files created as before and also an error message in dmesg
output:

chromeos_acpi: failed to retieve FRID (5)

which is expected behavior until BIOS supports FRID reproting.

Signed-off-by: Vadim Bendebury <vbendeb@google.com>

Review URL: http://codereview.chromium.org/3214011
CHROMIUM: Introduce chromeos platform layer

Based on Will's work, introduce a common chromeos layer that is stubbed out on
non-platform builds.

There are things left to do: Make sure it only initializes on chromeos-firmware devices
(DMI table), and functions need to be added to this as needed over time.

I also switched the chromeos_acpi and chromeos functions to be bools instead of tristate,
to avoid the issue of symbol dependencies at load time.

Change-Id: I7695040e0018b1f3b1e203b8046cd6d839248ceb
Signed-off-by: Olof Johansson <olofj@chromium.org>

BUG=none
TEST=emerge-x86-generic kernel; emerge-arm-generic kernel

Review URL: http://codereview.chromium.org/3266010

Conflicts:
	drivers/platform/x86/Makefile
CHROMIUMOS: chromeos_acpi: Increase the max size of ACPI variables.

Firmware ID string could potentially exceed the 40 character
limit allocated in the chromeos_acpi driver. The new limit,
agreed upon with BIOS vendor, is 256 bytes.

Change-Id: I5da8af8f719c3efa3b867fed30b97d5e3814826f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>

BUG=chrome-os-partner:1457
TEST=booted the new image and observed ACPI objects created.

Review URL: http://codereview.chromium.org/4672003
CHROMIUM: chromeos_acpi driver reads list of methods from MLST ACPI method

Change the chromeos_acpi driver to read its list of methods from the
MLST ACPI method.  This allows the chromeos_acpi device to support
future expansion of the methods provided by the BIOS, without changing
the device source code each time.

The driver still supports a hard-coded list of methods if the MLST
method is not present; this supports Cr-48 systems, which did not provide MLST.

Signed-off-by: Randall Spangler <rspangler@chromium.org>

BUG=12485
TEST=emerge-x86-generic kernel, then manually test on Cr-48

(1) With existing Cr-48 BIOS, check that /sys/devices/platform/chromeos_acpi
contains the same contents as before the patch.

(2) With a patched BIOS which provides MLST, check that
/sys/devices/platform/chromeos_acpi contains the methods listed in MLST.

Review URL: http://codereview.chromium.org/6576021

Change-Id: I48b9aa9f279fa5cd9acd8ad51629dcd76c334591
Introduce the ability to handle ACPI buffers.

ChromeOS needs to be able to receive assorted information
from the BIOS. Passing it in an opaque buffer structure
seems an obvious choice. This change adds the ability
to handle ACPI buffers in chromeos_acpi driver.

It turned out that chromeos_acpi can not be converted into a
removable module anymore, which made debugging difficult
(full kernel recompilation needed, if something goes wrong -
the machine is hosed, etc.)

This change restores the option of building chromeos_acpi as
a module, maintaining status quo (it is built in by
default). chromeos_acpi_exit() is copied from the original
implementation.

chromeos_acpi driver is architectured such that ACPI object
values are represented as strings. This addition converts
converts the binary buffer contents into a multiline string
(16 bytes representes in %.2.x format in each) line.

Change-Id: I8db12454e48db5dddb56a11836ad2d8fd8b6d7bf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>

BUG=chromium-os:13069, chromium-os:13091
TEST=manual

For two cases, when chromeos_acpi is configured as a module
and not:

- build system image, modify it for test
- install it on an target with BIOS supplying a
  chromeos ACPI buffer object
- restart the machine
- observe the contents of the VDAT object:

localhost tmp # cat /sys/devices/platform/chromeos_acpi/VDAT
 11 22 33 44 f7 1f 1c 40 96 57 74 41 cc dd ee ff

In case it is configured as a module:

- observe that chromeos_acpi can be removed/reinstalled:
localhost tmp # rmmod chromeos_acpi
localhost tmp # modprobe chromeos_acpi
localhost tmp # rmmod chromeos_acpi
localhost tmp # modprobe chromeos_acpi

- temporarily modify the module to print 5 bytes per string
- try installing the changed module and examine VDAT again:
localhost tmp # cat /sys/devices/platform/chromeos_acpi/VDAT
 11 22 33 44 f7
 1f 1c 40 96 57
 74 41 cc dd ee
 ff

Review URL: http://codereview.chromium.org/6690023
CHROMIUM: chromeos_acpi Support new NVRAM interface.

This CL changes the interface between chromeos_acpi and
chromeos drivers to accommodate the new NVRAM contents
structure (as described in http://goo.gl/kW1he).

Each shared integer element retrieved through ACPI is placed
in its own container, including the value and a boolean
indicating that the value has been already retrieved. This
scheme obviates the need for a separate
`chromeos_acpi_available` flag.

Writing nvram is now causing recalculating the crc8 value.

We want to be make sure that chromeos.c and chromeos_acpi.c
are always present together. The Kconfig change enforces
this.

The scheme is still vulnerable to race condition when more
than one entity are trying to modify the nvram buffer
contents, the locking mechanism needs to be implemented, but
this is beyond the scope of this change.

Change-Id: I636cc65d6a40ecd2a7b67a4d3bb7d2eb935d8723
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>

BUG=chromium-os:12734
TEST= see below, ideas welcome

The system builds and boots with the appropriate messages
showing up in the kernel log and the NVRAM read failure not
reported:

localhost ~ # dmesg | egrep -i '(chr|Failed reading NVRAM)'
[    0.000000] Linux version 2.6.32.26+drm33.12 (vbendeb@eskimo.mtv.corp.google.com) (gcc version 4.4.3 (gcc-4.4.3_cos_gg_v1_41723) ) #1 SMP Wed Mar 16 18:23:48 PDT 2011 (Ubuntu 2.6.32-0.1-chromeos-intel-menlow)
[    0.106129] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.178137] checking TSC synchronization [CPU#0 -> CPU#2]:
[    0.403575] chromeos_acpi: installed
[    0.404253] Chrome OS platform detected
[    1.000655] device-mapper: verity-chromeos: dm-verity-chromeos registered

Review URL: http://codereview.chromium.org/6673050
CHROMEOS: chromeos_acpi: handle data buffer overflow.

It was observed that running crossystem on a target with a
recent firmware (supporting the VDAT acpi object) causes
the kernel to complain about buffer overruns (see the
attached bug entry).

It turns out that the recent firmwares supply more than
3700 bytes in VDAT object, which (when converted into an
ASCII string) results in a buffer exceeding maximum sysfs
file size allowance of 4096 (kernel page size). The driver
was truncating the data to exactly the page size, which
caused the kernel generated warnings.

The proper fix would be to split the supplied data into
multiple sysfs objects, each not exceeding 4k, but as of
now only the small part of the VDAT buffer close to its
beginning is used by the application, so it is OK to
truncate the data at source.

This fix moves the VDAT processing code into a separate
function. It now stores the hex dump representation of the
beginning of the buffer guaranteed to fit into 4096 bytes.

Change-Id: I7f380f690be7cf4746f2fa76db37895e58773d73
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>

BUG=chromium-os:13482
TEST=msnual

- build a new image
- install it on the target supporting VDAT in firmware
- restart the target
1. Run the following commands:

dmesg | tail
crossystem
dmesg | tail

observe that crossystem succeeds and there is no messages
added to the dmesg output.

2.
localhost ~ # cat /sys/devices/platform/chromeos_acpi/VDAT | wc
    84    1336    4092
localhost ~ # dmesg | grep chromeos_acpi
[    0.370592] chromeos_acpi: truncating buffer from 3750 to 1336
[    0.371629] chromeos_acpi: installed

Review URL: http://codereview.chromium.org/6732045
CHROMIUM: chromneos_acpi: support both firmware flavors

Recent modification of chromeos_acpi.c (under
http://codereview.chromium.org/6673050) accomodated the new
firmware NVRAM interface, where a multibyte block is
reserved in the NVRAM to communicate between the firmware
and the kernel.

This change is incompatible with the "legacy" ChromeOS
firmware (used in CR-48 devices). Two things got broken for
CR-48:

- it is not considered a ChromeOS platform anymore, because
the availability of the VBNV ACPI element is used to decide
whether the platform is ChromeOS or not, and this element is
not exported by the legacy firmware. if the platform is not
a ChromeOS device, the crash memory dump is not initialized
on start up, hence the bug this CL is associated with.

- even if this was fixed, the
chromeos.c:chromeos_set_need_recovery() interface is also
broken, because it presumes that the nvram buffer is
available.

The fix is to use CHSW ACPI object as the evidence of
running on a ChromeOS platform, and using either CHNV
(if present) or VBNV to communicate the need for recovery
mode reboot.

Change-Id: I5674d68e2eec4e4313783a7edcac1da2b2c9123f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>

BUG=chromium-os:13483
TEST=manual, see below

Testing was conducted on two platforms, Mario (legacy
firmware) and Alex (new firmware).

-1-

. install the new image
. reboot the DUT
. examine the kernel startup log:

on Mario:
localhost ~ # dmesg | egrep 'chromeos_|Chrome'
[    0.470199] chromeos_acpi: falling back to default list of methods
[    0.470249] chromeos_acpi: registering CHSW 0
[    0.471392] chromeos_acpi: registering CHNV 0
[    0.471651] chromeos_acpi: failed to retrieve MLST (5)
[    0.471690] chromeos_acpi: installed
[    0.472069] Legacy ChromeOS firmware detected
localhost ~ #

on Alex:

localhost ~ # dmesg | egrep 'chromeos_|Chrome'
[    0.365498] chromeos_acpi: registering CHSW 0
[    0.366985] chromeos_acpi: registering VBNV 0
[    0.367012] chromeos_acpi: registering VBNV 1
[    0.368926] chromeos_acpi: truncating buffer from 3750 to 1336
[    0.369894] chromeos_acpi: installed
[    0.370490] ChromeOS firmware detected
localhost ~ #

- 2 -

. execute the following commands

localhost ~ # rm -rf /var/spool/crash
localhost ~ # echo -n test-consent > '/home/chronos/Consent To Send Stats'
localhost ~ # reboot

. observe the DUT reboot
. login again and enter

localhost ~ # echo bug > /proc/breakme

. observe the DUT reboot
. after it comes back up

localhost ~ # ls /var/spool/crash
kernel.20110329.180733.0.kcrash  kernel.20110329.180733.0.meta

Review URL: http://codereview.chromium.org/6775012