mfd: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that mer

mfd: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174731.4059811-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>

show more ...

drivers: remove struct module * setting from struct class

There is no need to manually set the owner of a struct class, as the
registering function does it automatically, so remove all of the
explic

drivers: remove struct module * setting from struct class

There is no need to manually set the owner of a struct class, as the
registering function does it automatically, so remove all of the
explicit settings from various drivers that did so as it is unneeded.

This allows us to remove this pointer entirely from this structure going
forward.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Link: https://lore.kernel.org/r/20230313181843.1207845-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Revert "mfd: cros_ec: Add SCP Core-1 as a new CrOS EC MCU"

This reverts commit 66ee379d743c69c726b61d078119a34d5be96a35.

The feature flag introduced by Commit 66ee379d743c ("mfd: cros_ec: Add
SCP C

Revert "mfd: cros_ec: Add SCP Core-1 as a new CrOS EC MCU"

This reverts commit 66ee379d743c69c726b61d078119a34d5be96a35.

The feature flag introduced by Commit 66ee379d743c ("mfd: cros_ec: Add
SCP Core-1 as a new CrOS EC MCU") was not first added in the source EC
code base[1]. This can lead to the possible misinterpration of an EC's
supported feature set, as well as causes issues with all future feature
flag updates.

[1] https://source.chromium.org/chromium/chromiumos/platform/ec/+/main:include/ec_commands.h

Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-by: Lee Jones <lee@kernel.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20221228004648.793339-2-pmalani@chromium.org

show more ...

mfd: cros_ec: Add SCP Core-1 as a new CrOS EC MCU

MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
Add a new CrOS feature ID to represent the SCP's 2nd core.

The 1st core is refer

mfd: cros_ec: Add SCP Core-1 as a new CrOS EC MCU

MT8195 System Companion Processors(SCP) is a dual-core RISC-V MCU.
Add a new CrOS feature ID to represent the SCP's 2nd core.

The 1st core is referred to as 'core 0', and the 2nd core is referred
to as 'core 1'.

Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220601112201.15510-16-tinghan.shen@mediatek.com

show more ...

platform/chrome: cros_ec_proto: Rename cros_ec_command function

cros_ec_command() is the name of a function as well as a struct, as such
it can confuse indexing tools (like ctags). Avoid this by ren

platform/chrome: cros_ec_proto: Rename cros_ec_command function

cros_ec_command() is the name of a function as well as a struct, as such
it can confuse indexing tools (like ctags). Avoid this by renaming it to
cros_ec_cmd(). Update all the callsites to use the new name.

This patch is a find-and-replace, so should not introduce any functional
changes.

Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20220606201825.763788-3-pmalani@chromium.org

show more ...

mfd: cros_ec_dev: Only register PCHG device if present

Don't create a device for the peripheral charger (PCHG) if there aren't
any peripheral charger ports. This removes a device on most ChromeOS
sy

mfd: cros_ec_dev: Only register PCHG device if present

Don't create a device for the peripheral charger (PCHG) if there aren't
any peripheral charger ports. This removes a device on most ChromeOS
systems, because the peripheral charger functionality isn't always
present.

Cc: Prashant Malani <pmalani@chromium.org>
Cc: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Daisuke Nojiri <dnojiri@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: <chrome-platform@lists.linux.dev>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220419000408.3202635-1-swboyd@chromium.org

show more ...

mfd: cros_ec: Drop unneeded MODULE_ALIAS

The MODULE_DEVICE_TABLE already creates proper alias. Having another
MODULE_ALIAS causes the alias to be duplicated:

$ modinfo cros_ec_dev.ko

alias:

mfd: cros_ec: Drop unneeded MODULE_ALIAS

The MODULE_DEVICE_TABLE already creates proper alias. Having another
MODULE_ALIAS causes the alias to be duplicated:

$ modinfo cros_ec_dev.ko

alias: platform:cros-ec-dev
srcversion: F84A69D2156719A4F717A76
alias: platform:cros-ec-dev

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

platform/chrome: cros_ec_proto: Use EC struct for features

The Chrome EC's features are returned through an
ec_response_get_features struct, but they are stored in an independent
array. Although the

platform/chrome: cros_ec_proto: Use EC struct for features

The Chrome EC's features are returned through an
ec_response_get_features struct, but they are stored in an independent
array. Although the two are effectively the same at present (2 unsigned
32 bit ints), there is the possibility that they could go out of sync.
Avoid this by only using the EC struct to store the features.

Signed-off-by: Prashant Malani <pmalani@chromium.org>
Link: https://lore.kernel.org/r/20211004170716.86601-1-pmalani@chromium.org
Signed-off-by: Benson Leung <bleung@chromium.org>

show more ...

mfd: cros_ec: Add peripheral device charger

This patch adds a cell entry for PCHG (Peripheral CHarGer). PCHG is a
framework managing power supplies for peripheral devices.

Signed-off-by: Daisuke No

mfd: cros_ec: Add peripheral device charger

This patch adds a cell entry for PCHG (Peripheral CHarGer). PCHG is a
framework managing power supplies for peripheral devices.

Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec_dev: Load lightbar module only present

The pixel lightbar is only present on chromebook pixel (link), pixel 2
and pixel C. For the latter two, the EC reports its presence.
Instead of al

mfd: cros_ec_dev: Load lightbar module only present

The pixel lightbar is only present on chromebook pixel (link), pixel 2
and pixel C. For the latter two, the EC reports its presence.
Instead of always loading the lightbar driver on all chromebook, only
load it when reported by the EC or Link device.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec_dev: Fix cros_feature_to_{name,cells} struct descriptions

Kerneldoc expects kernel structures to be prefixed with 'struct'.

Fixes the following W=1 level warnings:

drivers/mfd/cros_e

mfd: cros_ec_dev: Fix cros_feature_to_{name,cells} struct descriptions

Kerneldoc expects kernel structures to be prefixed with 'struct'.

Fixes the following W=1 level warnings:

drivers/mfd/cros_ec_dev.c:32: warning: cannot understand function prototype: 'struct cros_feature_to_name '
drivers/mfd/cros_ec_dev.c:44: warning: cannot understand function prototype: 'struct cros_feature_to_cells '

Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Check DT node for usbpd-notify add

Add a check to ensure there is indeed an EC device tree entry before
adding the cros-usbpd-notify device. This covers configs where both
CONFIG_ACPI

mfd: cros_ec: Check DT node for usbpd-notify add

Add a check to ensure there is indeed an EC device tree entry before
adding the cros-usbpd-notify device. This covers configs where both
CONFIG_ACPI and CONFIG_OF are defined, but the EC device is defined
using device tree and not in ACPI.

Fixes: 4602dce0361e ("mfd: cros_ec: Add cros-usbpd-notify subdevice")
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Add cros-usbpd-notify subdevice

Add the cros-usbpd-notify driver as a subdevice on platforms that
support the EC_FEATURE_USB_PD EC feature flag and don't have the
ACPI PD notification

mfd: cros_ec: Add cros-usbpd-notify subdevice

Add the cros-usbpd-notify driver as a subdevice on platforms that
support the EC_FEATURE_USB_PD EC feature flag and don't have the
ACPI PD notification device defined.

This driver allows other cros-ec devices to receive PD event
notifications from the Chrome OS Embedded Controller (EC) via a
notification chain.

Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'

This header file now only includes the cros_ec_dev struct, however, is the
'include/linux/platform_data/cros_ec_proto.h' who contains the defi

cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'

This header file now only includes the cros_ec_dev struct, however, is the
'include/linux/platform_data/cros_ec_proto.h' who contains the definition of
all the Chrome OS EC related structs. There is no reason to have a
separate include for this struct so move to the place where other
structs are defined. That way, we can remove the include itself, but also
simplify the common pattern

#include <linux/mfd/cros_ec.h>
#include <linux/platform_data/cros_ec_proto.h>

for a single include

#include <linux/platform_data/cros_ec_proto.h>

The changes to remove the cros_ec.h include were generated with the
following shell script:

git grep -l "<linux/mfd/cros_ec.h>" | xargs sed -i '/<linux\/mfd\/cros_ec.h>/d'

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...

mfd / platform / iio: cros_ec: Register sensor through sensorhub

Remove the duplicated code in MFD, since MFD just registers cros-ec-sensorhub
if at least one sensor is present.

Change IIO cros-ec

mfd / platform / iio: cros_ec: Register sensor through sensorhub

Remove the duplicated code in MFD, since MFD just registers cros-ec-sensorhub
if at least one sensor is present.

Change IIO cros-ec driver to get the pointer to the cros-ec-dev through
cros-ec-sensorhub.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

show more ...

mfd / platform: cros_ec: Add sensor_count and make check_features public

Add a new function to return the number of MEMS sensors available in a
ChromeOS Embedded Controller. It uses MOTIONSENSE_CMD_

mfd / platform: cros_ec: Add sensor_count and make check_features public

Add a new function to return the number of MEMS sensors available in a
ChromeOS Embedded Controller. It uses MOTIONSENSE_CMD_DUMP if available
or a specific memory map ACPI registers to find out.

Also, make check_features public as it can be useful for other drivers
to know what the Embedded Controller supports.

Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

show more ...

mfd: cros_ec: Use mfd_add_hotplug_devices() helper

Use mfd_add_hotplug_devices() helper to register the subdevices. The
helper allows us to reduce the boiler plate and also registers the
subdevices

mfd: cros_ec: Use mfd_add_hotplug_devices() helper

Use mfd_add_hotplug_devices() helper to register the subdevices. The
helper allows us to reduce the boiler plate and also registers the
subdevices in the same way as used in other functions used in this
files.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices

The CrOS EC is gaining lots of subdevices that are autodetectable by
sending the EC_FEATURE_GET_CMD, it takes fair am

mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices

The CrOS EC is gaining lots of subdevices that are autodetectable by
sending the EC_FEATURE_GET_CMD, it takes fair amount of boiler plate
code to add those devices. So, add a struct that can be used to quickly
add new subdevices without having to duplicate code.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs

With the increasing use of dedicated CrOS EC MCUs, it takes a fair amount
of boiler plate code to add those devices, add a struc

mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs

With the increasing use of dedicated CrOS EC MCUs, it takes a fair amount
of boiler plate code to add those devices, add a struct that can be used
to specify a dedicated CrOS EC MCU so we can just add a new item to it to
define a new dedicated MCU.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper

This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer() so we can remove some redundant code. It also uses
kzallo

mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper

This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer() so we can remove some redundant code. It also uses
kzalloc instead of kmalloc so we can remove more redundant code.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd / platform: cros_ec: Reorganize platform and mfd includes

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
expor

mfd / platform: cros_ec: Reorganize platform and mfd includes

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.h

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Series changes: 3
- Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp)
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: Switch to use the new cros-ec-chardev driver

With the purpose of remove the things that far extends the bounds of
what a MFD was designed to do, instantiate the new platform misc
cros-

mfd: cros_ec: Switch to use the new cros-ec-chardev driver

With the purpose of remove the things that far extends the bounds of
what a MFD was designed to do, instantiate the new platform misc
cros-ec-chardev driver and get rid of all the unneeded code. After this
patch the misc chardev driver is a sub-device of the MFD, and all the
new file operations should be implemented there.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

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 <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec_dev: Register cros_ec_accel_legacy driver as a subdevice

With this patch, the cros_ec_ctl driver will register the legacy
accelerometer driver (named cros_ec_accel_legacy) if it fails t

mfd: cros_ec_dev: Register cros_ec_accel_legacy driver as a subdevice

With this patch, the cros_ec_ctl driver will register the legacy
accelerometer driver (named cros_ec_accel_legacy) if it fails to
register sensors through the usual path cros_ec_sensors_register().
This legacy device is present on Chromebook devices with older EC
firmware only supporting deprecated EC commands:
- Glimmer based devices [Intel SOC using LPC transport]
- Veyron minnie devices [ARM SOC using SPI transport]

Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

mfd: cros_ec: differentiate SCP from EC by feature bit

System Companion Processor (SCP) is Cortex M4 co-processor on some
MediaTek platform that can run EC-style firmware. Since a SCP and EC
would b

mfd: cros_ec: differentiate SCP from EC by feature bit

System Companion Processor (SCP) is Cortex M4 co-processor on some
MediaTek platform that can run EC-style firmware. Since a SCP and EC
would both exist on a system, and use the cros_ec_dev driver, we need to
differentiate between them for the userspace, or they would both be
registered at /dev/cros_ec, causing a conflict.

Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...