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(-)
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@protonmail.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@protonmail.com>
Hi Yassine, On 10/07/2025 10:06, Yassine Oudjana via B4 Relay wrote: > 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. arguably a bit of a nit pick, but it might be worth clarifying that newer SoCs starting with sdm845 also work in much the same way, except the actual data is packed into protobuf messages which are sent over QMI, rather than using QMI itself for the sensor data (and hence aren't supported by this series). That said, this is really awesome :D Kind regards,> > 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@protonmail.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, -- // Casey (she/her)
On Thu, Jul 10, 2025 at 09:06:26AM +0100, Yassine Oudjana via B4 Relay wrote: > 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. ... Hi Yassine, This series both adds an IIO driver and updates Networking code. I'd suggest splitting the series so that the Networking updates can be targeted at net-next, while the IIO driver is targeted at a different tree. Also, I note that this series does not compile against current net-next. This seems like it should be addressed, at least for the Networking changes. -- pw-bot: changes-requested
On Thursday, July 10th, 2025 at 12:22 PM, Simon Horman <horms@kernel.org> wrote: > On Thu, Jul 10, 2025 at 09:06:26AM +0100, Yassine Oudjana via B4 Relay wrote: > > > 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. > > > ... > > Hi Yassine, > > This series both adds an IIO driver and updates Networking code. > > I'd suggest splitting the series so that the Networking updates can be > targeted at net-next, while the IIO driver is targeted at a different tree. > > Also, I note that this series does not compile against current net-next. > This seems like it should be addressed, at least for the Networking > changes. I targeted linux-next. By including the IIO driver my idea was to show an example of using the QRTR bus, but if it has to target different trees then sure, I'll split it.
© 2016 - 2025 Red Hat, Inc.