Message-ID: <o9POEVj6j_JoTCM8BNtkY-tPUh1jfHXyAgY7SHyws3zOuRqlaXZZsrDoaYxGtVjWyQdrFxAH1ztg4OD-Szh9ZdlYSe_3NbEMrY54DaqZYi4=@protonmail.com>
Date: Thu, 17 Jul 2025 13:27:08 +0000
From: Yassine Oudjana <y.oudjana@...tonmail.com>
To: Simon Horman <horms@...nel.org>
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 Thursday, July 10th, 2025 at 12:22 PM, Simon Horman <horms@...nel.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.

Powered by blists - more mailing lists