| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <9301fea1-9aa2-5030-9ac3-339bfb5193da@collabora.com>
Date: Fri, 22 Nov 2019 12:11:20 +0100
From: Enric Balletbo i Serra <enric.balletbo@...labora.com>
To: Gwendal Grignou <gwendal@...omium.org>, dmitry.torokhov@...il.com,
groeck@...omium.org, briannorris@...omium.org, jic23@...nel.org,
knaack.h@....de, lars@...afoo.de, pmeerw@...erw.net,
lee.jones@...aro.org, bleung@...omium.org, dianders@...omium.org,
fabien.lahoudere@...labora.com
Cc: linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-input@...r.kernel.org
Subject: Re: [PATCH v5 00/18] cros_ec: Add sensorhub driver and FIFO
processing
Hi,
On 15/11/19 10:33, Gwendal Grignou wrote:
> This patchset adds a sensorhub driver for spreading sensor
> events coming from the Embedded controller sensor FIFO:
>
> +---------------+ +--------------+ +----
> | cros_ec_accel | | cros_ec_gyro | | ...
> +---------------+ +--------------+ +----
> id:0 \ id:1 | / id:..
> +------------------------------+
> | cros_ec_sensorhub |
> +------------------------------+
> | cros_ec_dev |
> +------------------------------+
> | cros_ec_i2c, cros_ec_lpc, .. |
> +------------------------------+
> |
> EC
>
> When new sensors events are present, the EC raises and interrupt,
> sensorhub reads the FIFO and uses the 'id' field to spread the event to
> the proper IIO sensors. This stack is similar to the HID sensor input
> stack.
>
> The first patch move cros_ec_proto functions documentations into the
> code to prevent rot.
>
> The inext 3 patches add a primitive cros_ec_sensorhub. MFD just have to
> register this driver if at least one sensor is presented by the EC.
> cros_ec_sensorhub retrieves more information from the EC to find out
> which sensors are actually present:
> mfd: cros_ec: Add sensor_count and make check_features public
> platform: cros_ec: Add cros_ec_sensor_hub driver
> platform/mfd:iio: cros_ec: Register sensor through sensorhub
>
> The next 3 patches prepare for FIFO support:
> platform: chrome: cros-ec: record event timestamp in the hard irq
> platform: chrome: cros_ec: Do not attempt to register a non-positive
> platform: chrome: cros_ec: handle MKBP more events flag
>
> That last patch fixes a regression that changes event processing.
> Revert the patches that fixed that regression.
>
> The next 3 patches add FIFO support. An interface is added to connect
> the IIO sensors with cros_ec_sensorhub, and filters are needed to spread
> the timestamp when the EC send batches of events and deal with variation
> in interrupt delay.
> platform: chrome: sensorhub: Add FIFO support
> platform: chrome: sensorhub: Add code to spread timestmap
> platform: chrome: sensorhub: Add median filter
>
> The remaining patches update IIO cros_ec drivers:
> The first patch moves cros_ec_sensor_core functions documentation into
> the .c file.
> The second one exports iio_device_set_clock, so that the timestamp
> generated by the FIFO matches the default timestamp exposed by the IIO
> devices.
> Then we can use the FIFO function exposed by cros_ec_sensorhub:
> iio: cros_ec: Use triggered buffer only when EC does not support FIFO
>
> The power management functions are not necessary anymore, since we
> shutoff the FIFO from cros_ec_sensorhub:
> iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO
>
> Finally, the last 3 patches present sensor information following the IIO
> ABI:
> - Configurable EC timeout to allow batch mode in buffer/hwfifo_timeout,
> in seconds.
> - Hard coded EC FIFO size in buffer/hwfifo_watermark_max
> - Sensor sampling frequency in hertz at sampling_frequency:
> iio: cros_ec: Expose hwfifo_timeout
> iio: cros_ec: Report hwfifo_watermark_max
> iio: cros_ec: Use Hertz as unit for sampling frequency
>
> For testing, libiio test tools can be used:
> A iio device link looks like:
> iio:device1 ->
> ...09:00/GOOG0004:00/cros-ec-dev.6.auto/cros-ec-sensorhub.7.auto/
> cros-ec-accel.15.auto/iio:device1
>
> When FIFO is available, no trigger are presented. Once
> sampling_freqeuncy and hwfifo_timeout are set, sensor events flow
> when listening to /dev/iio:device1:
> echo 12 > sampling_frequency # Set ODR to at least 12Hz
> echo .100 > buffer/hwfifo_timeout # do not wait more than 100ms to
> # to send samples
> iio_readdev -b 2 -T 1000 -s 2 iio:device1 2>/dev/null| od -x
> 0000000 ffd0 2e20 d990 0000 8630 b56c 07ea 0000
> 0000020 ffc0 2e10 d970 0000 877e b56c 07ea 0000
> 0000040`
>
> When FIFO is not supported by the EC, a trigger is present in the
> directory. After registering a trigger, setting sampling_frequency,
> the latest data collected by the sensor will be retrieved by the host
> when the trigger expires.
>
> When cros_ec_accel_legacy driver is used, no FIFO is supported and the
> sampling frequency for the accelerometers is hard coded at 10Hz.
>
> This set is built upon the master branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
> Enrico Granata (2):
> platform: chrome: cros_ec: Do not attempt to register a non-positive
> IRQ number
> platform: chrome: cros_ec: handle MKBP more events flag
>
> Gwendal Grignou (16):
> mfd: cros_ec: Add sensor_count and make check_features public
> platform: cros_ec: Add cros_ec_sensor_hub driver
> platform/mfd:iio: cros_ec: Register sensor through sensorhub
> platform: chrome: cros-ec: record event timestamp in the hard irq
> Revert "Input: cros_ec_keyb - add back missing mask for event_type"
> Revert "Input: cros_ec_keyb: mask out extra flags in event_type"
> platform: chrome: sensorhub: Add FIFO support
> platform: chrome: sensorhub: Add code to spread timestmap
> platform: chrome: sensorhub: Add median filter
> iio: cros_ec: Move function description to .c file
> iio: expose iio_device_set_clock
> iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO
> iio: cros_ec: Remove pm function
> iio: cros_ec: Expose hwfifo_timeout
> iio: cros_ec: Report hwfifo_watermark_max
> iio: cros_ec: Use Hertz as unit for sampling frequency
>
> drivers/iio/accel/cros_ec_accel_legacy.c | 14 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> .../cros_ec_sensors/cros_ec_lid_angle.c | 3 +-
> .../common/cros_ec_sensors/cros_ec_sensors.c | 19 +-
> .../cros_ec_sensors/cros_ec_sensors_core.c | 359 +++++--
> drivers/iio/industrialio-core.c | 8 +-
> drivers/iio/light/cros_ec_light_prox.c | 21 +-
> drivers/iio/pressure/cros_ec_baro.c | 14 +-
> drivers/input/keyboard/cros_ec_keyb.c | 6 +-
> drivers/mfd/cros_ec_dev.c | 235 +----
> drivers/platform/chrome/Kconfig | 12 +
> drivers/platform/chrome/Makefile | 2 +
> drivers/platform/chrome/cros_ec.c | 51 +-
> drivers/platform/chrome/cros_ec_ishtp.c | 25 +-
> drivers/platform/chrome/cros_ec_lpc.c | 17 +-
> drivers/platform/chrome/cros_ec_proto.c | 197 +++-
> drivers/platform/chrome/cros_ec_rpmsg.c | 19 +-
> drivers/platform/chrome/cros_ec_sensorhub.c | 249 +++++
> .../platform/chrome/cros_ec_sensorhub_ring.c | 987 ++++++++++++++++++
> .../linux/iio/common/cros_ec_sensors_core.h | 104 +-
> include/linux/iio/iio.h | 2 +
> include/linux/platform_data/cros_ec_proto.h | 41 +-
> .../linux/platform_data/cros_ec_sensorhub.h | 196 ++++
> 23 files changed, 2054 insertions(+), 529 deletions(-)
> create mode 100644 drivers/platform/chrome/cros_ec_sensorhub.c
> create mode 100644 drivers/platform/chrome/cros_ec_sensorhub_ring.c
> create mode 100644 include/linux/platform_data/cros_ec_sensorhub.h
>
After having patches 1 to 8 on linux-next for one week I queued those for 5.5.
For 9/10/11 I have still comments to do, so will go probably for 5.6.
Lee, Jonathan and Dmitry, I created an immutable branch for those
*
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/tag/?h=tag-ib-chrome-mfd-iio-input-5.5
But you probably can skip to merge that branch if you don't plan to queue more
patches for 5.5. I tested with your next branches and merges cleanly. It is also
on my plans wait at least one week more to do the chrome-platform PR to Linus so
the patches are one week more in linux-next.
Thanks,
Enric
Powered by blists - more mailing lists