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

[Yassine Oudjana]

On Thursday, July 10th, 2025 at 12:22 PM, Simon Horman <horms@xxxxxxxxxx> 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.