kernel/linux.git/drivers/platform/chrome, branch v5.10.78

platform/chrome: cros_ec_trace: Fix format warnings

2021-09-26T12:08:58+00:00

[ Upstream commit 4665584888ad2175831c972c004115741ec799e9 ] Fix printf format issues in new tracing events. Fixes: 814318242687 ("platform/chrome: cros_ec_trace: Add fields to command traces") Signed-off-by: Gwendal Grignou Link: https://lore.kernel.org/r/20210830180050.2077261-1-gwendal@chromium.org Signed-off-by: Benson Leung Signed-off-by: Sasha Levin

platform/chrome: sensorhub: Add trace events for sample

2021-09-26T12:08:58+00:00

[ Upstream commit d453ceb6549af8798913de6a20444cb7200fdb69 ] Add trace event to report samples and their timestamp coming from the EC. It allows to check if the timestamps are correct and the filter is working correctly without introducing too much latency. To enable these events: cd /sys/kernel/debug/tracing/ echo 1 > events/cros_ec/enable echo 0 > events/cros_ec/cros_ec_request_start/enable echo 0 > events/cros_ec/cros_ec_request_done/enable echo 1 > tracing_on cat trace_pipe Observe event flowing: irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ... irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ... Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin

platform/chrome: cros_ec_proto: Send command again when timeout occurs

2021-09-18T11:40:37+00:00

commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream. Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: # 4.4+ Signed-off-by: Patryk Duda Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung Signed-off-by: Greg Kroah-Hartman

platform/chrome: cros_ec_typec: Add DP mode check

2021-05-22T09:40:53+00:00

[ Upstream commit c5bb32f57bf3a30ed03be51f7be0840325ba8b4a ] There are certain transitional situations where the dp_mode field in the PD_CONTROL response might not be populated with the right DP pin assignment value yet. Add a check for that to avoid sending an invalid value to the Type C mode switch. Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20210421042108.2002-1-pmalani@chromium.org Signed-off-by: Sasha Levin

platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask

2021-03-04T10:37:58+00:00

[ Upstream commit 852405d8efcbca0e02f14592fb1d1dcd0d3fb508 ] After 'platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT' some of the flags are not quite correct. LID_CLOSED is used to suspend the device, so it makes sense to ignore that. BATTERY events are also frequent and causing spurious wakes on elm/hana mt8173 devices. Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn Reviewed-by: Brian Norris Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201209220306.2.I3291bf83e4884c206b097ede34780e014fa3e265@changeid Signed-off-by: Sasha Levin

platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT

2021-03-04T10:37:58+00:00

[ Upstream commit 0944ea07baa748741563c8842122010fa9017d16 ] The host_event_code enum is 1-based, use EC_HOST_EVENT_MASK not BIT to generate the intended mask. This patch changes the behaviour of the mask, a following patch will restore the intended behaviour: 'Add LID and BATTERY to default mask' Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn Reviewed-by: Brian Norris Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201209220306.1.I6133572c0ab3c6b95426f804bac2d3833e24acb1@changeid Signed-off-by: Sasha Levin

platform/chrome: cros_ec_spi: Don't overwrite spi::mode

2020-12-30T10:53:45+00:00

[ Upstream commit 74639cbf51d7c0304342544a83dfda354a6bd208 ] There isn't any need to overwrite the mode here in the driver with what has been detected by the firmware, such as DT or ACPI. In fact, if we use the SPI CS gpio descriptor feature we will overwrite the mode with SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle when the device is probed when it shouldn't change, confusing the driver and making it fail to probe. Drop the assignment and let the spi core take care of it. Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver") Cc: Simon Glass Cc: Gwendal Grignou Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Acked-by: Enric Balletbo i Serra Cc: Alexandru M Stan Signed-off-by: Stephen Boyd Reviewed-by: Simon Glass Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

platform/chrome: Use kobj_to_dev() instead of container_of()

2020-09-29T08:08:44+00:00

Use kobj_to_dev() instead of container_of(). Signed-off-by: Wang Qing Reviewed-by: Guenter Roeck Signed-off-by: Enric Balletbo i Serra

platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer()

2020-09-21T08:51:58+00:00

Since cros_ec_cmd_xfer_status() now returns Linux error codes and all other files use that command, remove the now-unused function cros_ec_cmd_xfer(). Signed-off-by: Prashant Malani Signed-off-by: Enric Balletbo i Serra

platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites

2020-09-21T08:51:58+00:00

Since all the other call-sites of cros_ec_cmd_xfer() have been converted to use cros_ec_cmd_xfer_status() instead, update the remaining call-sites to prepare for the merge of cros_ec_cmd_xfer() into cros_ec_cmd_xfer_status(). As part of this update, change the error handling inside cros_ec_get_sensor_count() such that the legacy LPC interface is tried on all error values, not just when msg->result != EC_RESULT_SUCCESS. Note that there is a slight change in API in cros_ec_get_sensor_count(): it will return a negative number of sensors when there are no sensors on arm platform when MOTIONSENSE_CMD_DUMP is not supported (typical for sensorless chromebook) instead of 0. However, this is not a problem when probing the EC as we ignore errors only looking for cros_ec_get_sensor_count() returning a positive number of sensors. Signed-off-by: Prashant Malani Reviewed-by: Gwendal Grignou Tested-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra