[PATCH v2 0/7] Second batch of cleanups for cros_ec

[Javier Martinez Canillas <javier.martinez@collabora.co.uk>]

This is a second batch of cleanups patches for the mfd cros_ec
driver and its subdevices drivers. The first batch of cleanups
was posted by Doug Anderson [0] and have already been merged.
The patches were picked from the ChromeOS 3.8 kernel and after
these no cleanups patches for cros_ec are left, only commits
that add cros ec support not yet available in mainline.

This is a second version of the patch series that addresses
issues pointed out by Doug Anderson and Lee Jones on v1 [1].

There is almost no functionality added on this series but the
idea is to reduce the delta between the mainline drivers and
the ones in the downstream Chrome OS 3.8 kernel so the missing
functionality can be added on top once these cleanups patches
are merged. The missing functionlity currently in mainline is:

- Chrome OS Embedded Controller userspace device interface
- Chrome OS Embedded Controller Low Pin Count (LPC) inteface
- Access to vboot context stored on a block device
- Access to vboot context stored on EC's nvram

The patches in this series are authored by different people
(all on cc) and consist of the following:

Andrew Bresticker (3):
  mfd: cros_ec: stop calling ->cmd_xfer() directly
  mfd: cros_ec: move locking into cros_ec_cmd_xfer
  mfd: cros_ec: wait for completion of commands that return IN_PROGRESS

Derek Basehore (1):
  i2c: i2c-cros-ec-tunnel: Set retries to 3

Doug Anderson (1):
  mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC

Todd Broch (2):
  mfd: cros_ec: Instantiate sub-devices from device tree
  Input: cros_ec_keyb: Optimize ghosting algorithm.

 drivers/i2c/busses/i2c-cros-ec-tunnel.c |  5 +-
 drivers/input/keyboard/cros_ec_keyb.c   | 94 ++++++++++++++++++---------------
 drivers/mfd/cros_ec.c                   | 78 ++++++++++++++++++++-------
 drivers/mfd/cros_ec_spi.c               | 20 ++++---
 include/linux/mfd/cros_ec.h             | 24 ++++++---
 5 files changed, 141 insertions(+), 80 deletions(-)

Patches #1, #2, #6 and #7 do not depend of others so they can be
merged independently but patches #3, #4 and #5 have to be merged
in that specific order since they depend on the previous one. 

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/6/16/681
[1]: http://comments.gmane.org/gmane.linux.drivers.i2c/19256