<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/platform/chrome/Makefile, branch v5.14</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>platform/chrome: cros_ec_sensorhub: Add FIFO support</title>
<updated>2020-03-28T21:04:32+00:00</updated>
<author>
<name>Gwendal Grignou</name>
<email>gwendal@chromium.org</email>
</author>
<published>2020-03-27T22:34:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=145d59baff5944b71551ac518d7fd7d377a9c820'/>
<id>145d59baff5944b71551ac518d7fd7d377a9c820</id>
<content type='text'>
cros_ec_sensorhub registers a listener and query motion sense FIFO,
spread to iio sensors registers.

To test, we can use libiio:
  iiod&amp;
  iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x

Signed-off-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cros_ec_sensorhub registers a listener and query motion sense FIFO,
spread to iio sensors registers.

To test, we can use libiio:
  iiod&amp;
  iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x

Signed-off-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: Add Type C connector class driver</title>
<updated>2020-03-22T10:11:26+00:00</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2020-03-16T09:00:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fdc6b21e2444290b69ac9ffa936bf583830dc0de'/>
<id>fdc6b21e2444290b69ac9ffa936bf583830dc0de</id>
<content type='text'>
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 &lt;bleung@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;bleung@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform: chrome: Add cros-usbpd-notify driver</title>
<updated>2020-02-10T18:14:19+00:00</updated>
<author>
<name>Jon Flatley</name>
<email>jflat@chromium.org</email>
</author>
<published>2020-01-24T23:18:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ec2daf6e33f9f9113ba085b6ff88592907b6f1ce'/>
<id>ec2daf6e33f9f9113ba085b6ff88592907b6f1ce</id>
<content type='text'>
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 &lt;pmalani@chromium.org&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Signed-off-by: Jon Flatley &lt;jflat@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Acked-By: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Signed-off-by: Benson Leung &lt;bleung@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;pmalani@chromium.org&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Signed-off-by: Jon Flatley &lt;jflat@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Acked-By: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Signed-off-by: Benson Leung &lt;bleung@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio / platform: cros_ec: Add cros-ec-sensorhub driver</title>
<updated>2019-11-21T10:23:14+00:00</updated>
<author>
<name>Gwendal Grignou</name>
<email>gwendal@chromium.org</email>
</author>
<published>2019-11-19T12:45:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=53067471188c4066fc393ab892d0a74482eac000'/>
<id>53067471188c4066fc393ab892d0a74482eac000</id>
<content type='text'>
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 -&gt;
   ...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 &lt;gwendal@chromium.org&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
[Fix "unknown type name 'uint32_t'" type errors]
Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 -&gt;
   ...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 &lt;gwendal@chromium.org&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
[Fix "unknown type name 'uint32_t'" type errors]
Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd / platform: cros_ec: Miscellaneous character device to talk with the EC</title>
<updated>2019-09-02T10:33:21+00:00</updated>
<author>
<name>Enric Balletbo i Serra</name>
<email>enric.balletbo@collabora.com</email>
</author>
<published>2019-09-02T09:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=eda2e30c6684d67288edb841c6125d48c608a242'/>
<id>eda2e30c6684d67288edb841c6125d48c608a242</id>
<content type='text'>
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 &lt;enric.balletbo@collabora.com&gt;
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Tested-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;enric.balletbo@collabora.com&gt;
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Tested-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mfd / platform: cros_ec: Move cros-ec core driver out from MFD</title>
<updated>2019-09-02T10:33:12+00:00</updated>
<author>
<name>Enric Balletbo i Serra</name>
<email>enric.balletbo@collabora.com</email>
</author>
<published>2019-09-02T09:53:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=47f11e0b40e97f373da4efbacee0a9526c816ed5'/>
<id>47f11e0b40e97f373da4efbacee0a9526c816ed5</id>
<content type='text'>
Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrome subsystem.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Acked-by: Mark Brown &lt;broonie@kernel.org&gt;
Acked-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Acked-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Tested-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrome subsystem.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Acked-by: Mark Brown &lt;broonie@kernel.org&gt;
Acked-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Acked-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Reviewed-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Tested-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime</title>
<updated>2019-06-20T10:00:32+00:00</updated>
<author>
<name>Enric Balletbo i Serra</name>
<email>enric.balletbo@collabora.com</email>
</author>
<published>2019-06-14T21:43:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=22c040fa21b604b9b3d88645e108fb2f0a74474b'/>
<id>22c040fa21b604b9b3d88645e108fb2f0a74474b</id>
<content type='text'>
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the same LPC bus is used, but the protocol is
a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
config is enabled. Currently, the kernel decides at compile-time whether
or not to use the MEC variant, and, when that kernel option is selected
it breaks the other boards. We would like a kind of runtime detection to
avoid this.

This patch adds that detection mechanism by probing the protocol at
runtime, first we assume that a MEC variant is connected, and if the
protocol fails it fallbacks to the regular EC. This adds a bit of
overload because we try to read twice on those LPC boards that doesn't
contain a MEC variant, but is a better solution than having to select the
EC variant at compile-time.

While here also fix the alignment in Kconfig file for this config option
replacing the spaces by tabs.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Reviewed-by: Ezequiel Garcia &lt;ezequiel@collabora.com&gt;
Tested-by: Nick Crews &lt;ncrews@chromium.org&gt;
Reviewed-by: Nick Crews &lt;ncrews@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the same LPC bus is used, but the protocol is
a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
config is enabled. Currently, the kernel decides at compile-time whether
or not to use the MEC variant, and, when that kernel option is selected
it breaks the other boards. We would like a kind of runtime detection to
avoid this.

This patch adds that detection mechanism by probing the protocol at
runtime, first we assume that a MEC variant is connected, and if the
protocol fails it fallbacks to the regular EC. This adds a bit of
overload because we try to read twice on those LPC boards that doesn't
contain a MEC variant, but is a better solution than having to select the
EC variant at compile-time.

While here also fix the alignment in Kconfig file for this config option
replacing the spaces by tabs.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Reviewed-by: Ezequiel Garcia &lt;ezequiel@collabora.com&gt;
Tested-by: Nick Crews &lt;ncrews@chromium.org&gt;
Reviewed-by: Nick Crews &lt;ncrews@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_lpc: Merge cros_ec_lpc and cros_ec_lpc_reg</title>
<updated>2019-06-20T09:53:52+00:00</updated>
<author>
<name>Enric Balletbo i Serra</name>
<email>enric.balletbo@collabora.com</email>
</author>
<published>2019-06-14T21:43:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4116fd25c5262e90427f9840e861a8553374a867'/>
<id>4116fd25c5262e90427f9840e861a8553374a867</id>
<content type='text'>
The cros_ec_lpc_reg files are only used by the cros_ec_lpc core and
there isn't logical separation between them. So, merge those files into
the cros_ec_lpc also allowing us to drop the header file used for the
interface between the two.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Reviewed-by: Nick Crews &lt;ncrews@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The cros_ec_lpc_reg files are only used by the cros_ec_lpc core and
there isn't logical separation between them. So, merge those files into
the cros_ec_lpc also allowing us to drop the header file used for the
interface between the two.

Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Reviewed-by: Nick Crews &lt;ncrews@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: Add ChromeOS EC ISHTP driver</title>
<updated>2019-05-20T08:18:10+00:00</updated>
<author>
<name>Rushikesh S Kadam</name>
<email>rushikesh.s.kadam@intel.com</email>
</author>
<published>2019-05-15T10:38:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=26a14267aff218c60b89007fdb44ca392ba6122c'/>
<id>26a14267aff218c60b89007fdb44ca392ba6122c</id>
<content type='text'>
This driver implements a slim layer to enable the ChromeOS
EC kernel stack (cros_ec) to communicate with ChromeOS EC
firmware running on the Intel Integrated Sensor Hub (ISH).

The driver registers a ChromeOS EC MFD device to connect
with cros_ec kernel stack (upper layer), and it registers a
client with the ISH Transport Protocol bus (lower layer) to
talk with the ISH firwmare. See description of the ISHTP
protocol at Documentation/hid/intel-ish-hid.txt

Signed-off-by: Rushikesh S Kadam &lt;rushikesh.s.kadam@intel.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Reviewed-by: Jett Rink &lt;jettrink@chromium.org&gt;
Tested-by: Jett Rink &lt;jettrink@chromium.org&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver implements a slim layer to enable the ChromeOS
EC kernel stack (cros_ec) to communicate with ChromeOS EC
firmware running on the Intel Integrated Sensor Hub (ISH).

The driver registers a ChromeOS EC MFD device to connect
with cros_ec kernel stack (upper layer), and it registers a
client with the ISH Transport Protocol bus (lower layer) to
talk with the ISH firwmare. See description of the ISHTP
protocol at Documentation/hid/intel-ish-hid.txt

Signed-off-by: Rushikesh S Kadam &lt;rushikesh.s.kadam@intel.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Reviewed-by: Jett Rink &lt;jettrink@chromium.org&gt;
Tested-by: Jett Rink &lt;jettrink@chromium.org&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_proto: Add trace event to trace EC commands</title>
<updated>2019-04-17T08:29:34+00:00</updated>
<author>
<name>Raul E Rangel</name>
<email>rrangel@chromium.org</email>
</author>
<published>2019-04-16T21:03:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=58a2109f6eb46b2952e2ce3fe776ce02c0c540dd'/>
<id>58a2109f6eb46b2952e2ce3fe776ce02c0c540dd</id>
<content type='text'>
This is useful to see which EC commands are being executed and when.

To enable:

    echo 1 &gt; /sys/kernel/debug/tracing/events/cros_ec/enable

Example:

    cros_ec_cmd: version: 0, command: EC_CMD_GET_VERSION
    cros_ec_cmd: version: 0, command: EC_CMD_GET_PROTOCOL_INFO
    cros_ec_cmd: version: 1, command: EC_CMD_GET_CMD_VERSIONS
    cros_ec_cmd: version: 1, command: EC_CMD_USB_PD_CONTROL

The list of current commands is generated using the following script:

    sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1),\\/p' include/linux/mfd/cros_ec_commands.h

Signed-off-by: Raul E Rangel &lt;rrangel@chromium.org&gt;
Reviewed-by: Ross Zwisler &lt;zwisler@google.com&gt;
Reviewed-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is useful to see which EC commands are being executed and when.

To enable:

    echo 1 &gt; /sys/kernel/debug/tracing/events/cros_ec/enable

Example:

    cros_ec_cmd: version: 0, command: EC_CMD_GET_VERSION
    cros_ec_cmd: version: 0, command: EC_CMD_GET_PROTOCOL_INFO
    cros_ec_cmd: version: 1, command: EC_CMD_GET_CMD_VERSIONS
    cros_ec_cmd: version: 1, command: EC_CMD_USB_PD_CONTROL

The list of current commands is generated using the following script:

    sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1),\\/p' include/linux/mfd/cros_ec_commands.h

Signed-off-by: Raul E Rangel &lt;rrangel@chromium.org&gt;
Reviewed-by: Ross Zwisler &lt;zwisler@google.com&gt;
Reviewed-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
