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

Andy Shevchenko
2026-04-10T04:36:18Z

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