[PATCH AUTOSEL 6.17-6.6] iio: adc: imx93_adc: load calibrated values even calibration failed

[PATCH AUTOSEL 6.17-6.6] iio: adc: imx93_adc: load calibrated values even calibration failed

[Sasha Levin]

From: Haibo Chen <haibo.chen@nxp.com>

[ Upstream commit 12c9b09e981ab14ebec8e4eefa946cbd26dd306b ]

ADC calibration might fail because of the noise on reference voltage.
To avoid calibration fail, need to meet the following requirement:
    ADC reference voltage Noise < 1.8V * 1/2^ENOB

For the case which the ADC reference voltage on board do not meet
the requirement, still load the calibrated values, so ADC can also
work but maybe not that accurate.

Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Primoz Fiser <primoz.fiser@norik.com>
Link: https://patch.msgid.link/20250812-adc-v2-2-0260833f13b8@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

Explanation
- Problem addressed: On some boards the i.MX93 ADC calibration fails due
  to reference voltage noise (commit message). In the current code, a
  calibration failure aborts driver probe, leaving the ADC unusable for
  users.
- Current failure path: `imx93_adc_calibration()` returns `-EAGAIN` on
  calibration failure, explicitly powering down the ADC and aborting
  probe:
  - Failure check/return: drivers/iio/adc/imx93_adc.c:181 (checks
    `IMX93_ADC_MSR_CALFAIL_MASK`) and drivers/iio/adc/imx93_adc.c:185
    (returns `-EAGAIN`).
  - Probe abort on error: drivers/iio/adc/imx93_adc.c:367 (calibration
    call) and drivers/iio/adc/imx93_adc.c:368–396 (error unwinding).
- What the patch changes:
  - Adds `IMX93_ADC_CALCFG0` (0x3A0) and `IMX93_ADC_CALCFG0_LDFAIL_MASK`
    (BIT(4)) so the driver can instruct hardware to load calibrated
    values even if calibration “fails”.
  - In `imx93_adc_calibration()` (drivers/iio/adc/imx93_adc.c:146),
    before starting calibration, it writes
    `IMX93_ADC_CALCFG0_LDFAIL_MASK` to `IMX93_ADC_CALCFG0` to enable
    “load-on-fail”.
  - It changes the failure handling on `CALFAIL`: instead of returning
    `-EAGAIN`, it logs a warning and continues, allowing the driver to
    register and the ADC to function, albeit with potentially reduced
    accuracy.
  - The timeout path remains unchanged and still returns an error if
    calibration never completes (drivers/iio/adc/imx93_adc.c:171–178),
    preserving safety for a hard failure.
- User impact: This is a practical fix for real boards where Vref noise
  is above the stated threshold; without it, the ADC never comes up.
  With it, the ADC works (possibly with lower accuracy), which is
  typically preferable to complete unavailability.
- Scope and risk:
  - Small, contained change in a single driver
    (`drivers/iio/adc/imx93_adc.c`) with no ABI or framework changes.
  - No architectural refactoring; only adds a register define and a
    single bit write plus relaxed error handling.
  - Timeout/hard-error behavior is unchanged; only soft failure
    (CALFAIL) behavior is relaxed.
  - The driver matches only `nxp,imx93-adc`
    (drivers/iio/adc/imx93_adc.c:465–469), so the change is isolated to
    this hardware.
- Stable criteria:
  - Fixes a user-visible bug (driver failing to probe on noisy Vref
    boards).
  - Minimal and low risk; confined to probe/calibration logic.
  - No new features; behavior change is a robustness fix with guarded
    warning.
  - No broader side effects beyond this ADC device.

Given these points, this is a solid candidate for backporting to any
stable trees that contain the i.MX93 ADC driver and its current fail-
hard calibration path.

 drivers/iio/adc/imx93_adc.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/imx93_adc.c b/drivers/iio/adc/imx93_adc.c
index 7feaafd2316f2..9f1546c3d39d5 100644
--- a/drivers/iio/adc/imx93_adc.c
+++ b/drivers/iio/adc/imx93_adc.c
@@ -38,6 +38,7 @@
 #define IMX93_ADC_PCDR6		0x118
 #define IMX93_ADC_PCDR7		0x11c
 #define IMX93_ADC_CALSTAT	0x39C
+#define IMX93_ADC_CALCFG0	0x3A0
 
 /* ADC bit shift */
 #define IMX93_ADC_MCR_MODE_MASK			BIT(29)
@@ -58,6 +59,8 @@
 #define IMX93_ADC_IMR_ECH_MASK			BIT(0)
 #define IMX93_ADC_PCDR_CDATA_MASK		GENMASK(11, 0)
 
+#define IMX93_ADC_CALCFG0_LDFAIL_MASK		BIT(4)
+
 /* ADC status */
 #define IMX93_ADC_MSR_ADCSTATUS_IDLE			0
 #define IMX93_ADC_MSR_ADCSTATUS_POWER_DOWN		1
@@ -145,7 +148,7 @@ static void imx93_adc_config_ad_clk(struct imx93_adc *adc)
 
 static int imx93_adc_calibration(struct imx93_adc *adc)
 {
-	u32 mcr, msr;
+	u32 mcr, msr, calcfg;
 	int ret;
 
 	/* make sure ADC in power down mode */
@@ -158,6 +161,11 @@ static int imx93_adc_calibration(struct imx93_adc *adc)
 
 	imx93_adc_power_up(adc);
 
+	/* Enable loading of calibrated values even in fail condition */
+	calcfg = readl(adc->regs + IMX93_ADC_CALCFG0);
+	calcfg |= IMX93_ADC_CALCFG0_LDFAIL_MASK;
+	writel(calcfg, adc->regs + IMX93_ADC_CALCFG0);
+
 	/*
 	 * TODO: we use the default TSAMP/NRSMPL/AVGEN in MCR,
 	 * can add the setting of these bit if need in future.
@@ -180,9 +188,13 @@ static int imx93_adc_calibration(struct imx93_adc *adc)
 	/* check whether calbration is success or not */
 	msr = readl(adc->regs + IMX93_ADC_MSR);
 	if (msr & IMX93_ADC_MSR_CALFAIL_MASK) {
+		/*
+		 * Only give warning here, this means the noise of the
+		 * reference voltage do not meet the requirement:
+		 *     ADC reference voltage Noise < 1.8V * 1/2^ENOB
+		 * And the resault of ADC is not that accurate.
+		 */
 		dev_warn(adc->dev, "ADC calibration failed!\n");
-		imx93_adc_power_down(adc);
-		return -EAGAIN;
 	}
 
 	return 0;
-- 
2.51.0

[PATCH AUTOSEL 6.17] iio: imu: bmi270: Match PNP ID found on newer GPD firmware

[Sasha Levin]

From: Cryolitia PukNgae <cryolitia@uniontech.com>

[ Upstream commit dc757dc1572d579c2634c05d0a03c5676227c571 ]

GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID.
When they switched to BMI260 sensors in newer hardware, they reused
the existing Windows driver which accepts both "BMI0160" and "BMI0260"
IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260
devices, causing driver mismatches in Linux.

1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for
BMI260 sensors to avoid loading the bmi160 driver on Linux. While this
isn't Bosch's VID;
2. Bosch's official Windows driver uses "BMI0260" as a compatible ID
3. We're seeing real devices shipping with "BMI0260" in DSDT

The DSDT excerpt of GPD G1619-04 with BIOS v0.40:

Scope (_SB.I2CC)
{
    Device (BMA2)
    {
        Name (_ADR, Zero)  // _ADR: Address
        Name (_HID, "BMI0260")  // _HID: Hardware ID
        Name (_CID, "BMI0260")  // _CID: Compatible ID
        Name (_DDN, "Accelerometer")  // _DDN: DOS Device Name
        Name (_UID, One)  // _UID: Unique ID
        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (RBUF, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.I2CC",
                    0x00, ResourceConsumer, , Exclusive,
                    )
            })
            Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */
        }
        # omit some noise
    }
}

Link: http://download.softwincn.com/WIN%20Max%202024/Max2-7840-BIOS-V0.41.zip #1
Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Alex Lanzano <lanzano.alex@gmail.com>
Link: https://patch.msgid.link/20250821-bmi270-gpd-acpi-v4-1-5279b471d749@uniontech.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## BACKPORT RECOMMENDATION: **YES**

### Executive Summary

This commit adds ACPI device ID "BMI0260" to the bmi270 IIO driver to
support BMI260 IMU sensors on newer GPD devices (BIOS v0.40+). The
change is minimal (2 lines), safe, and addresses a real hardware
compatibility issue affecting users in the field.

---

### Comprehensive Analysis

#### 1. **Problem Being Fixed**

**User-Visible Bug**: GPD gaming handheld devices with updated BIOS
firmware (v0.40+) declare "BMI0260" as the ACPI hardware ID for their
BMI260 IMU sensors. Without this patch, these sensors are completely
non-functional because no Linux driver claims the "BMI0260" ACPI ID.

**Background Context** (from commit f35f3c832eb58):
- GPD originally used BMI160 sensors with "BMI0160" ACPI ID
- They switched to BMI260 hardware but initially kept "BMI0160" in
  firmware tables (causing driver mismatches)
- GPD released BIOS v0.40+ that properly reports "BMI0260" for BMI260
  sensors
- Linux needs to be updated to recognize this new ACPI ID

**Affected Hardware**: GPD Win Max 2 2023, GPD G1619-04, and potentially
other GPD gaming handhelds with BIOS v0.40+

#### 2. **Code Changes Analysis**

The commit modifies `drivers/iio/imu/bmi270/bmi270_i2c.c`:

```c
static const struct acpi_device_id bmi270_acpi_match[] = {
    /* GPD Win Mini, Aya Neo AIR Pro, OXP Mini Pro, etc. */
    { "BMI0160",  (kernel_ulong_t)&bmi260_chip_info },
+   /* GPD Win Max 2 2023(sincice BIOS v0.40), etc. */
+   { "BMI0260",  (kernel_ulong_t)&bmi260_chip_info },
    { }
};
```

**Change Characteristics**:
- **Size**: 2 lines added (1 comment, 1 ACPI ID entry)
- **Scope**: Single driver file, single match table
- **Type**: Device ID addition (no logic changes)
- **Complexity**: Trivial

**Minor Issue Noted**: Typo in comment: "sincice" should be "since"
- **Impact**: None - cosmetic only, doesn't affect functionality
- **Note**: In Linux kernel stable backports, typos in comments are
  acceptable if the code is correct

#### 3. **Safety & Risk Assessment**

**Regression Risk: ESSENTIALLY ZERO**

Evidence supporting zero regression risk:

1. **No Existing Functionality Modified**: The change only adds a new
   ACPI ID that currently matches NO driver
2. **Isolated Impact**: Only affects devices that declare "BMI0260" in
   their ACPI tables
3. **Hardware Validation Present**: The driver
   (bmi270_core.c:bmi270_validate_chip_id) reads the actual chip ID from
   hardware registers and validates it:
  ```c
  if (chip_id == BMI160_CHIP_ID_VAL)
  return -ENODEV;  // Reject BMI160 chips

  if (chip_id == bmi260_chip_info.chip_id)
  data->chip_info = &bmi260_chip_info;
  else if (chip_id == bmi270_chip_info.chip_id)
  data->chip_info = &bmi270_chip_info;
  ```
4. **Defense in Depth**: Even if ACPI tables are wrong, the driver
   detects mismatches via chip ID
5. **No Driver Conflicts**: The bmi160 driver does NOT claim "BMI0260"
   (I verified via grep - no files in bmi160 directory contain
   "BMI0260")

**Security Assessment**: LOW risk (from security audit agent)
- Chip ID validation prevents device confusion attacks
- No new attack surfaces introduced
- Firmware loading security is a pre-existing concern, not introduced by
  this change

#### 4. **Dependencies & Backport Target**

**Required Dependency**: BMI260 hardware support
- Commit: f35f3c832eb58 "iio: imu: bmi270: Add support for BMI260"
- Merged in: v6.13-rc1 (verified via `git describe --contains`)

**Backport Target**: Stable kernels v6.13 and later

**Reason**: Earlier kernels don't have BMI260 support, so adding the
ACPI ID would be meaningless

#### 5. **Stable Tree Criteria Evaluation**

| Criterion | Met? | Evidence |
|-----------|------|----------|
| Fixes important bug | ✅ YES | Hardware completely non-functional
without fix |
| Small and contained | ✅ YES | 2 lines, single file, single driver |
| Minimal regression risk | ✅ YES | Zero risk - only affects new device
IDs |
| Clear side effects? | ✅ NO | No side effects beyond fixing the issue |
| Architectural changes? | ✅ NO | None whatsoever |
| Critical subsystem? | ✅ NO | IIO driver for specific sensor |
| Well-reviewed | ✅ YES | Reviewed by Andy Shevchenko, Acked by Alex
Lanzano |
| Explicit stable tag | ⚠️ NO | Not present, but often added during
backport process |

**Score**: 7/8 criteria clearly met, 1 not required

#### 6. **Historical Context & Precedent**

**Similar Backported Commits**:
- commit ca2f16c315683: "Add 10EC5280 to bmi160_i2c ACPI IDs" - Similar
  ACPI ID addition for BMI160
- Many other IIO driver ACPI ID additions routinely get backported

**Established Pattern**: The kernel community regularly backports simple
device ID additions like this, as they:
- Enable hardware support for real devices
- Have zero regression risk
- Are trivial changes
- Don't modify existing functionality

#### 7. **ACPI Matching Mechanism Research**

From my kernel code researcher agent's findings:

**Key Insights**:
1. Multiple drivers CAN safely declare the same ACPI ID
2. The bmi160 and bmi270 drivers already share "BMI0160" successfully
3. When multiple drivers match, kernel tries each in order
4. Returning -ENODEV from probe allows fallback to next driver
5. The bmi270 driver explicitly checks chip ID and returns -ENODEV for
   BMI160 chips

**Safety Mechanism**: This design allows hardware-based driver selection
rather than relying solely on ACPI tables, which manufacturers sometimes
get wrong.

#### 8. **Real-World Impact**

**Without this patch**:
- Users with GPD devices on BIOS v0.40+ have non-functional IMU sensors
- Accelerometer and gyroscope features don't work
- Gaming handhelds rely on these sensors for screen rotation and game
  controls

**With this patch**:
- IMU sensors work correctly
- All sensor functionality enabled (accelerometer, gyroscope,
  temperature)
- Users can use screen rotation and sensor-based controls

**User Base**: Gaming handheld enthusiasts who keep their firmware
updated

#### 9. **Quality Indicators**

**Review Process**:
- Reviewed-by: Andy Shevchenko <andy@kernel.org> (experienced kernel
  developer)
- Acked-by: Alex Lanzano <lanzano.alex@gmail.com> (BMI270 driver
  maintainer)
- Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> (IIO
  subsystem maintainer)

**Testing**: Presumably tested on actual GPD hardware with BIOS v0.40+

**Code Style**: Follows existing patterns in the driver exactly

#### 10. **Comparison to Other Backport Candidates**

This commit is more straightforward than many other backport candidates
because:
- It's purely additive (no modifications to existing code)
- The affected hardware is completely non-functional without it
- There's zero chance of breaking existing functionality
- It's been reviewed by multiple experienced maintainers

---

### Final Recommendation: **YES - SHOULD BE BACKPORTED**

**Backport to**: Stable kernels v6.13+

**Justification**:
1. ✅ **Fixes Real User Problem**: Hardware compatibility issue affecting
   real devices
2. ✅ **Zero Regression Risk**: Only adds new device ID, no existing
   functionality changed
3. ✅ **Trivial Change**: 2 lines, well-reviewed, follows established
   patterns
4. ✅ **Safety Mechanisms**: Driver has chip ID validation preventing
   mismatches
5. ✅ **Meets Stable Criteria**: Small, contained, important bugfix,
   minimal risk
6. ✅ **Precedent**: Similar changes routinely backported

**Note on Typo**: The "sincice" → "since" typo in the comment is
cosmetic and doesn't affect functionality. In Linux kernel stable
backports, such typos are acceptable when the code itself is correct.

**Dependencies**: Requires BMI260 support (commit f35f3c832eb58), which
is present in v6.13+

 drivers/iio/imu/bmi270/bmi270_i2c.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/imu/bmi270/bmi270_i2c.c b/drivers/iio/imu/bmi270/bmi270_i2c.c
index c77839b03a969..b909a421ad017 100644
--- a/drivers/iio/imu/bmi270/bmi270_i2c.c
+++ b/drivers/iio/imu/bmi270/bmi270_i2c.c
@@ -41,6 +41,8 @@ static const struct i2c_device_id bmi270_i2c_id[] = {
 static const struct acpi_device_id bmi270_acpi_match[] = {
 	/* GPD Win Mini, Aya Neo AIR Pro, OXP Mini Pro, etc. */
 	{ "BMI0160",  (kernel_ulong_t)&bmi260_chip_info },
+	/* GPD Win Max 2 2023(sincice BIOS v0.40), etc. */
+	{ "BMI0260",  (kernel_ulong_t)&bmi260_chip_info },
 	{ }
 };
 
-- 
2.51.0