netdev - Re: [PATCH v2 0/4] QRTR bus and Qualcomm Sensor Manager IIO drivers

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250710112208.GR721198@horms.kernel.org>
Date: Thu, 10 Jul 2025 12:22:08 +0100
From: Simon Horman <horms@...nel.org>
To: y.oudjana@...tonmail.com
Cc: 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>,
	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>,
	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
Subject: Re: [PATCH v2 0/4] QRTR bus and Qualcomm Sensor Manager IIO drivers

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