kernel/linux.git/drivers/platform/chrome, branch v4.17.1

mfd: cros_ec: Retry commands when EC is known to be busy

2018-05-23T05:59:00+00:00

Commit 001dde9400d5 ("mfd: cros ec: spi: Fix "in progress" error signaling") pointed out some bad code, but its analysis and conclusion was not 100% correct. It *is* correct that we should not propagate result==EC_RES_IN_PROGRESS for transport errors, because this has a special meaning -- that we should follow up with EC_CMD_GET_COMMS_STATUS until the EC is no longer busy. This is definitely the wrong thing for many commands, because among other problems, EC_CMD_GET_COMMS_STATUS doesn't actually retrieve any RX data from the EC, so commands that expected some data back will instead start processing junk. For such commands, the right answer is to either propagate the error (and return that error to the caller) or resend the original command (*not* EC_CMD_GET_COMMS_STATUS). Unfortunately, commit 001dde9400d5 forgets a crucial point: that for some long-running operations, the EC physically cannot respond to commands any more. For example, with EC_CMD_FLASH_ERASE, the EC may be re-flashing its own code regions, so it can't respond to SPI interrupts. Instead, the EC prepares us ahead of time for being busy for a "long" time, and fills its hardware buffer with EC_SPI_PAST_END. Thus, we expect to see several "transport" errors (or, messages filled with EC_SPI_PAST_END). So we should really translate that to a retryable error (-EAGAIN) and continue sending EC_CMD_GET_COMMS_STATUS until we get a ready status. IOW, it is actually important to treat some of these "junk" values as retryable errors. Together with commit 001dde9400d5, this resolves bugs like the following: 1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400d5, we would abort the first time we saw EC_SPI_PAST_END) 2. Before commit 001dde9400d5, transport errors (e.g., EC_SPI_RX_BAD_DATA) seen in other commands (e.g., EC_CMD_RTC_GET_VALUE) used to yield junk data in the RX buffer; they will now yield -EAGAIN return values, and tools like 'hwclock' will simply fail instead of retrieving and re-programming undefined time values Fixes: 001dde9400d5 ("mfd: cros ec: spi: Fix "in progress" error signaling") Signed-off-by: Brian Norris Signed-off-by: Lee Jones

Merge remote-tracking branch 'origin/ib-chrome-platform-cros-ec-sysfs-debugfs-for-v4.17' into working-branch-for-4.17

2018-04-11T05:30:34+00:00

Merging Enric's cros-ec sysfs and debugfs fixes from immutable branch. Signed-off-by: Benson Leung

platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid angle

2018-04-11T05:25:07+00:00

This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle) used to set and get the keyboard wake lid angle. This attribute is present only if 2 accelerometers are controlled by the EC. This patch also moves the cros_ec features check before the device is added so the features map obtained from the EC is ready on time. Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Reviewed-by: Andy Shevchenko Acked-by: Lee Jones Signed-off-by: Benson Leung

platform/chrome: cros_ec_debugfs: Add PD port info to debugfs

2018-04-11T05:24:51+00:00

Add info useful for debugging USB-PD port state. Signed-off-by: Shawn Nematbakhsh Signed-off-by: Enric Balletbo i Serra Reviewed-by: Andy Shevchenko Acked-by: Lee Jones Signed-off-by: Benson Leung

platform/chrome: cros_ec_debugfs: Use octal permissions '0444'

2018-04-11T05:24:16+00:00

Fixed the following checkpatch warning: WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. Signed-off-by: Enric Balletbo i Serra Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Benson Leung

platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR variants

2018-04-11T05:23:48+00:00

Use DEVICE_ATTR variants for read/write attributes. This simplifies the source code, improves readbility, and reduces the chance of inconsistencies. Suggested-by: Andy Shevchenko Signed-off-by: Enric Balletbo i Serra Reviewed-by: Andy Shevchenko Signed-off-by: Benson Leung

platform/chrome: cros_ec_sysfs: introduce to_cros_ec_dev define.

2018-04-11T05:22:49+00:00

Add a define to get the cros_ec_dev from device and use it. Suggested-by: Andy Shevchenko Signed-off-by: Enric Balletbo i Serra Reviewed-by: Andy Shevchenko Signed-off-by: Benson Leung

platform/chrome: cros_ec_sysfs: Modify error handling

2018-04-11T05:22:34+00:00

When accessing a sysfs attribute, if the EC command fails, -EPROTO is now returned instead of an error message as it is unlikely an app is parsing the error message to do something meaningful. Also, this patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer() so an error message is printed in the syslog. Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Signed-off-by: Benson Leung

Merge remote-tracking branch 'chrome-platform-stop-being-a-platform-driver-plus-atmel_mxt_ts-for-v4.17' into working-branch-for-4.17

2018-04-10T06:00:04+00:00

platform/chrome: cros_ec_lpc: Add support for Google devices using custom coreboot firmware

2018-04-10T05:57:46+00:00

This patch adds generic device information to the DMI table of the cros_ec_lpc driver, needed for Chromebooks/boxes using a custom coreboot firmware. The DMI info would not contain "Google_*" as BIOS version string, instead the system vendor string would still be "GOOGLE", so this seems to be a reasonable match for every Chromebook/box running a custom firmware. Signed-off-by: Salvatore Bellizzi Signed-off-by: Vittorio Gambaletta Signed-off-by: Benson Leung