kernel/linux.git/drivers/platform/chrome/Makefile, branch v5.19

platform/chrome: Add ChromeOS ACPI device driver

2022-05-13T11:42:30+00:00

The x86 Chromebooks have the ChromeOS ACPI device. This driver attaches to the ChromeOS ACPI device and exports the values reported by ACPI in a sysfs directory. This data isn't present in ACPI tables when read through ACPI tools, hence a driver is needed to do it. The driver gets data from firmware using the ACPI component of the kernel. The ACPI values are presented in string form (numbers as decimal values) or binary blobs, and can be accessed as the contents of the appropriate read only files in the standard ACPI device's sysfs directory tree. This data is consumed by the ChromeOS user space. Reviewed-by: Guenter Roeck Reviewed-by: Andy Shevchenko Reviewed-by: Greg Kroah-Hartman Acked-by: Rafael J. Wysocki Signed-off-by: Enric Balletbo i Serra Co-developed-by: Muhammad Usama Anjum Signed-off-by: Muhammad Usama Anjum Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/Yn4OKYrtV35Dv+nd@debian-BULLSEYE-live-builder-AMD64

Merge tag 'tag-chrome-platform-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux

2022-04-02T17:44:18+00:00

Pull chrome platform updates from Benson Leung: "cros_ec_typec: - Check for EC device - Fix a crash when using the cros_ec_typec driver on older hardware not capable of typec commands - Make try power role optional - Mux configuration reorganization series from Prashant cros_ec_debugfs: - Fix use after free. Thanks Tzung-bi sensorhub: - cros_ec_sensorhub fixup - Split trace include file misc: - Add new mailing list for chrome-platform development: chrome-platform@lists.linux.dev Now with patchwork!" * tag 'tag-chrome-platform-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_debugfs: detach log reader wq from devm platform: chrome: Split trace include file platform/chrome: cros_ec_typec: Update mux flags during partner removal platform/chrome: cros_ec_typec: Configure muxes at start of port update platform/chrome: cros_ec_typec: Get mux state inside configure_mux platform/chrome: cros_ec_typec: Move mux flag checks platform/chrome: cros_ec_typec: Check for EC device platform/chrome: cros_ec_typec: Make try power role optional MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list

platform: chrome: Split trace include file

2022-03-31T23:56:29+00:00

cros_ec_trace.h defined 5 tracing events, 2 for cros_ec_proto and 3 for cros_ec_sensorhub_ring. These 2 files are in different kernel modules, the traces are defined twice in the kernel which leads to problem enabling only some traces. Move sensorhub traces from cros_ec_trace.h to cros_ec_sensorhub_trace.h and enable them only in cros_ec_sensorhub kernel module. Check we can now enable any single traces: without this patch, we can only enable all sensorhub traces or none. Fixes: d453ceb6549a ("platform/chrome: sensorhub: Add trace events for sample") Signed-off-by: Gwendal Grignou Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220122001301.640337-1-gwendal@chromium.org Signed-off-by: Benson Leung

platform/chrome: Add driver for ChromeOS privacy-screen

2022-01-10T11:17:37+00:00

This adds the ACPI driver for the ChromeOS privacy screen that is present on some chromeos devices. Note that ideally, we'd want this privacy screen driver to be probed BEFORE the drm probe in order to avoid a drm probe deferral: https://hansdegoede.livejournal.com/25948.html In practise, I found that ACPI drivers are bound to their devices AFTER the drm probe on chromebooks. So on chromebooks with privacy-screen, this patch along with the other one in this series results in a probe deferral of about 250ms for i915 driver. However, it did not result in any user noticeable delay of splash screen in my personal experience. In future if this probe deferral turns out to be an issue, we can consider turning this ACPI driver into something that is probed earlier than the drm drivers. Signed-off-by: Rajat Jain Reviewed-by: Dmitry Torokhov Acked-by: Benson Leung Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20220107190208.95479-2-rajatja@google.com

platform/chrome: sensorhub: Add trace events for sample

2021-07-26T11:24:46+00:00

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

platform/chrome: cros_ec_sensorhub: Add FIFO support

2020-03-28T21:04:32+00:00

cros_ec_sensorhub registers a listener and query motion sense FIFO, spread to iio sensors registers. To test, we can use libiio: iiod& iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x Signed-off-by: Gwendal Grignou Reviewed-by: Jonathan Cameron Acked-by: Andy Shevchenko Signed-off-by: Enric Balletbo i Serra

platform/chrome: Add Type C connector class driver

2020-03-22T10:11:26+00:00

Add a driver to implement the Type C connector class for Chrome OS devices with ECs (Embedded Controllers). The driver relies on firmware device specifications for various port attributes. On ACPI platforms, this is specified using the logical device with HID GOOG0014. On DT platforms, this is specified using the DT node with compatible string "google,cros-ec-typec". The driver reads the device FW node and uses the port attributes to register the typec ports with the Type C connector class framework, but doesn't do much else. Subsequent patches will add more functionality to the driver, including obtaining current port information (polarity, vconn role, current power role etc.) after querying the EC. Co-developed-by: Benson Leung Signed-off-by: Prashant Malani Reviewed-by: Heikki Krogerus Signed-off-by: Enric Balletbo i Serra

platform: chrome: Add cros-usbpd-notify driver

2020-02-10T18:14:19+00:00

ChromiumOS uses ACPI device with HID "GOOG0003" for power delivery related events. The existing cros-usbpd-charger driver relies on these events without ever actually receiving them on ACPI platforms. This is because in the ChromeOS kernel trees, the GOOG0003 device is owned by an ACPI driver that offers firmware updates to USB-C chargers. Introduce a new platform driver under cros-ec, the ChromeOS embedded controller, that handles these PD events and dispatches them appropriately over a notifier chain to all drivers that use them. On platforms that don't have the ACPI device defined, the driver gets instantiated for ECs which support the EC_FEATURE_USB_PD feature bit, and the notification events will get delivered using the MKBP event handling mechanism. Co-Developed-by: Prashant Malani Reviewed-by: Gwendal Grignou Reviewed-by: Benson Leung Signed-off-by: Jon Flatley Signed-off-by: Prashant Malani Acked-By: Enric Balletbo i Serra Signed-off-by: Benson Leung

iio / platform: cros_ec: Add cros-ec-sensorhub driver

2019-11-21T10:23:14+00:00

Similar to HID sensor stack, the new driver sits between cros-ec-dev and the IIO device drivers: The EC based IIO device topology would be: iio:device1 -> ...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/ cros-ec-sensorhub.7.auto/ cros-ec-accel.15.auto/ iio:device1 It will be expanded to control EC sensor FIFO. Signed-off-by: Gwendal Grignou Reviewed-by: Jonathan Cameron [Fix "unknown type name 'uint32_t'" type errors] Reported-by: kbuild test robot Signed-off-by: Enric Balletbo i Serra

mfd / platform: cros_ec: Miscellaneous character device to talk with the EC

2019-09-02T10:33:21+00:00

That's a driver to talk with the ChromeOS Embedded Controller via a miscellaneous character device, it creates an entry in /dev for every instance and implements basic file operations for communicating with the Embedded Controller with an userspace application. The API is moved to the uapi folder, which is supposed to contain the user space API of the kernel. Note that this will replace current character device interface implemented in the cros-ec-dev driver in the MFD subsystem. The idea is to move all the functionality that extends the bounds of what MFD was designed to platform/chrome subsystem. Signed-off-by: Enric Balletbo i Serra Acked-by: Andy Shevchenko Reviewed-by: Gwendal Grignou Tested-by: Gwendal Grignou Signed-off-by: Lee Jones