git.cascardo.eti.br Git - cascardo/linux.git/log

CHROMIUM: Input: atmel_mxt_ts - register input device before request_irq

As soon as the irq is request, input event interrupts could occur that
the isr should handle. Similarly, if there are input events queued up
in the device output buffer, it will send them immediately when we
drain the message buffer with mxt_handle_messages.

Therefore, register the input device before enabling the irq (or handling
messages).

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/object

Change-Id: I16172901d963cd2e60533e12e455012cb62cdfe5
Reviewed-on: https://gerrit.chromium.org/gerrit/21061
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - verify info block checksum

Compute 24 bit CRC over entire Information Block (ID info plus Object
Table), and verify that it matches checksum read from the device.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:9103
TEST=Verify atmel device is discovered and operates as before.

Change-Id: Ic20f585abf6726e7ff5e2cc4afd7ae805180b81d
Reviewed-on: https://gerrit.chromium.org/gerrit/20600
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add sysfs entry to read info checksum

The device stores the Information Block Checksum in the 3 bytes
immediately following the Information Block.

Read these three bytes, cache the value, and add a sysfs entry so
userspace can read it.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:9103
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/info_csum

Change-Id: I27512c624bad15674bc7c50c15717913595affe4
Reviewed-on: https://gerrit.chromium.org/gerrit/20599
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add sysfs entry to read config checksum

Config checksum is returned in the T6 message at every boot, and when
the config changes. Cache its value and add sysfs entry for userspace to
read it.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:9103
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/config_csum

Change-Id: Ic546d1671e9f6a3da598f06a31f76a6ca96ce235
Reviewed-on: https://gerrit.chromium.org/gerrit/20597
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - refactor mxt_object_show

* use scnprintf() like all well-behaved sysfs entries
* conserve limited (PAGE_SIZE) sysfs output buffer space by not printing
the object's index which is not that useful to userspace

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/object

Change-Id: Iefd6ebd058efbd7131ffbfff0db3762e3273dddf
Reviewed-on: https://gerrit.chromium.org/gerrit/20601
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - split hw_version from fw_version sysfs attribute

This driver's sysfs attribute is pretty dubious, however, for the fw & hw
version let's follow the 'one ASCII value per attribute' guidelines:
(For sysfs style, see Documentation/filesystems/sysfs.txt).

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:8474
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/<bus>/hw_version
# Confirm same as "Family ID: %d Variant ID: %d" in /var/log/messages
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/<bus>/fw_version
# Compare same as "Major.Minor.Build: %d.%d.%d" in /var/log/messages

Change-Id: Ib751d0d15c9fa6a59cad2ce3b09564b4ebf216a7
Reviewed-on: https://gerrit.chromium.org/gerrit/20906
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - Increase FWRESET_TIME

175ms is not enough time to update the firmware. Set to
500ms.

BUG=chrome-os-partner:8731
TEST=firmware update. ensure that transitions back to app mode at the end.

Change-Id: Idaec72cb4f326a10d3513ffb82bf4b144c68b30c
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19640
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - change MXT_BOOT_LOW to 0x26

Changed to support address on new part. This is contrary to
Atmel documentation, and we are still working with them
to clear up this inconsistency. In the meantime,
change it for now to allow existing systems to update.

BUG=chrome-os-partner:8734
TEST=Firmware update works.

Change-Id: Ib2db2a066126df291c7a85208743c80c5357d55d
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19639
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - Retry power mode reads

During the transition between power modes, the read byte
may fail. Extend the retry mechanism in set_power_mode to
the read byte as well.

Increase tries to 5, as they will be shared by both the read
and write steps.

BUG=chromium-os:28646,chromium-os:21047,chrome-os-partner:9229
TEST=Suspend and resume the system several times with the lid open
(using powerd_suspend) or with the lid closed, by closing the lid.
Ensure that the following errors do not appear in the logs:
set power mode failed, -6
resume active power failed, -6
set active power failed, -6

Change-Id: Ic8262b5ad7fc6423841a8c8682533bc40bfbb1dc
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19229

CHROMIUM: Input: atmel_mxt_ts - move mxt_intialize

Refactor only; no functional change.
This patch is in preparation for moving device creation and irq request
into mxt_initialize.  This will move all non-bootloader initialization
into a single function that can be called:
  a) on probe(), if device is using the APP i2c address
  b) after update_fw
  c) after updating device configuration

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:11197
TEST=builds clean; no functional change

Change-Id: I66c23f5922e013edeb8caa75788931792c16d2d8
Reviewed-on: https://gerrit.chromium.org/gerrit/20849
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - use client name for irq

The atmel_mxt_ts driver can support multiple devices simultaneously.
Use the i2c_client name instead of the driver name when requesting an
interrupt to make the different interrupts distinguishable in
/proc/interrupts and top.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:8547
TEST=cat /proc/interrupts
=> Should see i2c client name listed for each atmel_mxt_ts device

Change-Id: I1e3cc7bbb4ef3db8f0c2aca09c0a9a0c9206f524
Reviewed-on: https://gerrit.chromium.org/gerrit/20848
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - warn if sysfs could not be created

If sysfs entry creation fails, the driver is still usable, so don't
just abort probe. Just warn and continue.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:8733
TEST=builds clean

Change-Id: I67073b9ee773379395f8f9bbea3cd0163d7066ca
Reviewed-on: https://gerrit.chromium.org/gerrit/20846
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - detect OOM when creating mt slots

Also fix an erroneous duplicate line introduced in a recent commit.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; device detected and configured as before

Change-Id: I8b0cadbaa0f95502888a0e2d000e69095f796391
Reviewed-on: https://gerrit.chromium.org/gerrit/20845
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add calibrate sysfs entry

In some situations, a touch surface may get out of calibration.
It is useful to provide a means for userspace to trigger a recal, so add a
calibrate sysfs entry.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:9148
TEST=echo 1 > /sys/bus/i2c/drivers/atmel_mxt_ts/<dev>/calibrate

Change-Id: Idbdd7bf4f412f03e36604a2a1fae162f059234d3
Reviewed-on: https://gerrit.chromium.org/gerrit/20812
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - reorder sysfs handlers

Just a cleanup to reorganize the file to list sysfs handlers in
alphabetical order (the same order in which they are declared).

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=none (no functional change)

Change-Id: I6a84a7287df07fd4b067104ba0ae9fd8d103e685
Reviewed-on: https://gerrit.chromium.org/gerrit/20596
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - set phys

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/<#-004b>/input/input<#>/phys/input
=> i2c adapter name

Change-Id: I1b25d51a4efb83499f7ce721124afdcbad9081c2
Reviewed-on: https://gerrit.chromium.org/gerrit/20842
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - set POINTER and BUTTONPAD props

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27072
TEST=Use DISPLAY=:0 xinput list to find the ID for touchpad device
1) Dump touchpad_activity_log:
DISPLAY=:0 xinput set-prop 9 "Logging Notify" 1
2) grep isButtonPad /var/log/touchpad_activity_log.txt
=> should show: "isButtonPad": true,

Change-Id: I5327718761b968bf35fe81b7b83d6243c639bf94
Reviewed-on: https://gerrit.chromium.org/gerrit/20819
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - Support bootloader mode at probe

Support a device which comes up bootloader mode enough so that
the operator can echo 1 > update_fw to flash good firmware on.

BUG=chrome-os-partner:8733
TEST=Interrupt a firmware update. Boot the system. Ensure
that the atmel_mxt_ts driver brings up the device using one of
the two MXT_BOOT i2c addresses. From there, it should be possible
to echo 1 > update_fw and recover.

Change-Id: If86e6f0065bb24a5da340ac69adca4ac61d675c9
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19637

CHROMIUM: Input: atmel_mxt_ts - add sysfs entry to read firmware version

Make the firmware version available for other apps to query.

BUG=chrome-os-partner:8474
TEST=cat the fw_version attribute in the atmel_mxt_ts sysfs and make
sure the firmware version is returned.

Change-Id: I69de15ae7202578f971b21e62719241e822977d4
Reviewed-on: https://gerrit.chromium.org/gerrit/20609
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Commit-Ready: Yufeng Shen <miletus@chromium.org>

CHROMIUM: hid-apple - Disable NumLock Emulation for Apple BT keyboards

These keyboards have neither a NumLock key, nor a LED, nor do they
have overlaid NumberPad key caps.  Emulating NumLock on these keyboards
(for instance, by the numlockx utility) is very disorienting, since there
is no indication what happened, nor anyway to disable it.

I tested this with the only Apple BT keyboard that I had:
05AC:0239 USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI

And would appreciate help testing the others, since maybe some of them
really could benefit from the NumLock Emulation:
05AC:022c USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI
05AC:022d USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO
05AC:022e USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS
05AC:023a USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO
05AC:023b USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS
05AC:0256 USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:29169
TEST=Plug in a USB keyboard w/ numlock key & LED
  Pair an Apple BT keyboard with the chrome os system
  Enable NumLock on the USB keyboard
  1) Typing on BT keyboard produces letters, not numbers
  Disable NumLock on the USB keyboard
  2) Typing on BT keyboard produces letters, not numbers

Change-Id: If59b5b3db815218d2136470c53be5bae48c797d4
Reviewed-on: https://gerrit.chromium.org/gerrit/20439
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - Remove T38 from readable, add T37

Add T37, the diagnostic debug object, to the readable list.
Remove T38, user data, as it's not interesting to us for now.

BUG=chrome-os-partner:9134
TEST=cat object, and check that object T37 instance 1/1 is
outputted.

Change-Id: I6936805d547f3e451325d19210a5f03c7792cf69
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/20502
Reviewed-by: Matt Tenuta <mtenuta@chromium.org>
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMIUM: Input: cyapa Handle CONFIG_PM not being defined

If CONFIG_PM isn't defined, the kernel makes power_group_name
be NULL. We get a crash if we try to call sysfs_merge_group
with a NULL group name.

BUG=chromium-os:29327
TEST=Disable CONFIG_PM, build kernel with cyapa driver installed
and find no crash.
TEST=Enable CONFIG_PM, build kernel with cyapa driver installed
and see /sys/bus/i2c/drivers/cyapa/1-0067/power

Change-Id: I3652143176b03b1cc0c0d034a8994d8a772382c6
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/20122
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add new object types

Add new object types to support newer mxt devices.

BUG=chrome-os-partner:8732
TEST=None yet.

Change-Id: I5b7c8987ec4d98fc678a939154b7a057338037bd
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19638
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - make size/instances u16

Previously size and instances fields were u8 but could hold up to a value
of 255. Since we now +1 to size and instances, they must be u16 to hold
the full size of up to 256.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=Confirm object table is read correctly:
cat /sys/bus/i2c/devices/<dev>/object

Change-Id: Ib43baedf5c196b093713f2cec56f67e4ce93e60d
Reviewed-on: https://gerrit.chromium.org/gerrit/18548
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add device id for touchpad variant

This same driver can be used by atmel based touchscreens and touchpads
(buttonpads) by instantiating the i2c device as a "atmel_mxt_tp".

This will cause the driver to perform some touchpad specific
initializations, such as:
  * register input device name "Atmel maXTouch Touchpad" instead of
  Touchscreen.
  * register BTN_LEFT & BTN_TOOL_* event types.
  * register axis resolution (as a fixed constant, for now)
  * register BUTTONPAD property
  * process GPIO buttons using reportid T19

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27714
TEST=builds clean; atmel tp works using ddc lines and cmt

Change-Id: Ifb5cff5667156ca48c1ca90e5e8eea0c434480df
Reviewed-on: https://gerrit.chromium.org/gerrit/17959
Commit-Ready: Benson Leung <bleung@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - send all MT-B slots in one input report

Each interrupt contains information for all contacts with changing
properties.  Process all of this information at once, and send it all in a
a single input report (ie input events ending in EV_SYN/SYN_REPORT).

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean;
  Touch 3 fingers on the atmel device touch surface.
  Notice that 3 MT-B slots are created with unique SLOT & TRACKING IDs.
  Move all 3 fingers at once.
  Using evtest, notice that all 3 slots are updated between SYN_REPORTs.

Change-Id: Ib8ff0487a5db454afc0c9bb2271082178dc9371e
Reviewed-on: https://gerrit.chromium.org/gerrit/17958
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - remove mxt_make_highchg and parse T6 report

This function attempts to make the CHG pin high by reading a bunch of
messages until the device is happy.  Instead of just blindly trying to
read a fixed number of messages, let's actually read and process them.

It turns out that the messages after boot or nvupdates are T6 reports,
containing a status, and the config memory checksum.  So, let's parse
them and dump a useful info message.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; messages after boot are processed;
    Config Checksum displayed in dmesg:
    $ grep "Config Checksum" /var/log/messages

Change-Id: I3d1e266d1ac53f5640e65c5acc3fe6672a0c1451
Reviewed-on: https://gerrit.chromium.org/gerrit/17957
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - read num messages, then all messages

Implement the MXT DMA method of reading messages.
On an interrupt, the T44 report always contains the number of messages
pending to be read.  So, read 1 byte from T44 in 1 i2c transaction, then
read the N pending messages in a second transaction.

The end result is a much much faster read time for all pending messages.
Using 400kHz i2c, it is possible to read 10 pending messages (e.g. for 10
moving contatcts) in less than 2.8ms, which is well less than the typical
10-15ms update rate.

Note: There is a possible optimization here.  The T44 byte is guaranteed
to always be right before the T5 address.  Thus, it should be possible
to always fetch the T44 message count and the first message in a single
transaction.  This would eliminate the overhead of a second complete read
transaction for the case where there is only a single pending message.
(This is actually the most common case, for instance with just 1-contact
on the device touch surface). This optimization, however, is not done in
this patch.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; all pending messages are processed for each interrupt.

Change-Id: I9aa4627d2afdc6da14b7495e78c429d1c4ded7ae
Reviewed-on: https://gerrit.chromium.org/gerrit/17956
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - use cached T9 reportid range in isr

Streamline interrupt processing by caching the T9 reportid range when
first initializing the object table.

Note: the cached T9 reportid's are initialized to 0, which is an invalid
reportid. Thus, the checks in the interrupt handler will always fail
for devices that do not support the T9 object.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; atmel contacts processed in interrupts

Change-Id: I1e0f99465dfa7c86b7e47e3e159b50cdce2a175b
Reviewed-on: https://gerrit.chromium.org/gerrit/17955
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - refactor get info

Read whole info block in one i2c transaction.
And then re-read the matrix size after applying pdata config, since
it may have changed.
Note, however, that the matrix x & y size are just displayed for
information purposes. They aren't actually used by the driver itself.

Also, parse and info print the firmware major and minor version numbers.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=Confirm atmel device info is parsed properly:
$ grep atmel /var/log/messages

Change-Id: I9582d0b528204149bf4a238bec62f712cae5d9c5
Reviewed-on: https://gerrit.chromium.org/gerrit/17954
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - refactor reading object table

Instead of reading each object separately, fetch the whole table in one
large i2c transaction. A 6 byte table object requires 10 bytes to read,
so doing this dramatically reduces overhead.

Also, don't read T5, since this is the message buffer. Reading it will
only have two outcomes, neither of which is particularly useful:
1) the message count decrements, and a valid message will be lost
2) reportid 0xFF = invalid message

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; Readable objects in object table read successfully:
cat /sys/bus/i2c/devices/<dev>/object

Change-Id: I7761a2ca6bc36eba41a3aa27c5249c7c7868b525
Reviewed-on: https://gerrit.chromium.org/gerrit/17952
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - parse vector field of data packets

The atmel_mxt_ts T9 data contains information orientation in its 'vector'
field. Parse and debug print its contents, although its value isn't
actually used yet.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; vector values are reported when DEBUG is defined.

Change-Id: Ida4d9aa167e5134c76d044599240a6c7e329a62c
Reviewed-on: https://gerrit.chromium.org/gerrit/17951
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - simplify event reporting

Instead of carrying around per-finger state in the driver instance, just
report each finger as it arrives to the input layer, and let the input
layer (evdev) hold the event state (which it does anyway).

Also, the atmel pad reports "amplitude", which is reported to userspace
using the "PRESSURE" event type.  The variables now reflect this.

Note: this driver does not really do MT-B properly. Each input report
(a goup of input events followed by a SYN_REPORT) only contains data for
a single contact.  When multiple fingers are present on a device, each is
properly reported in its own MT_SLOT.  However, there is only ever one
MT_SLOT per SYN_REPORT.  This is fixed in a subsequent patch.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; input events sent properly when using atmel device.
  A tracking ID, x, y, pressure and area (as touch_major) should be
     reported for each contact.
  BTN_TOUCH should be 1 when (at least) 1 finger is touching, else 0.

Change-Id: Ie7c9058da27d5158c7f47bd2d11862955978905d
Reviewed-on: https://gerrit.chromium.org/gerrit/17950
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - add backupnv sysfs entry

Writing to the object sysfs entry permits individual object table entries
to be modified in the device RAM at runtime. To permanently save
the settings, they must be written to Non-Volatile memory (NVM).
This patch adds a write-only sysfs entry to allow userspace to save
current settings to NVM, but restricts access to root.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=ls -al /sys/.../backupnv
-> --w------- 1 root root 4096 Feb 14 20:54 backupnv

Change-Id: Id767e0b7ef7f882d6a45ebfe7e96e02800ef2cb8
Reviewed-on: https://gerrit.chromium.org/gerrit/17945
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - allow writing to object sysfs entry

Userspace can write a 32-bit value (encoded as a 8 character hex string)
to the 'object' sysfs entry to modify a single byte of the object table.
The hex string encodes 4 bytes, in the following format:

TTIIFFVV

Where:
TT = object type (atmel 'T' number)
II = object instance (0-indexes, so 0 is the first instance)
FF = object offset
VV = byte value

The object table is modified in device ram, which means the change is
volatile, and will be overwritten on the next device reset.  To make
changes permanent, the new settings should be persisted in the device's
Non-Voltatile Memory using the updatenv sysfs entry.

Also, since the device driver initializes itself by reading some values
from the object table, the entire driver may need to be unloaded and
reloaded after writing the values for the driver to stay in sync.  Whether
this is required depends on exactly which values were updated.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=ls -l /sys/.../object
  --wr--r--r 1 root root 4096 Feb 14 20:54 update_fw

  (0) confirm current number of fingers (look for (Type 9, Offset 14)):
  $ cat /sys/.../object
  (1) Change number of reported fingers (Type: 0x09, Offset: 0x0e) to 7:
  $ echo -n "090e07" > /sys/.../object
  (2) confirm current number of fingers (look for (Type 9, Offset 14)):
  $ cat /sys/.../object
  (3) using mtplot, notice that there now up to 7 fingers are reported.
  (4) reboot, and verify that the old number of fingers is restored.
TEST=Trying to write to a non-existant instance, or past the length of
     an object, should fail.  For example:
   echo -n "070005ab" > /sys/bus/i2c/devices/<dev>/object
  => -bash: echo: write error: Invalid argument

Change-Id: I8149770f762a84ef457c7bf4aefdb310d07c52c5
Reviewed-on: https://gerrit.chromium.org/gerrit/17944
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - take an instance for mxt_write_object

Objects in the object table can have multiple instances.
Force writes to specify a particular instance.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=build clean; atmel touch device configured and enabled correctly.

Change-Id: Ic7208b2b994b490528cce7b2d780bf5497e0d1db
Reviewed-on: https://gerrit.chromium.org/gerrit/18432
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - optimize writing of object table entries

Write each object using a single bulk i2c write transfer.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=confirm objects written properly by comparing table in
  chromeos_laptop to output of:
  cat /sys/bus/i2c/<dev>/object

  Note, however, that some objects are overwritten by pdata config values,
  or at runtime.

Change-Id: Iad557101796b472397585b59a4404d8bbf83fcf6
Reviewed-on: https://gerrit.chromium.org/gerrit/17953
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - refactor mxt_object_show

Read each object with a single i2c transaction instead of byte-by-byte.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=cat /sys/bus/i2c/devices/<dev>object

Change-Id: Ibd9da75de8b34a13cb2bf82cdc685133e25df0fb
Reviewed-on: https://gerrit.chromium.org/gerrit/17949
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - dump each message on just 1 line

Helps ensure all bytes for a single message together in the system log.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=check dmesg with #define DEBUG. All bytes for each message should be
on 1 line.

Change-Id: I1b5aa83f6ceac7a83090a87e98c920f0e31019f9
Reviewed-on: https://gerrit.chromium.org/gerrit/17948
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - do not read extra (checksum) byte

It isn't sent, nor checked anyway, so don't bother reading it.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean; atmel_mxt_ts driver probes device properly and handles
  contact data.
  Use #define DEBUG build to confirm only 8 bytes are read per message.
   (not 9 as before).

Change-Id: I03bac9c81d3fb6f5411ff42b2a16892d5ba2c44c
Reviewed-on: https://gerrit.chromium.org/gerrit/17947
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - store actual size and instance

These two object table entry fields are reported 1 less than their value.
So add 1 once, when building the object table, instead of every time
these fields are accessed.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=Confirm object table is read correctly:
cat /sys/bus/i2c/devices/<dev>/object

Change-Id: If303428b09e8ad5516bae8f2eccb3fd1c386192d
Reviewed-on: https://gerrit.chromium.org/gerrit/17946
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - dump mxt_read/write_reg

For verbose on-the-wire debugging.
Prints DUMP_LEN bytes (in hex) per line.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean w/ & w/out DEBUG defined.
If DEBUG defined, bytes read & written over i2c by atmel_mxt_ts should
appear in /var/log/messages

Change-Id: Ib1b8301a25bb915fea47e4dd62ff261ae5284c3c
Reviewed-on: https://gerrit.chromium.org/gerrit/17943
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - refactor mxt_read/write_reg to take a length

The i2c bus requires 5 bytes to do a 1 byte read (1-byte i2c address + 2
byte offset + 1-byte i2c address + 1 byte data), or 4 bytes to do a
1-byte write (1 byte i2c address + 2 byte offset + 1 byte data).

By taking a length with reads and writes, the driver can amortize
transaction overhead by performing larger transactions where appropriate.

This patch just sets up the new API. Later patches refactor reads/writes
to take advantage of the larger transactions.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean

Change-Id: I00a08856733de3ff4d5b8bf65d53107f981674e8
Reviewed-on: https://gerrit.chromium.org/gerrit/17942
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - only allow root to update firmware

Restrict permissions on the update_fw sysfs entry to read only for root
only.

Also, update object permission to use a macro S_IRUGO macro instead of
hard coded 0444.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=ls -l /sys/.../update_fw
-> --w------- 1 root root 4096 Feb 14 20:54 update_fw

Change-Id: Icdd2ae8cf5e0e41d4b9165a98bdd7ce08d758e60
Reviewed-on: https://gerrit.chromium.org/gerrit/17940
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - use CONFIG_PM_SLEEP

Simple cleanup to use newer PM APIs.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:27713
TEST=builds clean;
Confirm atmel device wakes after suspend/resume cycle.

Change-Id: I829fb8184ce8117aede043c36eb741b7f0d06597
Reviewed-on: https://gerrit.chromium.org/gerrit/17939
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - remove cyapa.h

With the removal of the misc interface, cyapa.h only provides one useful
definition, CYAPA_I2C_NAME.

However, all other i2c devices are instantiated with their name as a
hard coded string, and all usages of CYAPA_I2C_NAME have already been
converted, so it is now ok to remove even this definition.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:21047
TEST=builds clean for both lumpy and tegra2_kaen

Change-Id: I6615d3e76b33846690ee808e70c9c5588fbc5c65
Reviewed-on: https://gerrit.chromium.org/gerrit/16224
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - remove misc defines and structs

Remove misc related defines and structers from cyapa.h

BUG=chromium-os:21047
TEST=compiles clean

Change-Id: Ia68d5d30ac3a86294bbbd8a26348ff0813e25196
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/16221
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - suspend_scanrate_ms sysfs

Add a sysfs property for showing and updating the idle scanrate or
power mode used when the trackpad may wakeup the system from suspend.

"buttononly" : No touch capability. Physical click will wake the system.

An integer will set a variable idle scan interval.
Trackpad supports between 20ms to 1000ms scan intervals.
The time will be increased in increments of 10ms from 20ms to 100ms.
From 100ms to 1000ms, time will be increased in increments of 20ms.

BUG=chrome-os-partner:7121
TEST=echo enabled > power/wakeup
echo buttononly > power/suspend_scanrate_ms
powerd_suspend
Ensure that moving fingers across trackpad does not wake the system.
Click the button. Ensure the system wakes.
echo 20 > power/suspend_scanrate_ms
powerd_suspend.
Ensure trackpad wakes the system quickly on light touch.
echo 1000 > power/suspend_scanrate_ms
Ensure trackpad wakes, but notice it takes longer time on average.
echo 456 > power/suspend_scanrate_ms
cat power/suspend_scanrate_ms
Make sure returns 440. Ensure by trying several different values that the
value returned is rounded as per the increments described above.

Change-Id: Ie397145751e28165355ccbcbb93f42852e7eb381
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/16218
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: synaptics - fix 1->3 contact transition reporting

Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:

Action                 SGM  AGM (MTB slot:Contact)
1. Touch contact 0    (0:0)
2. Touch contact 1    (0:0, 1:1)
3. Lift  contact 0    (1:1)
4. Touch contacts 2,3 (0:2, 1:3)

In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3.  This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.

Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:

Action                SGM  AGM  (MTB slot:contact)
1. Touch contact 0   (0:0)
2. Touch contact 1   (0:0, 1:1)
3. Lift  contact 0   (1:1)
4. Touch contact 2   (0:2, 1:1)
5. Touch contact 3   (0:2, 1:3)

In this case, there was also a bug.  In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty.  So slot 0 can be used to report the new SGM (contact 0),
immediately.  Since it was empty, contact 2 in slot 0 will get a new
tracking ID.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:23197
TEST=Reproduce actions listed above.
  Inspect resulting event stream using evtest.
  Case (a) Contacts 2 and 3 should have different Tracking IDs than 0 and 1
  Case (b) Contact 2 should be reported in slot 0 in the first report
           after it is detected.

Change-Id: I3a58ae06c29b8d7570720297f3b2bd9383be87ca
Reviewed-on: https://gerrit.chromium.org/gerrit/11902
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: synaptics - disable fuzz when using mt slots

The input fuzz algorithm does a pretty good job filtering out small
jitter on input samples.

However, there is a subtle problem when fuzz is used with mt drivers that
also use input_mt_report_pointer_emulation() to report legacy single
touch coordinates.  The reported single touch coordinates are taken from
the active MT slot with smallest tracking id.  However, since the MT data
is sent first, it has already had FUZZ applied.  Thus, the ST coordinates
actually get FUZZ applied a second time, with the just-fuzzed MT value as
the 'old value'.

It appears that it is non-trivial to fix this in the mt layer/input core,
so, for now, just disable fuzz for the synaptics IMAGE_SENSOR path that
uses input_mt_report_pointer_emulation().

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:23196
TEST=Using evtest, inspect ABS_X/Y and ABS_MT_POSITION_X/Y for small
     motions on the image sensor trackpad.  They should always be the same.

Change-Id: I388e5fb1bb8e2254e3a5ac73c6f4c21d8544a317
Reviewed-on: https://gerrit.chromium.org/gerrit/11897
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Ryan T <ryant@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - set pm_wakeup_event

A user may touch the touchpad at right around the time the system is
entering suspend due to idle. This will help close that race condition in
favor of the system not entering suspend.

BUG=chrome-os-partner:8073
TEST=echo enabled > /sys/bus/i2c/devices/15-0067/power/wakeup
cat /sys/power/wakeup_count for a before count.
Touch the touchpad.
cat /sys/power/wakeup_count for an after count. Check that it has advanced.
echo disabled > /sys/bus/i2c/devices/15-0067/power/wakeup
cat wakeup_count again. Check that it does not change.

Change-Id: I420d996e99c4f4d54bd7771f7bb128aa81a9f093
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/16021
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - Use new power modes

Cyapa firmwares as of 11.8 support ACTIVE, (variable) IDLE, BUTTONONLY,
and OFF states.

BUG=chrome-os-partner:7121
TEST=Make sure that firmware 11.8 is used.
(check firmware by cat /sys/bus/i2c/devices/15-0067/firmware_version)
echo enabled > /sys/bus/i2c/devices/15-0067/power/wakeup
powerd_suspend
Try to wake the system by touching the touchpad. Ensure it wakes.
echo disabled > /sys/bus/i2c/devices/15-0067/power/wakeup
powerd_suspend
Try to wake the system again by touchpad. Ensure that it does not wake.

Change-Id: Id5dc007c2a65ce4dc9366689ab44ea35bcb3f2a2
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/15879
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - retry power mode writes

There are some conditions where the trackpad is unresponsive to a power
mode transition, especially when the trackpad is in Off state.
Allow for 3 retries with a 10ms delay only if the write fails.

BUG=chrome-os-partner:8070
TEST=Suspend and resume the system a number of times. Ensure that on resume
the trackpad is always responsive.

Change-Id: I07153873cc68e046310bdd831a7740557d620a1b
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/16018
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - remove misc interface

CYAPA firmware update is now done using the request_firmware() interface
accessible from userspace via sysfs.

The misc interface is therefore redundant, and can be removed.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:21047
TEST=compiles clean

Change-Id: If29f1f2ea3014f2c278fdca87575d93e58882e50
Reviewed-on: https://gerrit.chromium.org/gerrit/13581
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - avoid "unbalanced IRQ wake disable"

To avoid kernel "Unbalanced IRQ # wake disable" WARNING, only disable
irq wake on resume if irq wake was successfully enabled on suspend.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:7652
TEST=Using lumpy with cyapa trackpad driver configured with
  .flags = I2C_CLIENT_WAKE, and power/wakeup == enabled.
  Notice no "Unbalanced IRQ # wake disable" WARNING in /var/log/messages
  after suspend/resume

Change-Id: I2ff559bc2b5b73a43e28923eae49932df6115d4f
Reviewed-on: https://gerrit.chromium.org/gerrit/16121
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - always set full power when device is detected.

On some systems, a system crash / warm boot does not reset a device's
current power mode to FULL_ACTIVE.

If such an event happens during suspend, after the device has been put in
a low power mode, the device will still be in low power mode on a
subsequent boot, since there was never a matching resume().

Handle this by always forcing full power whenever a device is first
detected to be in operational mode.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:7663
TEST=suspend device; force crash (how?);
=> trackpad should be responsive again on next boot

Change-Id: I56ded0d226508e30bf6df7cd87c29756f7c1f120
Reviewed-on: https://gerrit.chromium.org/gerrit/15981
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - use %z as printk fomat for size_t

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:26412
TEST=builds w/out warnings

Change-Id: If6b631e53af0125fa83f7f2abcad60974a839f17
Reviewed-on: https://gerrit.chromium.org/gerrit/15896
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - add debugfs entry for reading device firmware

The cyapa 'misc' interface is global, and will be removed soon.
Firmware update has been implemented using the request_firmware() api.
This patch adds a debugfs API for reading back the firmware.

Note: The firmware is read from device flash starting from 128-byte the
bootloader header located at address 0x0780.  The resulting firmware file
will be 30848 bytes.

Several blocks of the firmware image contain "IDAC" or other calibration
values.  Since the location of these constants is defined by the particular
firmware version, the current value is returned by read_fw.
The resulting firmware image must have these values converted to their
default values before a read-from-device image can be written back to a
device.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:24107
TEST=cat /sys/kernel/debug/cyapa/15-0067/read_fw > /tmp/cyapa.bin
  => The first read of a cyapa firmware image should take ~7 seconds.
  => Subsequent reads should be instantaneous, since it uses buffered data

Change-Id: I495db89b5446ff6832cd1914e068595775d5c940
Reviewed-on: https://gerrit.chromium.org/gerrit/14605
Reviewed-by: Dudley Du <dudl@cypress.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - remove detect work

CYAPA detect has been sped up enough now that it isn't worth the overhead
and complexity of having its own workqueue.

The only time detection is significantly slow (~2 seconds) is immediately
after a firmware update. This case isn't even handled using the detect
work, since the firmware update is now done through the request_firmware()
interface which blocks until the entire update plus detection has
completed.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:21047
TEST=cyapa detect occurs immediately during probe and completes within
300ms.

Change-Id: I1575f3a90f4df815737ea6656b5f10b9ee837d90
Reviewed-on: https://gerrit.chromium.org/gerrit/13534
Reviewed-by: Dudley Du <dudl@cypress.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: Input: cyapa - disable irq on suspend, enable on resume

Touchpad interrupts were left enabled after cyapa_suspend so cyapa_irq
would still service interrupts and attempt to do block reads well
into a suspend. Under some circumstances, the underlying i2c bus
(i801_smbus) would suspend, and the irq task would be hung trying to
do a block read of cyapa registers. We aren't interested in any
tp data after cyapa_suspend, so disable the interrupt and reenable
when cyapa is resumed.

Also, verified that this change does not affect trackpad wake
which is configured using enable_irq_wake.

BUG=chrome-os-partner:7634
TEST=move finger across pad while issuing powerd_suspend.
Ensure the system does not hang, and reboot due to a hung task.

Change-Id: I480931fb1d80e2bc98babde6d73091039bc924d0
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/14541
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: input: cyapa driver

Picking up driver for cyapa trackpad. It's still being reworked
for upstream inclusion, so this specific driver will be reverted
once we get the real driver from upstream. But until then we need
something to use with the hardware.

This patch contains squashed commits from chromeos-3.0 up to:
dd92a7f134f45e CHROMIUM: Input: cyapa - remove detect work

Change-Id: Ibe8c0eaf54dfa13cfa35bd8741060c0321385ec0
Signed-off-by: Olof Johansson <olofj@chromium.org>
BUG=None
TEST=Build with the board part and config change, boot board, see trackpad work

Conflicts:

drivers/input/mouse/Kconfig

[anush: fixup for 3.4]
Signed-off-by: Anush Elangovan <anush@chromium.org>

CHROMIUM: INPUT: atmel_mxt_ts - Increase the wait times for backup and reset

Increase the sleep times after backup and reset, so that we can be sure they have been completed even when the mXT cycle time is set to maximum value (254ms).

Signed-off-by: Iiro Valkonen <iiro.valkonen@atmel.com>
Patch is in progress of being submitted at http://www.spinics.net/lists/linux-input/msg14593.html
Signed-off-by: Jon Kliegman <kliegs@chromium.org>
R=olofj@chromium.org, msb@chromium.org
BUG=chromium-os:13514
TEST=Built kernel
Validated kernel boots fine
Validated in conjunction with other CLs in bug that the driver works

Cherrypicking forward to 3.0 branch from 2.6.38
(cherry picked from commit 1ebffd5d7df2202b20eee3c906096ff7f1d6c56a)

Cherrypicking forward to 2.6.38 branch from http://codereview.chromium.org/6711073
(cherry picked from commit 4dc5fe662e1352e12181ba4cfeb0f8333486c882)

Review URL: http://codereview.chromium.org/6893098
Patch from Iiro Valkonen <iiro.valkonen@atmel.com>.

Change-Id: I487c75fd05d5eb7b6223b5a3b79d34076d096726
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8773

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>