Re: [PATCH v2 0/4] Add QST QMC5883P magnetometer driver

[Andy Shevchenko]

On Thu, Apr 09, 2026 at 09:07:11PM +0000, Hardik Phalet wrote:
> This series adds initial Linux support for the QST QMC5883P, a 3-axis
> anisotropic magneto-resistive (AMR) magnetometer with a 16-bit ADC that
> communicates over I2C. To my knowledge there is no existing upstream
> driver for this device.
> 
> The driver supports:
>   - Raw magnetic field readings on X, Y, and Z axes
>   - Four selectable full-scale ranges (±2 G, ±8 G, ±12 G, ±30 G)
>   - Configurable output data rate (10, 50, 100, 200 Hz)
>   - Configurable oversampling ratio (1, 2, 4, 8)
>   - Configurable downsampling ratio (1, 2, 4, 8) via a custom sysfs
>     attribute
>   - Runtime PM with a 2 s autosuspend delay
>   - System suspend/resume via pm_runtime_force_suspend/resume
> 
> Regmap with an rbtree cache is used throughout. CTRL_1 and CTRL_2
> bit fields are accessed via regmap_field to avoid read-modify-write
> races. The STATUS register is marked precious so regmap never reads
> it speculatively and clears the DRDY/OVFL bits unexpectedly.
> 
> The init sequence on probe is: soft reset → wait 1 ms → deassert
> reset → configure SET/RESET control → apply default ODR/OSR/DSR/RNG
> → enter normal mode. This ordering was determined empirically on
> hardware to produce reliable, non-zero axis readings.
> 
> The driver is placed under drivers/staging/iio/magnetometer/ with a
> TODO file tracking the remaining work before it can graduate:
>   - Triggered buffer support (iio_triggered_buffer_setup)
>   - DRDY interrupt support
>   - Self-test implementation
> 
> Patches:
>   1/4 - dt-bindings: vendor-prefixes: Add 'qst' for QST Corporation
>   2/4 - dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
>   3/4 - staging: iio: magnetometer: Add QST QMC5883P driver
>   4/4 - MAINTAINERS: Add entry for QST QMC5883P magnetometer driver
> 
> Testing
> -------
> Tested on a Raspberry Pi 4B running a mainline kernel (aarch64) with a
> GY-271 HM-246 board connected via I2C bus 1. The chip was confirmed to
> enumerate at address 0x2C via i2cdetect.
> 
> The driver was cross-compiled from Fedora (x86_64) targeting aarch64
> and loaded as a module (qmc5883p.ko) with the Device Tree overlay
> pointing at i2c1:0x2c.
> 
> Verification steps performed:
>   - Chip ID register (0x00) reads back 0x80 on probe, confirming the
>     correct device is present
>   - All three axes (in_magn_x_raw, in_magn_y_raw, in_magn_z_raw) return
>     non-zero, stable values when the board is held still and change
>     appropriately when the board is rotated
>   - in_magn_x_scale (and Y, Z) returns the expected fractional value for
>     the default ±8 G range (1/37500000)
>   - in_magn_sampling_frequency / _available, in_magn_oversampling_ratio /
>     _available, and downsampling_ratio / downsampling_ratio_available all
>     read and write correctly; the chip responds without error to each
>     valid setting
>   - Runtime PM: after 2 s of inactivity the device enters suspend mode
>     (MODE = 0x00 confirmed via i2cdump); the next sysfs read correctly
>     resumes the device and returns valid data
>   - System suspend/resume (echo mem > /sys/power/state) leaves the
>     driver in a consistent state; readings remain valid after resume
>   - dt_binding_check passes for patch 2/4
>   - Kernel builds cleanly with W=1 and no new warnings

This driver is rather huge. There are mistakes you made in the process, though:
- never send a new version for such a code (amount and complexity) earlier than
a week; give others a chance to review
- do not put driver to staging, why?
- the investigation is rather poor about existence of the driver — make sure
there is no compatible (by register layout) driver in IIO or even outside it
(for ADCs it might appear as HWMON [drivers/hwmon] or INPUT [drivers/input]
 in some cases)

-- 
With Best Regards,
Andy Shevchenko