Message-Id: <20250710-qcom-smgr-v2-0-f6e198b7aa8e@protonmail.com>
Date: Thu, 10 Jul 2025 09:06:26 +0100
From: Yassine Oudjana via B4 Relay <devnull+y.oudjana.protonmail.com@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>, 
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>, Bjorn Andersson <andersson@...nel.org>, 
 Konrad Dybcio <konradybcio@...nel.org>, 
 Masahiro Yamada <masahiroy@...nel.org>, 
 Nathan Chancellor <nathan@...nel.org>, 
 Nicolas Schier <nicolas.schier@...ux.dev>, 
 Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>, 
 Nuno Sá <nuno.sa@...log.com>, 
 Andy Shevchenko <andy@...nel.org>, Luca Weiss <luca@...aweiss.eu>
Cc: linux-arm-msm@...r.kernel.org, netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org, 
 linux-iio@...r.kernel.org, Yassine Oudjana <y.oudjana@...tonmail.com>
Subject: [PATCH v2 0/4] QRTR bus and Qualcomm Sensor Manager IIO drivers

Sensor Manager is a QMI service available on several Qualcomm SoCs which
exposes available sensors and allows for getting data from them. This
service is provided by either:

- SSC (Snapdragon Sensor Core): Also known as SLPI (Sensor Low Power
  Island). Has its own set of pins and peripherals to which sensors are
  connected. These peripherals are generally inaccessible from the AP,
  meaning sensors need to be operated exclusively through SSC. The only
  known SoCs in this category are MSM8996 and MSM8998 (and their
  derivatives).
- ADSP (Audio DSP): Shares pins and peripherals with the AP. At least on
  some devices, these pins could be configured as GPIOs which allows the AP
  to access sensors by bit-banging their interfaces. Some SoCs in this
  category are SDM630/660, MSM8953, MSM8974 and MSM8226.

Before Sensor Manager becomes accessible, another service known as Sensor
Registry needs to be provided by the AP. The remote processor that provides
Sensor Manager will then request data from it, and once that process is
done, will expose several services including Sensor Manager.

This series adds a kernel driver for the Sensor Manager service, exposing
sensors accessible through it as IIO devices. To facilitate probing of this
 driver, QRTR is turned into a bus, with services being exposed as devices.
Once the Sensor Manager service becomes available, the kernel attaches its
device to the driver added in this series. This allows for dynamic probing
of Sensor Manager without the need for static DT bindings, which would also
not be ideal because they would be describing software rather than
hardware. Sensor Manager is given as a working example of the QRTR bus.
Kernel drivers for other services may also be able to benefit from this
change.

As previously mentioned, a Sensor Registry server must run on the AP to
provide the remote processor (either SLPI or ADSP) with necessary data.
A userspace implementation of this server is made[1]. The server can be
supplied with the necessary data in the form of a plain-text configuration
file that can be pulled from the Android vendor partition (sample[2]), or
generated from a binary file that can be pulled from the persist partition.
A more recently developed kernel implementation of the Sensor Registry
server[3] can also be used. This last implementation only supports reading
data from the binary file pulled from persist. Sensor Registry remains out
of the scope of this patch series, as the Sensor Registry server and Sensor
Manager client (this series) are fully independent components.

Due to the total lack of documentation on Sensor Manager, this driver was
almost entirely the result of a process of capturing transactions between
SSC and the proprietary Android daemons with several methods and manually
decoding and interpreting them, sometimes by comparing with values acquired
from Android APIs. A blog post[4] describes part of this process more
detail. A little piece of downstream Android open-source code[5] was also
used as reference during later stages of development. All of this, as well
as a lack of time on my side for the last couple of years, meant that this
driver had to go through a slow and intermittent development process for
more than 3 years before reaching its current state.

Currently supported sensor types include accelerometers, gyroscopes,
magentometers, proximity and pressure sensors. Other types (namely
light and temperature sensors) are close to being implemented.

Some testing instructions may also be found here[6].

[1] https://gitlab.com/msm8996-mainline/sns-reg
[2] https://github.com/nian0114/android_vendor_xiaomi_scorpio/blob/mkn-mr1/proprietary/etc/sensors/sensor_def_qcomdev.conf
[3] https://github.com/sdm660-mainline/linux/pull/57
[4] https://emainline.gitlab.io/2022/04/08/Unlocking_SSC_P2.html
[5] https://android.googlesource.com/platform/system/chre/+/android-8.0.0_r2/platform/slpi
[6] https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/4118

Changes since v1:
- Split qdev renaming into separate patch
- Export new QRTR symbols with namespace
- Change struct initialization style
- Remove redundant NULL initialization of qdev->dev.driver
- Remove redundant devm_kfree
- Use variable in sizeof rather than type
- Change error return style in qcom_smd_qrtr_init
- Change order of operations in qcom_smd_qrtr_exit
- Use FIELD_PREP and GENMASK in QRTR_INSTANCE macro and add a CONST variant
- Remove per-sensor subdrivers and eliminate use of platform devices
- Put year range in copyright statements
- Use dev_err_probe for error messages in probe
- Remove unused include of linux/of.h
- Avoid casting away const in qcom_smgr_buffering_report_handler
- Use iio_push_to_buffers instead of iio_push_to_buffers_with_timestamp
- Preprocess proximity sensor data before pushing to buffer
- Add warning message for report with unknown ID received
- Change sentinel value style in array of struct initialization
- Refuse to set sampling frequency when buffer enabled
- Return -EINVAL inside default case in all applicable switch statements
- Move samp_freq_vals in qcom_smgr_iio_read_avail to priv and fix maximum
- Add devm_add_action_or_reset for releasing QMI handle and get rid of
  qcom_smgr_remove
- Add service versions and instance IDs found on some platforms to QRTR
  match table
- Fix null pointer dereference on registering unsupported sensor

Signed-off-by: Yassine Oudjana <y.oudjana@...tonmail.com>
---
Yassine Oudjana (4):
      net: qrtr: smd: Rename qdev to qsdev
      net: qrtr: Turn QRTR into a bus
      net: qrtr: Define macro to convert QMI version and instance to QRTR instance
      iio: Add Qualcomm Sensor Manager driver

 MAINTAINERS                                     |  13 +
 drivers/iio/accel/qcom_smgr_accel.c             | 138 ++++
 drivers/iio/common/Kconfig                      |   1 +
 drivers/iio/common/Makefile                     |   1 +
 drivers/iio/common/qcom_smgr/Kconfig            |  16 +
 drivers/iio/common/qcom_smgr/Makefile           |   8 +
 drivers/iio/common/qcom_smgr/qcom_smgr.c        | 840 ++++++++++++++++++++++++
 drivers/iio/common/qcom_smgr/qmi/Makefile       |   3 +
 drivers/iio/common/qcom_smgr/qmi/qmi_sns_smgr.c | 713 ++++++++++++++++++++
 drivers/iio/common/qcom_smgr/qmi/qmi_sns_smgr.h | 161 +++++
 drivers/soc/qcom/qmi_interface.c                |   5 +-
 include/linux/iio/common/qcom_smgr.h            |  80 +++
 include/linux/mod_devicetable.h                 |   9 +
 include/linux/soc/qcom/qrtr.h                   |  46 ++
 net/qrtr/af_qrtr.c                              |  23 +-
 net/qrtr/qrtr.h                                 |   3 +
 net/qrtr/smd.c                                  | 252 ++++++-
 scripts/mod/devicetable-offsets.c               |   4 +
 scripts/mod/file2alias.c                        |  10 +
 19 files changed, 2302 insertions(+), 24 deletions(-)
---
base-commit: 835244aba90de290b4b0b1fa92b6734f3ee7b3d9
change-id: 20250710-qcom-smgr-8db96d370b10

Best regards,
-- 
Yassine Oudjana <y.oudjana@...tonmail.com>

Powered by blists - more mailing lists