21 Apr, 2020
1 commit
-
commit f775ac78fcfc6bdc96bdda07029d11f2a5e84869 upstream.
Host event can be sent by remoteproc by any time, and
cros_ec_rpmsg_callback would be called after cros_ec_rpmsg_create_ept.
But the cros_ec_device is initialized after that, which cause host event
handler to use cros_ec_device that are not initialized properly yet.Fix this by don't schedule host event handler before cros_ec_register
returns. Instead, remember that we have a pending host event, and
schedule host event handler after cros_ec_register.Fixes: 71cddb7097e2 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.")
Signed-off-by: Pi-Hsun Shih
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Greg Kroah-Hartman
26 Jan, 2020
1 commit
-
[ Upstream commit 856a0a6e2d09d31fd8f00cc1fc6645196a509d56 ]
This is caused by dereferencing 'dev_data' after put_device() in
the telem_device_remove() function.
This patch just moves the put_device() down a bit to avoid this
issue.Fixes: 1210d1e6bad1 ("platform/chrome: wilco_ec: Add telemetry char device interface")
Signed-off-by: Wen Yang
Cc: Benson Leung
Cc: Enric Balletbo i Serra
Cc: Nick Crews
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Sasha Levin
20 Sep, 2019
1 commit
-
…ernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"CrOS EC / MFD Migration:
- Move cros_ec core driver from mfd into chrome platform.Wilco EC:
- Add batt_ppid_info command to Wilco telemetry driver.CrOS EC:
- cros_ec_rpmsg : Add support to inform EC of suspend/resume status
- cros_ec_rpmsg : Fix race condition on probe failed
- cros_ec_chardev : Add a poll handler to receive MKBP eventsMisc:
- bugfixes in cros_usbpd_logger and cros_ec_ishtp"* tag 'tag-chrome-platform-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_usbpd_logger: null check create_singlethread_workqueue
platform/chrome: cros_ec_chardev: Add a poll handler to receive MKBP events
platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed
platform/chrome: chromeos_tbmc: Report wake events
mfd: cros_ec: Use mfd_add_hotplug_devices() helper
mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices
mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs
mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper
mfd / platform: cros_ec: Reorganize platform and mfd includes
mfd / platform: cros_ec: Rename config to a better name
mfd: cros_ec: Switch to use the new cros-ec-chardev driver
mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
mfd / platform: cros_ec: Move cros-ec core driver out from MFD
mfd / platform: cros_ec: Handle chained ECs as platform devices
platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support
platform/chrome: chromeos_laptop: drop checks of NULL-safe functions
platform/chrome: wilco_ec: Add batt_ppid_info command to telemetry driver
15 Sep, 2019
1 commit
12 Sep, 2019
4 commits
-
In cros_usbpd_logger_probe the return value of
create_singlethread_workqueue may be null, it should be checked.Signed-off-by: Navid Emamdoost
Signed-off-by: Enric Balletbo i Serra -
Allow to poll on the cros_ec device to receive the MKBP events.
The /dev/cros_[ec|fp|..] file operations now implements the poll
operation. The userspace can now receive specific MKBP events by doing
the following:- Open the /dev/cros_XX file.
- Call the CROS_EC_DEV_IOCEVENTMASK ioctl with the bitmap of the MKBP
events it wishes to receive as argument.
- Poll on the file descriptor.
- When it gets POLLIN, do a read on the file descriptor, the first
queued event will be returned (using the struct
ec_response_get_next_event format: one byte of event type, then
the payload).The read() operation returns at most one event even if there are several
queued, and it might be truncated if the buffer is smaller than the
event (but the caller should know the maximum size of the events it is
reading).read() used to return the EC version string, it still does it when no
event mask or an empty event is set for backward compatibility (despite
nobody really using this feature).This will be used, for example, by the userspace daemon to receive and
treat the EC_MKBP_EVENT_FINGERPRINT sent by the FP MCU.Signed-off-by: Vincent Palatin
Signed-off-by: Enric Balletbo i Serra
Acked-by: Andy Shevchenko
Reviewed-by: Gwendal Grignou -
Since the rpmsg_endpoint is created before probe is called, it's
possible that a host event is received during cros_ec_register, and
there would be some pending work in the host_event_work workqueue while
cros_ec_register is called.If cros_ec_register fails, when the leftover work in host_event_work
run, the ec_dev from the drvdata of the rpdev could be already set to
NULL, causing kernel crash when trying to run cros_ec_get_next_event.Fix this by creating the rpmsg_endpoint by ourself, and when
cros_ec_register fails (or on remove), destroy the endpoint first (to
make sure there's no more new calls to cros_ec_rpmsg_callback), and then
cancel all works in the host_event_work workqueue.Cc: stable@vger.kernel.org
Fixes: 2de89fd98958 ("platform/chrome: cros_ec: Add EC host command support using rpmsg")
Signed-off-by: Pi-Hsun Shih
Signed-off-by: Enric Balletbo i Serra -
Mark chromeos_tbmc as wake capable and report wake events. This helps to
abort suspend on seeing a tablet mode switch event when kernel is
suspending. This also helps identifying if chromeos_tbmc is the wake
source.Signed-off-by: Ravi Chandra Sadineni
Signed-off-by: Enric Balletbo i Serra
07 Sep, 2019
1 commit
-
chrome-platform fixes for v5.3-rc6
Fixes:
1. platform/chrome: cros_ec_ishtp: fix crash during suspend
- Fixes a kernel crash during suspend/resume of cros_ec_ishtpSigned-off-by: Benson Leung
03 Sep, 2019
1 commit
-
…' into chrome-platform/for-next
Immutable branch between MFD, Extcon, HID, I2C, IIO, Input, Chrome, Power,
PWM, RTC and Sound to allow picking patches that depends on the series
that moves some code from the MFD subsystem to platform/chrome.Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
02 Sep, 2019
5 commits
-
There is a bit of mess between cros-ec mfd includes and platform
includes. For example, we have a linux/mfd/cros_ec.h include that
exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
we have a linux/mfd/cros_ec_commands.h file that is non related to the
multifunction device (in the sense that is not exporting any function of
the mfd device). This causes crossed includes between mfd and
platform/chrome subsystems and makes the code difficult to read, apart
from creating 'curious' situations where a platform/chrome driver includes
a linux/mfd/cros_ec.h file just to get the exported functions that are
implemented in another platform/chrome driver.In order to have a better separation on what the cros-ec multifunction
driver does and what the cros-ec core provides move and rework the
affected includes doing:- Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
- Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c
driver from include/linux/mfd/cros_ec.h to a new file
include/linux/platform_data/cros_ec_proto.h
- Update all the drivers with the new includes, so
- Drivers that only need to know about the protocol include
- linux/platform_data/cros_ec_proto.h
- linux/platform_data/cros_ec_commands.h
- Drivers that need to know about the cros-ec mfd device also include
- linux/mfd/cros_ec.hSigned-off-by: Enric Balletbo i Serra
Acked-by: Andy Shevchenko
Acked-by: Mark Brown
Acked-by: Wolfram Sang
Acked-by: Neil Armstrong
Acked-by: Alexandre Belloni
Acked-by: Jonathan Cameron
Acked-by: Benjamin Tissoires
Acked-by: Dmitry Torokhov
Acked-by: Sebastian Reichel
Acked-by: Chanwoo Choi
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Series changes: 3
- Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp)
Signed-off-by: Lee Jones -
The cros-ec-dev is a multifunction device that now doesn't implement any
chardev communication interface. MFD_CROS_EC_CHARDEV doesn't look
a good name to describe that device and can cause confusion. Hence
rename it to CROS_EC_DEV.Signed-off-by: Enric Balletbo i Serra
Acked-by: Andy Shevchenko
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Signed-off-by: Lee Jones -
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 -
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
Acked-by: Andy Shevchenko
Acked-by: Thierry Reding
Acked-by: Mark Brown
Acked-by: Wolfram Sang
Acked-by: Neil Armstrong
Acked-by: Alexandre Belloni
Acked-by: Jonathan Cameron
Acked-by: Benjamin Tissoires
Acked-by: Dmitry Torokhov
Acked-by: Sebastian Reichel
Acked-by: Chanwoo Choi
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Signed-off-by: Lee Jones -
An MFD is a device that contains several sub-devices (cells). For instance,
the ChromeOS EC fits in this description as usually contains a charger and
can have other devices with different functions like a Real-Time Clock,
an Audio codec, a Real-Time Clock, ...If you look at the driver, though, we're doing something odd. We have
two MFD cros-ec drivers where one of them (cros-ec-core) instantiates
another MFD driver as sub-driver (cros-ec-dev), and the latest
instantiates the different sub-devices (Real-Time Clock, Audio codec,
etc).MFD
------------------------------------------
cros-ec-core
|___ mfd-cellA (cros-ec-dev)
| |__ mfd-cell0
| |__ mfd-cell1
| |__ ...
|
|___ mfd-cellB (cros-ec-dev)
|__ mfd-cell0
|__ mfd-cell1
|__ ...The problem that was trying to solve is to describe some kind of topology for
the case where we have an EC (cros-ec) chained with another EC
(cros-pd). Apart from that this extends the bounds of what MFD was
designed to do we might be interested on have other kinds of topology that
can't be implemented in that way.Let's prepare the code to move the cros-ec-core part from MFD to
platform/chrome as this is clearly a platform specific thing non-related
to a MFD device.platform/chrome | MFD
------------------------------------------
|
cros-ec ________|___ cros-ec-dev
| |__ mfd-cell0
| |__ mfd-cell1
| |__ ...
|
cros-pd ________|___ cros-ec-dev
| |__ mfd-cell0
| |__ mfd-cell1
| |__ ...Signed-off-by: Enric Balletbo i Serra
Acked-by: Andy Shevchenko
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Signed-off-by: Lee Jones
27 Aug, 2019
1 commit
-
Add EC host command to inform EC of AP suspend/resume status.
Signed-off-by: Yilun Lin
Tested-by: Pi-Hsun Shih
Signed-off-by: Enric Balletbo i Serra
26 Aug, 2019
1 commit
-
No need to check the argument of i2c_unregister_device() and
property_entries_free() because the functions do check it.Signed-off-by: Wolfram Sang
Signed-off-by: Enric Balletbo i Serra
23 Aug, 2019
1 commit
-
Add the GET_BATT_PPID_INFO=0x8A command to the allowlist of accepted
telemetry commands. In addition, since this new command requires
verifying the contents of some of the arguments, I also restructure
the request to use a union of the argument structs. Also, zero out the
request buffer before each request, and change "whitelist" to
"allowlist".Signed-off-by: Nick Crews
Signed-off-by: Enric Balletbo i Serra
02 Aug, 2019
1 commit
-
The SPI thingies request FIFO-99 by default, reduce this to FIFO-50.
FIFO-99 is the very highest priority available to SCHED_FIFO and
it not a suitable default; it would indicate the SPI work is the
most important work on the machine.Cc: Benson Leung
Cc: Enric Balletbo i Serra
Cc: Guenter Roeck
Cc: Mark Brown
Cc: linux-spi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Douglas Anderson
Link: https://lore.kernel.org/r/20190801111541.917256884@infradead.org
Signed-off-by: Mark Brown
29 Jul, 2019
1 commit
-
Kernel crashes during suspend due to wrong conversion in
suspend and resume functions.Use the proper helper to get ishtp_cl_device instance.
Cc: # 5.2.x: b12bbdc5: HID: intel-ish-hid: fix wrong driver_data usage
Signed-off-by: Hyungwoo Yang
Signed-off-by: Enric Balletbo i Serra
12 Jul, 2019
1 commit
-
…ernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung
"CrOS EC:
- Add new CrOS ISHTP transport protocol
- Add proper documentation for debugfs entries and expose resume and
uptime files
- Select LPC transport protocol variant at runtime.
- Add lid angle sensor driver
- Fix oops on suspend/resume for lightbar driver
- Set CrOS SPI transport protol in realtimeWilco EC:
- Add telemetry char device interface
- Add support for event handling
- Add new sysfs attributesMisc:
- Contains ib-mfd-cros-v5.3 immutable branch from mfd, with
cros_ec_commands.h header freshly synced with Chrome OS's EC
project"* tag 'tag-chrome-platform-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: (54 commits)
mfd / platform: cros_ec_debugfs: Expose resume result via debugfs
platform/chrome: lightbar: Get drvdata from parent in suspend/resume
iio: cros_ec: Add lid angle driver
platform/chrome: wilco_ec: Add circular buffer as event queue
platform/chrome: cros_ec_lpc_mec: Fix kernel-doc comment first line
platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
platform/chrome: cros_ec_lpc: Merge cros_ec_lpc and cros_ec_lpc_reg
Input: cros_ec_keyb: mask out extra flags in event_type
platform/chrome: wilco_ec: Fix unreleased lock in event_read()
platform/chrome: cros_ec_debugfs: cros_ec_uptime_fops can be static
platform/chrome: cros_ec_debugfs: Add debugfs ABI documentation
platform/chrome: cros_ec_debugfs: Fix kernel-doc comment first line
platform/chrome: cros_ec_debugfs: Add debugfs entry to retrieve EC uptime
mfd: cros_ec: Update I2S API
mfd: cros_ec: Add Management API entry points
mfd: cros_ec: Add SKU ID and Secure storage API
mfd: cros_ec: Add API for rwsig
mfd: cros_ec: Add API for Fingerprint support
mfd: cros_ec: Add API for Touchpad support
mfd: cros_ec: Add API for EC-EC communication
...
01 Jul, 2019
1 commit
-
For ECs that support it, the EC returns the number of slp_s0
transitions and whether or not there was a timeout in the resume
response. Expose the last resume result to usermode via debugfs so
that usermode can detect and report S0ix timeouts.Signed-off-by: Evan Green
Acked-by: Lee Jones
Signed-off-by: Enric Balletbo i Serra
28 Jun, 2019
1 commit
-
The lightbar driver never assigned the drvdata in probe method, and
thus there is nothing there. Need to get the ec_dev from the parent's
drvdata.Signed-off-by: Rajat Jain
Reviewed-by: Gwendal Grignou
Signed-off-by: Enric Balletbo i Serra
25 Jun, 2019
1 commit
-
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
Signed-off-by: Enric Balletbo i Serra
20 Jun, 2019
3 commits
-
kernel-doc comments have a prescribed format. To be _particularly_ correct
we should also capitalise the brief description and terminate it with a
period.Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Nick Crews -
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
Reviewed-by: Ezequiel Garcia
Tested-by: Nick Crews
Reviewed-by: Nick Crews -
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
Reviewed-by: Nick Crews
18 Jun, 2019
4 commits
-
When copying an event to userspace failed, the event queue
lock was never released. This fixes that.Reported-by: Dan Carpenter
Signed-off-by: Nick Crews
Signed-off-by: Enric Balletbo i Serra -
Fixes: 909447f683b3 ("platform/chrome: cros_ec_debugfs: Add debugfs entry to retrieve EC uptime")
Signed-off-by: kbuild test robot
Signed-off-by: Enric Balletbo i Serra -
kernel-doc comments have a prescribed format. To be _particularly_
correct we should also capitalise the brief description and terminate
it with a period.Signed-off-by: Enric Balletbo i Serra
-
The new debugfs entry 'uptime' is being made available to userspace so that
a userspace daemon can synchronize EC logs with host time.Signed-off-by: Tim Wawrzynczak
[rework based on Tim's first approach]
Signed-off-by: Enric Balletbo i Serra
Tested-by: Tim Wawrzynczak
05 Jun, 2019
3 commits
-
Fix sparse warning:
drivers/platform/chrome/cros_ec_debugfs.c:256:30: warning: symbol 'cros_ec_console_log_fops' was not declared. Should it be static?
drivers/platform/chrome/cros_ec_debugfs.c:265:30: warning: symbol 'cros_ec_pdinfo_fops' was not declared. Should it be static?
drivers/platform/chrome/cros_ec_lightbar.c:550:24: warning: symbol 'cros_ec_lightbar_attr_group' was not declared. Should it be static?
drivers/platform/chrome/cros_ec_sysfs.c:338:24: warning: symbol 'cros_ec_attr_group' was not declared. Should it be static?
drivers/platform/chrome/cros_ec_vbc.c:104:24: warning: symbol 'cros_ec_vbc_attr_group' was not declared. Should it be static?
drivers/platform/chrome/cros_ec_lpc.c:408:25: warning: symbol 'cros_ec_lpc_pm_ops' was not declared. Should it be static?Reported-by: Hulk Robot
Signed-off-by: YueHaibing
Reviewed-by: Benson Leung
Signed-off-by: Enric Balletbo i Serra -
Add the ability to extract version information from the EC.
Example Output:
$ cd /sys/bus/platform/devices/GOOG000C:00
$ tail build_date build_revision version model_number
==> build_date build_revision version model_number
Reviewed-by: Nick Crews
Signed-off-by: Enric Balletbo i Serra -
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
Signed-off-by: Enric Balletbo i Serra
04 Jun, 2019
1 commit
-
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
Signed-off-by: Enric Balletbo i Serra
24 May, 2019
1 commit
-
All currently known ECs in the wild are very sensitive to timing.
Specifically the ECs are known to drop a transfer if more than 8 ms
passes from the assertion of the chip select until the transfer
finishes.Let's use the new feature introduced in the patch (spi: Allow SPI
devices to request the pumping thread be realtime") to request the SPI
pumping thread be realtime. This means that if we get shunted off to
the SPI thread for whatever reason we won't get downgraded to low
priority.NOTES:
- We still need to keep ourselves as high priority since the SPI core
doesn't guarantee that all transfers end up on the pumping thread
(in fact, it tries pretty hard to do them in the calling context).
- If future Chrome OS ECs ever fix themselves to be less sensitive
then we could consider adding a property (or compatible string) to
not set this property. For now we need it across the board.Signed-off-by: Douglas Anderson
Reviewed-by: Guenter Roeck
Signed-off-by: Enric Balletbo i Serra
21 May, 2019
2 commits
-
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
In commit 37a186225a0c ("platform/chrome: cros_ec_spi: Transfer
messages at high priority") we moved transfers to a high priority
workqueue. This helped make them much more reliable....but, we still saw failures.
We were actually finding ourselves competing for time with dm-crypt
which also scheduled work on HIGHPRI workqueues. While we can
consider reverting the change that made dm-crypt run its work at
HIGHPRI, the argument in commit a1b89132dc4f ("dm crypt: use
WQ_HIGHPRI for the IO and crypt workqueues") is somewhat compelling.
It does make sense for IO to be scheduled at a priority that's higher
than the default user priority. It also turns out that dm-crypt isn't
alone in using high priority like this. loop_prepare_queue() does
something similar for loopback devices.Looking in more detail, it can be seen that the high priority
workqueue isn't actually that high of a priority. It runs at MIN_NICE
which is _fairly_ high priority but still below all real time
priority.Should we move cros_ec_spi to real time priority to fix our problems,
or is this just escalating a priority war? I'll argue here that
cros_ec_spi _does_ belong at real time priority. Specifically
cros_ec_spi actually needs to run quickly for correctness. As I
understand this is exactly what real time priority is for.There currently doesn't appear to be any way to use the standard
workqueue APIs with a real time priority, so we'll switch over to
using using a kthread worker. We'll match the priority that the SPI
core uses when it wants to do things on a realtime thread and just use
"MAX_RT_PRIO - 1".This commit plus the patch ("platform/chrome: cros_ec_spi: Request the
SPI thread be realtime") are enough to get communications very close
to 100% reliable (the only known problem left is when serial console
is turned on, which isn't something that happens in shipping devices).
Specifically this test case now passes (tested on rk3288-veyron-jerry):dd if=/dev/zero of=/var/log/foo.txt bs=4M count=512&
while true; do
ectool version > /dev/null;
doneIt should be noted that "/var/log" is encrypted (and goes through
dm-crypt) and also passes through a loopback device.Signed-off-by: Douglas Anderson
Reviewed-by: Guenter Roeck
Signed-off-by: Enric Balletbo i Serra
20 May, 2019
2 commits
-
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.txtSigned-off-by: Rushikesh S Kadam
Acked-by: Srinivas Pandruvada
Reviewed-by: Jett Rink
Tested-by: Jett Rink
Signed-off-by: Enric Balletbo i Serra -
The Chrome OS EC driver attaches to devices using the of_match_table
even when ACPI is the underlying firmware. It does this using the
magic PRP0001 ACPI HID, which tells ACPI to go find an OF compatible
string under the hood and match on that.The cros_ec_spi driver needs to provide the of_match_table regardless
of whether CONFIG_OF is enabled or not, since the table is used by
ACPI for PRP0001 devices.Signed-off-by: Evan Green
Reviewed-by: Benson Leung
Signed-off-by: Enric Balletbo i Serra
