summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome/wilco_ec/event.c
AgeCommit message (Collapse)Author
2020-03-22platform/chrome: wilco_ec: event: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-06-25platform/chrome: wilco_ec: Add circular buffer as event queueNick Crews
The current implementation of the event queue both wastes space using a doubly linked list and isn't super obvious in how it behaves. This converts the queue to an actual circular buffer. The size of the queue is a tunable module parameter. This also fixes a few other things: - A memory leak that occurred when the ACPI device was removed, but the events were not freed from the queue. - Now kfree() the oldest event from outside all locks. - Add newline to logging messages. - Add helper macros to calculate size of events. - Remove unneeded lock around a check for dev_data->exist in hangup_device(). - Remove an unneeded null event pointer check in enqueue_events(). - Correct some comments. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-06-18platform/chrome: wilco_ec: Fix unreleased lock in event_read()Nick Crews
When copying an event to userspace failed, the event queue lock was never released. This fixes that. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-06-03platform/chrome: wilco_ec: Add event handlingNick Crews
The Wilco Embedded Controller can create custom events that are not handled as standard ACPI objects. These events can contain information about changes in EC controlled features, such as errors and events in the dock or display. For example, an event is triggered if the dock is plugged into a display incorrectly. These events are needed for telemetry and diagnostics reasons, and for possibly alerting the user. These events are triggered by the EC with an ACPI Notify(0x90), and then the BIOS reads the event buffer from EC RAM via an ACPI method. When the OS receives these events via ACPI, it passes them along to this driver. The events are put into a queue which can be read by a userspace daemon via a char device that implements read() and poll(). The event queue acts as a circular buffer of size 64, so if there are no userspace consumers the kernel will not run out of memory. The char device will appear at /dev/wilco_event{n}, where n is some small non-negative integer, starting from 0. Standard ACPI events such as the battery getting plugged/unplugged can also come through this path, but they are dealt with via other paths, and are ignored here. To test, you can tail the binary data with $ cat /dev/wilco_event0 | hexdump -ve '1/1 "%x\n"' and then create an event by plugging/unplugging the battery. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>