| Age | Commit message (Collapse) | Author |
|---|
|
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them.
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Link: https://lore.kernel.org/r/20240405134151.5560-2-schnelle@linux.ibm.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
Enable this Kconfig on COMPILE_TEST enabled configs so we can get more
build coverage.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
The EC is in charge of controlling the keyboard backlight on
the Wilco platform. We expose a standard LED class device
named platform::kbd_backlight.
Since the EC will never change the backlight level of its own accord,
we don't need to implement a brightness_get() method.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Daniel Campello <campello@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/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 realtime
Wilco EC:
- Add telemetry char device interface
- Add support for event handling
- Add new sysfs attributes
Misc:
- 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
...
|
|
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 <enric.balletbo@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Nick Crews <ncrews@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
|
|
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>
|
|
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>
|
|
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 <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When CROS_EC_LPC is set to =m, we get a link failure for a
builtin wilco-ec module:
drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_remove':
core.c:(.text+0x26): undefined reference to `cros_ec_lpc_mec_destroy'
drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_probe':
core.c:(.text+0x18c): undefined reference to `cros_ec_lpc_mec_init'
core.c:(.text+0x224): undefined reference to `cros_ec_lpc_mec_destroy'
drivers/platform/chrome/wilco_ec/mailbox.o: In function `wilco_ec_mailbox':
mailbox.c:(.text+0x104): undefined reference to `cros_ec_lpc_io_bytes_mec'
The problem with the existing CROS_EC_LPC_MEC dependency is that this
is only for a 'bool' symbol, so the information about the exported
functions being in a module is lost on the way, and we actually have
to depend on both CROS_EC_LPC and CROS_EC_LPC_MEC.
Fixes: 7b3d4f44abf0 ("platform/chrome: Add new driver for Wilco EC")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
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>
|
|
This EC is an incompatible variant of the typical Chrome OS embedded
controller. It uses the same low-level communication and a similar
protocol with some significant differences. The EC firmware does
not support the same mailbox commands so it is not registered as a
cros_ec device type. This commit exports the wilco_ec_mailbox()
function so that other modules can use it to communicate with the EC.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Nick Crews <ncrews@chromium.org>
[Fix the sparse warning: symbol 'wilco_ec_transfer' was not declared]
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
[Fix Kconfig dependencies for wilco_ec]
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
