static priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low' priority level,
plus sched_set_normal() to set the policy back to non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in a separate
tree.
When merging to the latest upstream tree there's a conflict in drivers/spi/spi.c,
which can be resolved via:
sched_set_fifo(ctlr->kworker_task);
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAl8pPQIRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1j0Jw/+LlSyX6gD2ATy3cizGL7DFPZogD5MVKTb
IXbhXH/ACpuPQlBe1+haRLbJj6XfXqbOlAleVKt7eh+jZ1jYjC972RCSTO4566mJ
0v8Iy9kkEeb2TDbYx1H3bnk78lf85t0CB+sCzyKUYFuTrXU04eRj7MtN3vAQyRQU
xJg83x/sT5DGdDTP50sL7lpbwk3INWkD0aDCJEaO/a9yHElMsTZiZBKoXxN/s30o
FsfzW56jqtng771H2bo8ERN7+abwJg10crQU5mIaLhacNMETuz0NZ/f8fY/fydCL
Ju8HAdNKNXyphWkAOmixQuyYtWKe2/GfbHg8hld0jmpwxkOSTgZjY+pFcv7/w306
g2l1TPOt8e1n5jbfnY3eig+9Kr8y0qHkXPfLfgRqKwMMaOqTTYixEzj+NdxEIRX9
Kr7oFAv6VEFfXGSpb5L1qyjIGVgQ5/JE/p3OC3GHEsw5VKiy5yjhNLoSmSGzdS61
1YurVvypSEUAn3DqTXgeGX76f0HH365fIKqmbFrUWxliF+YyflMhtrj2JFtejGzH
Md3RgAzxusE9S6k3gw1ev4byh167bPBbY8jz0w3Gd7IBRKy9vo92h6ZRYIl6xeoC
BU2To1IhCAydIr6hNsIiCSDTgiLbsYQzPuVVovUxNh+l1ZvKV2X+csEHhs8oW4pr
4BRU7dKL2NE=
=/7JH
-----END PGP SIGNATURE-----
Merge tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull sched/fifo updates from Ingo Molnar:
"This adds the sched_set_fifo*() encapsulation APIs to remove static
priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low'
priority level, plus sched_set_normal() to set the policy back to
non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in
a separate tree"
* tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits)
sched,tracing: Convert to sched_set_fifo()
sched: Remove sched_set_*() return value
sched: Remove sched_setscheduler*() EXPORTs
sched,psi: Convert to sched_set_fifo_low()
sched,rcutorture: Convert to sched_set_fifo_low()
sched,rcuperf: Convert to sched_set_fifo_low()
sched,locktorture: Convert to sched_set_fifo()
sched,irq: Convert to sched_set_fifo()
sched,watchdog: Convert to sched_set_fifo()
sched,serial: Convert to sched_set_fifo()
sched,powerclamp: Convert to sched_set_fifo()
sched,ion: Convert to sched_set_normal()
sched,powercap: Convert to sched_set_fifo*()
sched,spi: Convert to sched_set_fifo*()
sched,mmc: Convert to sched_set_fifo*()
sched,ivtv: Convert to sched_set_fifo*()
sched,drm/scheduler: Convert to sched_set_fifo*()
sched,msm: Convert to sched_set_fifo*()
sched,psci: Convert to sched_set_fifo*()
sched,drbd: Convert to sched_set_fifo*()
...
As with cros_ec_cmd_xfer_status(), etc., it's not enough to simply check
for the return status of send_command() -- that only covers transport or
other similarly-fatal errors. One must also check the ->result field, to
see whether the command really succeeded. If not, we can't use the data
it returns.
The caller of cros_ec_get_host_event_wake_mask() ignores this, and so
for example, on EC's where the command is not implemented, we're using
junk (or in practice, all zeros) for our wake-mask. We should be using a
non-zero default (currently, it's supposed to be all-1's).
Fix this by checking the ->result field and returning -EPROTO for
errors.
I might label this as fixing commit 29d99b966d ("cros_ec: Don't signal
wake event for non-wake host events"), except that this fix alone
actually may make things worse, as it now allows for a lot more spurious
wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
ECs that don't implement EC_CMD_HOST_EVENT_GET_WAKE_MASK should still
have some reasonable default mask -- otherwise, they'll treat a variety
of EC signals as spurious wakeups. Battery and AC events can be
especially common, for devices that have been sitting at full charge
plugged into AC for a long time, as they may cycle their charging off
and on, or their battery may start reporting failures as it ages.
Treating these as wakeups does not serve a useful purpose, and is
instead often counterproductive. And indeed, later ECs (that implement
the mask) don't include these events in their wake-mask.
Note that this patch doesn't do anything without the subsequent patch
("platform/chrome: cros_ec_proto: check for missing
EC_CMD_HOST_EVENT_GET_WAKE_MASK"), because
cros_ec_get_host_event_wake_mask() currently does not return an error if
EC_CMD_HOST_EVENT_GET_WAKE_MASK is not implemented.
Some additional notes:
While the EC typically knows not to wake the CPU for these unimportant
events once the CPU reaches a sleep state, it doesn't really have a way
to know that the CPU is "almost" asleep, unless it has support for
EC_CMD_HOST_SLEEP_EVENT. Alas, these older ECs do not support that
command either, so this solution is not 100% complete.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
On some machines (nami), interrupt latency cause samples to appear
to be from the future and are pegged to the current time.
We would see samples with this pattern:
[t, t + ~5ms, t + ~10ms, t + ~10ms + 100us, t + ~10ms + 200us],
(current now) (current now)
(t is the last timestamp time)
Last 2 samples would be barely spread, causing applications to
complain.
We now spread the entire sequence. This is not great: in the example
the sensor was supposed to send samples every 5ms, it now appears to
send one every 2.5ms, but it is slightly closer to reality:
sampling time in the example above
At sensor level
1 2 3 4 5
+-----5ms-----+-----5ms-----+-----5ms-----+----5ms-----+---> t
Before, at host level
1 2 3 4 5
--interrupt delay------+-----5ms-----+-----5ms-----+-+-+---> t
Afer, at host level
1 2 3 4 5
--interrupt delay------+-2.5ms-+-2.5ms-+-2.5ms-+-2.5ms-+---> t
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Now that all the remaining users of cros_ec_cmd_xfer() has been removed,
make this function private to the cros_ec_proto module.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
When port update is called during probe(), any error with setting the
Type C muxes results in an errno being returned to probe(), which promptly
returns that itself. Ensure that we unregister any registered partners
when doing so, to prevent orphaned partners on the Type C connector
class framework.
Move the cros_typec_add_partner() and cros_typec_remove_partner() code
together to higher up in the file, so that they are together, and we can
call cros_typec_remove_partner() from cros_unregister_ports().
Fixes: 7e7def15fa ("platform/chrome: cros_ec_typec: Add USB mux control")
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
EC is using 32 bit timestamps (us), and before converting it to 64bit
they were not casted, so it would overflow every 4s.
Regular overflow every ~70 minutes was not taken into account either.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Define basic suspend resume functions for cros-ec-typec. On suspend, we
simply ensure that any pending port update work is completed, and on
resume, we re-poll the port state to account for any
changes/disconnections that might have occurred during suspend.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Use a work queue to call the port update routines, instead of doing it
directly in the PD notifier callback. This will prevent other drivers
with PD notifier callbacks from being blocked on the port update routine
completing.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
As reported by the kernel test robot the cros_ec_typec driver fails to
build if the USB_ROLE_SWITCH is not selected, to fix that, add a
dependency on that symbol. This fixes the following build error:
drivers/platform/chrome/cros_ec_typec.c:133: undefined reference to `usb_role_switch_put'
ld: drivers/platform/chrome/cros_ec_typec.o: in function `cros_typec_get_switch_handles':
drivers/platform/chrome/cros_ec_typec.c:108: undefined reference to `fwnode_usb_role_switch_get'
ld: drivers/platform/chrome/cros_ec_typec.c:117: undefined reference to `usb_role_switch_put'
Fixes: 7e7def15fa ("platform/chrome: cros_ec_typec: Add USB mux control")
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
In function cros_ec_ishtp_probe(), "up_write" is already called
before function "cros_ec_dev_init". But "up_write" will be called
again after the calling of the function "cros_ec_dev_init" failed.
Thus add a call of the function “down_write” in this if branch
for the completion of the exception handling.
Fixes: 26a14267af ("platform/chrome: Add ChromeOS EC ISHTP driver")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Tested-by: Mathew King <mathewk@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Kerneldoc expects all kernel structure member to be documented.
Fixes the following W=1 level warnings:
cros_ec_rpmsg.c:49: warning: Function parameter or member 'ept' not described in 'cros_ec_rpmsg'
cros_ec_rpmsg.c:49: warning: Function parameter or member 'has_pending_host_event' not described in 'cros_ec_rpmsg'
cros_ec_rpmsg.c:49: warning: Function parameter or member 'probe_done' not described in 'cros_ec_rpmsg'
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Kerneldoc expects all kernel function members to be documented.
Fixes the following W=1 level warnings:
cros_ec_spi.c:153: warning: Function parameter or member 'ec_dev' not described in 'receive_n_bytes'
cros_ec_spi.c:153: warning: Function parameter or member 'buf' not described in 'receive_n_bytes'
cros_ec_spi.c:153: warning: Function parameter or member 'n' not described in 'receive_n_bytes'
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Since cros_typec_configure_mux() is only used in cros-ec-typec,
it should be marked static.
Fixes: 7e7def15fa ("platform/chrome: cros_ec_typec: Add USB mux control")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Handle Chrome EC mux events to configure on-board muxes correctly while
entering DP alternate mode. Since we don't surface SVID and VDO
information regarding the DP alternate mode, configure the Type C
muxes directly from the port driver. Later, when mode discovery
information is correctly surfaced to the driver, we can register the DP
alternate mode driver and let it handle the mux configuration.
Also, modify the struct_typec_state state management to account for the
addition of DP alternate mode.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Add support to configure various Type C switches appropriately using the
Type C connector class API, when the Chrome OS EC informs the AP that
the USB operating mode has been entered.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Recognize EC_CMD_USB_PD_CONTROL command version 2. This is necessary in
order to process Type C mux information (like DP alt mode pin
configuration), which is needed by the Type C Connector class API to
configure the Type C muxes correctly
While we are here, rename the struct member storing this version number
from cmd_ver to pd_ctrl_ver, which more accurately reflects what is
being stored.
Also, slightly change the logic for calling
cros_typec_set_port_params_*(). Now, v0 is called when pd_ctrl_ver is 0,
and v1 is called otherwise.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Register Type C mux and switch handles, when provided via firmware
bindings. These will allow the cros-ec-typec driver, and also alternate
mode drivers to configure connected Muxes correctly, according to PD
information retrieved from the Chrome OS EC.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
When EC does not support uptime command (EC_CMD_GET_UPTIME_INFO),
do not create the uptime sysfs entry point.
User space application will not probe the file needlessly.
The EC console log will not contain EC_CMD_GET_UPTIME_INFO anymore.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Add support for controlling voltage regulator that is connected and
controlled by ChromeOS EC. Kernel controls these regulators through
newly added EC host commands.
Changes from v5:
* Move new host command to a separate patch.
* Use devm_regulator_register.
* Address review comments.
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file name.
* Remove check around CONFIG_OF in driver.
* Add new host commands to cros_ec_trace.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Change license for dt binding according to checkpatch.pl.
* Address comments on code styles.
Pi-Hsun Shih (3):
dt-bindings: regulator: Add DT binding for cros-ec-regulator
platform/chrome: cros_ec: Add command for regulator control.
regulator: Add driver for cros-ec-regulator
.../regulator/google,cros-ec-regulator.yaml | 51 ++++
drivers/platform/chrome/cros_ec_trace.c | 5 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/cros-ec-regulator.c | 257 ++++++++++++++++++
.../linux/platform_data/cros_ec_commands.h | 82 ++++++
6 files changed, 406 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
create mode 100644 drivers/regulator/cros-ec-regulator.c
base-commit: b791d1bdf9
--
2.27.0.290.gba653c62da-goog
Add host commands for voltage regulator control through ChromeOS EC.
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200612040526.192878-3-pihsun@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Ingo suggested that since the new sched_set_*() functions are
implemented using the 'nocheck' variants, they really shouldn't ever
fail, so remove the return value.
Cc: axboe@kernel.dk
Cc: daniel.lezcano@linaro.org
Cc: sudeep.holla@arm.com
Cc: airlied@redhat.com
Cc: broonie@kernel.org
Cc: paulmck@kernel.org
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Because SCHED_FIFO is a broken scheduler model (see previous patches)
take away the priority field, the kernel can't possibly make an
informed decision.
No effective change.
Cc: broonie@kernel.org
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Since commit 84af7a6194 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.
This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.
There are a variety of indentation styles found.
a) 4 spaces + '---help---'
b) 7 spaces + '---help---'
c) 8 spaces + '---help---'
d) 1 space + 1 tab + '---help---'
e) 1 tab + '---help---' (correct indentation)
f) 1 tab + 1 space + '---help---'
g) 1 tab + 2 spaces + '---help---'
In order to convert all of them to 1 tab + 'help', I ran the
following commend:
$ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* cros_ec_typec
- Add notifier for update, and register port partner
* Sensors/iio:
- Fixes to cros_ec_sensorhub around allocation of resources, and send_sample.
* Wilco EC
- Fix to output format of h1_gpio
* Misc
- Misc fixes to appease kernel-doc and other warnings.
- Set user space log size in chromeos_pstore
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQCtZK6p/AktxXfkOlzbaomhzOwwgUCXtbFXgAKCRBzbaomhzOw
woJ3AQDUNnb4ocSXLRyg8IDgLWcA7rjT53jzuvPioTUunRoYAAEA/FR8tQWYOz6e
91ZBHrkQB4fm2w9GQsJk5OpOy8qtZwA=
=9IiQ
-----END PGP SIGNATURE-----
Merge tag 'tag-chrome-platform-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"cros_ec_typec:
- Add notifier for update, and register port partner
Sensors/iio:
- Fixes to cros_ec_sensorhub around allocation of resources, and
send_sample
Wilco EC:
- Fix to output format of h1_gpio
Misc:
- Misc fixes to appease kernel-doc and other warnings
- Set user space log size in chromeos_pstore"
* tag 'tag-chrome-platform-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_usbpd_logger: Add __printf annotation to append_str()
platform/chrome: cros_ec_i2c: Appease the kernel-doc deity
platform/chrome: typec: Fix ret value check error
platform/chrome: cros_ec_typec: Register port partner
platform/chrome: cros_ec_typec: Add struct for port data
platform/chrome: cros_ec_typec: Use notifier for updates
platform/chrome: cros_ec_ishtp: free ishtp buffer before sending event
platform/chrome: cros_ec_ishtp: skip old cros_ec responses
platform/chrome: wilco_ec: Provide correct output format to 'h1_gpio' file
platform/chrome: chromeos_pstore: set user space log size
- refactor pstore locking for safer module unloading (Kees Cook)
- remove orphaned records from pstorefs when backend unloaded (Kees Cook)
- refactor dump_oops parameter into max_reason (Pavel Tatashin)
- introduce pstore/zone for common code for contiguous storage (WeiXiong Liao)
- introduce pstore/blk for block device backend (WeiXiong Liao)
- introduce mtd backend (WeiXiong Liao)
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAl7UbYYWHGtlZXNjb29r
QGNocm9taXVtLm9yZwAKCRCJcvTf3G3AJpkgD/9/09OkJIWydwk2lr2T89HW5fSF
5uBT0a309/QDUpnV9yhcRsrESEicnvbtaGxD0kuYIInkiW/2cj1l689EkyRjUmy9
q3z4GzLqOlC7qvd7LUPFNGHmllBb09H/CxmXDxRP3aynB9oHzdpNQdPcpLBDA00r
0byp/AE48dFbKIhtT0QxpGUYZFOlyc7XVAaOkED4bmu148gx8q7MU1AxFgbx0Feb
9iPV0r6XYMgXJZ3sn/3PJsxF0V/giDSJ8ui2xsYRjCE408zVIYLdDs2e8dz+2yW6
+3Lyankgo+ofZc4XYExTYgn3WjhPFi+pjVRUaj+BcyTk9SLNIj2WmZdmcLMuzanh
BaUurmED7ffTtlsH4PhQgn8/OY4FX2PO2MwUHwlU+87Y8YDiW0lpzTq5H822OO8p
QQ8awql/6lLCJuyzuWIciVUsS65MCPxsZ4+LSiMZzyYpWu1sxrEY8ic3agzCgsA0
0i+4nZFlLG+Aap/oiKpegenkIyAunn2tDXAyFJFH6qLOiZJ78iRuws3XZqjCElhJ
XqvyDJIfjkJhWUb++ckeqX7ThOR4CPSnwba/7GHv7NrQWuk3Cn+GQ80oxydXUY6b
2/4eYjq0wtvf9NeuJ4/LYNXotLR/bq9zS0zqwTWG50v+RPmuC3bNJB+RmF7fCiCG
jo1Sd1LMeTQ7bnULpA==
=7s1u
-----END PGP SIGNATURE-----
Merge tag 'pstore-v5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull pstore updates from Kees Cook:
"Fixes and new features for pstore.
This is a pretty big set of changes (relative to past pstore pulls),
but it has been in -next for a while. The biggest change here is the
ability to support a block device as a pstore backend, which has been
desired for a while. A lot of additional fixes and refactorings are
also included, mostly in support of the new features.
- refactor pstore locking for safer module unloading (Kees Cook)
- remove orphaned records from pstorefs when backend unloaded (Kees
Cook)
- refactor dump_oops parameter into max_reason (Pavel Tatashin)
- introduce pstore/zone for common code for contiguous storage
(WeiXiong Liao)
- introduce pstore/blk for block device backend (WeiXiong Liao)
- introduce mtd backend (WeiXiong Liao)"
* tag 'pstore-v5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (35 commits)
mtd: Support kmsg dumper based on pstore/blk
pstore/blk: Introduce "best_effort" mode
pstore/blk: Support non-block storage devices
pstore/blk: Provide way to query pstore configuration
pstore/zone: Provide way to skip "broken" zone for MTD devices
Documentation: Add details for pstore/blk
pstore/zone,blk: Add ftrace frontend support
pstore/zone,blk: Add console frontend support
pstore/zone,blk: Add support for pmsg frontend
pstore/blk: Introduce backend for block devices
pstore/zone: Introduce common layer to manage storage zones
ramoops: Add "max-reason" optional field to ramoops DT node
pstore/ram: Introduce max_reason and convert dump_oops
pstore/platform: Pass max_reason to kmesg dump
printk: Introduce kmsg_dump_reason_str()
printk: honor the max_reason field in kmsg_dumper
printk: Collapse shutdown types into a single dump reason
pstore/ftrace: Provide ftrace log merging routine
pstore/ram: Refactor ftrace buffer merging
pstore/ram: Refactor DT size parsing
...
Now that pstore_register() can correctly pass max_reason to the kmesg
dump facility, introduce a new "max_reason" module parameter and
"max-reason" Device Tree field.
The "dump_oops" module parameter and "dump-oops" Device
Tree field are now considered deprecated, but are now automatically
converted to their corresponding max_reason values when present, though
the new max_reason setting has precedence.
For struct ramoops_platform_data, the "dump_oops" member is entirely
replaced by a new "max_reason" member, with the only existing user
updated in place.
Additionally remove the "reason" filter logic from ramoops_pstore_write(),
as that is not specifically needed anymore, though technically
this is a change in behavior for any ramoops users also setting the
printk.always_kmsg_dump boot param, which will cause ramoops to behave as
if max_reason was set to KMSG_DUMP_MAX.
Co-developed-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Link: https://lore.kernel.org/lkml/20200515184434.8470-6-keescook@chromium.org/
Signed-off-by: Kees Cook <keescook@chromium.org>
This allows the compiler to verify the format strings vs the types of
the arguments. Also, silence the warning (triggered by W=1):
cros_usbpd_logger.c:55:2: warning: function ‘append_str’ might be a
candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace a comment starting with /** by simply /* to avoid having
it interpreted as a kernel-doc comment.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Merging 5.7 fixes branch as of April 29, containing one fix to branch
destined for chrome-platform-5.8.
b31d1d2b1c platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before claiming sensors
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Allocate callbacks array before enumerating the sensors: The probe routine
for these sensors (for instance cros_ec_sensors_probe) can be called
within the sensorhub probe routine (cros_ec_sensors_probe())
Fixes: 145d59baff ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reported-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
cros_typec_add_partner() returns 0 on success, so check for "ret"
instead of "!ret" as an error.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Fixes: 9d33ea3310 ("platform/chrome: cros_ec_typec: Register port partner")
Signed-off-by: Benson Leung <bleung@chromium.org>
Register (and unregister) the port partner when a connect (and
disconnect) is detected.
Co-developed-by: Jon Flatley <jflat@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Add a separate struct for storing port data, including Type C connector
class struct pointers and caps.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Register a listener for the cros-usbpd-notifier, and update port state
when a notification comes in.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Merging 5.7 fixes branch as of April 13, containing two fixes to branch
destined for chrome-platform-5.8.
538b8471fe platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages
5b69c23799 platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample()
Signed-off-by: Benson Leung <bleung@chromium.org>
Recycle the ISH buffer before notifying of a response or an event. Often
a new message is sent in response to an event and in high traffic
scenarios this can lead to exhausting all available buffers. We can
ensure we are using the fewest buffers possible by freeing buffers as
soon as they are used.
Signed-off-by: Jett Rink <jettrink@chromium.org>
Signed-off-by: Mathew King <mathewk@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The ISHTP layer can give us old responses that we already gave up on. We
do not want to interpret these old responses as the current response we
are waiting for.
The cros_ish should only have one request in flight at a time. We send
the request and wait for the response from the ISH. If the ISH is too
slow to respond we give up on that request and we can send a new
request. The ISH may still send the response to the request that timed
out and without this we treat the old response as the response to the
current command. This is a condition that should not normally happen but
it has been observed with a bad ISH image. So add a token to the request
header which is copied into the response header when the ISH processes
the message to ensure that response is for the current request.
Signed-off-by: Jett Rink <jettrink@chromium.org>
Signed-off-by: Mathew King <mathewk@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Function 'h1_gpio_get' is receiving 'val' parameter of type u64,
this is being passed to 'send_ec_cmd' as type u8, thus, result
is stored in least significant byte. Due to output format,
the whole 'val' value was being displayed when any of the most
significant bytes are different than zero.
This fix will make sure only least significant byte is displayed
regardless of remaining bytes value.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
On x86 ChromiumOS devices, the pmsg_size is set to 0 (check
/sys/module/ramoops/parameters/pmsg_size): this prevents use of
pstore-pmsg, even if CONFIG_PSTORE_PMSG is enabled. Set pmsg_size
to a value that is consistent with the size used on non-x86 ChromiumOS
devices.
Signed-off-by: Sarthak Kukreti <sarthakkukreti@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.
Fixes: 145d59baff ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The sensorhub->push_data[] array has sensorhub->sensor_num elements.
It's allocated in cros_ec_sensorhub_ring_add(). So the > should be >=
to prevent a read one element beyond the end of the array.
Fixes: 145d59baff ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The use of `delay_usecs` in terminate_request() was replaced with the new
`delay` struct used by the SPI subsystem, however the unit was
set to SPI_DELAY_UNIT_NSECS instead of SPI_DELAY_UNIT_USECS. This fixes that.
Fixes: 7d3ca507fd ("platform/chrome: cros_ec_spi: Use new structure for SPI transfer delays")
Signed-off-by: Benson Leung <bleung@chromium.org>
Events are timestamped in EC time space, their timestamps need to be
converted in host time space.
The assumption is the time delta between when the interrupt is sent
by the EC and when it is receive by the host is a [small] constant.
This is not always true, even with hard-wired interrupt. To mitigate
worst offenders, add a median filter to weed out bigger than expected
delays.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <gwendal@chromium.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To better manage resources, store the number of sensors reported by
the EC.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
When converting to i2c_new_scanned_device(), it was overlooked that a
conversion to i2c_new_client_device() was also needed. Fix it.
Fixes: c82ebf1bf7 ("platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
After registering the ports at probe, get the current port information
from EC and update the Type C connector class ports accordingly.
Co-developed-by: Jon Flatley <jflat@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <bleung@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Read the PD host even status from the EC and send that to the notifier
listeners, for more fine-grained event information.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Convert the ACPI driver into the equivalent platform driver, with the
same ACPI match table as before. This allows the device driver to access
the parent platform EC device and its cros_ec_device struct, which will
be required to communicate with the EC to pull PD Host event information
from it.
Also change the ACPI driver name to "cros-usbpd-notify-acpi" so that
there is no confusion between it and the "regular" platform driver on
platforms that have both CONFIG_ACPI and CONFIG_OF enabled.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Introduce a device driver data structure, cros_usbpd_notify_data, in
which we can store the notifier block object and pointers to the struct
cros_ec_device and struct device objects.
This will make it more convenient to access these pointers when
executing both platform and ACPI callbacks.
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
cros-usbpd-notify notifier was returning NOTIFY_BAD when no host event
was available in the MKBP message.
But MKBP messages are used to transmit other information, so return
NOTIFY_DONE instead, to allow other notifier to be called.
Fixes: ec2daf6e33 ("platform: chrome: Add cros-usbpd-notify driver")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Remove the CONFIG_ prefix from the select statement for MFD_CROS_EC.
Fixes: 2fa2b980e3 ("mfd / platform: cros_ec: Rename config to a better name")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case the change is trivial and the only
reason to do it is because we want to make cros_ec_cmd_xfer() a private
function for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). It allows us to remove some redundand code. In this
case, though, we are changing a bit the behaviour because of returning
-EINVAL on protocol error we propagate the error return for
cros_ec_cmd_xfer_status() function, but I think it will be fine, even
more clear as we don't mask the Linux error code.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case the change is trivial and the only
reason to do it is because we want to make cros_ec_cmd_xfer() a private
function for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Looking at the code I am even unsure that makes sense differentiate
these two errors but let's not change the behaviour for now.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case the change is trivial and the only
reason to do it is because we want to make cros_ec_cmd_xfer() a private
function for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case the change is trivial and the only
reason to do it is because we want to make cros_ec_cmd_xfer() a private
function for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
In practice most drivers that use the EC protocol what really care is if
the result was successful or not, hence, we introduced a
cros_ec_cmd_xfer_status() function that converts EC errors to standard
Linux error codes. On some few cases, though, we are interested on know
if the command is supported or not, and in such cases, just ignore the
error. To achieve this, return a -ENOTSUPP error when the command is not
supported.
This will allow us to finish the conversion of all users to use the
cros_ec_cmd_xfer_status() function instead of cros_ec_cmd_xfer() and
make the latest private to the protocol driver, so users of the protocol
are not confused in which function they should use.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Prashant Malani <pmalani@chromium.org>
In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current
`delay_usecs` with `delay` for this driver.
The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).
[1] commit bebcfd272d ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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: 71cddb7097 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.")
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
RO and RW of EC may have different EC protocol version. If EC transitions
between RO and RW, but AP does not reboot (this is true for fingerprint
microcontroller / cros_fp, but not true for main ec / cros_ec), the AP
still uses the protocol version queried before transition, which can
cause problems. In the case of fingerprint microcontroller, this causes
AP to send the wrong version of EC_CMD_GET_NEXT_EVENT to RO in the
interrupt handler, which in turn prevents RO to clear the interrupt
line to AP, in an infinite loop.
Once an EC_HOST_EVENT_INTERFACE_READY is received, we know that there
might have been a transition between RO and RW, so re-query the protocol.
Signed-off-by: Yicheng Li <yichengli@chromium.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Replace with appropriate types.h.
Also there is no need to include device.h, but mutex.h.
For the pointers to unknown structures use forward declarations.
In the *.c files we need to include all headers that provide APIs
being used in the module.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Merge 0cbb4f9c69 ("platform/chrome: wilco_ec: Include asm/unaligned instead of
linux/ path") from chrome-platform-5.6-fixes into for-next destined branch.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
It seems that we shouldn't try to include the include/linux/ path to
unaligned functions. Just include asm/unaligned.h instead so that we
don't run into compilation warnings like below.
In file included from drivers/platform/chrome/wilco_ec/properties.c:8:0:
include/linux/unaligned/le_memmove.h:7:19: error: redefinition of 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:23,
from arch/ia64/include/asm/smp.h:21,
from include/linux/smp.h:68,
from include/linux/percpu.h:7,
from include/linux/arch_topology.h:9,
from include/linux/topology.h:30,
from include/linux/gfp.h:9,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:18,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from include/linux/platform_data/wilco-ec.h:11,
from drivers/platform/chrome/wilco_ec/properties.c:6:
include/linux/unaligned/le_struct.h:7:19: note: previous definition of 'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 60fb8a8e93 ("platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TEST")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <pmalani@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Jon Flatley <jflat@chromium.org>
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-By: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The 'cros_ec' core driver is the common interface for the cros_ec
transport drivers to do the shared operations to register, unregister,
suspend, resume and handle_event. The interface is provided by including
the header 'include/linux/platform_data/cros_ec_proto.h', however, instead
of have the implementation of these functions in cros_ec_proto.c, it is in
'cros_ec.c', which is a different kernel module. Apart from being a bad
practice, this can induce confusions allowing the users of the cros_ec
protocol to call these functions.
The register, unregister, suspend, resume and handle_event functions
*should* only be called by the different transport drivers (i2c, spi, lpc,
etc.), so make this a bit less confusing by moving these functions from
the public in-kernel space to a private include in platform/chrome, and
then, the interface for cros_ec module and for the cros_ec_proto module is
clean.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This include isn't used. Remove it.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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>
printk messages all require newlines, or it looks very odd in the log
when messages are not on different lines. Add them.
Cc: Nick Crews <ncrews@chromium.org>
Cc: Daniel Campello <campello@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The EC on the Wilco platform responds with 0xFF to commands related to
the keyboard backlight on the absence of a keyboard backlight module.
This change allows the EC driver to continue loading even if the
backlight module is not present.
Fixes: 119a3cb6d6 ("platform/chrome: wilco_ec: Add keyboard backlight LED support")
Signed-off-by: Daniel Campello <campello@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The unregistration should happen in the opposite order of
the registration, so change it accordingly.
No real issue has been noticed, but it is good practice to
keep the correct unregistration order.
Signed-off-by: Daniel Campello <campello@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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>
The init_lock is not declared or used outside of cros_ec_ishtp.c
so make it static to avoid the following warning:
drivers/platform/chrome/cros_ec_ishtp.c:79:1: warning: symbol 'init_lock' was not declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Move from the deprecated i2c_new_probed_device() to the new
i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
As platform_get_irq() now prints an error when the interrupt does not
exist, use platform_get_irq_optional() to get the IRQ which is optional
to avoid below error message during probe:
[ 5.113502] cros_ec_lpcs GOOG0004:00: IRQ index 0 not found
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Add the ability to view response codes as well.
I dropped the EVENT_CLASS since there is only one event per class.
cros_ec_cmd has now been renamed to cros_ec_request_start.
Example:
$ echo 1 > /sys/kernel/debug/tracing/events/cros_ec/enable
$ cat /sys/kernel/debug/tracing/trace
369.416372: cros_ec_request_start: version: 0, command: EC_CMD_USB_PD_POWER_INFO
369.420528: cros_ec_request_done: version: 0, command: EC_CMD_USB_PD_POWER_INFO, ec result: EC_RES_SUCCESS, retval: 16
369.420529: cros_ec_request_start: version: 0, command: EC_CMD_USB_PD_DISCOVERY
369.421383: cros_ec_request_done: version: 0, command: EC_CMD_USB_PD_DISCOVERY, ec result: EC_RES_SUCCESS, retval: 5
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
There are some EC commands that are not included yet as trace commands,
in order to get all the traces for the all supported commands match the
commands accordingly.
Note that a change, adding or removing an EC command, should be
reflected in the cros_ec_trace.c file in order to avoid mismatches
again.
The list of current commands is generated using the following script:
sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1),\\/p' \
include/linux/platform_data/cros_ec_commands.h
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* CrOS EC / MFD / IIO
- Contains tag-ib-chrome-mfd-iio-input-5.5, which is the first part of a
series from Gwendal to refactor sensor code between MFD, CrOS EC, iio
and input in order to add a new sensorhub driver and FIFO processing
* Wilco EC:
- Add support for Dell's USB PowerShare policy control, keyboard
backlight LED driver, and a new test_event file.
- Fixes use after free in wilco_ec's telemetry driver.
* Misc:
- bugfix in cros_usbpd_logger (missing destroy workqueue).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQCtZK6p/AktxXfkOlzbaomhzOwwgUCXeaqtwAKCRBzbaomhzOw
wilIAQCQ3/dpAwg2skKYYf3RBLDJeDLA1id7rNSgMOXc2aKyTAD/fCQtNhwj+Hal
W//04WWngTCQF5fkE9OCJrDwbm5eRwc=
=uOGe
-----END PGP SIGNATURE-----
Merge tag 'tag-chrome-platform-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform changes from Benson Leung:
"CrOS EC / MFD / IIO:
- Contains tag-ib-chrome-mfd-iio-input-5.5, which is the first part
of a series from Gwendal to refactor sensor code between MFD, CrOS
EC, iio and input in order to add a new sensorhub driver and FIFO
processing
Wilco EC:
- Add support for Dell's USB PowerShare policy control, keyboard
backlight LED driver, and a new test_event file.
- Fixes use after free in wilco_ec's telemetry driver.
Misc:
- bugfix in cros_usbpd_logger (missing destroy workqueue)"
* tag 'tag-chrome-platform-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: wilco_ec: fix use after free issue
platform/chrome: cros_ec: Add Kconfig default for cros-ec-sensorhub
Revert "Input: cros_ec_keyb: mask out extra flags in event_type"
Revert "Input: cros_ec_keyb - add back missing mask for event_type"
platform/chrome: cros_ec: handle MKBP more events flag
platform/chrome: cros_ec: Do not attempt to register a non-positive IRQ number
platform/chrome: cros-ec: Record event timestamp in the hard irq
mfd / platform / iio: cros_ec: Register sensor through sensorhub
iio / platform: cros_ec: Add cros-ec-sensorhub driver
mfd / platform: cros_ec: Add sensor_count and make check_features public
platform/chrome: cros_ec: Put docs with the code
platform/chrome: cros_usbpd_logger: add missed destroy_workqueue in remove
platform/chrome: cros_ec: Fix Kconfig indentation
platform/chrome: wilco_ec: Add keyboard backlight LED support
platform/chrome: wilco_ec: Add charging config driver
platform/chrome: wilco_ec: Add Dell's USB PowerShare Policy control
platform/chrome: wilco_ec: Add debugfs test_event file
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: 1210d1e6ba ("platform/chrome: wilco_ec: Add telemetry char device interface")
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Cc: Benson Leung <bleung@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Nick Crews <ncrews@chromium.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Like the other CrOS EC sub-drivers set that depends on his parent and
set default to the parent's value.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The ChromeOS EC has support for signaling to the host that a single IRQ
can serve multiple MKBP (Matrix KeyBoard Protocol) events.
Doing this serves an optimization purpose, as it minimizes the number of
round-trips into the interrupt handling machinery, and it proves
beneficial to sensor timestamping as it keeps the desired synchronization
of event times between the two processors.
This patch adds kernel support for this EC feature, allowing the ec_irq
to loop until all events have been served.
Signed-off-by: Enrico Granata <egranata@chromium.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-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>
Add a layer of sanity checking to cros_ec_register against attempting to
register IRQ values that are not strictly greater than 0.
Signed-off-by: Enrico Granata <egranata@chromium.org>
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>
To improve sensor timestamp precision, given EC and AP are in different
time domains, the AP needs to try to record the exact moment an event
was signalled to the AP by the EC as soon as possible after it happens.
First thing in the hard irq is the best place for this.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <gwendal@chromium.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Fix "unknown type name 'uint32_t'" type errors]
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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>
To avoid doc rot, put function documentations with code, not header.
Use kernel-doc style comments for exported functions.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The driver forgets to destroy workqueue in remove.
Add the missed call to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.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>
Add a device to control the charging algorithm used on Wilco devices,
which will be picked up by the drivers/power/supply/wilco-charger.c
driver. See Documentation/ABI/testing/sysfs-class-power-wilco for the
userspace interface and other info.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
1. Get EC codec's capabilities.
2. Get and set SHM address if any.
3. Transmit language model to EC codec if needed.
4. Start to read audio data from EC codec if receives host event.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20191019143504.1.I5388b69a7a9c551078fed216a77440cee6dedf49@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactor by the following items:
- reformat copyright declaration
- use more specific name "i2s rx"
- use verbose symbol names to separate namespaces
- make some short functions inline
- remove unused TDM-related code
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Acked-By: Benson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20191014180059.02.I43373b9a66dbb70196b3f216b3aa86111c410836@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
USB PowerShare is a policy which affects charging via the special
USB PowerShare port (marked with a small lightning bolt or battery icon)
when in low power states:
- In S0, the port will always provide power.
- In S0ix, if usb_charge is enabled, then power will be supplied to
the port when on AC or if battery is > 50%. Else no power is supplied.
- In S5, if usb_charge is enabled, then power will be supplied to
the port when on AC. Else no power is supplied.
Signed-off-by: Daniel Campello <campello@chromium.org>
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
This change introduces a new debugfs file 'test_event' that when written
to causes the EC to generate a test event.
This adds a second sub cmd for the test event, and pulls out send_ec_cmd
to be a common helper between h1_gpio_get and test_event_set.
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
In cros_usbpd_logger_probe the return value of
create_singlethread_workqueue may be null, it should be checked.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <vpalatin@chromium.org>
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>
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: 2de89fd989 ("platform/chrome: cros_ec: Add EC host command support using rpmsg")
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <ravisadineni@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAl1s8HwACgkQUa+KL4f8
d2HpRg/5AeEuNE5EFEVNZcBingdBh7Cppj9EIsjuY3XRDAxVw/wXdI9uX3PKH9rD
/lwhgMtLn+xZbL+ZBn5kzg7Q9XQ+4i7WHVUikWLJ/fZtE6rZQmilTnC8gX/10L7J
/5Pj47GPTH/kUGvG/lHC+fWyfgzz6uIdUmo/FjaNAGNwduIqjQf9hIGrHMeKAzi+
/dOskN17I4R1HzMskGDG8ICfyyWeoHxxO9/UzZR9hDVV2dnPTGBAi+m7F/KJ4130
KZT9dy0bwyzcb2JEVWohUcXxqogWfra7q6k6xmGOMBEkQj8b3VLh0V1T1JrcPDpF
0bhRvZamolQdBNpXhH3NOWJQhfPKDwZJKa6jEktiOxkKt55/ai8Imxt3ITTlRlF8
SI4yvF6PoX+d12WarFf0RY+88eyt2HwkWhcVnjIAkgT+QthTvvjyTfD1mEdeV+N1
NWBjK5MmiyobTO2mz+1+9qznyGugpBgOuiU0l1WziAjDzhBo3srjkhXrkqcs9FRc
cbcFwubxTqljW1hv3+mExztnIWPbtLfdbDdrP212YRsKaP1r1Gz2VEWzIP4/x5uU
tsZr2frITnHumJ6CNNXZCMhDyY6X7EYRSM4u50bhVd5BUlths571grEsKAsN/yMl
B3x8ynsN7Q5KrbHdbZagr0rd3HEoDlLkzBbpEdx7nijWtrT05HA=
=UcyY
-----END PGP SIGNATURE-----
Merge tag 'ib-mfd-extcon-hid-i2c-iio-input-media-chrome-power-pwm-rtc-sound-v5.4' 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>
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>
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 <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>
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>
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 <enric.balletbo@collabora.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.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>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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 <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>
Add EC host command to inform EC of AP suspend/resume status.
Signed-off-by: Yilun Lin <yllin@chromium.org>
Tested-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <wsa+renesas@sang-engineering.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <bleung@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20190801111541.917256884@infradead.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kernel crashes during suspend due to wrong conversion in
suspend and resume functions.
Use the proper helper to get ishtp_cl_device instance.
Cc: <stable@vger.kernel.org> # 5.2.x: b12bbdc5: HID: intel-ish-hid: fix wrong driver_data usage
Signed-off-by: Hyungwoo Yang <hyungwoo.yang@intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* 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.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQCtZK6p/AktxXfkOlzbaomhzOwwgUCXSbP3AAKCRBzbaomhzOw
wjoNAP4lrY3UboMaQklHLOCxPTFXwIHjImXxJUCrezJj4eBRcwEAz+adSNKieVEY
xNf/yetCkjVnQNMVjGaBJRUp3F+2LwQ=
=/Xj3
-----END PGP SIGNATURE-----
Merge tag 'tag-chrome-platform-for-v5.3' of 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
...
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 <evgreen@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <rajatja@google.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <enric.balletbo@collabora.com>
Reviewed-by: Nick Crews <ncrews@chromium.org>
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 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 <enric.balletbo@collabora.com>
Reviewed-by: Nick Crews <ncrews@chromium.org>
When copying an event to userspace failed, the event queue
lock was never released. This fixes that.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <enric.balletbo@collabora.com>
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 <twawrzynczak@chromium.org>
[rework based on Tim's first approach]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
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 <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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>
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 <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@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>
In commit 37a186225a ("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 a1b89132dc ("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: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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: Rushikesh S Kadam <rushikesh.s.kadam@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Tested-by: Jett Rink <jettrink@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
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 <evgreen@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The 0xF6 command, intended to send and receive 256 byte payloads to
and from the EC, is not needed. The 0xF5 command for 32 byte
payloads is sufficient. This patch removes support for the 0xF6
command and 256 byte payloads.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Boot on AC is a policy which makes the device boot from S5 when AC
power is connected. This is useful for users who want to run their
device headless or with a dock.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
A Property is typically a data item that is stored to NVRAM
by the EC. Each of these data items has an index associated
with it, known as the Property ID (PID). Properties may have
variable lengths, up to a max of WILCO_EC_PROPERTY_MAX_SIZE
bytes. Properties can be simple integers, or they may be more
complex binary data.
This patch adds support for getting and setting properties.
This will be useful for setting the charge algorithm and charge
schedules, which all use properties.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
- Document (kerneldoc) core mfd_add_devices() API
- New Drivers
- Add support for Altera SOCFPGA System Manager
- Add support for Maxim MAX77650/77651 PMIC
- Add support for Maxim MAX77663 PMIC
- Add support for ST Multi-Function eXpander (STMFX)
- New Device Support
- Add support for LEDs to Intel Cherry Trail Whiskey Cove PMIC
- Add support for RTC to SAMSUNG Electronics S2MPA01 PMIC
- Add support for SAM9X60 to Atmel HLCDC (High-end LCD Controller)
- Add support for USB X-Powers AXP 8xx PMICs
- Add support for Integrated Sensor Hub (ISH) to ChromeOS EC
- Add support for USB PD Logger to ChromeOS EC
- Add support for AXP223 to X-Powers AXP series PMICs
- Add support for Power Supply to X-Powers AXP 803 PMICs
- Add support for Comet Lake to Intel Low Power Subsystem
- Add support for Fingerprint MCU to ChromeOS EC
- Add support for Touchpad MCU to ChromeOS EC
- Move TI LM3532 support to LED
- New Functionality
- Add/extend DT support; max77650, max77620
- Add support for power-off; max77620
- Add support for clocking; syscon
- Add support for host sleep event; cros_ec
- Fix-ups
- Trivial; Formatting, spelling, etc; Kconfig, sec-core, ab8500-debugfs
- Remove unused functionality; rk808, da9063-*
- SPDX conversion; da9063-*, atmel-*,
- Adapt/add new register definitions; cs47l35-tables, cs47l90-tables, imx6q-iomuxc-gpr
- Fix-up DT bindings; ti-lmu, cirrus,lochnagar
- Simply obtaining driver data; ssbi, t7l66xb, tc6387xb, tc6393xb
- Bug Fixes
- Fix incorrect defined values; max77620, da9063
- Fix device initialisation; twl6040
- Reset device on init; intel-lpss
- Fix build warnings when !OF; sun6i-prcm
- Register OF match tables; tps65912-spi
- Fix DMI matching; intel_quark_i2c_gpio
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAlzame0ACgkQUa+KL4f8
d2GbBQ//bUoA+hcTo/ZUyQQGmE8axikZ6pacY+Y41pdzzLFoOM3IIz4NpdUF0fP2
6r11zDiM2cL9CuMJl/AMiBv7fifowYykaBUEkkm8n2Cpj/bpLIm8eQy6jf14kqNR
gj9sTy/feBcnZhqLLx9x9W9695nRTE4q3g+mDOj5sXRvZxqcPBaNgWkk5a8vtN9V
yH2XkQSoK0EvvNWjl3pshp7HdKhX8k1xDZ2ghOi3Yk9JmFlg+wrWEKE4KQ7dDoUa
SFXFReIwyleAw4Bc/demT1tSDiNgIPc9ZHtb67dUmDCQgpQqTK/h6WV1JeW1I0vh
AM6n2hnogcbVcJdAHtwS5tR6nVahpUQ1V+XhYDyyHNmx6rqW5q2e3xRF75CT4wBZ
NMIVaWNlih62Y196Exy+6CANHvJyxL6yRgvXkpfyaf9vYdXUrBRUujxn1PzrbkNJ
kJwvZk5yHgg0n5SIV/D4CVy+RHP6uqe4oE4iXNWP5Um06OyVCieqMvoduyGQdLG/
7Xrflc4EmeqTfWZrnW3ljh6sOBC+MQCfIKgRtvkPQ5EpcNU2VPXeNsAvIIHCpWHy
HJY43WRP98DTNyP+/oBrsh56y8n+NwMBcWSmL4tv4cKmGx11bRvp35Mzy1ElPw6Y
Zzttsw8Puz2EMmfGdcRwkZW0KWb5sAvJcImCkrjg/13QPHgcPgk=
=dTSD
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Core Framework:
- Document (kerneldoc) core mfd_add_devices() API
New Drivers:
- Altera SOCFPGA System Manager
- Maxim MAX77650/77651 PMIC
- Maxim MAX77663 PMIC
- ST Multi-Function eXpander (STMFX)
New Device Support:
- LEDs support in Intel Cherry Trail Whiskey Cove PMIC
- RTC support in SAMSUNG Electronics S2MPA01 PMIC
- SAM9X60 support in Atmel HLCDC (High-end LCD Controller)
- USB X-Powers AXP 8xx PMICs
- Integrated Sensor Hub (ISH) in ChromeOS EC
- USB PD Logger in ChromeOS EC
- AXP223 in X-Powers AXP series PMICs
- Power Supply in X-Powers AXP 803 PMICs
- Comet Lake in Intel Low Power Subsystem
- Fingerprint MCU in ChromeOS EC
- Touchpad MCU in ChromeOS EC
- Move TI LM3532 support to LED
New Functionality:
- max77650, max77620: Add/extend DT support
- max77620 power-off
- syscon clocking
- croc_ec host sleep event
Fix-ups:
- Trivial; Formatting, spelling, etc; Kconfig, sec-core, ab8500-debugfs
- Remove unused functionality; rk808, da9063-*
- SPDX conversion; da9063-*, atmel-*,
- Adapt/add new register definitions; cs47l35-tables, cs47l90-tables, imx6q-iomuxc-gpr
- Fix-up DT bindings; ti-lmu, cirrus,lochnagar
- Simply obtaining driver data; ssbi, t7l66xb, tc6387xb, tc6393xb
Bug Fixes:
- Fix incorrect defined values; max77620, da9063
- Fix device initialisation; twl6040
- Reset device on init; intel-lpss
- Fix build warnings when !OF; sun6i-prcm
- Register OF match tables; tps65912-spi
- Fix DMI matching; intel_quark_i2c_gpio"
* tag 'mfd-next-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (65 commits)
mfd: Use dev_get_drvdata() directly
mfd: cros_ec: Instantiate properly CrOS Touchpad MCU device
mfd: cros_ec: Instantiate properly CrOS FP MCU device
mfd: cros_ec: Update the EC feature codes
mfd: intel-lpss: Add Intel Comet Lake PCI IDs
mfd: lochnagar: Add links to binding docs for sound and hwmon
mfd: ab8500-debugfs: Fix a typo ("deubgfs")
mfd: imx6sx: Add MQS register definition for iomuxc gpr
dt-bindings: mfd: LMU: Fix lm3632 dt binding example
mfd: intel_quark_i2c_gpio: Adjust IOT2000 matching
mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L
mfd: tps65912-spi: Add missing of table registration
mfd: axp20x: Add USB power supply mfd cell to AXP803
mfd: sun6i-prcm: Fix build warning for non-OF configurations
mfd: intel-lpss: Set the device in reset state when init
platform/chrome: Add support for v1 of host sleep event
mfd: cros_ec: Add host_sleep_event_v1 command
mfd: cros_ec: Instantiate the CrOS USB PD logger driver
mfd: cs47l90: Make DAC_AEC_CONTROL_2 readable
mfd: cs47l35: Make DAC_AEC_CONTROL_2 readable
...
Add support in code for the new forms of the host sleep event.
Detects the presence of this version of the command at runtime,
and use whichever form the EC supports. At this time, always
request the default timeout, and only report the failing response
via a WARN_ONCE(). Future versions could accept the sleep parameter
from outside the driver, and return the response information to
usermode or elsewhere.
Signed-off-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Rajat Jain <rajatja@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
CrOS EC:
- Add EC host command support using rpmsg
- Add new CrOS USB PD logging driver
- Transfer spi messages at high priority
- Add support to trace CrOS EC commands
- Minor fixes and cleanups in protocol and debugfs
Wilco EC:
- Standardize Wilco EC mailbox interface
- Add h1_gpio status to debugfs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAlzV61YACgkQHwn1ewov
5lgEFw//S7GVmBrFxcqu5wAjF1CW+mOGi3y6nVuTAHanWG/hJGWT+itOwsdDp6c9
TggYgohprz64JAZOPqPCTonV/qbxgsfKrSQRxFDtHH4F1iEUF46fnlsULDKi8VwM
Qzj4g4d//ePsOwHOsYVrbJRU2qKyF6Rm2hpOxKfI9u2Dv5fxLFu6fxUhrSq1Inr6
U67j7pxBwOnBtN2A6hMKHZaOUVkSNYT6azSPO3Z2YH0aky2Baxw/LPoRnbCNhwUQ
iyneX5+K0wpCz2fpnBF/QSh1QBACeyfrO6HHA+flfaejhShaWttrS36Gar+sdHFN
p6eeR1CoEJZbRY79Eetj8Cv5Be1ivVG/SC5JF4O1apAAn87wXLI6AaLG/03ul0vc
KOkcjrXMxISRlAUr+OKD0rg3Uo2oI0ht70XMT9DDsCRNDoVHvkDQJNdkWrKq+E1c
xL4YeLofZpcEN+Oe/WnwUZtYUdY3qcWs+C4hV+h0L0Ke5xir25DEUfF3j3J/uK2B
JEgkTpH8j6YjbGAErBPkTxWt5HE3oWtkK4moPlrfPKfxoSo2eRDvqz68qHsgIn8p
WBM+FSr+dQ7qyYDigMKrFSesiBpwCBI4lIgPxkvTxqbubaoZcsABHm3BUGjykXII
E5z2qsgRnDrB+uGGDkTvDoR0Kr3U0hGlag7u/N61H86PoiMLUig=
=NF5N
-----END PGP SIGNATURE-----
Merge tag 'tag-chrome-platform-for-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"CrOS EC:
- Add EC host command support using rpmsg
- Add new CrOS USB PD logging driver
- Transfer spi messages at high priority
- Add support to trace CrOS EC commands
- Minor fixes and cleanups in protocol and debugfs
Wilco EC:
- Standardize Wilco EC mailbox interface
- Add h1_gpio status to debugfs"
* tag 'tag-chrome-platform-for-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_ec_proto: Add trace event to trace EC commands
platform/chrome: cros_ec_debugfs: Use cros_ec_cmd_xfer_status helper
platform/chrome: cros_ec: Add EC host command support using rpmsg
platform/chrome: wilco_ec: Add h1_gpio status to debugfs
platform/chrome: wilco_ec: Standardize mailbox interface
platform/chrome: cros_ec_proto: check for NULL transfer function
platform/chrome: Add CrOS USB PD logging driver
platform/chrome: cros_ec_spi: Transfer messages at high priority
platform/chrome: cros_ec_debugfs: no need to check return value of debugfs_create functions
platform/chrome: cros_ec_debugfs: Remove dev_warn when console log is not supported
Using scripts/coccinelle/api/stream_open.cocci added in 10dce8af34
("fs: stream_open - opener for stream-like files so that read and write
can run simultaneously without deadlock"), search and convert to
stream_open all in-kernel nonseekable_open users for which read and
write actually do not depend on ppos and where there is no other methods
in file_operations which assume @offset access.
I've verified each generated change manually - that it is correct to convert -
and each other nonseekable_open instance left - that it is either not correct
to convert there, or that it is not converted due to current stream_open.cocci
limitations. The script also does not convert files that should be valid to
convert, but that currently have .llseek = noop_llseek or generic_file_llseek
for unknown reason despite file being opened with nonseekable_open (e.g.
drivers/input/mousedev.c)
Among cases converted 14 were potentially vulnerable to read vs write deadlock
(see details in 10dce8af34):
drivers/char/pcmcia/cm4000_cs.c:1685:7-23: ERROR: cm4000_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/gnss/core.c:45:1-17: ERROR: gnss_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/hid/uhid.c:635:1-17: ERROR: uhid_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/infiniband/core/user_mad.c:988:1-17: ERROR: umad_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/input/evdev.c:527:1-17: ERROR: evdev_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/input/misc/uinput.c:401:1-17: ERROR: uinput_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/isdn/capi/capi.c:963:8-24: ERROR: capi_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/leds/uleds.c:77:1-17: ERROR: uleds_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/media/rc/lirc_dev.c:198:1-17: ERROR: lirc_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/s390/char/fs3270.c:488:1-17: ERROR: fs3270_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/usb/misc/ldusb.c:310:1-17: ERROR: ld_usb_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
drivers/xen/evtchn.c:667:8-24: ERROR: evtchn_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
net/batman-adv/icmp_socket.c:80:1-17: ERROR: batadv_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
net/rfkill/core.c:1146:8-24: ERROR: rfkill_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
and the rest were just safe to convert to stream_open because their read and
write do not use ppos at all and corresponding file_operations do not
have methods that assume @offset file access(*):
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:631:8-24: WARNING: mpc52xx_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_ibox_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_ibox_stat_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_mbox_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_mbox_stat_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_wbox_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/powerpc/platforms/cell/spufs/file.c:591:8-24: WARNING: spufs_wbox_stat_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/um/drivers/harddog_kern.c:88:8-24: WARNING: harddog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
arch/x86/kernel/cpu/microcode/core.c:430:33-49: WARNING: microcode_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/char/ds1620.c:215:8-24: WARNING: ds1620_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/char/dtlk.c:301:1-17: WARNING: dtlk_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/char/ipmi/ipmi_watchdog.c:840:9-25: WARNING: ipmi_wdog_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/char/pcmcia/scr24x_cs.c:95:8-24: WARNING: scr24x_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/char/tb0219.c:246:9-25: WARNING: tb0219_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/firewire/nosy.c:306:8-24: WARNING: nosy_ops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/hwmon/fschmd.c:840:8-24: WARNING: watchdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/hwmon/w83793.c:1344:8-24: WARNING: watchdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/infiniband/core/ucma.c:1747:8-24: WARNING: ucma_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/infiniband/core/ucm.c:1178:8-24: WARNING: ucm_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/infiniband/core/uverbs_main.c:1086:8-24: WARNING: uverbs_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/input/joydev.c:282:1-17: WARNING: joydev_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/pci/switch/switchtec.c:393:1-17: WARNING: switchtec_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/platform/chrome/cros_ec_debugfs.c:135:8-24: WARNING: cros_ec_console_log_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/rtc/rtc-ds1374.c:470:9-25: WARNING: ds1374_wdt_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/rtc/rtc-m41t80.c:805:9-25: WARNING: wdt_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/s390/char/tape_char.c:293:2-18: WARNING: tape_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/s390/char/zcore.c:194:8-24: WARNING: zcore_reipl_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/s390/crypto/zcrypt_api.c:528:8-24: WARNING: zcrypt_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/spi/spidev.c:594:1-17: WARNING: spidev_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/staging/pi433/pi433_if.c:974:1-17: WARNING: pi433_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/acquirewdt.c:203:8-24: WARNING: acq_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/advantechwdt.c:202:8-24: WARNING: advwdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/alim1535_wdt.c:252:8-24: WARNING: ali_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/alim7101_wdt.c:217:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ar7_wdt.c:166:8-24: WARNING: ar7_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/at91rm9200_wdt.c:113:8-24: WARNING: at91wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ath79_wdt.c:135:8-24: WARNING: ath79_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/bcm63xx_wdt.c:119:8-24: WARNING: bcm63xx_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/cpu5wdt.c:143:8-24: WARNING: cpu5wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/cpwd.c:397:8-24: WARNING: cpwd_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/eurotechwdt.c:319:8-24: WARNING: eurwdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/f71808e_wdt.c:528:8-24: WARNING: watchdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/gef_wdt.c:232:8-24: WARNING: gef_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/geodewdt.c:95:8-24: WARNING: geodewdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ib700wdt.c:241:8-24: WARNING: ibwdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ibmasr.c:326:8-24: WARNING: asr_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/indydog.c:80:8-24: WARNING: indydog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/intel_scu_watchdog.c:307:8-24: WARNING: intel_scu_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/iop_wdt.c:104:8-24: WARNING: iop_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/it8712f_wdt.c:330:8-24: WARNING: it8712f_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ixp4xx_wdt.c:68:8-24: WARNING: ixp4xx_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/ks8695_wdt.c:145:8-24: WARNING: ks8695wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/m54xx_wdt.c:88:8-24: WARNING: m54xx_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/machzwd.c:336:8-24: WARNING: zf_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/mixcomwd.c:153:8-24: WARNING: mixcomwd_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/mtx-1_wdt.c:121:8-24: WARNING: mtx1_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/mv64x60_wdt.c:136:8-24: WARNING: mv64x60_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/nuc900_wdt.c:134:8-24: WARNING: nuc900wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/nv_tco.c:164:8-24: WARNING: nv_tco_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pc87413_wdt.c:289:8-24: WARNING: pc87413_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd.c:698:8-24: WARNING: pcwd_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd.c:737:8-24: WARNING: pcwd_temp_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd_pci.c:581:8-24: WARNING: pcipcwd_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd_pci.c:623:8-24: WARNING: pcipcwd_temp_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd_usb.c:488:8-24: WARNING: usb_pcwd_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pcwd_usb.c:527:8-24: WARNING: usb_pcwd_temperature_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pika_wdt.c:121:8-24: WARNING: pikawdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/pnx833x_wdt.c:119:8-24: WARNING: pnx833x_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/rc32434_wdt.c:153:8-24: WARNING: rc32434_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/rdc321x_wdt.c:145:8-24: WARNING: rdc321x_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/riowd.c:79:1-17: WARNING: riowd_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sa1100_wdt.c:62:8-24: WARNING: sa1100dog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sbc60xxwdt.c:211:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sbc7240_wdt.c:139:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sbc8360.c:274:8-24: WARNING: sbc8360_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sbc_epx_c3.c:81:8-24: WARNING: epx_c3_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sbc_fitpc2_wdt.c:78:8-24: WARNING: fitpc2_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sb_wdog.c:108:1-17: WARNING: sbwdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sc1200wdt.c:181:8-24: WARNING: sc1200wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sc520_wdt.c:261:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/sch311x_wdt.c:319:8-24: WARNING: sch311x_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/scx200_wdt.c:105:8-24: WARNING: scx200_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/smsc37b787_wdt.c:369:8-24: WARNING: wb_smsc_wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/w83877f_wdt.c:227:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/w83977f_wdt.c:301:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wafer5823wdt.c:200:8-24: WARNING: wafwdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/watchdog_dev.c:828:8-24: WARNING: watchdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdrtas.c:379:8-24: WARNING: wdrtas_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdrtas.c:445:8-24: WARNING: wdrtas_temp_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt285.c:104:1-17: WARNING: watchdog_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt977.c:276:8-24: WARNING: wdt977_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt.c:424:8-24: WARNING: wdt_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt.c:484:8-24: WARNING: wdt_temp_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt_pci.c:464:8-24: WARNING: wdtpci_fops: .write() has stream semantic; safe to change nonseekable_open -> stream_open.
drivers/watchdog/wdt_pci.c:527:8-24: WARNING: wdtpci_temp_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
net/batman-adv/log.c:105:1-17: WARNING: batadv_log_fops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
sound/core/control.c:57:7-23: WARNING: snd_ctl_f_ops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
sound/core/rawmidi.c:385:7-23: WARNING: snd_rawmidi_f_ops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
sound/core/seq/seq_clientmgr.c:310:7-23: WARNING: snd_seq_f_ops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
sound/core/timer.c:1428:7-23: WARNING: snd_timer_f_ops: .read() has stream semantic; safe to change nonseekable_open -> stream_open.
One can also recheck/review the patch via generating it with explanation comments included via
$ make coccicheck MODE=patch COCCI=scripts/coccinelle/api/stream_open.cocci SPFLAGS="-D explain"
(*) This second group also contains cases with read/write deadlocks that
stream_open.cocci don't yet detect, but which are still valid to convert to
stream_open since ppos is not used. For example drivers/pci/switch/switchtec.c
calls wait_for_completion_interruptible() in its .read, but stream_open.cocci
currently detects only "wait_event*" as blocking.
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Yongzhi Pan <panyongzhi@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Tejun Heo <tj@kernel.org>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Nikolaus Rath <Nikolaus@rath.org>
Cc: Han-Wen Nienhuys <hanwen@google.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "James R. Van Zandt" <jrv@vanzandt.mv.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: Lubomir Rintel <lkundrak@v3.sk> [scr24x_cs]
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Johan Hovold <johan@kernel.org>
Cc: David Herrmann <dh.herrmann@googlemail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jean Delvare <jdelvare@suse.com>
Acked-by: Guenter Roeck <linux@roeck-us.net> [watchdog/* hwmon/*]
Cc: Rudolf Marek <r.marek@assembler.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
Acked-by: Logan Gunthorpe <logang@deltatee.com> [drivers/pci/switch/switchtec]
Acked-by: Bjorn Helgaas <bhelgaas@google.com> [drivers/pci/switch/switchtec]
Cc: Benson Leung <bleung@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [platform/chrome]
Cc: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> [rtc/*]
Cc: Mark Brown <broonie@kernel.org>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Zwane Mwaikambo <zwanem@gmail.com>
Cc: Marek Lindner <mareklindner@neomailbox.ch>
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Cc: Antonio Quartulli <a@unstable.cc>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-By: Benson Leung <bleung@chromium.org>
This is useful to see which EC commands are being executed and when.
To enable:
echo 1 > /sys/kernel/debug/tracing/events/cros_ec/enable
Example:
cros_ec_cmd: version: 0, command: EC_CMD_GET_VERSION
cros_ec_cmd: version: 0, command: EC_CMD_GET_PROTOCOL_INFO
cros_ec_cmd: version: 1, command: EC_CMD_GET_CMD_VERSIONS
cros_ec_cmd: version: 1, command: EC_CMD_USB_PD_CONTROL
The list of current commands is generated using the following script:
sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1),\\/p' include/linux/mfd/cros_ec_commands.h
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Ross Zwisler <zwisler@google.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer() so we can remove some redundant code.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
tests, we need to ensure that the H1 chip is properly setting
some GPIO lines. The h1_gpio attribute exposes the state
of the lines:
- ENTRY_TO_FACT_MODE in BIT(0)
- SPI_CHROME_SEL in BIT(1)
There are two reasons that I am exposing this in debugfs,
and not as a GPIO:
1. This is only useful for testing, so end users shouldn't ever
care about this. In fact, if it passes the tests, then the value of
h1_gpio will always be 2, so it would be really uninteresting for users.
2. This GPIO is not connected to, controlled by, or really even related
to the AP. The GPIO runs between the EC and the H1 security chip.
Changes in v4:
- Use "0x02x\n" instead of "02x\n" for format string
- Use DEFINE_DEBUGFS_ATTRIBUTE()
- Add documentation
Changes in v3:
- Fix documentation to correspond with formatting change in v2.
Changes in v2:
- Zero out the unused fields in the request.
- Format result as "%02x\n" instead of as a decimal.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw debugfs interface, and reading or writing
properties such as the Peak Shift policy (this last to be submitted soon).
Similarly for the response message from the EC, the current interface
assumes that the first byte of data is always 0, and the second byte
is unused. However, in both setting and getting the RTC time, in the
debugfs interface, and for reading and writing properties, this isn't
true.
The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
specify when and when not to skip these initial bytes in the sent and
received message. They are confusing and used so much that they are
normal, and not exceptions. In addition, the first byte of
response in the debugfs interface is still always skipped, which is
weird, since this raw interface should be giving the entire result.
Additionally, sent messages assume the first byte is a command, and so
struct wilco_ec_message contains the "command" field. In setting or
getting properties however, the first byte is not a command, and so this
field has to be filled with a byte that isn't actually a command. This
is again inconsistent.
wilco_ec_message contains a result field as well, copied from
wilco_ec_response->result. The message result field should be removed:
if the message fails, the cause is already logged, and the callers are
alerted. They will never care about the actual state of the result flag.
These flags and different cases make the wilco_ec_transfer() function,
used in wilco_ec_mailbox(), really gross, dealing with a bunch of
different cases. It's difficult to figure out what it is doing.
Finally, making these assumptions about the structure of a message make
it so that the messages do not correspond well with the specification
for the EC's mailbox interface. For instance, this interface
specification may say that MBOX[9] in the received message contains
some information, but the calling code needs to remember that the first
byte of response is always skipped, and because it didn't set the
RESPONSE_RAW flag, the next byte is also skipped, so this information
is actually contained within wilco_ec_message->response_data[7]. This
makes it difficult to maintain this code in the future.
To fix these problems this patch standardizes the mailbox interface by:
- Removing the WILCO_EC_FLAG_RAW* flags
- Removing the command and reserved_raw bytes from wilco_ec_request
- Removing the mbox0 byte from wilco_ec_response
- Simplifying wilco_ec_transfer() because of these changes
- Gives the callers of wilco_ec_mailbox() the responsibility of exactly
and consistently defining the structure of the mailbox request and
response
- Removing command and result from wilco_ec_message.
This results in the reduction of total code, and makes it much more
maintainable and understandable.
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
As new transfer mechanisms are added to the EC codebase, they may
not support v2 of the EC protocol.
If the v3 initial handshake transfer fails, the kernel will try
and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
will be NULL, and the code will end up causing a kernel panic.
Add a check for NULL before calling the transfer function, along
with a helpful comment explaining how one might end up in this
situation.
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The CrOS USB PD logging feature is logically separate functionality of
the charge manager, hence has its own driver. The driver logs the event
data for the USB PD charger available in some ChromeOS Embedded
Controllers.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
[remove macro to APPEND_STRING and minor cleanups]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
The software running on the Chrome OS Embedded Controller (cros_ec)
handles SPI transfers in a bit of a wonky way. Specifically if the EC
sees too long of a delay in a SPI transfer it will give up and the
transfer will be counted as failed. Unfortunately the timeout is
fairly short, though the actual number may be different for different
EC codebases.
We can end up tripping the timeout pretty easily if we happen to
preempt the task running the SPI transfer and don't get back to it for
a little while.
Historically this hasn't been a _huge_ deal because:
1. On old devices Chrome OS used to run PREEMPT_VOLUNTARY. That meant
we were pretty unlikely to take a big break from the transfer.
2. On recent devices we had faster / more processors.
3. Recent devices didn't use "cros-ec-spi-pre-delay". Using that
delay makes us more likely to trip this use case.
4. For whatever reasons (I didn't dig) old kernels seem to be less
likely to trip this.
5. For the most part it's kinda OK if a few transfers to the EC fail.
Mostly we're just polling the battery or doing some other task
where we'll try again.
Even with the above things, this issue has reared its ugly head
periodically. We could solve this in a nice way by adding reliable
retries to the EC protocol [1] or by re-designing the code in the EC
codebase to allow it to wait longer, but that code doesn't ever seem
to get changed. ...and even if it did, it wouldn't help old devices.
It's now time to finally take a crack at making this a little better.
This patch isn't guaranteed to make every cros_ec SPI transfer
perfect, but it should improve things by a few orders of magnitude.
Specifically you can try this on a rk3288-veyron Chromebook (which is
slower and also _does_ need "cros-ec-spi-pre-delay"):
md5sum /dev/zero &
md5sum /dev/zero &
md5sum /dev/zero &
md5sum /dev/zero &
while true; do
cat /sys/class/power_supply/sbs-20-000b/charge_now > /dev/null;
done
...before this patch you'll see boatloads of errors. After this patch I
don't see any in the testing I did.
The way this patch works is by effectively boosting the priority of
the cros_ec transfers. As far as I know there is no simple way to
just boost the priority of the current process temporarily so the way
we accomplish this is by queuing the work on the system_highpri_wq.
NOTE: this patch relies on the fact that the SPI framework attempts to
push the messages out on the calling context (which is the one that is
boosted to high priority). As I understand from earlier (long ago)
discussions with Mark Brown this should be a fine assumption. Even if
it isn't true sometimes this patch will still not make things worse.
[1] https://crbug.com/678675
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
If the debugfs interface is enabled, every time a CrOS device is
instantiated a warning like this can appear for every probed device.
"device does not support reading the console log"
The warning message adds nothing, rather it is source of confusion as
this is expected on some cases. For example, on Samus, that has a
cros-ec and a cros-pd instance the message appears twice, and I suspect
this will happen also on those devices that has a non-standard EC.
If the command is not supported just return silently and don't print the
warning, otherwise the code will already print an error.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Before, ec->data_buffer could be written to from multiple
contexts at the same time. Since the ec is shared data,
it needs to be inside the mutex as well.
Fixes: 7b3d4f44ab ("platform/chrome: Add new driver for Wilco EC")
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.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: 7b3d4f44ab ("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>
This Embedded Controller has an internal RTC that is exposed
as a standard RTC class driver with read/write functionality.
The driver is added to the drivers/rtc/ so that the maintainer of that
directory will be able to comment on this change, as that maintainer is
the expert on this system. In addition, the driver code is called
indirectly after a corresponding device is registered from core.c,
as opposed to core.c registering the driver callbacks directly.
To test:
> hwclock --show --rtc /dev/rtc1
2007-12-31 16:01:20.460959-08:00
> hwclock --systohc --rtc /dev/rtc1
> hwclock --show --rtc /dev/rtc1
2018-11-29 17:08:00.780793-08:00
> hwclock --show --rtc /dev/rtc1
2007-12-31 16:01:20.460959-08:00
> hwclock --systohc --rtc /dev/rtc1
> hwclock --show --rtc /dev/rtc1
2018-11-29 17:08:00.780793-08:00
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Nick Crews <ncrews@chromium.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
[Fix the sparse warning: symbol 'wilco_ec_rtc_read/write' was not declared]
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
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>
In order to allow this code to be re-used, remove the dependency
on the rest of the cros_ec code from the cros_ec_lpc_mec functions.
Instead of using a hardcoded register base address of 0x800 have
this be passed in to cros_ec_lpc_mec_init(). The existing cros_ec
use case now passes in the 0x800 base address this way.
There are some error checks that happen in cros_ec_lpc_mec_in_range()
that probably shouldn't be there, as they are checking kernel-space
callers and not user-space input. However, we'll just do the refactor in
this patch, and in a future patch might remove this error checking and
fix all the instances of code that calls this.
There's a similar problem in cros_ec_lpc_read_bytes(), where we return a
checksum, but on error just return 0. This should probably be changed so
that it returns int, but we don't want to have to mess with all the
calling code for this fix. Maybe we'll come back through later and fix
this.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Nick Crews <ncrews@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
This driver no longer has any pr_{level} messages. Remove the pr_fmt().
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
This driver no longer has any pr_{level} messages. Remove the pr_fmt().
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also change the term 'Chrome OS' for 'ChromeOS' to be
coherent with other drivers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also change the description for one more appropriate.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also remove the license boiler-plate and redundant driver
description.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also fix the module license mismatch and change the
description for a more descriptive phrase.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also change the description for one more appropriate.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Adopt the SPDX license identifier headers to ease license compliance
management. Also fix the module license mismatch and change the term
'Chrome OS' for 'ChromeOS' to be coherent with other drivers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Due to the way attribute groups visibility work, the function
cros_ec_lightbar_attrs_are_visible is called multiple times, once per
attribute, and each of these calls makes an EC transaction. For what is
worth the EC log reports multiple errors on boot when the lightbar is
not available. Instead, check if the EC has a lightbar in the probe
function and only instantiate the device.
Ideally we should have instantiate the driver only if the
EC_FEATURE_LIGHTBAR is defined, but that's not possible because that flag
is not in the very first Pixel Chromebook (Link), only on Samus. So, the
driver is instantiated by his parent always.
This patch changes a bit the actual behaviour. Before the patch if an EC
doesn't have a lightbar an empty lightbar folder is created in
/sys/class/chromeos/<ec-device-name>, after the patch the empty folder is
not created, so, the folder is only created if the lightbar exists.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The cros-ec-vbc driver is DT-only and there is a DT property that
indicates if the EC has the VCB NVRAM, in such case instantiate the
driver but don't instantiate on the other cases.
To do this move the check code to its parent instead of play with the
attribute group visibility. This changes a bit the actual behaviour.
Before the patch if an EC doesn't have a VBC NVRAM an empty vbc folder
is created in /sys/class/chromeos/<ec-device-name>, after the patch the
empty folder is not created, so, the folder is only created if the vbc
is set.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The entire way how cros debugfs attibutes are created is broken.
cros_ec_sysfs should be its own driver and its attributes should be
associated with the sysfs driver not the mfd driver.
The patch also adds the sysfs documentation.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The entire way how cros debugfs attibutes are created is broken.
cros_ec_debugfs should be its own driver and its attributes should be
associated with a debugfs driver not the mfd driver.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The entire way how cros sysfs attibutes are created is broken.
cros_ec_vbc should be its own driver and its attributes should be
associated with a vbc driver not the mfd driver. In order to retain
the path, the vbc attributes are attached to the cros_class.
The patch also adds the sysfs documentation.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The entire way how cros sysfs attibutes are created is broken.
cros_ec_lightbar should be its own driver and its attributes should be
associated with a lightbar driver not the mfd driver. In order to retain
the path, the lightbar attributes are attached to the cros_class.
The patch also adds the sysfs documentation.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Use devm_mfd_add_devices() for adding cros-ec core MFD child devices. This
reduces the need of remove callback from platform/chrome for removing the
MFD child devices.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
reasons, and there are very few cases in which they should be treated as
wakeup interrupts (particularly, when a certain
MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
mainline cros_ec_sensor driver yet). Most of the time, they are benign
sensor readings. In any case, the top-level cros_ec device doesn't know
enough to determine that they should wake the system, and so it should
not report the event. This would be the job of the cros_ec_sensors
driver to parse.
This patch adds checks to cros_ec_get_next_event() such that it doesn't
signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.
This patch is particularly relevant on devices like Scarlet (Rockchip
RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
reports sensor events much more frequently. This was causing
/sys/power/wakeup_count to increase very frequently, often needlessly
interrupting our ability to suspend the system.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
cros_ec_get_next_event() is documented to return 0 for success and
negative for errors. It currently returns negative for some errors, and
non-negative (number of bytes received) for success (including some "no
data available" responses as zero). This mostly works out OK, because the
callers were more or less ignoring the documentation, and only treating
positive values as success (and indepdently checking the modification of
'wakeup').
Let's button this up by avoiding pretending to handle event/wakeup
distinctions when no event info was retrieved (i.e., returned 0 bytes).
And fix the documentation of cros_ec_get_host_event() and
cros_ec_get_next_event() to accurately describe their behavior.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
This commit allows cros_ec_lpc to register a direct IRQ instead of relying
on the ACPI notification chain to receive MKBP events.
This change is done in the interest of allowing reduced jitter in the
communication path between the CrOS EC and the host for receiving sensor
data.
Signed-off-by: Enrico Granata <egranata@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Commit 57e94c8b97 caused cros-ec keyboard events
be truncated on many chromebooks so that Left and Right keys on Column 12 were
always 0. Use ret as memcpy len to fix this.
The old code was using ec_dev->event_size, which is the event payload/data size
excluding event_type header, for the length of the memcpy operation. Use ret
as memcpy length to avoid the off by one and copy the whole msg->data.
Fixes: 57e94c8b97 ("mfd: cros-ec: Increase maximum mkbp event size")
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Karlson <jekarlson@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The cros-ec-lpc driver lives in drivers/platform because is platform
specific, however there are two includes (cros_ec_lpc_mec.h and
cros_ec_lpc_reg.h) that lives in include/linux/mfd. These two includes
are only used for the platform driver and are not really related to the
MFD subsystem, so move the includes from include/linux/mfd to
drivers/platform/chrome.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
cros_ec_i2c and cros_ec_spi drivers moved from mfd
to chrome platform.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAlt8XgMACgkQHwn1ewov
5li8MQ//RiM40heoQL4IaZbivsKlB1gT2zX/NvxfL54OX3eG35IYuyFiNKX35bPq
suupcZq2tk5btj1Wu5ljXXExc1KS8vCDwCVA9ljZGZ97sr7ttGzwX0oVxmXFjt6J
2L+RT40rc/H33jIAhWcxi73cwVE9Of8ao+UbnZNWxL30ddX3r6lH2NS1gHta6Mb9
33qReMT5Z1TB+OCZd+ktkC6fS3p1LESIHY/jfu6okAxbd7auJC7q5hl6ngeGFrkx
cLs8dKlHFWBcmdjIiY8f93vgokKxbO+vnx/0m+7uPa36vOi2RbEz+Hgy5+v1scZ0
XOasPnY9AbJLuX+5q6ukYNVD536xlbeThsvxeN4ymjTLnlnRzLw/1+ezSTKYAFPQ
6lJkudcLLmGDia7wH1mTjyHdU0ZsYWH9SzgUf/panX5fdy7wpPU1D4vfm36jS2wJ
cvNXPwDZ3Pqbp24IFtFR3phgn4KNr5dXPfiHaItcPb0Fykol5tFw8tAnChWlDyCX
fJ6U/Xj0tmQ0Awj/SEEuCWALgt8X3czAz/SSUSfLm0zSixm4kJ2gQHV1aP7dXR3f
osxhISHPxt9+6CrnUodUYpD1QG60O+mdrx7tcs4WVPzT9Fpnp62YgUkey6SLeyhj
itQtghxlYxJeB1hgU3Ez7KObiujA0UCrRKm5BklRV0gyM7GqSKk=
=HNMG
-----END PGP SIGNATURE-----
Merge tag 'chrome-platform-for-linus-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform
Pull chrome platform updates from Benson Leung.
Everything but the SPDX identifier updates actually came in earlier
through the MFD merge.
* tag 'chrome-platform-for-linus-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: chromeos_tbmc - fix SPDX identifier
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAltCtRsACgkQHwn1ewov
5lhIQg//fEoZkDIjFsWIDn2WB1brLS2q7Wnv01NJR3/ZxzA29JYQ1lNA3nCM5mVS
Bf1RqPfVwIO6/d+QA5AnxLBRpRYJ7F7NKwvTvrqQ9QpFPNOLk0m7uUNYSsWTOqlA
uoReeFfJ2/UuUavd04KJRPv1ilCjoki2Wyc4lqVFSJSGZZjDWUOASAiOd666h26F
avW4qBUpJm7mmAfOFh76g6c/Jq713fJkqfdRcstRajB13oLjotfRxa/Rhxb+y8aX
RrlNz8PChIjpYTQ7yDwfLU8u5TDg2sEtz8529YaddDNBWkRyC2BIrKrkev+GIiUx
SZiPT7nmvpEOGJoPQodUa5bgE/9db7pPKb7XqUNmYQIS71jtLaOXMNje9uLn2NHo
CJtoVHJXZ9YWyODn1NPvFM28aysis14PWQGWK1HRq5PCfb8TpZ8W0QTaJV18pUBe
vdrmgxPcdnkAn0Tbt92oBiUrsVT3zoSQuLw9FPuy3ne9Oz+TKHa6kKzjcMMkynwb
mFmDhf822mfbUVkjUpNTtLJ0UMsNtd/tphDUmv1OQDRNStZS/MI4+xr23bPZbf/X
blrIjz5fM6uhUbHSKztWnntGAtzbEy75zzyhh2w99JVzJtK4UK+3ET40Kko4KUIx
1ppYa2wOJVVSvd733O8mYGmzQotKuFc5lyNozlB4EUT8ro/zW1Q=
=EhHj
-----END PGP SIGNATURE-----
Merge branches 'ib-mfd-4.19', 'ib-mfd-gpio-pinctrl-4.19', 'ib-mfd-i915-media-platform-4.19' and 'ib-mfd-regulator-4.19', tag 'ib-platform-chrome-mfd-move-cros-ec-transport-for-4.19' into ibs-for-mfd-merged
Immutable branch (mfd, chrome) due for the v4.19 window
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAltCtRsACgkQHwn1ewov
5lhIQg//fEoZkDIjFsWIDn2WB1brLS2q7Wnv01NJR3/ZxzA29JYQ1lNA3nCM5mVS
Bf1RqPfVwIO6/d+QA5AnxLBRpRYJ7F7NKwvTvrqQ9QpFPNOLk0m7uUNYSsWTOqlA
uoReeFfJ2/UuUavd04KJRPv1ilCjoki2Wyc4lqVFSJSGZZjDWUOASAiOd666h26F
avW4qBUpJm7mmAfOFh76g6c/Jq713fJkqfdRcstRajB13oLjotfRxa/Rhxb+y8aX
RrlNz8PChIjpYTQ7yDwfLU8u5TDg2sEtz8529YaddDNBWkRyC2BIrKrkev+GIiUx
SZiPT7nmvpEOGJoPQodUa5bgE/9db7pPKb7XqUNmYQIS71jtLaOXMNje9uLn2NHo
CJtoVHJXZ9YWyODn1NPvFM28aysis14PWQGWK1HRq5PCfb8TpZ8W0QTaJV18pUBe
vdrmgxPcdnkAn0Tbt92oBiUrsVT3zoSQuLw9FPuy3ne9Oz+TKHa6kKzjcMMkynwb
mFmDhf822mfbUVkjUpNTtLJ0UMsNtd/tphDUmv1OQDRNStZS/MI4+xr23bPZbf/X
blrIjz5fM6uhUbHSKztWnntGAtzbEy75zzyhh2w99JVzJtK4UK+3ET40Kko4KUIx
1ppYa2wOJVVSvd733O8mYGmzQotKuFc5lyNozlB4EUT8ro/zW1Q=
=EhHj
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAltD8WcACgkQHwn1ewov
5ljpGBAAtU0XoIn0p+ujvGdX/EdMrt3vzanjg995Z7yncUk3N4Ahx5q4l9NV7tTL
FulOH4mhA/1djVZk5q+Rr7vENHaZW+T4v6GMhG9wqhk2VBd6e3s2It3y+LKzQ0oI
Bpc6CyGAfNrCNXAK8pkeBf82771+X9QL5KIIh5ZRtGEV/lKzJPPNJ/2Q78m/eh85
Z/izB5v0dY9YfwsIQTKBoIMw7ddz3RPWiGsc1HVNarM9Jz0G+Mj83hwnMoraUvBd
P2JF0xL072sL59T+PCJlUVuh5abx0kh1nei2eROr3dqcunROG3sbhTFvQ7x/OOCN
KbxDWascFi+8D8M6QYM3orvc4LZF8GMf8aaRlill6S/KFwcD28uNtXMAARJgdvR4
v/j4HvYo5dmMtxMiRR7kkm7er3tWsUevXEQg2TLqbbJln8Wp/3jPcKM46uV5diLd
Kei2iiM7cTuLMU36StHW6VbLk9tDkVcJzjKf8968j/ZrvsRw/79j4wVVuNcZSHx5
2QTacquSPk1h0ax8bOXjZf/Gb8VlD34AquJOpYzZbmQggXO3KX9kXcoW5gdM6UjF
dQmdobGueUD+C9qT647XAggS7OI8As/dv1iIHBzWYwnq871wWDFiUjbs3VDFmeoU
n+EybA4UQCxiFHL75PmW98jB2erZ3b/QDQNTECG8AyBQ7N90L8c=
=u5Ht
-----END PGP SIGNATURE-----
Merge tag 'ib-platform-chrome-mfd-move-cros-ec-transport-for-4.19' into working-branch-for-4.19
Immutable branch (mfd, chrome) due for the v4.19 window
Immutable Branch which moves the cros_ec_i2c and cros_ec_spi
transport drivers from mfd to platform/chrome. Changes in arm are a simple
rename in defconfigs. Change in input is a rename in help text.
There are some cros-ec transport drivers (I2C, SPI) living in MFD, while
others (LPC) living in drivers/platform. The transport drivers are more
platform specific. So, move the I2C and SPI transport drivers to the
platform/chrome directory. The patch also removes the MFD_ prefix of
their Kconfig symbols.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Original submission was GPLv2 only, so mark as GPL-2.0.
Also restored some descriptive lines that were there before.
Signed-off-by: Benson Leung <bleung@chromium.org>
Further changes from Dmitry related to the removal of platform data from
atmel_mxt_ts and chromeos_laptop. This time, we have some changes that
teach chromeos_laptop how to supply acpi properties for some input devices
so that the peripheral driver doesn't have to do dmi matching on some
Chromebook platforms.
Also adds the Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.
Other misc. cleanup.
Thanks,
Benson
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAlsUrmMACgkQHwn1ewov
5ljpzRAAqgscZzPqHZNOtLC/QXsohdCKnbfjVL1Nd+xor773kJwA0jJVU6fSfvzx
sxqQkRUno3aFD3TeKzRVY+jBXzb8hkYUpIfvT2Fl3fGK26NIFaB+F0wqqwZZcyOt
36lR7Ngtun3HvrxxiJ8utQeF4z5fofpWRwSGzE+ADalBr47NSIBM2JofcWmo35tk
pw0wkZvvJhzSlouF4JW8ca6LjPpk6Ngw2988HEDzyXlYGwdS/IXGjriMQ5AIiRuE
qAFtydRYYcBfZ9IH7O3Utmq74mDg+UXcFjnnt8lrvbca8QiPRWvblxwkQ5alpbPQ
x/HS9dJqkPfy5xskKiivDSKCtYXSNi5E15crcbhreiZwSlX2ictVIYu9zEo2KYCh
aD0Ba1iCQVCs8uXdoIqIh92LDLzgkr8L7kjqqFwDWpQeEH5LGYtOaHD17e5vIBc8
dllkAiJfRPVtcJtdZgUkW7NwKl8CdKFAMi2X5owYCyEsPgwUtpi2xfO6xSpA2gWl
+srbY22RTcwmMgds0kktS46GgbW73rdFxEIlbeR6moaO6GUEILicsxu6BzvXYxuj
pfsjAt1CP50Hy1kInyiFjtgEwIEv0vbr39DsZNTWWjMFXlZHzmOc8JbjFK1lb+Kw
Hh2x31BtXHA4pFyk2DUem9ctqybDZePt1vlN5QYz7WjHzMeJRqg=
=mA72
-----END PGP SIGNATURE-----
Merge tag 'chrome-platform-for-linus-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform
Pull chrome platform updates from Benson Leung:
- further changes from Dmitry related to the removal of platform data
from atmel_mxt_ts and chromeos_laptop.
This time, we have some changes that teach chromeos_laptop how to
supply acpi properties for some input devices so that the peripheral
driver doesn't have to do dmi matching on some Chromebook platforms.
- new Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.
- other misc cleanup
* tag 'chrome-platform-for-linus-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: Use to_cros_ec_dev more broadly
platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes
platform: chrome: Add input dependency for tablet switch driver
platform/chrome: chromeos_laptop - supply properties for ACPI devices
platform/chrome: chromeos_tbmc - add SPDX identifier
platform: chrome: Add Tablet Switch ACPI driver
platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found
Move to_cros_ec_dev macro to cros_ec.h and use it when the private ec
object is needed from device object.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Celes has newer touch controller (compared to the controllers used in
older BayTrail-based devices) and so uses the same button mapping as
Samus.
This fixes the issue with mouse button being stuck in pressed state
after the first click.
Reported-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
We should stop our worker thread while we're suspended. If we don't
then we'll get messages like:
cros-ec-spi spi5.0: spi transfer failed: -108
cros-ec-spi spi5.0: cs-deassert spi transfer failed: -108
cros-ec-ctl cros-ec-ctl.0.auto: EC communication failed
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
BayTrail-based and newer Chromebooks describe their peripherals in ACPI;
unfortunately their description is not complete, and peripherals
drivers, such as driver for Atmel Touch controllers, has to resort to
DMI-matching to configure the peripherals properly. To avoid polluting
peripheral driver code, let's teach chromeos_laptop driver to supply
missing data via generic device properties.
Note we supply "compatible" string for Atmel peripherals not because it is
needed for matching devices and driver (matching is still done on ACPI HID
entries), but because peripherals driver will be using presence of
"compatible" property to determine if device properties have been attached
to the device, and fail to bind if they are absent.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace the original license statement with the SPDX identifier.
Add also one line of description as recommended by the COPYING file.
Signed-off-by: Benson Leung <bleung@chromium.org>
Add a kernel driver for GOOG0006, an ACPI driver reporting an event when
the tablet switch status changes.
On an ACPI based convertible chromebook check evtest display tablet mode
switch changes:
Available devices:
..
/dev/input/event3: Tablet Mode Switch
..
Testing ... (interrupt to exit)
Event: time 1484879712.604360, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 1
Event: time 1484879712.604360, -------------- SYN_REPORT ------------
Event: time 1484879715.132228, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 0
Event: time 1484879715.132228, -------------- SYN_REPORT ------------
...
Check state is updated at resume time when different from suspend time.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Commit 001dde9400 ("mfd: cros ec: spi: Fix "in progress" error
signaling") pointed out some bad code, but its analysis and conclusion
was not 100% correct.
It *is* correct that we should not propagate result==EC_RES_IN_PROGRESS
for transport errors, because this has a special meaning -- that we
should follow up with EC_CMD_GET_COMMS_STATUS until the EC is no longer
busy. This is definitely the wrong thing for many commands, because
among other problems, EC_CMD_GET_COMMS_STATUS doesn't actually retrieve
any RX data from the EC, so commands that expected some data back will
instead start processing junk.
For such commands, the right answer is to either propagate the error
(and return that error to the caller) or resend the original command
(*not* EC_CMD_GET_COMMS_STATUS).
Unfortunately, commit 001dde9400 forgets a crucial point: that for
some long-running operations, the EC physically cannot respond to
commands any more. For example, with EC_CMD_FLASH_ERASE, the EC may be
re-flashing its own code regions, so it can't respond to SPI interrupts.
Instead, the EC prepares us ahead of time for being busy for a "long"
time, and fills its hardware buffer with EC_SPI_PAST_END. Thus, we
expect to see several "transport" errors (or, messages filled with
EC_SPI_PAST_END). So we should really translate that to a retryable
error (-EAGAIN) and continue sending EC_CMD_GET_COMMS_STATUS until we
get a ready status.
IOW, it is actually important to treat some of these "junk" values as
retryable errors.
Together with commit 001dde9400, this resolves bugs like the
following:
1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400, we
would abort the first time we saw EC_SPI_PAST_END)
2. Before commit 001dde9400, transport errors (e.g.,
EC_SPI_RX_BAD_DATA) seen in other commands (e.g.,
EC_CMD_RTC_GET_VALUE) used to yield junk data in the RX buffer; they
will now yield -EAGAIN return values, and tools like 'hwclock' will
simply fail instead of retrieving and re-programming undefined time
values
Fixes: 001dde9400 ("mfd: cros ec: spi: Fix "in progress" error signaling")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Older models of Chromebooks did not describe the LPC EC in their ACPI
tables; starting with Strago-based devices Google is using GOOG0004 device
to describe EC LPC.
DMI-based match is fragile and does not work reliably, especially when
using custom firmware. It is also not needed when we can locate the right
ACPI device, so let's stop bailing out when DMI does not match but the
right ACPI device is present.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle)
used to set and get the keyboard wake lid angle. This attribute is
present only if 2 accelerometers are controlled by the EC.
This patch also moves the cros_ec features check before the device is
added so the features map obtained from the EC is ready on time.
Signed-off-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>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Add info useful for debugging USB-PD port state.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Fixed the following checkpatch warning:
WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider
using octal permissions '0444'.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Use DEVICE_ATTR variants for read/write attributes. This simplifies the
source code, improves readbility, and reduces the chance of
inconsistencies.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Add a define to get the cros_ec_dev from device and use it.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
When accessing a sysfs attribute, if the EC command fails, -EPROTO is
now returned instead of an error message as it is unlikely an app is
parsing the error message to do something meaningful.
Also, this patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer() so an error message is printed in the syslog.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This patch adds generic device information to the DMI table of
the cros_ec_lpc driver, needed for Chromebooks/boxes using a
custom coreboot firmware.
The DMI info would not contain "Google_*" as BIOS version string,
instead the system vendor string would still be "GOOGLE", so this
seems to be a reasonable match for every Chromebook/box running
a custom firmware.
Signed-off-by: Salvatore Bellizzi <lkml@seppia.net>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Benson Leung <bleung@chromium.org>
Chrome platform installed a Chrome EC notify handler which prevents
default EC GPE handler getting called. Add pm_system_wakeup to the
Chrome EC notify handler so wake up from s2idle can happen.
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Mark board data as __intconst/__initdata and make a copy of appropriate
entry once we identified the board we are running on. The rest of the data
will be discarded once the kernel finished booting (or module finished
loading).
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Now that Atmel driver uses generic device properties we can use them
instead of platform data when setting up touchpad on the original
Google Pixel.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Instead of passing interrupt flags via platform data to drivers, or
hoping that drivers will do the right thing and set it up the way we
need, let's set up IRQ resource and attach it to the I2C board info, and
let I2C core set it up for us.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Instead of using platform device and deferrals to handle the case when i2C
adapters appear late in the game, and not handling device unbinding all
that well, let's switch to using I2C bus notifier to get told when a new
I2C adapter appears in the system, and attempt to add appropriate devices
at that time.
In case when we have 2 Designware adapters in the system (Acer C720),
instead of counting and hoping they get enumerate din the right order,
let's switch to using their PCI devids (slot/function) that should be
stable.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Instead of trying to parse DMI IRQ data every time we try to instantiate a
device, let's do it once, when we identify the device we are working with.
This allows us to mark chromeos_laptop_get_irq_from_dmi() as __init and
discard it once module is initialized.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Instead of having separate setup() functions responsible for instantiating
i2c client for each peripheral, let's generalize the behavior and use
common code for instantiating all i2c peripherals.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This will make code instantiating I2C device a bit clearer.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace the original license statement with the SPDX identifier.
Add also one line of description as recommended by the COPYING file.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This reverts commit a376cd9160 because
chromeos_laptop instances should not be marked as "const" (at this
time), since i2c_peripheral is being modified (we change "state" and
"tries") when we instantiate devices.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:
for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
done
with de-mangling cleanups yet to come.
NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do. But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.
The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Moving cros_ec_dev to drivers/mfd.
Other small maintenance fixes.
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAlp+l8YUHGJsZXVuZ0Bj
aHJvbWl1bS5vcmcACgkQHwn1ewov5ljXzw/+MAcTYwIBdUyIZXBhA/FMYvAyouyN
0xzi/J7raKGhewG0Art28t+KT5j4T7Rz8Pd6zas6k4lGVfvWN5YBhz0ggMyCn3Lc
6t5aDzp4wG5OSl30Y1uA5x2mZ4uXDSskcgSCng0BooJptY1jxGwmt/97m/hxzDdH
ChiaRab+rhMeV2K2haONHWXGPi472fqPsXOb1uyIoX2quRdt1XbWrCGGmR81Tp/e
uQZC5DYOti1I3EYz+jOecbOkr42YIJyZxGTK6Mtk2NgUAsFNxhpg7vF6LGV39ynr
t4BAZk0qrIY/kP0xHl13+laW3w6eh/Rnrw/mSMaeo1CZ8K0X9NDRKb7hoSPcEkVe
Jzz6h+Gs4K2cds/VgOjjF8l/OzoZ5sIWaBoJf4tZKuEZ5JSIPeXH72k6ufg9/d72
0ArHQunxdAuZYrq1pwizduW/h5nG0nlHI9tGx1dQ9lS5TFl82EWkj6cE5gr8kFfo
FmUOyt0AM4ZYGqF1qgwEDXdSpbKrBA/CKB/K2xkcEl426DZlbO08TZ9bpsmX6pqb
d9ZbN9OvZxpDmb2XIXBPWCs6z/oWEyDTa011IJPkbq7SZ2Gckrt6x5FkgIBQFR7e
whEa9S0EMApEkCWVEF83Hpw/HL9UtLduRAMoxgjd81hJpQkBZ/jrwpU4aZOo3kAn
20AdipHKII3+6V8=
=YEO6
-----END PGP SIGNATURE-----
Merge tag 'chrome-platform-for-linus-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform
Pull chrome platform updates from Benson Leung:
- move cros_ec_dev to drivers/mfd
- other small maintenance fixes
[ The cros_ec_dev movement came in earlier through the MFD tree - Linus ]
* tag 'chrome-platform-for-linus-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: Use proper protocol transfer function
platform/chrome: cros_ec_lpc: Add support for Google Glimmer
platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.
platform/chrome: cros_ec_lpc: remove redundant pointer request
cros_ec: fix nul-termination for firmware build info
platform/chrome: chromeos_laptop: make chromeos_laptop const
Pull poll annotations from Al Viro:
"This introduces a __bitwise type for POLL### bitmap, and propagates
the annotations through the tree. Most of that stuff is as simple as
'make ->poll() instances return __poll_t and do the same to local
variables used to hold the future return value'.
Some of the obvious brainos found in process are fixed (e.g. POLLIN
misspelled as POLL_IN). At that point the amount of sparse warnings is
low and most of them are for genuine bugs - e.g. ->poll() instance
deciding to return -EINVAL instead of a bitmap. I hadn't touched those
in this series - it's large enough as it is.
Another problem it has caught was eventpoll() ABI mess; select.c and
eventpoll.c assumed that corresponding POLL### and EPOLL### were
equal. That's true for some, but not all of them - EPOLL### are
arch-independent, but POLL### are not.
The last commit in this series separates userland POLL### values from
the (now arch-independent) kernel-side ones, converting between them
in the few places where they are copied to/from userland. AFAICS, this
is the least disruptive fix preserving poll(2) ABI and making epoll()
work on all architectures.
As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and
it will trigger only on what would've triggered EPOLLWRBAND on other
architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered
at all on sparc. With this patch they should work consistently on all
architectures"
* 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits)
make kernel-side POLL... arch-independent
eventpoll: no need to mask the result of epi_item_poll() again
eventpoll: constify struct epoll_event pointers
debugging printk in sg_poll() uses %x to print POLL... bitmap
annotate poll(2) guts
9p: untangle ->poll() mess
->si_band gets POLL... bitmap stored into a user-visible long field
ring_buffer_poll_wait() return value used as return value of ->poll()
the rest of drivers/*: annotate ->poll() instances
media: annotate ->poll() instances
fs: annotate ->poll() instances
ipc, kernel, mm: annotate ->poll() instances
net: annotate ->poll() instances
apparmor: annotate ->poll() instances
tomoyo: annotate ->poll() instances
sound: annotate ->poll() instances
acpi: annotate ->poll() instances
crypto: annotate ->poll() instances
block: annotate ->poll() instances
x86: annotate ->poll() instances
...
pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.
Fixes: 2c7589af3c ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This patch adds device information to the DMI table of the cros_ec_lpc
driver for Google Glimmer devices. Since Google BIOS does not enumerate
devices in the LPC bus, the cros_ec_lpc driver checks for system
compatibility and registers the cros_ec device itself.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Commit 12278dc7c5 ("platform/chrome: cros_ec_lpc: Add support for
GOOG004 ACPI device") added support when the firmware reports the ACPI
device, there are some firmwares though that doesn't report this device
but have it. In such cases we need to instantiate the driver explicitly
if it is not instantiated through ACPI.
Fixes: 12278dc7c5 ("platform/chrome: cros_ec_lpc: Add support for GOOG004 ACPI device")
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Pointer request is being assigned but never used, so remove it. Cleans
up the clang warning:
drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to
'request' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
This changes the code back to what it did before changing to a
zero-length array structure.
Fixes: a841178445 ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Benson Leung <bleung@chromium.org>
Declare chromeos_laptop structures as const as they are only used during
a copy operation. As their value is never modified during runtime, they
can be made const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The cros_ec_dev module is responsible for registering the MFD devices
attached to the ChromeOS EC. This patch moves this module to drivers/mfd
so calls to mfd_add_devices() are not done from outside the MFD subtree
anymore.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch splits the cros_ec_devs module in two parts with a
cros_ec_dev module responsible for handling MFD devices registration and
a cros_ec_ctl module responsible for handling the various user-space
interfaces.
For consistency purpose, the driver name for the cros_ec_dev module is
now cros-ec-dev instead of cros-ec-ctl.
In the next commit, the new cros_ec_dev module will be moved to the MFD
subtree so mfd_add_devices() calls are not done from outside MFD.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The only reference to the new functions is inside of an #ifdef,
which now causes a harmless warning when CONFIG_PM_SLEEP is not set:
chrome/cros_ec_dev.c:478:12: error: 'ec_device_resume' defined but not used [-Werror=unused-function]
chrome/cros_ec_dev.c:469:12: error: 'ec_device_suspend' defined but not used [-Werror=unused-function]
This marks the two functions as __maybe_unused so they can get
silently dropped by the compiler.
Fixes: 405c84308c ("platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar sequence")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
The subset of wake-enabled host events is defined by the EC, but the EC
may still send non-wake host events if we're in the process of
suspending. Get the mask of wake-enabled host events from the EC and
filter out non-wake events to prevent spurious aborted suspend
attempts.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
When the EC is not responsive at probe, we try to get basic information
(protocol to use) later on through cros_xfer_cmd() call.
This patch makes sure there is no deadlock when re-probing the EC by
replacing call to cros_xfer_cmd() with send_command() in the function
cros_ec_get_host_command_version_mask(). Also, this patch adds the
function header indicating it must be called protected.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
With this patch, cros_ec_query_all() does not return an error if it
fails to check for MKBP events support. Instead, the EC device structure
indicates that it does not support MKBP events (mkbp_event_supported
field) and cros_ec_query_all() returns 0.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
A Mutex lock in cros_ec_cmd_xfer which may be held by frozen
Userspace thread during system suspending. So should not
call this routine in suspend thread.
Signed-off-by: Jeffery Yu <jefferyy@nvidia.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Some devices might want to turn off the lightbar if e.g. the
system turns the screen off due to idleness. This prevents the
kernel from going through its normal suspend/resume pathways.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Don't let EC control suspend/resume sequence. If the EC controls the
lightbar and sets the sequence when it notices the chipset transitioning
between states, we can't make exceptions for cases where we don't want
to activate the lightbar. Instead, let's move the suspend/resume
notifications into the kernel so we can selectively play the sequences.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Add a program feature so we can upload and run programs for lightbar
sequences. We should be able to use this to shift sequences out of the
EC and save space there.
$ cat <suitable program bin> > /sys/devices/.../cros_ec/program
$ echo program > /sys/devices/.../cros_ec/sequence
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
This patch installs a notify handler to process MKBP events for EC
firmware directing them over ACPI.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This patch removes platform_device_register() call and adds an ACPI
device id structure. The driver is now automatically probed for devices
with a GOOG0004 ACPI entry.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
This adds support for the ChromeOS LPC Microchip Embedded Controller
(mec1322) variant.
mec1322 accesses I/O region [800h, 9ffh] through embedded memory
interface (EMI) rather than LPC.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Call common functions for read / write to prepare support for future
LPC protocol variants which use different I/O ops than inb / outb.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
This dumps the EC panic information from the previous reboot.
Similar to the information presented by ectool panicinfo, except
that we do not bother doing any parsing (we should write a small
offline tool for that).
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
We should output or receive every byte in the param / reply struct,
unrelated to the pointer size.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
[bleung: Picked from crosreview.com/444085 for cros_ec_debugfs.c only.
cros_ec.c upstream had a different cros_ec_sleep_event which didn't
have the sizeof issue]
Signed-off-by: Benson Leung <bleung@chromium.org>
If the EC supports the new CONSOLE_READ command type, then we
place a console_log file in debugfs for that EC device which allows
us to grab EC logs. The kernel will poll every 10 seconds for the
log and keep its own buffer, but userspace should grab this and
write it out to some logs which actually get rotated.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
[bleung: restored original version of this commit, with pointer size
issue to be fixed in next commit]
Signed-off-by: Benson Leung <bleung@chromium.org>
Add cros_ec_get_event() entry point to retrieve event within functions
called by the notifier.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper. The helper replaces a common pattern by
taking the proper reference against the parent device and adding both
the cdev and the device.
At the same time we cleanup the error path through device_probe
function: we use put_device instead of kfree directly as recommended
by the device_initialize documentation.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Add new !TOUCHSCREEN_SUN4I dependency for SUN4I_GPADC
- List include/dt-bindings/mfd/* to files supported in MAINTAINERS
- New Drivers
- Intel Apollo Lake SPI NOR
- ST STM32 Timers (Advanced, Basic and PWM)
- Motorola 6556002 CPCAP (PMIC)
- New Device Support
- Add support for AXP221 to axp20x
- Add support for Intel Gemini Lake to intel-lpss-pci
- Add support for MT6323 LED to mt6397-core
- Add support for COMe-bBD#, COMe-bSL6, COMe-bKL6,
COMe-cAL6 and COMe-cKL6 to kempld-core
- New Functionality
- Add support for Analog CODAC to sun6i-prcm
- Add support for Watchdog to lpc_ich
- Fix-ups
- Error handling improvements; axp288_charger, axp20x, ab8500-sysctrl
- Adapt platform data handling; axp20x
- IRQ handling improvements; arizona, axp20x
- Remove superfluous code; arizona, axp20x, lpc_ich
- Trivial coding style/spelling fixes; axp20x, abx500, mfd.txt
- Regmap fix-ups; axp20x
- DT changes; mfd.txt, aspeed-lpc, aspeed-gfx, ab8500-core, tps65912, mt6397
- Use new I2C probing mechanism; max77686
- Constification; rk808
- Bug Fixes
- Stop data transfer whilst suspended; cros_ec
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJYrYwQAAoJEFGvii+H/HdhVMMP/3Y5/S1y7bCRhsta3PQVHT/2
+nxu833451qTTUKNqR5rTQrjdjVLr6+rfhMmMxIDhHMrn3EvwT0bQDQmncLLYgc2
u5n2j93Y/nfyJvy76W3aTlisBaKfxhFBuLBEkewXNwPaZk97tbgf9IbyNq6eirHo
afv5Z54q9RN+OlT5ZfM8mJcOQAdyE6CXzq/GKZI6LjSqPb5vQhasqoD/yb9pMMga
jYseI47KlIVLhUnnAjxRdxt16rjtee2JHZmGCGJaeo+nWiTwDOZ5l5eZDHKwD6ng
3CW4xWDPbzeLD22oi6Uzvhx+8Eqt9S/K1AY+kn3W6WLk/CTi5yamMHw0DjBUcS9a
hqdqGZrCSveRQrSCt/9N5uzSMkiUHFMGdj5LtX3yB4fDp0R42WJGMxkvidKb7otB
wJIT0i5T5M5G3IT3xPkdEtfEAK3xoAus+IF0faFNaD7GqsEs97KD+740nTgulSKz
g28Lo6NLpZhl+uQ74fx76Wll+Onj1voWABZW8Z//kjRWkAwKU8OhbXrX8kccGY6m
C980wWtj0979jYFstwUuSXspjuvk9L1nfSuLBmtawm9S58TUIS/WLe2A8kU9/XEY
e3PLpO4AxvCJvBBa80yVFG15JoaTX5TOg/F3NqKYaHqA2cusOVOEFAeOAdwav2rL
SR2Y8s8ceIL4n9ccmr0b
=P5Dp
-----END PGP SIGNATURE-----
Merge tag 'mfd-for-linus-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Core Frameworks:
- Add new !TOUCHSCREEN_SUN4I dependency for SUN4I_GPADC
- List include/dt-bindings/mfd/* to files supported in MAINTAINERS
New Drivers:
- Intel Apollo Lake SPI NOR
- ST STM32 Timers (Advanced, Basic and PWM)
- Motorola 6556002 CPCAP (PMIC)
New Device Support:
- Add support for AXP221 to axp20x
- Add support for Intel Gemini Lake to intel-lpss-pci
- Add support for MT6323 LED to mt6397-core
- Add support for COMe-bBD#, COMe-bSL6, COMe-bKL6, COMe-cAL6 and
COMe-cKL6 to kempld-core
New Functionality:
- Add support for Analog CODAC to sun6i-prcm
- Add support for Watchdog to lpc_ich
Fix-ups:
- Error handling improvements; axp288_charger, axp20x, ab8500-sysctrl
- Adapt platform data handling; axp20x
- IRQ handling improvements; arizona, axp20x
- Remove superfluous code; arizona, axp20x, lpc_ich
- Trivial coding style/spelling fixes; axp20x, abx500, mfd.txt
- Regmap fix-ups; axp20x
- DT changes; mfd.txt, aspeed-lpc, aspeed-gfx, ab8500-core, tps65912,
mt6397
- Use new I2C probing mechanism; max77686
- Constification; rk808
Bug Fixes:
- Stop data transfer whilst suspended; cros_ec"
* tag 'mfd-for-linus-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (43 commits)
mfd: lpc_ich: Enable watchdog on Intel Apollo Lake PCH
mfd: lpc_ich: Remove useless comments in core part
mfd: Add support for several boards to Kontron PLD driver
mfd: constify regmap_irq_chip structures
MAINTAINERS: Add include/dt-bindings/mfd to MFD entry
mfd: cpcap: Add minimal support
mfd: mt6397: Add MT6323 LED support into MT6397 driver
Documentation: devicetree: Add LED subnode binding for MT6323 PMIC
mfd: tps65912: Export OF device ID table as module aliases
mfd: ab8500-core: Rename clock device and compatible
mfd: cros_ec: Send correct suspend/resume event to EC
mfd: max77686: Remove I2C device ID table
mfd: max77686: Use the struct i2c_driver .probe_new instead of .probe
mfd: max77686: Use of_device_get_match_data() helper
mfd: max77686: Don't attempt to get i2c_device_id .data
mfd: ab8500-sysctrl: Handle probe deferral
mfd: intel-lpss: Add Intel Gemini Lake PCI IDs
mfd: axp20x: Fix AXP806 access errors on cold boot
mfd: cros_ec: Send suspend state notification to EC
mfd: cros_ec: Prevent data transfer while device is suspended
...
The cros_ec driver is still active while the device is suspended.
Besides that, it also tries to transfer data even after the I2C host had
been suspended. This patch uses a simple flag to prevent this.
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Check whether the ChromeOS Embedded Controller is a sensor hub and in
such case issue a command to get the number of sensors and register them
all.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the EC_CMD_GET_FEATURES message to check the supported features for
each MCU.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
[tomeu: adapted to changes in mainline]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
[enric: remove references to USB PD feature and do it more generic]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
For the MFD changes:
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Newer revisions of the ChromeOS EC add more events besides the keyboard
ones. So handle interrupts in the MFD driver and let consumers register
for notifications for the events they might care.
To keep backward compatibility, if the EC doesn't support MKBP event, we
fall back to the old MKBP key matrix host command.
Cc: Randall Spangler <rspangler@chromium.org>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Signed-off-by: Vic Yang <victoryang@google.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom iProc,
STMPE and ChromeOS EC controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQI2BAABCAAgBQJXpLFKGRx0aGllcnJ5LnJlZGluZ0BnbWFpbC5jb20ACgkQ3SOs
138+s6E2Nw/9FggtgYlVQRS5lzwTKxQI/5HMlOfdyH84S76fUS8uAxvEsZvyHXZ7
NiwCJMkmMqPHMlrfuXacs4nueKz3jvy8csaffH5T2yHf0ZPGmkxBsdX97rvQp3z/
WTUXX8vo8fiEPQSXQOUzIYk10s7CBO2094uL8FBqfYeSySY3Ti35SpmZSQKVd1LS
A1rR/qRgNbIlhI7+L5CotdrNMkHXqHZIHDyXO1dWBDVL+3MU3IPpB//J/WjU/OMs
5MHEtTr7943s8LQYhM1p5PFDn8ehe31L1quSswmMTLuepPrTUjD31476VYW8p8gg
lzOv5JF5b8Rkw0B+4vDC0z/OPZA47tg8DfiS9Sa1SrCGxslOH7pvI7m9dV89FOc2
/hA1n048jBhIrHPylXZ+hUPKNM0WTwFrHVxROgtEb6/wtYskgOFGQrYKpD4FtH+j
zqXxvCRMX4ZLLXy2QO4GAW3dv51pLjiM2yxVWtM1lWFWiKKvRoqHiFcnmCJJwQ4T
NXUPnyt+G/GCtpVHlMtHW9YszJ650ECt+H8I1EhuGLkpOXncCPdmw34oR1wSmMi3
+1yjCvZV8bNJLt2GQDpoFEUc1dqY6g/SLqm9sz+W69QYA0oDt9JpFK+RFw118282
EX24GT9+PYe0kMt1WWopjHeFZ+6HhsG/ODwOUOaG/8kp6qZLB4EKP9k=
=TdEI
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom
iProc, STMPE and ChromeOS EC controllers"
* tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range
regulator: pwm: Support extra continuous mode cases
pwm: Add ChromeOS EC PWM driver
dt-bindings: pwm: Add binding for ChromeOS EC PWM
mfd: cros_ec: Add EC_PWM function definitions
mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper
pwm: atmel: Use of_device_get_match_data()
pwm: atmel: Fix checkpatch warnings
pwm: atmel: Fix disabling of PWM channels
dt-bindings: pwm: Add R-Car H3 device tree bindings
pwm: rcar: Use ARCH_RENESAS
pwm: tegra: Add support for Tegra186
dt-bindings: pwm: tegra: Add compatible string for Tegra186
pwm: tegra: Avoid overflow when calculating duty cycle
pwm: tegra: Allow 100 % duty cycle
pwm: tegra: Add support for reset control
pwm: tegra: Rename mmio_base to regs
pwm: tegra: Remove useless padding
pwm: tegra: Drop NUM_PWM macro
pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value
...
So that callers of cros_ec_cmd_xfer() don't have to repeat boilerplate
code when checking for errors from the EC side.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
We verify "u_cmd.outsize" and "u_cmd.insize" but we need to make sure
that those values have not changed between the two copy_from_user()
calls. Otherwise it could lead to a buffer overflow.
Additionally, cros_ec_cmd_xfer() can set s_cmd->insize to a lower value.
We should use the new smaller value so we don't copy too much data to
the user.
Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
Fixes: a841178445 ('mfd: cros_ec: Use a zero-length array for command data')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Olof Johansson <olof@lixom.net>
This reverts commit bff3c624dc.
Board "Leon" is otherwise known as "Toshiba CB35" and we already have
the entry that supports that board as of this commit :
963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
Remove this duplicate.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
The upcoming Elan Wolf (Dell Chromebook 11) devices need to know to look
for Elan touchpads on the i2c bus so that they will be functional.
Based on the chromeos-kernel commit :
https://chromium-review.googlesource.com/198283
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add the elan trackpad to the Acer C720 (peppy) list, as it is an alternate
trackpad option. It may exist at i2c address 0x15.
Based on this change from the chromeos kernel :
https://chromium-review.googlesource.com/186253
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
compat_ioctl has to be populated for 32 bit userspace applications to work
with 64 bit kernels.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Lightbar attributes are hidden if the ID of the device is not 0 (the
assumption being that 0 = cros_ec = might have a lightbar, 1 = cros_pd =
hide); however, sometimes these devices get IDs 1 and 2 (or something
else) instead of IDs 0 and 1. This prevents the lightbar attributes from
appearing when they should.
Proposed change is to instead check whether the name assigned to the
device is CROS_EC_DEV_NAME (true for cros_ec, false for cros_pd).
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Prevent memory scribble by checking that ioctl buffer size parameters
are sane.
Without this check, on 32 bits system, if .insize = 0xffffffff - 20 and
.outsize the amount to scribble, we would overflow, allocate a small
amounts and be able to write outside of the malloc'ed area.
Adding a hard limit allows argument checking of the ioctl. With the
current EC, it is expected .insize and .outsize to be at around 512 bytes
or less.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
This is a driver for ACPI-based keyboard backlight LEDs found on
Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
backlight as "chromeos::kbd_backlight" LED class device in sysfs.
Signed-off-by: Simon Que <sque@chromium.org>
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Evan McClain <aeroevan@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Accidentally specified a smaller record size, bring it back
to the same size as we had when we used the config file.
Signed-off-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
In order to handle the firmware placing the ramoops buffer
in a different location than the kernel is configured to look
probe for an ACPI device specified by GOOG9999 acpi id. If
no device is found or the first memory resource is not defined
properly fall back to the configured base and length.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Ben Zhang <benzh@chromium.org>
Signed-off-by: Filipe Brandenburger <filbranden@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add support for Leon touch devices, which is the same as
slippy/falco/peppy/wolf on the same buses using the LynxPoint-LP I2C via
the i2c-designware-pci driver.
Based on the following patch:
https://chromium-review.googlesource.com/#/c/168351/
Signed-off-by: Gene Chen <gene.chen@intel.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit d80d134182 ("i2c: designware: Move common probe code into
i2c_dw_probe()") caused the I2C adapter lookup code here to fail for PCI
enumerated i2c-designware because commit changed the adapter name but
didn't update it here.
Fix the I2C adapter lookup by using the "Synopsys DesignWare I2C adapter"
name.
Reported-by: Jeremiah Mahler <jmmahler@gmail.com>
Fixes: d80d134182 ("i2c: designware: Move common probe code into i2c_dw_probe()")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Some EC implementations include a small nvram space used to store
verified boot context data. This patch offers a way to expose this
data to userspace.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Emilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Function led_rgb_store() contains some direct returns in error cases that
leak the already allocated cros_ec_command message structure. Make sure
that 'msg' is freed in all exit paths. Detected by Coverity CID 1309666.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Olof Johansson <olof@lixom.net>
The allocated cros_ec_command message structure is not freed in function
sequence_store(). Make sure that 'msg' is freed in all exit paths.
Detected by Coverity CID 1309667.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Olof Johansson <olof@lixom.net>
With Chrome running on 64-bit ARM devices, add ARM64 to the list of
supported architectures.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[olof; Fixed up due to addition of COMPILE_TEST]
Signed-off-by: Olof Johansson <olof@lixom.net>
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Since the verion of ACPI in Google BIOS does not enumerate the devices
in the LPC bus, the cros_ec_lpc driver resorts to DMI data to check if
a system is supported by the driver and autoload if built as a module.
Add information about the Google Pixel 2 to the DMI device table.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit 6db07b6336 ("mfd: cros_ec: Check result code from EC messages")
added a common cros_ec_check_result() function that can be used to check
the ec_msg->result for errors and warns about them.
Use the existing function instead of duplicating same check in the driver.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
The ChromeOS EC LPC and chardev drivers depend on CROS_EC_PROTO but
MFD_CROS_EC select CROS_EC_PROTO instead. Mixing select and depends
on is bad practice as it may lead to circular Kconfig dependencies.
Since the platform devices that are matched with these drivers are
registered by the ChromeOS EC mfd driver, they really depend on
MFD_CROS_EC. And because this config option selects CROS_EC_PROTO,
that dependency is met as well. So make the drivers to depend on
MFD_CROS_EC instead of CROS_EC_PROTO.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
This reverts commit d12bbcd3ea ("platform/chrome: Don't make
CHROME_PLATFORMS depends on X86 || ARM") since it was found to
not be the correct fix for the MFD_CROS_EC config unmet direct
dependencies warning.
The correct solution was to add the needed dependencies to the
MFD_CROS_EC symbol. Besides the revert, this patch extends the
CHROME_PLATFORMS symbol dependencies and adds || COMPILE_TEST
to allow drivers to have build coverage on other architectures.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
The hardcoded 0x83 CTRL setting overrides other settings in that byte,
enabling extra reporting that may not be useful on a particular platform.
Implement improved suspend mechanism via deep sleep. By writing zero to
both the active and idle cycle times the maXTouch device can be put into a
deep sleep mode, using minimal power. It is necessary to issue a calibrate
command after the chip has spent any time in deep sleep, however a soft
reset is unnecessary.
Use the old method on Chromebook Pixel via platform data option.
This patch also deals with the situation where the power configuration is
zero on probe, which would mean that the device never wakes up to execute
commands.
After a config download, the T7 power configuration may have changed so it
is necessary to re-read it.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Chrome platform support depends on X86 || ARM because there are
only Chromebooks using those architectures. But only some drivers
depend on a given architecture, and the ones that do already have
a dependency on their specific Kconfig symbol entries.
An option is to also make CHROME_PLATFORMS depends on || COMPILE_TEST
but is more future proof to remove the dependency and let the drivers
be built in all architectures if possible to have more build coverage.
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add proto v3 support to the SPI, I2C, and LPC.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
