Changes in debugfs-wilco-ec

54a19b4d - docs: ABI: cleanup several ABI documents

Fri, 30 Oct 2020 07:40:50 +0000

docs: ABI: cleanup several ABI documentsThere are some ABI documents that, while they don't generateany warnings, they have issues when parsed by get_abi.pl scripton its output result.Address them, in order to provide a clean output.Reviewed-by: Tom Rix # for fpga-managerReviewed-By: Kajol Jain # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7Acked-by: Jonathan Cameron #for IIOAcked-by: Oded Gabbay # for HabanalabsAcked-by: Vaibhav Jain # for sysfs-bus-papr-pmemAcked-by: Cezary Rojewski # for catptAcked-by: Suzuki K Poulose Acked-by: Ilya Dryomov # for rbdAcked-by: Jonathan Corbet Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/5bc78e5b68ed1e9e39135173857cb2e753be868f.1604042072.git.mchehab+huawei@kernel.orgSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/Documentation/ABI/testing/debugfs-wilco-ec

2ad1f7a9 - platform/chrome: wilco_ec: Remove 256 byte transfers

Wed, 08 May 2019 21:38:09 +0000

platform/chrome: wilco_ec: Remove 256 byte transfersThe 0xF6 command, intended to send and receive 256 byte payloads toand from the EC, is not needed. The 0xF5 command for 32 bytepayloads is sufficient. This patch removes support for the 0xF6command and 256 byte payloads.Signed-off-by: Nick Crews Signed-off-by: Enric Balletbo i Serra List of files: /linux-6.15/Documentation/ABI/testing/debugfs-wilco-ec

9e2b0e0b - platform/chrome: wilco_ec: Add h1_gpio status to debugfs

Fri, 12 Apr 2019 18:14:43 +0000

platform/chrome: wilco_ec: Add h1_gpio status to debugfsAs part of Chrome OS's FAFT (Fully Automated Firmware Testing)tests, we need to ensure that the H1 chip is properly settingsome GPIO lines. The h1_gpio attribute exposes the stateof 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 evercare about this. In fact, if it passes the tests, then the value ofh1_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 relatedto 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 documentationChanges 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 Signed-off-by: Enric Balletbo i Serra List of files: /linux-6.15/Documentation/ABI/testing/debugfs-wilco-ec

14e14aaf - platform/chrome: wilco_ec: Standardize mailbox interface

Thu, 04 Apr 2019 22:54:15 +0000

platform/chrome: wilco_ec: Standardize mailbox interfaceThe 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 byactual data. This doesn't happen in several cases, such as setting theRTC time, using the raw debugfs interface, and reading or writingproperties such as the Peak Shift policy (this last to be submitted soon).Similarly for the response message from the EC, the current interfaceassumes that the first byte of data is always 0, and the second byteis unused. However, in both setting and getting the RTC time, in thedebugfs interface, and for reading and writing properties, this isn'ttrue.The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags tospecify when and when not to skip these initial bytes in the sent andreceived message. They are confusing and used so much that they arenormal, and not exceptions. In addition, the first byte ofresponse in the debugfs interface is still always skipped, which isweird, since this raw interface should be giving the entire result.Additionally, sent messages assume the first byte is a command, and sostruct wilco_ec_message contains the "command" field. In setting orgetting properties however, the first byte is not a command, and so thisfield has to be filled with a byte that isn't actually a command. Thisis again inconsistent.wilco_ec_message contains a result field as well, copied fromwilco_ec_response->result. The message result field should be removed:if the message fails, the cause is already logged, and the callers arealerted. 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 ofdifferent cases. It's difficult to figure out what it is doing.Finally, making these assumptions about the structure of a message makeit so that the messages do not correspond well with the specificationfor the EC's mailbox interface. For instance, this interfacespecification may say that MBOX[9] in the received message containssome information, but the calling code needs to remember that the firstbyte of response is always skipped, and because it didn't set theRESPONSE_RAW flag, the next byte is also skipped, so this informationis actually contained within wilco_ec_message->response_data[7]. Thismakes 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 moremaintainable and understandable.Signed-off-by: Nick Crews Acked-by: Alexandre Belloni Signed-off-by: Enric Balletbo i Serra List of files: /linux-6.15/Documentation/ABI/testing/debugfs-wilco-ec

b787bb12 - platform/chrome: wilco_ec: Add support for raw commands in debugfs

Sat, 09 Feb 2019 00:37:18 +0000

platform/chrome: wilco_ec: Add support for raw commands in debugfsAdd a debugfs attribute that allows sending raw commands to the EC.This is useful for development and debug but should not be enabledin a production environment.To test:Get the EC firmware build dateFirst send the request command> echo 00 f0 38 00 03 00 > rawThen read the result. "12/21/18" is in the middle of the response> cat raw00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18.......Get the EC firmware build dateFirst send the request command> echo 00 f0 38 00 03 00 > rawThen read the result. "12/21/18" is in the middle of the response> cat raw00 31 32 2f 32 31 2f 31 38 00 00 0f 01 00 01 00 .12/21/18.......Signed-off-by: Duncan Laurie Signed-off-by: Nick Crews [Fix off-by-one error in wilco_ec/debugfs.c]Reported-by: Dan Carpenter Signed-off-by: Enric Balletbo i Serra List of files: /linux-6.15/Documentation/ABI/testing/debugfs-wilco-ec