CHROMIUM: nm10_gpio: support additional LPC IDs

Adding more LPC device IDs of the Intel 6 Series and C200 Series
chipsets.

This has been tested and works on HM65 and HM67 variants.

BUG=none
TEST=run crossystem and ensure that the current values of recovery and
dev switches are correct

Change-Id: I895fca9bd5c23caeb2b4a3b06bbb20bc46d8691a
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5682
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>

CHROMIUM: gpio: nm10_gpio: Add device ID of Intel HM65 chipset

The GPIO access mechanism on the HM65 PCH is the same a NM10. Simply
adding the device ID of HM65 to this driver instead of writing a new
driver that essentially does the same thing.

BUG=chrome-os-partner:4977
TEST=crossystem should report the correct values of recoverysw_cur and
devsw_cur with this driver in place,

Change-Id: I5bb0082b77dc4dec8739f9e24d92be485e3f28ae
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4272
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: chromeos_arm: use device tree

This change removes the old shared memory model, and uses the device
tree to pass the boot-time variables directly to userspace. Left to
handle is just the in-kernel use of being able to read and write the
"nvram" block on MMC to mark that the system needs recovery, etc.

Also, remove the locally-cashed copy of the nonvolatile storage from
the driver, since userspace does direct modification of the block by
opening the device and reading/writing from it. If a local copy is kept,
it ends up getting out of sync with the state set from userspace.

This requires a bit of trickery with flushing the buffer cache to avoid
the userspace tool from getting stale data (and vice versa).

BUG=chromium-os:16665
TEST=boot with vboot on and off, check for function

Change-Id: Id374cf42088ffe86c65b126412b92441d5aa1095
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3766
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

CHROMIUM: x86: efi: add smbios base debugfs export

Cherry pick from 60ae8c961b357d5bac639d4d9d60508e1d5370f6
This can then be used by mosys to get to the DMI table. Scraping from
dmesg is fragile at best.

File moved from arch/x86/kernel/efi.c

Signed-off-by: Olof Johansson <olofj@chromium.org>
BUG=chrome-os:6795
TEST=boot image, check /sys/kernel/debug/efi_smbios_base

Change-Id: If550d69779de33903974ba1f5eca129b82402435
Reviewed-on: http://gerrit.chromium.org/gerrit/1489
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>

CHROMIUM: arm: fix chromeos_arm printout whitespace mistakes

On Seaboard, chromeos_arm prints the following message at boot:

  [    0.379058] chromeos_armversion mismatch: 0 != 1

Fix that plus a few more message bugs.

BUG=none
TEST=verify that the kernel prints "chromeos_arm: version mismatch: 0 != 1"

Change-Id: Ic98731230e1eda1b1c908f575c9ea1694ad4097e
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/1124
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>

CHROMIUM: Refactor chromeos platform layer to cover both arm and x86.

This CL completes the set of modifications required to support
chromeos ARM platforms (see
http://codereview.chromium.org/6883204 and
http://codereview.chromium.org/6902164 submitted earlier).

The chromeos.c interface layer is refactored: the platform
independent components consolidated, and platform specific ones
are moved to the appropriate platform modules. The ability to run
arm/chromos_arm.c as a module is eliminated, and the default
value of the shared memory window base is set.

The unused APIs (chromeos_is_devmode() and
chromeos_initialized()) are removed, appropriate Kconfig and
Makefile changes are made to reflect single chromeos.c module for
both platforms.

fs/proc/breakme.c is modified to allow requesting a recovery mode
reboot, to facilitate testing of the chromeos API.

BUG=chromium-os:12522
TEST=manual:

. build the new kernel image for mario, alex and kaen

. on all platforms run `crossystem' and observe the results (the
  results look reasonable).

. on all systems request reboot in recovery mode using `crossystem
  recovery_request=0xc1' and reboot. Observe the systems come back in
  recovery mode.

. on mario and alex recuest recovery by executing `echo need_recovery
  > /proc/breakme' and reboot. Observe the systems come back in
  recovery mode.

Change-Id: Ifa30aafa110479ee8981325a5e08fb3127ef8b6e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/450
Reviewed-by: Olof Johansson <olofj@chromium.org>
[olofj: removed breakme modification when splitting branches]
Signed-off-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: ARM: Add chromeos NVRAM simulator

This change introduces support for Nvram storage required by
dm-verity and verified boot to exchange status information
between firmware (u-boot), kernel and userland. It relies on
the changed shared memory structure which is being
introduced under http://codereview.chromium.org/6905135

X86 platforms use 16 bytes in CMOS for this, ARM platforms
do not have such luxury, so a different storage device has
been picked, the very first sector on the MMC device.

The sector number, offset and size of the sector space used
for Nvram emulation is configured by the u-boot and passed
as part of the shared memory structure created by
u-boot (see  http://codereview.chromium.org/6883204 for
details of kernel and userland shared memory access).

U-boot keeps a copy of the Nvram contents in the shared
memory as well, thus providing the kernel and userland with
easy access to the Nvram block contents.

With this CL, when userland needs to write the contents of
the Nvram, it writes exactly 16 bytes intto the same file it
uses to access the shared memory
/sys/kernel/debug/chromeos_arm). The driver's write()
function verifies the data (mainly that it is of a proper
size), places it in the block 0 of the MMC device and then
saves in the shared memory, so that the NVRAM copy available
through /sys/kernel/debug/chromeos_arm stays in sync.

The block device write() implementation was borrowed from
the previously submitted
http://codereview.chromium.org/6880063 and modified to work
in 2.6.38 environment.

Change-Id: I8543e3303ec7d99b08e4131d9237b17e9cc16888
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chromium-os:12522
TEST=manual:

- install the driver
- examine the contents of the first block of the mmc device
- examine the contents of the shared memory (nvram cache
  comes starting at offset 28 into the window).
- try writing wrong number of bytes into the shared memory
  file, observe write errors.
- write exactly 16 bytes and examine the first mmc block
  and the contents of the shared memory as exposed by
 /sys/kernel/debug/chromeos_arm

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
localhost var # insmod chromeos_arm.ko
localhost var # od -t x1 /sys/kernel/debug/chromeos_arm
0000000 3c 07 00 00 43 48 52 4f 4d 45 4f 53 00 00 00 00
0000020 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00
0000040 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00
[snip]
localhost var #  dd if=/dev/mmcblk0 of=/tmp/blk bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.001529 s, 335 kB/s
localhost var #  od -t x1  /tmp/blk
0000000 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66
*
0001000
localhost var # echo 1 >  /sys/kernel/debug/chromeos_arm
-bash: echo: write error: Invalid argument
localhost var # echo 0123456789abcdef >  /sys/kernel/debug/chromeos_arm
-bash: echo: write error: Invalid argument
localhost var # echo -n 0123456789abcdef >  /sys/kernel/debug/chromeos_arm
localhost var # od -t x1 /sys/kernel/debug/chromeos_arm
0000000 3c 07 00 00 43 48 52 4f 4d 45 4f 53 00 00 00 00
0000020 00 00 00 00 00 00 00 00 00 00 10 00 30 31 32 33
0000040 34 35 36 37 38 39 61 62 63 64 65 66 00 00 00 00
[snip]
localhost var #  dd if=/dev/mmcblk0 of=/tmp/blk bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00174 s, 294 kB/s
localhost var # od -t x1  /tmp/blk
0000000 30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
0000020 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66
*
0001000
localhost var # dmesg | tail
[snip]
[  739.358239] chromeos_arm: memory window base at 3ff00000
[  784.874696] chromeos_arm: 2 != 16, invalid block size
[  800.444117] chromeos_arm: 17 != 16, invalid block size
localhost var #
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

CHROMIUM: arm: driver for accessing shared memory, first cut.

This change borrows from the previously submitted for review
http://codereview.chromium.org/6880063 (it was considered
too impacting) and needs to be accompanied by the config
change as per http://codereview.chromium.org/6902094

Also, for this to work it is required  that u-boot creates
a certain memory structure at 1M below the top of the
available physical memory, and modifies the kernel command
line to exclude the top 1 megabyte of DRAM from the kernel's
control.

It was envisioned originally, that drivers/platform/x86/chromeos.c
would be a common module providing dm-verity with interface
to platform specific modules, but as of now that file is too
much x86 centric, so a new interface file,
drivers/platform/arm/chromeos.c is introduced with this CL,
these two files will have to be merged with the underlying
drivers refactored.

Apart form adding new config options, this CL introduces the
actual driver which discovers the shared memory object and
exposes the shared memory as a file in /sys/kernel/debug to
be parsed by crossystem.

Blending in of the actual gpio states into the mapped
memory, as well as handling of nonvolatile storage will be
added in the upcoming CLs.

Change-Id: Ia961081ac1a7f760b4fa67b691c2774d810f3369
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chromium-os:12522
TEST=manual

- recompile the kernel
- scp chromeos_arm.ko to the target's /var directory
- on the target:
  insmod /var/chromeos_arm.ko
  rmmod chromeos_arm
  insmod /var/chromeos_arm.ko
  dmesg | grep chromeos_arm:
- observe messages indicating installing/removal of
  the driver
- observe that the file /sys/kernel/debug/chromeos_arm gets
  created/removed with driver installation/removal

localhost var # wc -c /sys/kernel/debug/chromeos_arm
892 /sys/kernel/debug/chromeos_arm

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

CHROMIUM: chromeos_acpi: support both firmware flavors.

This is a manual reconciliation of the fix done under

http://codereview.chromium.org/6775012

There was no patch conflicts, the chromeos-intel-menlow
config builds cleanly.

Change-Id: I0896c99aa4b5f237d117a10ff5c792b7a52c1b91
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chromium-os:13483
TEST=manual

Successfully built the chromeos-intel-menlow target.

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

CHROMIUM: chromeos_acpi: Fix comment typos in chromeos_acpi.h

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=none

Change-Id: Id984f43df9989061601d71aceb2c670edc82daa1

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

CHROMIUM: chromeos_acpi: fix build failure

The owner field was removed from struct attribute in
6fd69dc578fa0b1bbc3aad70ae3af9a137211707, so don't assign it anymore.

BUG=none
TEST=compiles

Change-Id: Iaa743f58ed705d8b3d38c5e345d6f47630b7a019
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
TBR=dlaurie@chromium.org,olofj@chromium.org

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

CHROMIUM: chromeos_acpi: support for MLST and new NVRAM interface

This is a lump change integrating the following three CLs
from 2.6.32. It is done in one shot because there were
changes which sneaked in in between, and some of these CLs
cancel each other (enabling/disabling the ability to
modularize chromeos_acpi.c):

http://codereview.chromium.org/6576021
http://codereview.chromium.org/6673050
http://codereview.chromium.org/6732045

After applying the three patches the differences between
this and the 2.6.32 trees looked as follows:

kernel-next 98 > for f in drivers/platform/x86/chromeos.c \
 drivers/platform/x86/chromeos_acpi.c \
 drivers/platform/x86/chromeos_acpi.h \
 include/linux/chromeos_platform.h \
do
  echo "**** $f ***************";
  diff ../kernel/files/$f $f;
done
**** drivers/platform/x86/chromeos.c ***************
**** drivers/platform/x86/chromeos_acpi.c ***************
197d196
<       paa->dev_attr.attr.owner = THIS_MODULE;
584,585c583,584
<                       copy_size = min(element->string.length,
<                                       (u32)ACPI_NAME_SIZE);
---
>                       copy_size = min((int)element->string.length,
>                                       ACPI_NAME_SIZE);
**** drivers/platform/x86/chromeos_acpi.h ***************
**** include/linux/chromeos_platform.h ***************
13,15d12
< /* Checks whether ChromeOS platform was detected and initialized */
< extern bool chromeos_initialized(void);
<
28,32d24
< static inline bool chromeos_initialized(void)
< {
<       return false;
< }
<

The diff in chromeos_acpi.c is due to a different way of
fixing a compilation warning in different branches, this CL
consolidates the both branches to do the same.

The diff in chromeos_platform.h is in fact something which
should be removed in 2.6.32, it is not essential, just a
clean up leftover.

So, as submitted for review, the only source code file
different bewteen 2.6.32 and 2.6.37 is chromeos_platform.h
as shown above.

Change-Id: If0eab62ace389b26556506e32c427cff8ce37f15
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chromium-os:13513
TEST=manual, see below.

. build an image using the changed code
. run the following commands:

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

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

CHROMIUM: chromeos_acpi driver reads list of methods from MLST ACPI method

Porting this change from kernel to kernel-next.
Original CL: http://codereview.chromium.org/6576021/

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/6592078

Change-Id: Ifd6f016c6feded7234f682e49b01dc83ac2e8639

CHROMIUM: 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: gpio: nm10: Add ability to change gpio directions.

This CL adds nm10_gpio.c driver methods to allow changing of
GPIO pin directions. The driver code is being refactored to
separate common input parameters check.

Once the new methods are added, the gpiolib.c layer adss the
appropriate attribute (direction) to every enabled nm10 gpio
pin in /sys/class/gpio.

Writing "in" or "out" into the direction attribute sets the
pin's direction.

Change-Id: I4116542c7424dfb7f5c6fdc35930caf0a5d2e11b

BUG=chrome-os-partner:970 chromium-os:3612
TEST=see below

1. Install the new driver version on the system
2. Enable all GPIO pins
localhost tmp # i=0; while [ "$i" != "64" ] ; do gpio=$(expr $i \+ 192) ; i=$(expr $i \+ 1) ; echo $gpio > /sys/class/gpio/export ; done

2. define a shell function to display gpio pins' status:
gpiodump() {  i=0; while [ "$i" != "64" ]; do gpio=$(expr $i \+ 192) ;  i=$(expr $i \+ 1) ; cat /sys/class/gpio/gpio$gpio/value ; done | awk '{ if (i == 8) {print ""; i = 0;}  printf " %s", $1; i = i + 1}  END { print "" }' ; }

3. Set the recovery mode pin direction to output:
localhost tmp # echo out > /sys/class/gpio/gpio230/direction

4. Run gpiodump with the button pressed and released,
observe that there is no difference in the output.

5. Set the recovery mode pin direction to input:
localhost tmp # echo in > /sys/class/gpio/gpio230/direction

6. Run gpiodump with the button released and the pressed,
observe that there is difference in the output value of pin38:
localhost tmp # gpiodump
 0 0 0 0 0 1 1 0
 0 0 0 0 0 1 0 0
 0 0 0 0 0 0 0 0
 0 0 0 1 1 0 0 0
 0 1 0 0 0 0 1 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
localhost tmp # gpiodump
 0 0 0 0 0 1 1 0
 0 0 0 0 0 1 0 0
 0 0 0 0 0 0 0 0
 0 0 0 1 1 0 0 0
 0 1 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0

Signed-off-by: Vadim Bendebury <vbendeb@google.com>
Review URL: http://codereview.chromium.org/3333016

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

CHROMIUM: NM10 gpio driver

See the driver file header for implementation details.

Tested on an ST8 as follows
^^^^^^^^^^^^^^^^^^^^^^^^^^^

localhost ~ # cd /tmp
localhost tmp # scp <user@host>:<path>/nm10_gpio.ko .
localhost tmp # ls /sys/class/gpio/
export  unexport
localhost tmp # insmod nm10_gpio.ko
localhost tmp # ls /sys/class/gpio/
export  gpiochip192  unexport
localhost tmp # i=0; while [ "$i" != "64" ]
> do
> gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  echo $gpio > /sys/class/gpio/export
> done
localhost tmp # ls /sys/class/gpio/
export   gpio195  gpio199  gpio203
gpio207  gpio211  gpio215  gpio219
gpio223  gpio227  gpio231  gpio235
gpio239  gpio243  gpio247  gpio251
gpio255  gpio192  gpio196  gpio200
gpio204  gpio208  gpio212  gpio216
gpio220  gpio224  gpio228  gpio232
gpio236  gpio240  gpio244  gpio248
gpio252  gpiochip192 gpio193  gpio197
gpio201  gpio205  gpio209  gpio213
gpio217  gpio221  gpio225  gpio229
gpio233  gpio237  gpio241  gpio245
gpio249  gpio253  unexport gpio194
gpio198  gpio202  gpio206  gpio210
gpio214  gpio218  gpio222  gpio226
gpio230  gpio234  gpio238  gpio242
gpio246  gpio250  gpio254
localhost tmp #
localhost tmp # gpiodump() {
> i=0; while [ "$i" != "64" ]
> do
>  gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  cat /sys/class/gpio/gpio$gpio/value
> done | awk \
> '{ if (i == 8) {print ""; i = 0;} \
> printf " %s", $1; i = i + 1} \
> END { print "" }'
> }
localhost tmp # gpiodump
 1 1 0 1 0 1 1 0
 1 1 1 0 1 1 1 1
 0 0 0 0 0 0 1 0
 0 0 0 0 0 0 0 0
 0 1 1 0 1 0 1 1
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
localhost tmp # gpiodump
 1 1 0 1 0 1 0 0
 1 1 1 0 1 1 1 1
 0 0 0 0 0 0 1 0
 0 0 0 0 0 0 0 0
 0 1 1 0 1 0 1 1
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
localhost tmp #
localhost tmp # i=0; while [ "$i" != "64" ]
> do
> gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  echo $gpio > /sys/class/gpio/unexport
> done
localhost tmp # ls /sys/class/gpio/
export  gpiochip192  unexport
localhost tmp # rmmod nm10_gpio.ko
localhost tmp # ls /sys/class/gpio/
export  unexport
localhost tmp # dmesg | tail -3
[ 5476.917362] nm10_gpio version 0.04 built on May 26 2010 at 14:37:58
[ 5476.917390] gpiochip_find_base: found new base at 192
[ 5995.995601] nm10_gpio base 192 removed
localhost tmp #

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

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
[olof: build fix]
Signed-off-by: Olof Johansson <olof@lixom.net>

CHROMIUM: chromeos_acpi: build fix for 2.6.36

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

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: 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: 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

Change-Id: I0ebd7ecfdc6c80dbda2c5b3e88846227f351f897

CHROMIUM: 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
Signed-off-by: vbendeb <vbendeb@chromium.org>
Conflicts:

drivers/platform/x86/Kconfig
drivers/platform/x86/Makefile

Conflicts:

chromeos/config/i386/config.common.i386

Conflicts:

drivers/platform/x86/Makefile
[anush: fixup for 3.4]
Signed-off-by: Anush Elangovan <anush@chromium.org>
Change-Id: Ie90b5a201d20b2725d599dffb0daf6b24f711a9c

Linux 3.4

Merge tag 'parisc-fixes' of git://git./linux/kernel/git/jejb/parisc-2.6

Pull PA-RISC fixes from James Bottomley:
 "This is a set of three bug fixes that gets parisc running again on
  systems with PA1.1 processors.

  Two fix regressions introduced in 2.6.39 and one fixes a prefetch bug
  that only affects PA7300LC processors.  We also have another pending
  fix to do with the sectional arrangement of vmlinux.lds, but there's a
  query on it during testing on one particular system type, so I'll hold
  off sending it in for now."

* tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6:
  [PARISC] fix panic on prefetch(NULL) on PA7300LC
  [PARISC] fix crash in flush_icache_page_asm on PA1.1
  [PARISC] fix PA1.1 oops on boot

Merge branch 'x86/ld-fix' of git://git./linux/kernel/git/tip/tip

Pull x86 linker bug workarounds from Peter Anvin.

GNU ld-2.22.52.0.[12] (*) has an unfortunate bug where it incorrectly
turns certain relocation entries absolute.  Section-relative symbols
that are part of otherwise empty sections are silently changed them to
absolute.  We rely on section-relative symbols staying section-relative,
and actually have several sections in the linker script solely for this
purpose.

See for example

   http://sourceware.org/bugzilla/show_bug.cgi?id=14052

We could just black-list the buggy linker, but it appears that it got
shipped in at least F17, and possibly other distros too, so it's sadly
not some rare unusual case.

This backports the workaround from the x86/trampoline branch, and as
Peter says: "This is not a minimal fix, not at all, but it is a tested
code base."

* 'x86/ld-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, relocs: When printing an error, say relative or absolute
  x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
  x86, realmode: 16-bit real-mode code support for relocs tool

(*) That's a manly release numbering system. Stupid, sure. But manly.

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

Pull block layer fixes from Jens Axboe:
 "A few small, but important fixes.  Most of them are marked for stable
  as well

   - Fix failure to release a semaphore on error path in mtip32xx.
   - Fix crashable condition in bio_get_nr_vecs().
   - Don't mark end-of-disk buffers as mapped, limit it to i_size.
   - Fix for build problem with CONFIG_BLOCK=n on arm at least.
   - Fix for a buffer overlow on UUID partition printing.
   - Trivial removal of unused variables in dac960."

* 'for-linus' of git://git.kernel.dk/linux-block:
  block: fix buffer overflow when printing partition UUIDs
  Fix blkdev.h build errors when BLOCK=n
  bio allocation failure due to bio_get_nr_vecs()
  block: don't mark buffers beyond end of disk as mapped
  mtip32xx: release the semaphore on an error path
  dac960: Remove unused variables from DAC960_CreateProcEntries()

Merge git://git./linux/kernel/git/davem/net

Pull one more networking bug-fix from David Miller:
 "One last straggler.

  Eric Dumazet's pktgen unload oops fix was not entirely complete, but
  all the cases should be handled properly now....  fingers crossed."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  pktgen: fix module unload for good

memcg,thp: fix res_counter:96 regression

Occasionally, testing memcg's move_charge_at_immigrate on rc7 shows
a flurry of hundreds of warnings at kernel/res_counter.c:96, where
res_counter_uncharge_locked() does WARN_ON(counter->usage < val).

The first trace of each flurry implicates __mem_cgroup_cancel_charge()
of mc.precharge, and an audit of mc.precharge handling points to
mem_cgroup_move_charge_pte_range()'s THP handling in commit 12724850e806
("memcg: avoid THP split in task migration").

Checking !mc.precharge is good everywhere else, when a single page is to
be charged; but here the "mc.precharge -= HPAGE_PMD_NR" likely to
follow, is liable to result in underflow (a lot can change since the
precharge was estimated).

Simply check against HPAGE_PMD_NR: there's probably a better
alternative, trying precharge for more, splitting if unsuccessful; but
this one-liner is safer for now - no kernel/res_counter.c:96 warnings
seen in 26 hours.

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86, relocs: When printing an error, say relative or absolute

When the relocs tool throws an error, let the error message say if it
is an absolute or relative symbol.  This should make it a lot more
clear what action the programmer needs to take and should help us find
the reason if additional symbol bugs show up.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: <stable@vger.kernel.org>

x86, relocs: Workaround for binutils 2.22.52.0.1 section bug

GNU ld 2.22.52.0.1 has a bug that it blindly changes symbols from
section-relative to absolute if they are in a section of zero length.
This turns the symbols __init_begin and __init_end into absolute
symbols.  Let the relocs program know that those should be treated as
relative symbols.

Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: <stable@vger.kernel.org>
Cc: Jarkko Sakkinen <jarkko.sakkinen@intel.com>

x86, realmode: 16-bit real-mode code support for relocs tool

A new option is added to the relocs tool called '--realmode'.
This option causes the generation of 16-bit segment relocations
and 32-bit linear relocations for the real-mode code. When
the real-mode code is moved to the low-memory during kernel
initialization, these relocation entries can be used to
relocate the code properly.

In the assembly code 16-bit segment relocations must be relative
to the 'real_mode_seg' absolute symbol. Linear relocations must be
relative to a symbol prefixed with 'pa_'.

16-bit segment relocation is used to load cs:ip in 16-bit code.
Linear relocations are used in the 32-bit code for relocatable
data references. They are declared in the linker script of the
real-mode code.

The relocs tool is moved to arch/x86/tools/relocs.c, and added new
target archscripts that can be used to build scripts needed building
an architecture.  be compiled before building the arch/x86 tree.

[ hpa: accelerating this because it detects invalid absolute
  relocations, a serious bug in binutils 2.22.52.0.x which currently
  produces bad kernels. ]

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>

Merge tag 'dm-3.4-fixes-2' of git://git./linux/kernel/git/agk/linux-dm

Pull a dm fix from Alasdair G Kergon:
 "A fix to the thin provisioning userspace interface."

* tag 'dm-3.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm thin: fix table output when pool target disables discard passdown internally

dm thin: fix table output when pool target disables discard passdown internally

When the thin pool target clears the discard_passdown parameter
internally, it incorrectly changes the table line reported to userspace.
This breaks dumb string comparisons on these table lines in generic
userspace device-mapper library code and leads to tables being reloaded
repeatedly when nothing is actually meant to be changing.

This patch corrects this by no longer changing the table line when
discard passdown was disabled.

We can still tell when discard passdown is overridden by looking for the
message "Discard unsupported by data device (sdX): Disabling discard passdown."

This automatic detection is also moved from the 'load' to the 'resume'
so that it is re-evaluated should the properties of underlying devices
change.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>

Merge tag 'md-3.4-fixes' of git://neil.brown.name/md

Pull one more md bugfix from NeilBrown:
 "Fix bug in recent fix to RAID10.

  Without this patch, recovery will crash"

* tag 'md-3.4-fixes' of git://neil.brown.name/md:
  md/raid10: fix transcription error in calc_sectors conversion.

Merge branch 'stable' of git://git./linux/kernel/git/cmetcalf/linux-tile

Pull tile tree bugfix from Chris Metcalf:
 "This fixes a security vulnerability (and correctness bug) in tilegx"

* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  tilegx: enable SYSCALL_WRAPPERS support

md/raid10: fix transcription error in calc_sectors conversion.

The old code was
sector_div(stride, fc);
the new code was
sector_dir(size, conf->near_copies);

'size' is right (the stride various wasn't really needed), but
'fc' means 'far_copies', and that is an important difference.

Signed-off-by: NeilBrown <neilb@suse.de>

Merge branch 'akpm' (Andrew's patch-bomb)

Merge misc fixes from Andrew Morton.

* emailed from Andrew Morton <akpm@linux-foundation.org>: (4 patches)
  frv: delete incorrect task prototypes causing compile fail
  slub: missing test for partial pages flush work in flush_all()
  fs, proc: fix ABBA deadlock in case of execution attempt of map_files/ entries
  drivers/rtc/rtc-pl031.c: configure correct wday for 2000-01-01

proc: move fd symlink i_mode calculations into tid_fd_revalidate()

Instead of doing the i_mode calculations at proc_fd_instantiate() time,
move them into tid_fd_revalidate(), which is where the other inode state
(notably uid/gid information) is updated too.

Otherwise we'll end up with stale i_mode information if an fd is re-used
while the dentry still hangs around.  Not that anything really *cares*
(symlink permissions don't really matter), but Tetsuo Handa noticed that
the owner read/write bits don't always match the state of the
readability of the file descriptor, and we _used_ to get this right a
long time ago in a galaxy far, far away.

Besides, aside from fixing an ugly detail (that has apparently been this
way since commit 61a28784028e: "proc: Remove the hard coded inode
numbers" in 2006), this removes more lines of code than it adds.  And it
just makes sense to update i_mode in the same place we update i_uid/gid.

Al Viro correctly points out that we could just do the inode fill in the
inode iops ->getattr() function instead.  However, that does require
somewhat slightly more invasive changes, and adds yet *another* lookup
of the file descriptor.  We need to do the revalidate() for other
reasons anyway, and have the file descriptor handy, so we might as well
fill in the information at this point.

Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

pktgen: fix module unload for good

commit c57b5468406 (pktgen: fix crash at module unload) did a very poor
job with list primitives.

1) list_splice() arguments were in the wrong order

2) list_splice(list, head) has undefined behavior if head is not
initialized.

3) We should use the list_splice_init() variant to clear pktgen_threads
list.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tilegx: enable SYSCALL_WRAPPERS support

Some discussion with the glibc mailing lists revealed that this was
necessary for 64-bit platforms with MIPS-like sign-extension rules
for 32-bit values.  The original symptom was that passing (uid_t)-1 to
setreuid() was failing in programs linked -pthread because of the "setxid"
mechanism for passing setxid-type function arguments to the syscall code.
SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with
proper sign-extension and is thus the appropriate fix for this problem.

On other platforms (s390, powerpc, sparc64, and mips) this was fixed
in 2.6.28.6.  The general issue is tracked as CVE-2009-0029.

Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

Merge tag 'linus-mce-fix' of git://git./linux/kernel/git/ras/ras

Pull a machine check recovery fix from Tony Luck.

I really don't like how the MCE code does some of the things it does,
but this does seem to be an improvement.

* tag 'linus-mce-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  x86/mce: Only restart instruction after machine check recovery if it is safe

frv: delete incorrect task prototypes causing compile fail

Commit 41101809a865 ("fork: Provide weak arch_release_[task_struct|
thread_info] functions") in -tip highlights a problem in the frv arch,
where it has needles prototypes for alloc_task_struct_node and
free_task_struct.  This now shows up as:

  kernel/fork.c:120:66: error: static declaration of 'alloc_task_struct_node' follows non-static declaration
  kernel/fork.c:127:51: error: static declaration of 'free_task_struct' follows non-static declaration

since that commit turned them into real functions.  Since arch/frv does
does not define define __HAVE_ARCH_TASK_STRUCT_ALLOCATOR (i.e.  it just
uses the generic ones) it shouldn't list these at all.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

slub: missing test for partial pages flush work in flush_all()

I found some kernel messages such as:

    SLUB raid5-md127: kmem_cache_destroy called for cache that still has objects.
    Pid: 6143, comm: mdadm Tainted: G           O 3.4.0-rc6+        #75
    Call Trace:
    kmem_cache_destroy+0x328/0x400
    free_conf+0x2d/0xf0 [raid456]
    stop+0x41/0x60 [raid456]
    md_stop+0x1a/0x60 [md_mod]
    do_md_stop+0x74/0x470 [md_mod]
    md_ioctl+0xff/0x11f0 [md_mod]
    blkdev_ioctl+0xd8/0x7a0
    block_ioctl+0x3b/0x40
    do_vfs_ioctl+0x96/0x560
    sys_ioctl+0x91/0xa0
    system_call_fastpath+0x16/0x1b

Then using kmemleak I found these messages:

    unreferenced object 0xffff8800b6db7380 (size 112):
      comm "mdadm", pid 5783, jiffies 4294810749 (age 90.589s)
      hex dump (first 32 bytes):
        01 01 db b6 ad 4e ad de ff ff ff ff ff ff ff ff  .....N..........
        ff ff ff ff ff ff ff ff 98 40 4a 82 ff ff ff ff  .........@J.....
      backtrace:
        kmemleak_alloc+0x21/0x50
        kmem_cache_alloc+0xeb/0x1b0
        kmem_cache_open+0x2f1/0x430
        kmem_cache_create+0x158/0x320
        setup_conf+0x649/0x770 [raid456]
        run+0x68b/0x840 [raid456]
        md_run+0x529/0x940 [md_mod]
        do_md_run+0x18/0xc0 [md_mod]
        md_ioctl+0xba8/0x11f0 [md_mod]
        blkdev_ioctl+0xd8/0x7a0
        block_ioctl+0x3b/0x40
        do_vfs_ioctl+0x96/0x560
        sys_ioctl+0x91/0xa0
        system_call_fastpath+0x16/0x1b

This bug was introduced by commit a8364d5555b ("slub: only IPI CPUs that
have per cpu obj to flush"), which did not include checks for per cpu
partial pages being present on a cpu.

Signed-off-by: majianpeng <majianpeng@gmail.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Tested-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs, proc: fix ABBA deadlock in case of execution attempt of map_files/ entries

map_files/ entries are never supposed to be executed, still curious
minds might try to run them, which leads to the following deadlock

  ======================================================
  [ INFO: possible circular locking dependency detected ]
  3.4.0-rc4-24406-g841e6a6 #121 Not tainted
  -------------------------------------------------------
  bash/1556 is trying to acquire lock:
   (&sb->s_type->i_mutex_key#8){+.+.+.}, at: do_lookup+0x267/0x2b1

  but task is already holding lock:
   (&sig->cred_guard_mutex){+.+.+.}, at: prepare_bprm_creds+0x2d/0x69

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (&sig->cred_guard_mutex){+.+.+.}:
         validate_chain+0x444/0x4f4
         __lock_acquire+0x387/0x3f8
         lock_acquire+0x12b/0x158
         __mutex_lock_common+0x56/0x3a9
         mutex_lock_killable_nested+0x40/0x45
         lock_trace+0x24/0x59
         proc_map_files_lookup+0x5a/0x165
         __lookup_hash+0x52/0x73
         do_lookup+0x276/0x2b1
         walk_component+0x3d/0x114
         do_last+0xfc/0x540
         path_openat+0xd3/0x306
         do_filp_open+0x3d/0x89
         do_sys_open+0x74/0x106
         sys_open+0x21/0x23
         tracesys+0xdd/0xe2

  -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}:
         check_prev_add+0x6a/0x1ef
         validate_chain+0x444/0x4f4
         __lock_acquire+0x387/0x3f8
         lock_acquire+0x12b/0x158
         __mutex_lock_common+0x56/0x3a9
         mutex_lock_nested+0x40/0x45
         do_lookup+0x267/0x2b1
         walk_component+0x3d/0x114
         link_path_walk+0x1f9/0x48f
         path_openat+0xb6/0x306
         do_filp_open+0x3d/0x89
         open_exec+0x25/0xa0
         do_execve_common+0xea/0x2f9
         do_execve+0x43/0x45
         sys_execve+0x43/0x5a
         stub_execve+0x6c/0xc0

This is because prepare_bprm_creds grabs task->signal->cred_guard_mutex
and when do_lookup happens we try to grab task->signal->cred_guard_mutex
again in lock_trace.

Fix it using plain ptrace_may_access() helper in proc_map_files_lookup()
and in proc_map_files_readdir() instead of lock_trace(), the caller must
be CAP_SYS_ADMIN granted anyway.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Dave Jones <davej@redhat.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/rtc/rtc-pl031.c: configure correct wday for 2000-01-01

The reset date of the ST Micro version of PL031 is 2000-01-01.  The
correct weekday for 2000-01-01 is saturday, but pl031 is initialized to
sunday.  This may lead to alarm malfunction, so configure the correct
wday if RTC_DR indicates reset.

Signed-off-by: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Mattias Wallin <mattias.wallin@stericsson.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

Pull ARM fixes from Russell King:
 "Small set of fixes again."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7419/1: vfp: fix VFP flushing regression on sigreturn path
  ARM: 7418/1: LPAE: fix access flag setup in mem_type_table
  ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS
  ARM: 7417/1: vfp: ensure preemption is disabled when enabling VFP access

Merge git://git./linux/kernel/git/davem/net

Pull two networking fixes from David S. Miller:

1) Thanks to Willy Tarreau and Eric Dumazet, we've unlocked a bug that's
   been present in do_tcp_sendpages() since that function was written in
   2002.

   When we block to wait for memory we have to unconditionally try and
   push out pending TCP data, otherwise we can block for an unreasonably
   long amount of time.

2) Fix deadlock in e1000, fixes kernel bugzilla 43132

   From Tushar Dave.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  e1000: Prevent reset task killing itself.
  tcp: do_tcp_sendpages() must try to push data out on oom conditions

ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold

Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.

First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.

Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power().  Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.

Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3.  However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare.  This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now.  In particular, some unused graphics adapters are not turned
off as a result.

To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.

This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.

References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

e1000: Prevent reset task killing itself.

Killing reset task while adapter is resetting causes deadlock.
Only kill reset task if adapter is not resetting.
Ref bug #43132 on bugzilla.kernel.org

CC: stable@vger.kernel.org
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp: do_tcp_sendpages() must try to push data out on oom conditions

Since recent changes on TCP splicing (starting with commits 2f533844
"tcp: allow splice() to build full TSO packets" and 35f9c09f "tcp:
tcp_sendpages() should call tcp_push() once"), I started seeing
massive stalls when forwarding traffic between two sockets using
splice() when pipe buffers were larger than socket buffers.

Latest changes (net: netdev_alloc_skb() use build_skb()) made the
problem even more apparent.

The reason seems to be that if do_tcp_sendpages() fails on out of memory
condition without being able to send at least one byte, tcp_push() is not
called and the buffers cannot be flushed.

After applying the attached patch, I cannot reproduce the stalls at all
and the data rate it perfectly stable and steady under any condition
which previously caused the problem to be permanent.

The issue seems to have been there since before the kernel migrated to
git, which makes me think that the stalls I occasionally experienced
with tux during stress-tests years ago were probably related to the
same issue.

This issue was first encountered on 3.0.31 and 3.2.17, so please backport
to -stable.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Eric Dumazet <edumazet@google.com>
Cc: <stable@vger.kernel.org>

Merge branch '3.4-urgent' of git://git./linux/kernel/git/nab/target-pending

Pull two more target-core updates from Nicholas Bellinger:
 "The first patch addresses a SPC-2 reservations RELEASE bug in a
  special (iscsi specific) multi-ISID setup case that was allowing the
  same initiator to be able to incorrect release it's own reservation on
  a different SCSI path with enforce_pr_isid=1 operation.  This bug was
  caught by Bernhard Kohl.

  The second patch is to address a bug with FILEIO backends where the
  incorrect number of blocks for READ_CAPACITY was being reported after
  an underlying device-mapper block_device size change.  This patch uses
  now i_size_read() in fd_get_blocks() for FILEIO backends with an
  underlying block_device, instead of trying to determine this value at
  setup time during fd_create_virtdevice().  (hch CC'ed)

  Both are CC'ed to stable."

* '3.4-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target: Fix bug in handling of FILEIO + block_device resize ops
  target: Fix SPC-2 RELEASE bug for multi-session iSCSI client setups

target: Fix bug in handling of FILEIO + block_device resize ops

This patch fixes a bug in the handling of FILEIO w/ underlying block_device
resize operations where the original fd_dev->fd_dev_size was incorrectly being
used in fd_get_blocks() for READ_CAPACITY response payloads.

This patch avoids using fd_dev->fd_dev_size for FILEIO devices with
an underlying block_device, and instead changes fd_get_blocks() to
get the sector count directly from i_size_read() as recommended by hch.

Reported-by: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

Pull slave-dmaengine fixes fromVinod Koul:
 "fixes of cylic dma usages in slave dma drivers"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: fix cyclic dma usage
  dmaengine: pl330: dont complete descriptor for cyclic dma

Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull last minute virtio fixes from Michael S. Tsirkin:
 "Here are a couple of last minute virtio fixes for 3.4.  Hope it's not
  too late yes - I might have tried too hard to make sure the fix is
  well tested.

  Fixes are by Amit and myself.  One fixes module removal and one
  suspend of a VM, the last one the handling of out of memory condition.

  They are thus very low risk as most people never hit these paths, but
  do fix very annoying problems for people that do use the feature.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio_net: invoke softirqs after __napi_schedule
  virtio: balloon: let host know of updated balloon size before module removal
  virtio: console: tell host of open ports after resume from s3/s4

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM: SoC fixes from Olof Johansson:
 "I will stop trying to predict when we're done with fixes for a
  release.

  Here's another small batch of three patches for arm-soc:

   - A fix for a boot time WARN_ON() due to irq domain conversion on
     PRIMA2
   - Fix for a regression in Tegra SMP spinup code due to swapped
     register offsets
   - Fixed config dependency for mv_cesa crypto driver to avoid build
     breakage"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: PRIMA2: fix irq domain size and IRQ mask of internal interrupt controller
  crypto: mv_cesa requires on CRYPTO_HASH to build
  ARM: tegra: Fix flow controller accesses

Merge tag 'md-3.4-fixes' of git://neil.brown.name/md

Pull two md fixes from NeilBrown:
 "One fixes a bug in the new raid10 resize code so is relevant to 3.4
  only.

  The other fixes a bug in the use of md by dm-raid, so is relevant to
  any kernel with dm-raid support"

* tag 'md-3.4-fixes' of git://neil.brown.name/md:
  MD: Add del_timer_sync to mddev_suspend (fix nasty panic)
  md/raid10: set dev_sectors properly when resizing devices in array.

Merge branches 'perf-urgent-for-linus', 'x86-urgent-for-linus' and 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf, x86 and scheduler updates from Ingo Molnar.

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tracing: Do not enable function event with enable
  perf stat: handle ENXIO error for perf_event_open
  perf: Turn off compiler warnings for flex and bison generated files
  perf stat: Fix case where guest/host monitoring is not supported by kernel
  perf build-id: Fix filename size calculation

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, kvm: KVM paravirt kernels don't check for CPUID being unavailable
  x86: Fix section annotation of acpi_map_cpu2node()
  x86/microcode: Ensure that module is only loaded on supported Intel CPUs

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix KVM and ia64 boot crash due to sched_groups circular linked list assumption

ARM: 7419/1: vfp: fix VFP flushing regression on sigreturn path

Commit ff9a184c ("ARM: 7400/1: vfp: clear fpscr length and stride bits
on entry to sig handler") flushes the VFP state prior to entering a
signal handler so that a VFP operation inside the handler will trap and
force a restore of ABI-compliant registers. Reflushing and disabling VFP
on the sigreturn path is predicated on the saved thread state indicating
that VFP was used by the handler -- however for SMP platforms this is
only set on context-switch, making the check unreliable and causing VFP
register corruption in userspace since the register values are not
necessarily those restored from the sigframe.

This patch unconditionally flushes the VFP state after a signal handler.
Since we already perform the flush before the handler and the flushing
itself happens lazily, the redundant flush when VFP is not used by the
handler is essentially a nop.

Reported-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7418/1: LPAE: fix access flag setup in mem_type_table

A zero value for prot_sect in the memory types table implies that
section mappings should never be created for the memory type in question.
This is checked for in alloc_init_section().

With LPAE, we set a bit to mask access flag faults for kernel mappings.
This breaks the aforementioned (!prot_sect) check in alloc_init_section().

This patch fixes this bug by first checking for a non-zero
prot_sect before setting the PMD_SECT_AF flag.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

virtio_net: invoke softirqs after __napi_schedule

__napi_schedule might raise softirq but nothing
causes do_softirq to trigger, so it does not in fact
run. As a result,
the error message "NOHZ: local_softirq_pending 08"
sometimes occurs during boot of a KVM guest when the network service is
started and we are oom:

  ...
  Bringing up loopback interface:  [  OK  ]
  Bringing up interface eth0:
  Determining IP information for eth0...NOHZ: local_softirq_pending 08
   done.
  [  OK  ]
  ...

Further, receive queue processing might get delayed
indefinitely until some interrupt triggers:
virtio_net expected napi to be run immediately.

One way to cause do_softirq to be executed is by
invoking local_bh_enable(). As __napi_schedule is
normally called from bh or irq context, this
seems to make sense: disable bh before __napi_schedule
and enable afterwards.

In fact it's a very complicated way of calling do_softirq(),
and works since this function is only used when we are not
in interrupt context.  It's not hot at all, in any ideal scenario.

Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Tested-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>

virtio: balloon: let host know of updated balloon size before module removal

When the balloon module is removed, we deflate the balloon, reclaiming
all the pages that were given to the host.  However, we don't update the
config values for the new balloon size, resulting in the host showing
outdated balloon values.

The size update is done after each leak and fill operation, only the
module removal case was left out.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

virtio: console: tell host of open ports after resume from s3/s4

If a port was open before going into one of the sleep states, the port
can continue normal operation after restore.  However, the host has to
be told that the guest side of the connection is open to restore
pre-suspend state.

This wasn't noticed so far due to a bug in qemu that was fixed recently
(which marked the guest-side connection as always open).

CC: stable@vger.kernel.org # Only for 3.3
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

ARM: PRIMA2: fix irq domain size and IRQ mask of internal interrupt controller

the old codes will cause 3.4 kernel warning as irq domain size is wrong:
------------[ cut here ]------------
WARNING: at kernel/irq/irqdomain.c:74 irq_domain_legacy_revmap+0x24/0x48()
Modules linked in:
[<c0013f50>] (unwind_backtrace+0x0/0xf8) from [<c001e7d8>] (warn_slowpath_common+0x54/0x64)
[<c001e7d8>] (warn_slowpath_common+0x54/0x64) from [<c001e804>] (warn_slowpath_null+0x1c/0x24)
[<c001e804>] (warn_slowpath_null+0x1c/0x24) from [<c005c3c4>] (irq_domain_legacy_revmap+0x24/0x48)
[<c005c3c4>] (irq_domain_legacy_revmap+0x24/0x48) from [<c005c704>] (irq_create_mapping+0x20/0x120)
[<c005c704>] (irq_create_mapping+0x20/0x120) from [<c005c880>] (irq_create_of_mapping+0x7c/0xf0)
[<c005c880>] (irq_create_of_mapping+0x7c/0xf0) from [<c01a6c48>] (irq_of_parse_and_map+0x2c/0x34)
[<c01a6c48>] (irq_of_parse_and_map+0x2c/0x34) from [<c01a6c68>] (of_irq_to_resource+0x18/0x74)
[<c01a6c68>] (of_irq_to_resource+0x18/0x74) from [<c01a6ce8>] (of_irq_count+0x24/0x34)
[<c01a6ce8>] (of_irq_count+0x24/0x34) from [<c01a7220>] (of_device_alloc+0x58/0x158)
[<c01a7220>] (of_device_alloc+0x58/0x158) from [<c01a735c>] (of_platform_device_create_pdata+0x3c/0x80)
[<c01a735c>] (of_platform_device_create_pdata+0x3c/0x80) from [<c01a7468>] (of_platform_bus_create+0xc8/0x190)
[<c01a7468>] (of_platform_bus_create+0xc8/0x190) from [<c01a74cc>] (of_platform_bus_create+0x12c/0x190)
---[ end trace 1b75b31a2719ed32 ]---

Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

MD: Add del_timer_sync to mddev_suspend (fix nasty panic)

Use del_timer_sync to remove timer before mddev_suspend finishes.

We don't want a timer going off after an mddev_suspend is called.  This is
especially true with device-mapper, since it can call the destructor function
immediately following a suspend.  This results in the removal (kfree) of the
structures upon which the timer depends - resulting in a very ugly panic.
Therefore, we add a del_timer_sync to mddev_suspend to prevent this.

Cc: stable@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>

md/raid10: set dev_sectors properly when resizing devices in array.

raid10 stores dev_sectors in 'conf' separately from the one in
'mddev' because it can have a very significant effect on block
addressing and so need to be updated carefully.

However raid10_resize isn't updating it at all!

To update it correctly, we need to make sure it is a proper
multiple of the chunksize taking various details of the layout
in to account.
This calculation is currently done in setup_conf.   So split it
out from there and call it from raid10_resize as well.
Then set conf->dev_sectors properly.

Signed-off-by: NeilBrown <neilb@suse.de>

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm powerpc fixes from Marcelo Tosatti:
 "Urgent KVM PPC updates, quoting Alexander Graf:

    There are a few bugs in 3.4 that really should be fixed before
    people can be all happy and fuzzy about KVM on PowerPC.  These fixes
    are:

     * fix POWER7 bare metal with PR=y
     * fix deadlock on HV=y book3s_64 mode in low memory cases
     * fix invalid MMU scope of PR=y mode on book3s_64, possibly eading
       to memory corruption"

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates
  powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM
  KVM: PPC: Book3S: PR: Fix hsrr code
  KVM: PPC: Fix PR KVM on POWER7 bare metal
  KVM: PPC: Book3S: PR: Handle EMUL_ASSIST

Merge tag 'sound-3.4' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A few last-minute regression fixes for 3.4 final kernel.  All trivial,
  and Cc'ed to stable kernel."

* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: wm8994: Fix AIF2ADC power down
  ALSA: hda/idt - Fix power-map for speaker-pins with some HP laptops
  ASoC: cs42l73: Sync digital mixer kcontrols to allow for 0dB

Merge tag 'rproc-for-linus' of git://git./linux/kernel/git/ohad/remoteproc

Pull remoteproc fix from Ohad Ben-Cohen:
 "Fix a nasty off-by-one remoteproc bug which leaks memory when a remote
  processor is shut down and, on certain circumstances, can indirectly
  prevent it from being reloaded."

* tag 'rproc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  remoteproc: fix off-by-one bug in __rproc_free_vrings

Merge git://git.samba.org/sfrench/cifs-2.6

Pull CIFS fix from Jeff Layton

* git://git.samba.org/sfrench/cifs-2.6:
  cifs: fix misspelling of "forcedirectio"

Merge branch 'stable' of git://git./linux/kernel/git/cmetcalf/linux-tile

Pull two Tile arch fixes from Chris Metcalf:
 "These are both bug-fixes, one to avoid some issues in how we invoke
  the "pending userspace work" flags on return to userspace, and the
  other to provide the same signal handler arguments for tilegx32 that
  we do for tilegx64."

* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  arch/tile: apply commit 74fca9da0 to the compat signal handling as well
  arch/tile: fix up some issues in calling do_work_pending()

Merge git://git./linux/kernel/git/davem/net

Pull networking tree from David Miller:

1) ptp_pch driver build broke during this merge window due to missing
   slab.h header, fix from Geery Uytterhoeven.

2) If ipset passes in a bogus hash table size we crash because the size
   is not validated properly.  Compounding this, gcc-4.7 can miscompile
   ipset such that even when the user specifies legitimate parameters
   the tool passes in an out-of-range size to the kernel.

   Fix from Jozsef Kadlecsik.

3) Users have reported that the netdev watchdog can trigger with pch_gbe
   devices, and it turns out this is happening because of races in the
   TX path of the driver leading to the transmitter hanging.  Fix from
   Eric Dumazet, reported and tested by Andy Cress.

4) Novatel USB551L devices match the generic class entries for the cdc
   ethernet USB driver, but they don't work because they have generic
   descriptors and thus need FLAG_WWAN to function properly.

   Add the necessary ID table entry to fix this, from Dan Williams.

5) A recursive locking fix in the USBNET driver added a new problem, in
   that packet list traversal is now racy and we can thus access
   unlinked SKBs and crash.

   Avoid this situation by adding some extra state tracking, from Ming
   Lei.

6) The rtlwifi conversion to asynchronous firmware loading is racy, fix
   by reordering the probe procedure.  From Larry Finger.

   Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43187

7) Fix regressions with bluetooth keyboards by notifying userland
   properly when the security level changes, from Gustavo Padovan.

8) Bluetooth needs to make sure device connected events are emitted
   before other kinds of events, otherwise userspace will think there is
   no baseband link yet and therefore abort the sockets associated with
   that connection.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  netfilter: ipset: fix hash size checking in kernel
  ptp_pch: Add missing #include <linux/slab.h>
  pch_gbe: fix transmit races
  cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN
  usbnet: fix skb traversing races during unlink(v2)
  Bluetooth: mgmt: Fix device_connected sending order
  Bluetooth: notify userspace of security level change
  rtlwifi: fix for race condition when firmware is cached

arch/tile: apply commit 74fca9da0 to the compat signal handling as well

This passes siginfo and mcontext to tilegx32 signal handlers that
don't have SA_SIGINFO set just as we have been doing for tilegx64.

Cc: stable@vger.kernel.org
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

arch/tile: fix up some issues in calling do_work_pending()

First, we were at risk of handling thread-info flags, in particular
do_signal(), when returning from kernel space.  This could happen
after a failed kernel_execve(), or when forking a kernel thread.
The fix is to test in do_work_pending() for user_mode() and return
immediately if so; we already had this test for one of the flags,
so I just hoisted it to the top of the function.

Second, if a ptraced process updated the callee-saved registers
in the ptregs struct and then processed another thread-info flag, we
would overwrite the modifications with the original callee-saved
registers.  To fix this, we add a register to note if we've already
saved the registers once, and skip doing it on additional passes
through the loop.  To avoid a performance hit from the couple of
extra instructions involved, I modified the GET_THREAD_INFO() macro
to be guaranteed to be one instruction, then bundled it with adjacent
instructions, yielding an overall net savings.

Reported-By: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>

netfilter: ipset: fix hash size checking in kernel

The hash size must fit both into u32 (jhash) and the max value of
size_t. The missing checking could lead to kernel crash, bug reported
by Seblu.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

ptp_pch: Add missing #include <linux/slab.h>

drivers/ptp/ptp_pch.c: In function 'pch_remove':
drivers/ptp/ptp_pch.c:576:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/ptp/ptp_pch.c: In function 'pch_probe':
drivers/ptp/ptp_pch.c:587:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cifs: fix misspelling of "forcedirectio"

...and add a "directio" synonym since that's what the manpage has
always advertised.

Acked-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>

ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

Cc: <stable@vger.kernel.org>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Merge branch 'for-3.4/fixes-for-final' of git://git./linux/kernel/git/swarren/linux-tegra into fixes

* 'for-3.4/fixes-for-final' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
  ARM: tegra: Fix flow controller accesses

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge branch 'marvell_fixes_for_v3.4' of git://git.infradead.org/users/jcooper/linux into fixes

* 'marvell_fixes_for_v3.4' of git://git.infradead.org/users/jcooper/linux:
  crypto: mv_cesa requires on CRYPTO_HASH to build

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

KVM: PPC: Book3S HV: Fix bug leading to deadlock in guest HPT updates

When handling the H_BULK_REMOVE hypercall, we were forgetting to
invalidate and unlock the hashed page table entry (HPTE) in the case
where the page had been paged out.  This fixes it by clearing the
first doubleword of the HPTE in that case.

This fixes a regression introduced in commit a92bce95f0 ("KVM: PPC:
Book3S HV: Keep HPTE locked when invalidating").  The effect of the
regression is that the host kernel will sometimes hang when under
memory pressure.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>

powerpc/kvm: Fix VSID usage in 64-bit "PR" KVM

The code forgot to scramble the VSIDs the way we normally do
and was basically using the "proto VSID" directly with the MMU.

This means that in practice, KVM used random VSIDs that could
collide with segments used by other user space programs.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[agraf: simplify ppc32 case]
Signed-off-by: Alexander Graf <agraf@suse.de>

KVM: PPC: Book3S: PR: Fix hsrr code

When jumping back into the kernel to code that knows that it would be
using HSRR registers instead of SRR registers, we need to make sure we
pass it all information on where to jump to in HSRR registers.

Unfortunately, we used r10 to store the information to distinguish between
the HSRR and SRR case. That register got clobbered in between though,
rendering the later comparison invalid.

Instead, let's use cr1 to store this information. That way we don't
need yet another register and everyone's happy.

This fixes PR KVM on POWER7 bare metal for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

KVM: PPC: Fix PR KVM on POWER7 bare metal

When running on a system that is HV capable, some interrupts use HSRR
SPRs instead of the normal SRR SPRs. These are also used in the Linux
handlers to jump back to code after an interrupt got processed.

Unfortunately, in our "jump back to the real host handler after we've
done the context switch" code, we were only setting the SRR SPRs,
rendering Linux to jump back to some invalid IP after it's processed
the interrupt.

This fixes random crashes on p7 opal mode with PR KVM for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

KVM: PPC: Book3S: PR: Handle EMUL_ASSIST

In addition to normal "priviledged instruction" traps, we can also receive
"emulation assist" traps on newer hardware that has the HV bit set.

Handle that one the same way as a privileged instruction, including the
instruction fetching. That way we don't execute old instructions that we
happen to still leave in that field when an emul assist trap comes.

This fixes -M mac99 / -M g3beige on p7 bare metal for me.

Signed-off-by: Alexander Graf <agraf@suse.de>

[PARISC] fix panic on prefetch(NULL) on PA7300LC

Due to an errata, the PA7300LC generates a TLB miss interruption even on the
prefetch instruction.  This means that prefetch(NULL), which is supposed to be
a nop on linux actually generates a NULL deref fault.  Fix this by testing the
address of prefetch against NULL before doing the prefetch.

Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[PARISC] fix crash in flush_icache_page_asm on PA1.1

As pointed out by serveral people, PA1.1 only has a type 26 instruction
meaning that the space register must be explicitly encoded.  Not giving an
explicit space means that the compiler uses the type 24 version which is PA2.0
only resulting in an illegal instruction crash.

This regression was caused by

    commit f311847c2fcebd81912e2f0caf8a461dec28db41
    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date:   Wed Dec 22 10:22:11 2010 -0600

        parisc: flush pages through tmpalias space

Reported-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org #2.6.39+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

[PARISC] fix PA1.1 oops on boot

All PA1.1 systems have been oopsing on boot since

commit f311847c2fcebd81912e2f0caf8a461dec28db41
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Wed Dec 22 10:22:11 2010 -0600

    parisc: flush pages through tmpalias space

because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB
insertion interruption path when it was consolidated with the do_alias macro.
Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit.
Cc: stable@vger.kernel.org #2.6.39+
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Merge branch 'for-davem' of git://git./linux/kernel/git/linville/wireless

John Linville says:

Here are three more fixes that some of my developers are desperate to
see included in 3.4...

Johan Hedberg went to some length justifyng the inclusion of these two
Bluetooth fixes:

"The device_connected fix should be quite self-explanatory, but it's
actually a wider issue than just for keyboards. All profiles that do
incoming connection authorization (e.g. headsets) will break without it
with specific hardware. The reason it wasn't caught earlier is that it
only occurs with specific Bluetooth adapters.

As for the security level patch, this fixes L2CAP socket based security
level elevation during a connection. The HID profile needs this (for
keyboards) and it is the only way to achieve the security level
elevation when using the management interface to talk to the kernel
(hence the management enabling patch being the one that exposes this"

The rtlwifi fix addresses a regression related to firmware loading,
as described in kernel.org bug 43187.  It basically just moves a hunk
of code to a more appropriate place.

Signed-off-by: David S. Miller <davem@davemloft.net>

mn10300/CPU hotplug: Add missing call to notify_cpu_starting()

The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

parisc/CPU hotplug: Add missing call to notify_cpu_starting()

The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-and-Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-and-Tested-by: Tobias Ulmer <tobiasu@tmux.org>
Tested-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless into for-davem

Merge tag 'asoc-3.4' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Last minute fixes

Some last minute fixes for ASoC.  Small, focused changes to specific
drivers.

pch_gbe: fix transmit races

Andy reported pch_gbe triggered "NETDEV WATCHDOG" errors.

May 11 11:06:09 kontron kernel: WARNING: at net/sched/sch_generic.c:261
dev_watchdog+0x1ec/0x200() (Not tainted)
May 11 11:06:09 kontron kernel: Hardware name: N/A
May 11 11:06:09 kontron kernel: NETDEV WATCHDOG: eth0 (pch_gbe):
transmit queue 0 timed out

It seems pch_gbe has a racy tx path (races with TX completion path)

Remove tx_queue_lock lock since it has no purpose, we must use tx_lock
instead.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andy Cress <andy.cress@us.kontron.com>
Tested-by: Andy Cress <andy.cress@us.kontron.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN

Needs to be tagged with FLAG_WWAN, which since it has generic
descriptors, won't happen if we don't override the generic
driver info.

Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dan Williams <dcbw@redhat.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

usbnet: fix skb traversing races during unlink(v2)

Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock before unlink, but may
cause skb traversing races:
- after URB is unlinked and the queue lock is released,
the refered skb and skb->next may be moved to done queue,
even be released
- in skb_queue_walk_safe, the next skb is still obtained
by next pointer of the last skb
- so maybe trigger oops or other problems

This patch extends the usage of entry->state to describe 'start_unlink'
state, so always holding the queue(rx/tx) lock to change the state if
the referd skb is in rx or tx queue because we need to know if the
refered urb has been started unlinking in unlink_urbs.

The other part of this patch is based on Huajun's patch:
always traverse from head of the tx/rx queue to get skb which is
to be unlinked but not been started unlinking.

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

ASoC: wm8994: Fix AIF2ADC power down

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

genirq: export handle_edge_irq() and irq_to_desc()

Export handle_edge_irq() and irq_to_desc() to modules to allow them to
do things such as

__irq_set_handler_locked(...., handle_edge_irq);

This fixes

ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!
ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!

when gpio-pch is being built as a module.

This was introduced by commit df9541a60af0 ("gpio: pch9: Use proper flow
type handlers") that added

__irq_set_handler_locked(d->irq, handle_edge_irq);

but handle_edge_irq() was not exported for modules (and inlined
__irq_set_handler_locked() requires irq_to_desc() exported as well)

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

block: fix buffer overflow when printing partition UUIDs

6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
added part_unpack_uuid() which assumes that the passed in buffer has
enough space for sprintfing "%pU" - 37 characters including '\0'.

Unfortunately, b5af921ec0233 "init: add support for root devices
specified by partition UUID" supplied 33 bytes buffer to the function
leading to the following panic with stackprotector enabled.

  Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e

  [<ffffffff815e226b>] panic+0xba/0x1c6
  [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb
  [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20
  [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb
  [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f
  [<ffffffff81aee0fa>] mount_root+0x57/0x5b
  [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176
  [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30
  [<ffffffff81aedd60>] kernel_init+0x155/0x15a
  [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0
  [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10
  [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5
  [<ffffffff815f4d20>] ? gs_change+0x13/0x13

Increase the buffer size, remove the dangerous part_unpack_uuid() and
use snprintf() directly from printk_all_partitions().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Szymon Gruszczynski <sz.gruszczynski@googlemail.com>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>

ALSA: hda/idt - Fix power-map for speaker-pins with some HP laptops

BIOS on some HP laptops don't set the speaker-pins as fixed but expose
as jacks, and this confuses the driver as if these pins are
jack-detectable.  As a result, the machine doesn't get sounds from
speakers because the driver prepares the power-map update via jack
unsol events which never come up in reality.  The bug was introduced
in some time in 3.2 for enabling the power-mapping feature.

This patch fixes the problem by replacing the check of the persistent
power-map bits with a proper is_jack_detectable() call.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43240

Cc: <stable@vger.kernel.org> [v3.2+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

dmaengine: fix cyclic dma usage

for cyclic dma, dont makr the descriptor as complte. Fix the remaining users of
cyclic dma which do so

Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Tested-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Mika Westerberg <mika.westerberg@iki.fi>