sensors: upgrade 1.2.1 -> 2.0.0 by bmasta018 · Pull Request #2562 · qualcomm-linux/meta-qcom

bmasta018 · 2026-06-20T19:37:31Z

Upgraded sensor binaries from 1.2.1 to 2.0.0. Add nanopb based proto compilation. Enabled the sensors features for Shikra target

Upgraded sensor binaries from 1.2.1 to 2.0.0. Add nanopb based proto compilation. Enabled the sensors features for Shikra target Signed-off-by: Bhanu Vivek Matsa <bmasta@qti.qualcomm.com>

lumag · 2026-06-20T22:53:37Z

    install -d ${D}${sysconfdir}/sensors/config
    install -d ${D}${sysconfdir}/sensors/registry
    install -d ${D}${systemd_system_unitdir}
+    install -d ${D}/lib/firmware/qcom/shikra/sensors/config


Why is a part of the firmware?

It is accessed as a part of readonly (/lib/firmware/qcom/shikra/) and we are using this directory to place our registry files.

It is not the firmware, so keep it away from that dir. Follow what has been established beforehand,

The RFS upstream driver translates remoteproc readonly path to /lib/firmware/qcom/shikra/ and readwrite path to /var/lib/tqftpserv only, so these paths added as per RFS team suggestion.

The PR needs to explain, why is it being loaded via TQFTP, how does it differ from the previous platforms, etc.

Anyway, form my point of view, all registry changes should be at the same place (/usr/share/qcom/SoC/Vendor/device/sensors/registry) and then, if necessary, symlinked to the TQFTP location.

The PR needs to explain, why is it being loaded via TQFTP, how does it differ from the previous platforms, etc.

So far, we have only supported targets that use the QMI framework as the communication mechanism for sensors. This is the first target(Shikra) to support the GLINK communication mechanism, which requires a different registry path due to RFS requirements.
As a result, we currently maintain separate sns_reg_config configurations for the two variants to ensure that each uses its own output directory. Consolidating the registry into a single location would cause the output directory of one target to overwrite that of the other, even when using symlinks.

Okay. Perfect. That's why we invented directories under /usr/share/qcom. It matches older devices, which loaded registry via the DSP calls.

lumag · 2026-06-20T22:54:36Z

    install -d ${D}${systemd_system_unitdir}
+    install -d ${D}/lib/firmware/qcom/shikra/sensors/config
+    install -d ${D}${sysconfdir}/udev/rules.d
+    install -d ${D}/var/lib/tqftpserv/sensors/registry


Is it accessed as /read write ?

Yes, it is accessed as readwrite. (/var/lib/tqftpserv)

So, how do we share it between different boards? Consider a rootfs working for Shikra and some other platform which also needs to ship those files.

So currently we are using two different communication mechanisms namely QMI framework and Glink,All the targets using QMI framework will be using etc/sensors/config as input directory for registry whereas the current target shikra is using:/lib/firmware/qcom/shikra/sensors/config.We are currently using SOC id to distinguish between the targets for which the communication mechanism needs to be picked.

First of all, for Glink communications we really expect a proper kernel driver, exporting necessary methods. No, using rpmsgexport is not a good or viable idea.

Second, as your commit messages lack explanations, I can only repeat myself. No, sensors configs are not firmware. If they are shared between targets, reuse /etc/sensors/config. If they are not, move them to /usr/share/qcom/SoC/Vendor/Device tree (see the link that I posted earlier). Extend tqftpserv to load data from that directory in some way.

The most important, start explaining why you are doing something in the commit messages. Then you will get more sensible responses from the maintainers and reviewers. Otherwise the only response you can get is "this doesn't match my view on the way things should be done, NAK".

Last, but not least. As a warning. #1907 has been open for a long time. Beforehand I also have been trying to get them published for a long time. After this PR lands, I'm going to block all future non-fixes updates to sensors binaries until there is at least some progress on that issue. If there are internal OSR tickets, please cc me on them so that I can monitor the progress. We need to stop ignoring our devices and at least provide necessary data so that the community can pick them up.

How do we distinguish two different SoCs using TQFTP for providing registry? If Shikra+1 uses the same approach, how would you handle it?

lumag · 2026-06-20T22:55:38Z

    install -m 0644 ${S}/etc/sensors/sns_reg_config ${D}${sysconfdir}/sensors/
    install -m 0644 ${S}/etc/sensors/config/* ${D}${sysconfdir}/sensors/config/
    install -m 0644 ${S}/etc/sensors/registry/sns_reg_version ${D}${sysconfdir}/sensors/registry/
+    install -m 0644 ${S}/lib/firmware/qcom/shikra/sensors/config/* ${D}/lib/firmware/qcom/shikra/sensors/config/


Definitely not a firmware. Install sensors configs to their place, under /use/share/qcom

lumag · 2026-06-20T22:57:52Z

+    install -m 0644 ${S}/lib/firmware/qcom/shikra/sensors/sns_reg_config ${D}/lib/firmware/qcom/shikra/sensors/
+    install -m 0644 ${S}/etc/udev/rules.d/99-rpmsg.rules ${D}${sysconfdir}/udev/rules.d/
+    install -m 0644 ${S}/var/lib/tqftpserv/sensors/registry/sns_reg_version ${D}/var/lib/tqftpserv/sensors/registry/
+    install -m 0644 ${S}/var/lib/tqftpserv/sensors/registry/sensors_registry ${D}/var/lib/tqftpserv/sensors/registry/


Registry is also a part of /use/share/qcom, to be installed in a device-specific path per my understanding.

quaresmajose · 2026-06-22T11:22:54Z

+
+FILES:${PN} += "/lib/firmware/qcom/shikra/sensors/*"
+
+INSANE_SKIP:${PN} += "usrmerge"


Can you please explain why we need this INSANE_SKIP?

The INSANE_SKIP was added because the sensor firmware is expected to be installed under /lib/firmware/qcom/sensors/. Without this, the files were being packaged under /usr/lib/firmware/qcom/sensors/, which is not the desired install location.

And isn't it exactly the same because of the /lib -> /usr/lib symlink?

The INSANE_SKIP was added because the sensor firmware is expected to be installed under /lib/firmware/qcom/sensors/. Without this, the files were being packaged under /usr/lib/firmware/qcom/sensors/, which is not the desired install location.

You should avoid using "/lib" or "/var" for the target rootfs and instaed use the bitbake variables for this.

sensors: upgrade 1.2.1 -> 2.0.0

5c763e1

Upgraded sensor binaries from 1.2.1 to 2.0.0. Add nanopb based proto compilation. Enabled the sensors features for Shikra target Signed-off-by: Bhanu Vivek Matsa <bmasta@qti.qualcomm.com>

bmasta018 requested review from anujm1, koenkooi, lumag, ndechesne, ricardosalveti and vkraleti as code owners June 20, 2026 19:37

lumag requested changes Jun 20, 2026

View reviewed changes

quaresmajose reviewed Jun 22, 2026

View reviewed changes

lumag added the backport wrynose label Jun 28, 2026


		FILES:${PN} += "/lib/firmware/qcom/shikra/sensors/*"

		INSANE_SKIP:${PN} += "usrmerge"

Uh oh!

Conversation

bmasta018 commented Jun 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants