Re: [PATCH v2] iio: accel: mma8452: add ACPI match table

[Jonathan Cameron <jic23@kernel.org>]

On Fri,  7 Aug 2026 20:13:25 +0300
Danil Sirin <danilsirin24@gmail.com> wrote:

> The mma8452 driver supports obtaining chip-specific data through
> i2c_get_match_data(), but only provides Device Tree and I2C match
> tables.
> 
> On ACPI-based x86 systems, compatible devices such as the MMA8653 are
> enumerated via ACPI, preventing the driver from binding.
> 
> Add an ACPI match table mapping the supported devices to the existing
> chip information structures.
> 
> Tested on a Bay Trail tablet exposing an MMA8653 device via ACPI. With
> this change the driver successfully probes, reads the expected chip ID
> (0x5a), and registers an IIO device.
These unfortunately are not ACPI spec complaint IDs. 
Given it is a 3 letter prefix it is the format of a PNP ID.
So to see who owns that space, need to look here:
https://uefi.org/pnp_id_list

Micromedia AG	MMA	1997-04-24

Which is not who made this part :( or I'd assume the the tablet you have.
They make nice looking audio interfaces it seems: https://www.micromedia.ch/

Fingers crossed they don't have a device with this ID sat on a relevant
bus type.

FWIW the ID should either have been one provided by the accelerometer
manufacturer, or one provided by the integrator (intel ones are fairly
common as they do this stuff right and produce reference designs that get
copied)

Anyhow, with all this in mind we are a bit flexible
on accepting them anyway, but needs to do a few things.

1. Name (and shame) the actual device that is shipping with this ID
   as a comment along side the ID table entry.  This stops us deleting
   it in future.
2. Keep the change tightly scoped, I don't want to see any invalid
   IDs without a comment next to them providing an example device
   that contains that part and uses the relevant wrong ID.
3. If you happen to have a contact with or can dig one out for the
   tablet manufacturers, please forward on the request that they stop
   doing this for future products. It is rare, but we have gotten a
   few firms to switch to doing it right!

> 
> Signed-off-by: Danil Sirin <danilsirin24@gmail.com>
> ---
> v2:
> - Update Signed-off-by tag with real name

Please don't send new versions in reply to old ones. It leads to
very confusing threads after a few versions and generally makes it
less likely anyone will notice the new version.

> 
>  drivers/iio/accel/mma8452.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index cefc7cf4b..8cb78e4cf 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1822,6 +1822,17 @@ static const struct dev_pm_ops mma8452_pm_ops = {
>  			   mma8452_runtime_resume, NULL)
>  };
> 
> +static const struct acpi_device_id mma8452_acpi_id[] = {
> +	{ "FXLS8471", (kernel_ulong_t)&mma_chip_info_table[fxls8471] },

What fun. That's an ACPI ID - I was briefly hoping a valid one.  But nope
	https://uefi.org/ACPI_ID_List?acpi_search=freescale
gives freescales ID as FRSC so it should have that prefix.

> +	{ "MMA8451", (kernel_ulong_t)&mma_chip_info_table[mma8451] },
> +	{ "MMA8452", (kernel_ulong_t)&mma_chip_info_table[mma8452] },
> +	{ "MMA8453", (kernel_ulong_t)&mma_chip_info_table[mma8453] },
> +	{ "MMA8652", (kernel_ulong_t)&mma_chip_info_table[mma8652] },
> +	{ "MMA8653", (kernel_ulong_t)&mma_chip_info_table[mma8653] },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(acpi, mma8452_acpi_id);
> +
>  static const struct i2c_device_id mma8452_id[] = {
>  	{ "fxls8471", (kernel_ulong_t)&mma_chip_info_table[fxls8471] },
>  	{ "mma8451", (kernel_ulong_t)&mma_chip_info_table[mma8451] },
> @@ -1837,6 +1848,7 @@ static struct i2c_driver mma8452_driver = {
>  	.driver = {
>  		.name	= "mma8452",
>  		.of_match_table = mma8452_dt_ids,
> +		.acpi_match_table = mma8452_acpi_id,
>  		.pm	= &mma8452_pm_ops,
>  	},
>  	.probe = mma8452_probe,
> --
> 2.55.0
>