platform/chrome: cros_ec_typec: Displayport support

Add support for entering and exiting displayport alt-mode on systems
using AP driven alt-mode.

Signed-off-by: Abhishek Pandit-Subedi <abhishekpan

platform/chrome: cros_ec_typec: Displayport support

Add support for entering and exiting displayport alt-mode on systems
using AP driven alt-mode.

Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
Link: https://lore.kernel.org/r/20241213153543.v5.6.I142fc0c09df58689b98f0cebf1c5e48b9d4fa800@changeid
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

platform/chrome: Introduce device tree hardware prober

Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connect

platform/chrome: Introduce device tree hardware prober

Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.

This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.

Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component prober. For any given
class of devices on the same I2C bus, it will go through all of them,
doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.

This requires some minor modifications in the existing device tree.
The status for all the device nodes for the component options must be
set to "fail-needs-probe". This makes it clear that some mechanism is
needed to enable one of them, and also prevents the prober and device
drivers running at the same time.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>

show more ...

platform/chrome: kunit: make EC protocol tests independent

Remove CONFIG_CROS_KUNIT and common code concept for ChromeOS Kunit but
make it bundle to ChromeOS EC protocol tests.

Reviewed-by: Guenter

platform/chrome: kunit: make EC protocol tests independent

Remove CONFIG_CROS_KUNIT and common code concept for ChromeOS Kunit but
make it bundle to ChromeOS EC protocol tests.

Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Tzung-Bi Shih <[email protected]>

show more ...

platform/chrome: cros_ec_typec: Add initial VDM support

Add ops to support USB PD VDM (Vendor Defined Message) from the port
driver. This enables the port driver to interface with alternate mode
dri

platform/chrome: cros_ec_typec: Add initial VDM support

Add ops to support USB PD VDM (Vendor Defined Message) from the port
driver. This enables the port driver to interface with alternate mode
drivers and communicate with connected peripherals.

The initial support just contains an implementation of the Enter
Mode command.

Cc: Heikki Krogerus <[email protected]>
Signed-off-by: Prashant Malani <[email protected]>
[pmalani: Fixed trivial conflict in Makefile]
Reviewed-by: Benson Leung <[email protected]>
Acked-by: Heikki Krogerus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: cros_ec_typec: Alter module name with hyphens

Change the Type-C module name from cros_ec_typec to cros-ec-typec. This
allows us to include more files in the same module (rather than

platform/chrome: cros_ec_typec: Alter module name with hyphens

Change the Type-C module name from cros_ec_typec to cros-ec-typec. This
allows us to include more files in the same module (rather than relying
on the file name cros_ec_typec to also be the module name).

Signed-off-by: Prashant Malani <[email protected]>
[pmalani: Fixed trivial conflict in Makefile]
Reviewed-by: Benson Leung <[email protected]>
Acked-by: Heikki Krogerus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: cros_ec_uart: Add transport layer

This patch does following:
1. Adds a new cros-ec-uart driver. This driver can send EC requests on
UART and process response packets received on

platform/chrome: cros_ec_uart: Add transport layer

This patch does following:
1. Adds a new cros-ec-uart driver. This driver can send EC requests on
UART and process response packets received on UART transport.
2. Once probed, this driver will initialize the serdev device based on
the underlying information in the ACPI resource. After serdev device
properties are set, this driver will register itself cros-ec.
3. High level driver can use this implementation to talk to ChromeOS
Embedded Controller device in case it supports UART as transport.
4. When cros-ec driver initiates a request packet, outgoing message is
processed in buffer and sent via serdev. Once bytes are sent, driver
enables a wait_queue.
5. Since ChromeOS EC device sends response asynchronously, AP's TTY
driver accumulates response bytes and calls the registered callback.
TTY driver can send multiple callback for bytes ranging from 1 to MAX
bytes supported by EC device.
6. Driver waits for EC_MSG_DEADLINE_MS to collect and process received
bytes. It wakes wait_queue if expected bytes are received or else
wait_queue timeout. Based on the error condition, driver returns
data_len or error to cros_ec.

Signed-off-by: Bhanu Prakash Maiya <[email protected]>
Co-developed-by: Mark Hasemeyer <[email protected]>
Signed-off-by: Mark Hasemeyer <[email protected]>
Reviewed-by: Prashant Malani <[email protected]>
Signed-off-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/20221227123212.v13.1.If7926fcbad397bc6990dd725690229bed403948c@changeid

show more ...

platform/chrome: add a driver for HPS

This patch introduces a driver for the ChromeOS human presence
sensor (aka. HPS). The driver supports a sensor connected to the I2C bus
and identified as "GOOG0

platform/chrome: add a driver for HPS

This patch introduces a driver for the ChromeOS human presence
sensor (aka. HPS). The driver supports a sensor connected to the I2C bus
and identified as "GOOG0020" in the ACPI tables.

When loaded, the driver exports the sensor to userspace through a
character device. This device only supports power management, i.e.,
communication with the sensor must be done through regular I2C
transmissions from userspace.

Power management is implemented by enabling the respective power GPIO
while at least one userspace process holds an open fd on the character
device. By default, the device is powered down if there are no active
clients.

Note that the driver makes no effort to preserve the state of the sensor
between power down and power up events. Userspace is responsible for
reinitializing any needed state once power has been restored.

The device firmware, I2C protocol and other documentation is available
at https://chromium.googlesource.com/chromiumos/platform/hps-firmware.

Co-developed-by: Sami Kyöstilä <[email protected]>
Signed-off-by: Sami Kyöstilä <[email protected]>
Signed-off-by: Dan Callaghan <[email protected]>
Signed-off-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: cros_typec_switch: Add switch driver

Introduce a driver to configure USB Type-C mode switches and retimers
which are controlled by the ChromeOS EC (Embedded Controller).
This allows

platform/chrome: cros_typec_switch: Add switch driver

Introduce a driver to configure USB Type-C mode switches and retimers
which are controlled by the ChromeOS EC (Embedded Controller).
This allows Type-C port drivers, as well as alternate mode drivers to
configure their relevant mode switches and retimers according to the
Type-C state they want to achieve.

ACPI devices with ID GOOG001A will bind to this driver.

Currently, we only register a retimer switch with a stub set function.
Subsequent patches will implement the host command set functionality,
and introduce mode switches.

Signed-off-by: Prashant Malani <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: merge Kunit utils and test cases

Merge CROS_KUNIT and CROS_EC_PROTO_KUNIT_TEST so that when they're built
as modules cros_kunit_util doesn't need to export the symbols.

Signed-off-

platform/chrome: merge Kunit utils and test cases

Merge CROS_KUNIT and CROS_EC_PROTO_KUNIT_TEST so that when they're built
as modules cros_kunit_util doesn't need to export the symbols.

Signed-off-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

Revert "platform/chrome: cros_typec_switch: Add switch driver"

This reverts commit e54369058f3da181fcc4c893f224a0c5a8a526b6.

The chrome platform driver changes need to come in through the platform

Revert "platform/chrome: cros_typec_switch: Add switch driver"

This reverts commit e54369058f3da181fcc4c893f224a0c5a8a526b6.

The chrome platform driver changes need to come in through the platform
tree due to some api changes that showed up there that cause build
errors in linux-next

Reported-by: Stephen Rothwell <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Prashant Malani <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

platform/chrome: cros_typec_switch: Add switch driver

Introduce a driver to configure USB Type-C mode switches and retimers
which are controlled by the Chrome OS EC (Embedded Controller).
This allow

platform/chrome: cros_typec_switch: Add switch driver

Introduce a driver to configure USB Type-C mode switches and retimers
which are controlled by the Chrome OS EC (Embedded Controller).
This allows Type-C port drivers, as well as alternate mode drivers to
configure their relevant mode switches and retimers according to the
Type-C state they want to achieve.

ACPI devices with ID GOOG001A will bind to this driver.

Currently, we only register a retimer switch with a stub set function.
Subsequent patches will implement the host command set functionality,
and introduce mode switches.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Prashant Malani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_query_all()

cros_ec_query_all() sends multiple host commands to EC for querying
supported protocols and settings.

Add required mock for i

platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_query_all()

cros_ec_query_all() sends multiple host commands to EC for querying
supported protocols and settings.

Add required mock for interacting with cros_ec_query_all() and Kunit
tests.

Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_prepare_tx()

cros_ec_prepare_tx() is used to fill the protocol headers according to
the requested protocol version.

Add Kunit tests cros_

platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_prepare_tx()

cros_ec_prepare_tx() is used to fill the protocol headers according to
the requested protocol version.

Add Kunit tests cros_ec_prepare_tx() for each version.

Signed-off-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/chrome: Add ChromeOS ACPI device driver

The x86 Chromebooks have the ChromeOS ACPI device. This driver attaches
to the ChromeOS ACPI device and exports the values reported by ACPI in a
sysf

platform/chrome: Add ChromeOS ACPI device driver

The x86 Chromebooks have the ChromeOS ACPI device. This driver attaches
to the ChromeOS ACPI device and exports the values reported by ACPI in a
sysfs directory. This data isn't present in ACPI tables when read
through ACPI tools, hence a driver is needed to do it. The driver gets
data from firmware using the ACPI component of the kernel. The ACPI values
are presented in string form (numbers as decimal values) or binary
blobs, and can be accessed as the contents of the appropriate read only
files in the standard ACPI device's sysfs directory tree. This data is
consumed by the ChromeOS user space.

Reviewed-by: Guenter Roeck <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Co-developed-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/Yn4OKYrtV35Dv+nd@debian-BULLSEYE-live-builder-AMD64

show more ...

platform: chrome: Split trace include file

cros_ec_trace.h defined 5 tracing events, 2 for cros_ec_proto and
3 for cros_ec_sensorhub_ring.
These 2 files are in different kernel modules, the traces a

platform: chrome: Split trace include file

cros_ec_trace.h defined 5 tracing events, 2 for cros_ec_proto and
3 for cros_ec_sensorhub_ring.
These 2 files are in different kernel modules, the traces are defined
twice in the kernel which leads to problem enabling only some traces.

Move sensorhub traces from cros_ec_trace.h to cros_ec_sensorhub_trace.h
and enable them only in cros_ec_sensorhub kernel module.

Check we can now enable any single traces: without this patch,
we can only enable all sensorhub traces or none.

Fixes: d453ceb6549a ("platform/chrome: sensorhub: Add trace events for sample")

Signed-off-by: Gwendal Grignou <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benson Leung <[email protected]>

show more ...

platform/chrome: Add driver for ChromeOS privacy-screen

This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.

Note that ideally, we'd want this privacy

platform/chrome: Add driver for ChromeOS privacy-screen

This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.

Note that ideally, we'd want this privacy screen driver to be probed
BEFORE the drm probe in order to avoid a drm probe deferral:
https://hansdegoede.livejournal.com/25948.html

In practise, I found that ACPI drivers are bound to their devices AFTER
the drm probe on chromebooks. So on chromebooks with privacy-screen,
this patch along with the other one in this series results in a probe
deferral of about 250ms for i915 driver. However, it did not result in
any user noticeable delay of splash screen in my personal experience.

In future if this probe deferral turns out to be an issue, we can
consider turning this ACPI driver into something that is probed
earlier than the drm drivers.

Signed-off-by: Rajat Jain <[email protected]>
Reviewed-by: Dmitry Torokhov <[email protected]>
Acked-by: Benson Leung <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

platform/chrome: sensorhub: Add trace events for sample

Add trace event to report samples and their timestamp coming from the
EC. It allows to check if the timestamps are correct and the filter is
w

platform/chrome: sensorhub: Add trace events for sample

Add trace event to report samples and their timestamp coming from the
EC. It allows to check if the timestamps are correct and the filter is
working correctly without introducing too much latency.

To enable these events:

cd /sys/kernel/debug/tracing/
echo 1 > events/cros_ec/enable
echo 0 > events/cros_ec/cros_ec_request_start/enable
echo 0 > events/cros_ec/cros_ec_request_done/enable
echo 1 > tracing_on
cat trace_pipe
Observe event flowing:
irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ...
irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ...

Signed-off-by: Gwendal Grignou <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>

show more ...

platform/chrome: cros_ec_sensorhub: Add FIFO support

cros_ec_sensorhub registers a listener and query motion sense FIFO,
spread to iio sensors registers.

To test, we can use libiio:
iiod&
iio_r

platform/chrome: cros_ec_sensorhub: Add FIFO support

cros_ec_sensorhub registers a listener and query motion sense FIFO,
spread to iio sensors registers.

To test, we can use libiio:
iiod&
iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x

Signed-off-by: Gwendal Grignou <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>

show more ...

platform/chrome: Add Type C connector class driver

Add a driver to implement the Type C connector class for Chrome OS
devices with ECs (Embedded Controllers).

The driver relies on firmware device s

platform/chrome: Add Type C connector class driver

Add a driver to implement the Type C connector class for Chrome OS
devices with ECs (Embedded Controllers).

The driver relies on firmware device specifications for various port
attributes. On ACPI platforms, this is specified using the logical
device with HID GOOG0014. On DT platforms, this is specified using the
DT node with compatible string "google,cros-ec-typec".

The driver reads the device FW node and uses the port attributes to
register the typec ports with the Type C connector class framework, but
doesn't do much else.

Subsequent patches will add more functionality to the driver, including
obtaining current port information (polarity, vconn role, current power
role etc.) after querying the EC.

Co-developed-by: Benson Leung <[email protected]>
Signed-off-by: Prashant Malani <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>

show more ...

platform: chrome: Add cros-usbpd-notify driver

ChromiumOS uses ACPI device with HID "GOOG0003" for power delivery
related events. The existing cros-usbpd-charger driver relies on these
events withou

platform: chrome: Add cros-usbpd-notify driver

ChromiumOS uses ACPI device with HID "GOOG0003" for power delivery
related events. The existing cros-usbpd-charger driver relies on these
events without ever actually receiving them on ACPI platforms. This is
because in the ChromeOS kernel trees, the GOOG0003 device is owned by an
ACPI driver that offers firmware updates to USB-C chargers.

Introduce a new platform driver under cros-ec, the ChromeOS embedded
controller, that handles these PD events and dispatches them
appropriately over a notifier chain to all drivers that use them.

On platforms that don't have the ACPI device defined, the driver gets
instantiated for ECs which support the EC_FEATURE_USB_PD feature bit,
and the notification events will get delivered using the MKBP event
handling mechanism.

Co-Developed-by: Prashant Malani <[email protected]>
Reviewed-by: Gwendal Grignou <[email protected]>
Reviewed-by: Benson Leung <[email protected]>
Signed-off-by: Jon Flatley <[email protected]>
Signed-off-by: Prashant Malani <[email protected]>
Acked-By: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Benson Leung <[email protected]>

show more ...

iio / platform: cros_ec: Add cros-ec-sensorhub driver

Similar to HID sensor stack, the new driver sits between cros-ec-dev
and the IIO device drivers:

The EC based IIO device topology would be:

ii

iio / platform: cros_ec: Add cros-ec-sensorhub driver

Similar to HID sensor stack, the new driver sits between cros-ec-dev
and the IIO device drivers:

The EC based IIO device topology would be:

iio:device1 ->
...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/
cros-ec-sensorhub.7.auto/
cros-ec-accel.15.auto/
iio:device1

It will be expanded to control EC sensor FIFO.

Signed-off-by: Gwendal Grignou <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
[Fix "unknown type name 'uint32_t'" type errors]
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>

show more ...

mfd / platform: cros_ec: Miscellaneous character device to talk with the EC

That's a driver to talk with the ChromeOS Embedded Controller via a
miscellaneous character device, it creates an entry in

mfd / platform: cros_ec: Miscellaneous character device to talk with the EC

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 <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Reviewed-by: Gwendal Grignou <[email protected]>
Tested-by: Gwendal Grignou <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

show more ...

mfd / platform: cros_ec: Move cros-ec core driver out from MFD

Now, the ChromeOS EC core driver has nothing related to an MFD device, so
move that driver from the MFD subsystem to the platform/chrom

mfd / platform: cros_ec: Move cros-ec core driver out from MFD

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 <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Acked-by: Benjamin Tissoires <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Reviewed-by: Gwendal Grignou <[email protected]>
Tested-by: Gwendal Grignou <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

show more ...

platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime

On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
C

platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime

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 <[email protected]>
Reviewed-by: Ezequiel Garcia <[email protected]>
Tested-by: Nick Crews <[email protected]>
Reviewed-by: Nick Crews <[email protected]>

show more ...

platform/chrome: cros_ec_lpc: Merge cros_ec_lpc and cros_ec_lpc_reg

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 f

platform/chrome: cros_ec_lpc: Merge cros_ec_lpc and cros_ec_lpc_reg

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 <[email protected]>
Reviewed-by: Nick Crews <[email protected]>

show more ...