Received-SPF: pass (google.com: domain of linux-kernel+bounces-60444-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 10 Feb 2024 16:02:10 +0000
From: Jonathan Cameron <jic23@kernel.org>
To: Jesus Gonzalez <jesusmgh@gmail.com>
Cc: andriy.shevchenko@linux.intel.com, lars@metafoo.de,
 linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] Add 10EC5280 to bmi160_i2c ACPI IDs to allow
 binding on some devices
Message-ID: <20240210160210.65bb2c95@jic23-huawei>
In-Reply-To: <20240207195549.37994-2-jesusmgh@gmail.com>
References: <ZcOLql2RGmPP10EY@smile.fi.intel.com>
	<20240207195549.37994-2-jesusmgh@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed,  7 Feb 2024 20:55:50 +0100
Jesus Gonzalez <jesusmgh@gmail.com> wrote:

> "10EC5280" is used by several manufacturers like Lenovo, GPD, or AYA (and
> probably others) in their ACPI table as the ID for the bmi160 IMU. This
> means the bmi160_i2c driver won't bind to it, and the IMU is unavailable
> to the user. Manufacturers have been approached on several occasions to
> try getting a BIOS with a fixed ID, mostly without actual positive
> results, and since affected devices are already a few years old, this is
> not expected to change. This patch enables using the bmi160_i2c driver for
> the bmi160 IMU on these devices.
> 
> Here is the relevant extract from the DSDT of a GPD Win Max 2 (AMD 6800U
> model) with the latest firmware 1.05 installed. GPD sees this as WONTFIX
> with the argument of the device working with the Windows drivers.
> 
> 	Device (BMA2)
> 	{
> 	    Name (_ADR, Zero)  // _ADR: Address
> 	    Name (_HID, "10EC5280")  // _HID: Hardware ID
> 	    Name (_CID, "10EC5280")  // _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 */
> 	    }
> 	    
> 	    ...
> 	    
> 	}
> 
> Signed-off-by: Jesus Gonzalez <jesusmgh@gmail.com>
For future reference don't send a new version in reply to the old one.
It makes a big mess in many people's email clients
if we get lots of versions.  The patch naming is enough to associate
the different versions.

Applied to the togreg branch of iio.git and pushed out as testing for 0-day
to take a look at it.

Thanks,

Jonathan

> ---
> v4: Moved comment back to relevant position inside function
> 
>  drivers/iio/imu/bmi160/bmi160_i2c.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/iio/imu/bmi160/bmi160_i2c.c b/drivers/iio/imu/bmi160/bmi160_i2c.c
> index 81652c08e644..a081305254db 100644
> --- a/drivers/iio/imu/bmi160/bmi160_i2c.c
> +++ b/drivers/iio/imu/bmi160/bmi160_i2c.c
> @@ -43,6 +43,15 @@ static const struct i2c_device_id bmi160_i2c_id[] = {
>  MODULE_DEVICE_TABLE(i2c, bmi160_i2c_id);
>  
>  static const struct acpi_device_id bmi160_acpi_match[] = {
> +	/*
> +	 * FIRMWARE BUG WORKAROUND
> +	 * Some manufacturers like GPD, Lenovo or Aya used the incorrect
> +	 * ID "10EC5280" for bmi160 in their DSDT. A fixed firmware is not
> +	 * available as of Feb 2024 after trying to work with OEMs, and
> +	 * this is not expected to change anymore since at least some of
> +	 * the affected devices are from 2021/2022.
> +	 */
> +	{"10EC5280", 0},
>  	{"BMI0160", 0},
>  	{ },
>  };