Skip to content

L
linux
Switch branch/tag
  1. 12 Jun, 2019 1 commit
  3. 10 Jun, 2019 30 commits
  5. 05 Jun, 2019 3 commits
    • YueHaibing's avatar
      platform/chrome: cros_ec: Make some symbols static · 81bc8c03
      YueHaibing authored 
      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: default avatarHulk Robot <hulkci@huawei.com>
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Reviewed-by: default avatarBenson Leung <bleung@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      81bc8c03
    • Raul E Rangel's avatar
      platform/chrome: wilco_ec: Add version sysfs entries · 79e3f1d3
      Raul E Rangel authored 
      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 <==
04/25/19

==> build_revision <==
d2592cae0

==> version <==
00.00.14

==> model_number <==
08B6
Signed-off-by: default avatarRaul E Rangel <rrangel@chromium.org>
Reviewed-by: default avatarNick Crews <ncrews@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      79e3f1d3
    • Nick Crews's avatar
      platform/chrome: wilco_ec: Add telemetry char device interface · 1210d1e6
      Nick Crews authored 
      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: default avatarNick Crews <ncrews@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      1210d1e6
  7. 03 Jun, 2019 1 commit
    • Nick Crews's avatar
      platform/chrome: wilco_ec: Add event handling · f7b0bc5e
      Nick Crews authored 
      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: default avatarNick Crews <ncrews@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      f7b0bc5e
  9. 24 May, 2019 2 commits
  11. 23 May, 2019 1 commit
  13. 20 May, 2019 2 commits
    • Douglas Anderson's avatar
      platform/chrome: cros_ec_spi: Move to real time priority for transfers · 7dadf88f
      Douglas Anderson authored 
      In commit 37a18622 ("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 a1b89132 ("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;
  done

It should be noted that "/var/log" is encrypted (and goes through
dm-crypt) and also passes through a loopback device.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      7dadf88f
    • Rushikesh S Kadam's avatar
      platform/chrome: Add ChromeOS EC ISHTP driver · 26a14267
      Rushikesh S Kadam authored 
      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: default avatarRushikesh S Kadam <rushikesh.s.kadam@intel.com>
Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: default avatarJett Rink <jettrink@chromium.org>
Tested-by: default avatarJett Rink <jettrink@chromium.org>
Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      26a14267
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7