Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
d184d60a |
| 19-Apr-2023 |
Zhengkang Huang <zkhuang@hust.edu.cn> |
platform/chrome: wilco_ec: remove return value check of debugfs_create_dir()
Smatch complains that: wilco_ec_debugfs_probe() warn: 'debug_info->dir' is an error pointer or valid
Debugfs checks are
platform/chrome: wilco_ec: remove return value check of debugfs_create_dir()
Smatch complains that: wilco_ec_debugfs_probe() warn: 'debug_info->dir' is an error pointer or valid
Debugfs checks are generally not supposed to be checked for errors and it is not necessary here.
Just delete the dead code.
Signed-off-by: Zhengkang Huang <zkhuang@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230419100303.343379-1-zkhuang@hust.edu.cn
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31 |
|
#
ad35da94 |
| 02-Apr-2020 |
Bernardo Perez Priego <bernardo.perez.priego@intel.com> |
platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file
Function 'h1_gpio_get' is receiving 'val' parameter of type u64, this is being passed to 'send_ec_cmd' as type u8, thus, re
platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file
Function 'h1_gpio_get' is receiving 'val' parameter of type u64, this is being passed to 'send_ec_cmd' as type u8, thus, result is stored in least significant byte. Due to output format, the whole 'val' value was being displayed when any of the most significant bytes are different than zero.
This fix will make sure only least significant byte is displayed regardless of remaining bytes value.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2 |
|
#
e6679fd1 |
| 24-Sep-2019 |
Daniel Campello <campello@chromium.org> |
platform/chrome: wilco_ec: Add debugfs test_event file
This change introduces a new debugfs file 'test_event' that when written to causes the EC to generate a test event. This adds a second sub cmd
platform/chrome: wilco_ec: Add debugfs test_event file
This change introduces a new debugfs file 'test_event' that when written to causes the EC to generate a test event. This adds a second sub cmd for the test event, and pulls out send_ec_cmd to be a common helper between h1_gpio_get and test_event_set.
Signed-off-by: Daniel Campello <campello@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
1210d1e6 |
| 21-May-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add telemetry char device interface
The Wilco Embedded Controller is able to send telemetry data which is useful for enterprise applications. A daemon running on the OS se
platform/chrome: wilco_ec: Add telemetry char device interface
The Wilco Embedded Controller is able to send telemetry data which is useful for enterprise applications. A daemon running on the OS sends a command to the EC via a write() to a char device, and can read the response with a read(). The write() request is verified by the driver to ensure that it is performing only one of the whitelisted commands, and that no extraneous data is being transmitted to the EC. The response is passed directly back to the reader with no modification.
The character device will appear as /dev/wilco_telemN, where N is some small non-negative integer, starting with 0. Only one process may have the file descriptor open at a time. The calling userspace program needs to keep the device file descriptor open between the calls to write() and read() in order to preserve the response. Up to 32 bytes will be available for reading.
For testing purposes, try requesting the EC's firmware build date, by sending the WILCO_EC_TELEM_GET_VERSION command with argument index=3. i.e. write [0x38, 0x00, 0x03] to the device node. An ASCII string of the build date is returned.
Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1 |
|
#
2ad1f7a9 |
| 08-May-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Remove 256 byte transfers
The 0xF6 command, intended to send and receive 256 byte payloads to and from the EC, is not needed. The 0xF5 command for 32 byte payloads is suff
platform/chrome: wilco_ec: Remove 256 byte transfers
The 0xF6 command, intended to send and receive 256 byte payloads to and from the EC, is not needed. The 0xF5 command for 32 byte payloads is sufficient. This patch removes support for the 0xF6 command and 256 byte payloads.
Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
9e2b0e0b |
| 12-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add h1_gpio status to debugfs
As part of Chrome OS's FAFT (Fully Automated Firmware Testing) tests, we need to ensure that the H1 chip is properly setting some GPIO lines.
platform/chrome: wilco_ec: Add h1_gpio status to debugfs
As part of Chrome OS's FAFT (Fully Automated Firmware Testing) tests, we need to ensure that the H1 chip is properly setting some GPIO lines. The h1_gpio attribute exposes the state of the lines: - ENTRY_TO_FACT_MODE in BIT(0) - SPI_CHROME_SEL in BIT(1)
There are two reasons that I am exposing this in debugfs, and not as a GPIO: 1. This is only useful for testing, so end users shouldn't ever care about this. In fact, if it passes the tests, then the value of h1_gpio will always be 2, so it would be really uninteresting for users. 2. This GPIO is not connected to, controlled by, or really even related to the AP. The GPIO runs between the EC and the H1 security chip.
Changes in v4: - Use "0x02x\n" instead of "02x\n" for format string - Use DEFINE_DEBUGFS_ATTRIBUTE() - Add documentation Changes in v3: - Fix documentation to correspond with formatting change in v2. Changes in v2: - Zero out the unused fields in the request. - Format result as "%02x\n" instead of as a decimal.
Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.7 |
|
#
14e14aaf |
| 04-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure, with a c
platform/chrome: wilco_ec: Standardize mailbox interface
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure, with a command byte in MBOX[0], followed by a junk byte, followed by actual data. This doesn't happen in several cases, such as setting the RTC time, using the raw debugfs interface, and reading or writing properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface assumes that the first byte of data is always 0, and the second byte is unused. However, in both setting and getting the RTC time, in the debugfs interface, and for reading and writing properties, this isn't true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to specify when and when not to skip these initial bytes in the sent and received message. They are confusing and used so much that they are normal, and not exceptions. In addition, the first byte of response in the debugfs interface is still always skipped, which is weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so struct wilco_ec_message contains the "command" field. In setting or getting properties however, the first byte is not a command, and so this field has to be filled with a byte that isn't actually a command. This is again inconsistent.
wilco_ec_message contains a result field as well, copied from wilco_ec_response->result. The message result field should be removed: if the message fails, the cause is already logged, and the callers are alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function, used in wilco_ec_mailbox(), really gross, dealing with a bunch of different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make it so that the messages do not correspond well with the specification for the EC's mailbox interface. For instance, this interface specification may say that MBOX[9] in the received message contains some information, but the calling code needs to remember that the first byte of response is always skipped, and because it didn't set the RESPONSE_RAW flag, the next byte is also skipped, so this information is actually contained within wilco_ec_message->response_data[7]. This makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by: - Removing the WILCO_EC_FLAG_RAW* flags - Removing the command and reserved_raw bytes from wilco_ec_request - Removing the mbox0 byte from wilco_ec_response - Simplifying wilco_ec_transfer() because of these changes - Gives the callers of wilco_ec_mailbox() the responsibility of exactly and consistently defining the structure of the mailbox request and response - Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21 |
|
#
b787bb12 |
| 08-Feb-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add support for raw commands in debugfs
Add a debugfs attribute that allows sending raw commands to the EC. This is useful for development and debug but should not be enab
platform/chrome: wilco_ec: Add support for raw commands in debugfs
Add a debugfs attribute that allows sending raw commands to the EC. This is useful for development and debug but should not be enabled in a production environment.
To test: Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18.......
Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18.......
Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> [Fix off-by-one error in wilco_ec/debugfs.c] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31 |
|
#
ad35da94 |
| 02-Apr-2020 |
Bernardo Perez Priego <bernardo.perez.priego@intel.com> |
platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file Function 'h1_gpio_get' is receiving 'val' parameter of type u64, this is being passed to 'send_ec_cmd' as type
platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file Function 'h1_gpio_get' is receiving 'val' parameter of type u64, this is being passed to 'send_ec_cmd' as type u8, thus, result is stored in least significant byte. Due to output format, the whole 'val' value was being displayed when any of the most significant bytes are different than zero. This fix will make sure only least significant byte is displayed regardless of remaining bytes value. Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2 |
|
#
e6679fd1 |
| 24-Sep-2019 |
Daniel Campello <campello@chromium.org> |
platform/chrome: wilco_ec: Add debugfs test_event file This change introduces a new debugfs file 'test_event' that when written to causes the EC to generate a test event. This adds a
platform/chrome: wilco_ec: Add debugfs test_event file This change introduces a new debugfs file 'test_event' that when written to causes the EC to generate a test event. This adds a second sub cmd for the test event, and pulls out send_ec_cmd to be a common helper between h1_gpio_get and test_event_set. Signed-off-by: Daniel Campello <campello@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
1210d1e6 |
| 21-May-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add telemetry char device interface The Wilco Embedded Controller is able to send telemetry data which is useful for enterprise applications. A daemon running
platform/chrome: wilco_ec: Add telemetry char device interface The Wilco Embedded Controller is able to send telemetry data which is useful for enterprise applications. A daemon running on the OS sends a command to the EC via a write() to a char device, and can read the response with a read(). The write() request is verified by the driver to ensure that it is performing only one of the whitelisted commands, and that no extraneous data is being transmitted to the EC. The response is passed directly back to the reader with no modification. The character device will appear as /dev/wilco_telemN, where N is some small non-negative integer, starting with 0. Only one process may have the file descriptor open at a time. The calling userspace program needs to keep the device file descriptor open between the calls to write() and read() in order to preserve the response. Up to 32 bytes will be available for reading. For testing purposes, try requesting the EC's firmware build date, by sending the WILCO_EC_TELEM_GET_VERSION command with argument index=3. i.e. write [0x38, 0x00, 0x03] to the device node. An ASCII string of the build date is returned. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1 |
|
#
2ad1f7a9 |
| 08-May-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Remove 256 byte transfers The 0xF6 command, intended to send and receive 256 byte payloads to and from the EC, is not needed. The 0xF5 command for 32 byte
platform/chrome: wilco_ec: Remove 256 byte transfers The 0xF6 command, intended to send and receive 256 byte payloads to and from the EC, is not needed. The 0xF5 command for 32 byte payloads is sufficient. This patch removes support for the 0xF6 command and 256 byte payloads. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
9e2b0e0b |
| 12-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add h1_gpio status to debugfs As part of Chrome OS's FAFT (Fully Automated Firmware Testing) tests, we need to ensure that the H1 chip is properly setting
platform/chrome: wilco_ec: Add h1_gpio status to debugfs As part of Chrome OS's FAFT (Fully Automated Firmware Testing) tests, we need to ensure that the H1 chip is properly setting some GPIO lines. The h1_gpio attribute exposes the state of the lines: - ENTRY_TO_FACT_MODE in BIT(0) - SPI_CHROME_SEL in BIT(1) There are two reasons that I am exposing this in debugfs, and not as a GPIO: 1. This is only useful for testing, so end users shouldn't ever care about this. In fact, if it passes the tests, then the value of h1_gpio will always be 2, so it would be really uninteresting for users. 2. This GPIO is not connected to, controlled by, or really even related to the AP. The GPIO runs between the EC and the H1 security chip. Changes in v4: - Use "0x02x\n" instead of "02x\n" for format string - Use DEFINE_DEBUGFS_ATTRIBUTE() - Add documentation Changes in v3: - Fix documentation to correspond with formatting change in v2. Changes in v2: - Zero out the unused fields in the request. - Format result as "%02x\n" instead of as a decimal. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.7 |
|
#
14e14aaf |
| 04-Apr-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Standardize mailbox interface The current API for the wilco EC mailbox interface is bad. It assumes that most messages sent to the EC follow a similar str
platform/chrome: wilco_ec: Standardize mailbox interface The current API for the wilco EC mailbox interface is bad. It assumes that most messages sent to the EC follow a similar structure, with a command byte in MBOX[0], followed by a junk byte, followed by actual data. This doesn't happen in several cases, such as setting the RTC time, using the raw debugfs interface, and reading or writing properties such as the Peak Shift policy (this last to be submitted soon). Similarly for the response message from the EC, the current interface assumes that the first byte of data is always 0, and the second byte is unused. However, in both setting and getting the RTC time, in the debugfs interface, and for reading and writing properties, this isn't true. The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to specify when and when not to skip these initial bytes in the sent and received message. They are confusing and used so much that they are normal, and not exceptions. In addition, the first byte of response in the debugfs interface is still always skipped, which is weird, since this raw interface should be giving the entire result. Additionally, sent messages assume the first byte is a command, and so struct wilco_ec_message contains the "command" field. In setting or getting properties however, the first byte is not a command, and so this field has to be filled with a byte that isn't actually a command. This is again inconsistent. wilco_ec_message contains a result field as well, copied from wilco_ec_response->result. The message result field should be removed: if the message fails, the cause is already logged, and the callers are alerted. They will never care about the actual state of the result flag. These flags and different cases make the wilco_ec_transfer() function, used in wilco_ec_mailbox(), really gross, dealing with a bunch of different cases. It's difficult to figure out what it is doing. Finally, making these assumptions about the structure of a message make it so that the messages do not correspond well with the specification for the EC's mailbox interface. For instance, this interface specification may say that MBOX[9] in the received message contains some information, but the calling code needs to remember that the first byte of response is always skipped, and because it didn't set the RESPONSE_RAW flag, the next byte is also skipped, so this information is actually contained within wilco_ec_message->response_data[7]. This makes it difficult to maintain this code in the future. To fix these problems this patch standardizes the mailbox interface by: - Removing the WILCO_EC_FLAG_RAW* flags - Removing the command and reserved_raw bytes from wilco_ec_request - Removing the mbox0 byte from wilco_ec_response - Simplifying wilco_ec_transfer() because of these changes - Gives the callers of wilco_ec_mailbox() the responsibility of exactly and consistently defining the structure of the mailbox request and response - Removing command and result from wilco_ec_message. This results in the reduction of total code, and makes it much more maintainable and understandable. Signed-off-by: Nick Crews <ncrews@chromium.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|
Revision tags: v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21 |
|
#
b787bb12 |
| 08-Feb-2019 |
Nick Crews <ncrews@chromium.org> |
platform/chrome: wilco_ec: Add support for raw commands in debugfs Add a debugfs attribute that allows sending raw commands to the EC. This is useful for development and debug but should
platform/chrome: wilco_ec: Add support for raw commands in debugfs Add a debugfs attribute that allows sending raw commands to the EC. This is useful for development and debug but should not be enabled in a production environment. To test: Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18....... Get the EC firmware build date First send the request command > echo 00 f0 38 00 03 00 > raw Then read the result. "12/21/18" is in the middle of the response > cat raw 00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18....... Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> [Fix off-by-one error in wilco_ec/debugfs.c] Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
show more ...
|