| Message ID | 12437546.O9o76ZdvQC@nobara-ally-pc (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/2] iio: accel: bmc150: ASUS ROG ALLY Abort Loading | expand |
On Sun, Feb 11, 2024 at 12:32 AM Jonathan LoBue <jlobue10@gmail.com> wrote: > > From 0aed4d398be185d43b92db63693bb1c5c6a8a78b Mon Sep 17 00:00:00 2001 > From: Jonathan LoBue <jlobue10@gmail.com> > Date: Sat, 10 Feb 2024 12:28:35 -0800 > Subject: [PATCH 1/2] iio: accel: bmc150: ASUS ROG ALLY Abort Loading Something went wrong, please use `git send-email ...` to send patches. > This portion of the patch series aborts the loading of the bmc150 driver > upon DMI board match for ASUS ROG ALLY and Ayaneo Air Plus (requested by > ChimeraOS dev). ... > + if (dmi_match(DMI_BOARD_NAME, "RC71L") || (dmi_match(DMI_BOARD_NAME, "AB05-AMD") && dmi_match(DMI_PRODUCT_NAME, "AIR Plus"))) > + return -ENODEV; // Abort loading bmc150 for ASUS ROG ALLY, Ayaneo Air Plus Please, make this as the proper table (see many examples in drivers/platform/x86/ folder on how to do that). ... Speaking of the PDx86 subsystem, OTOH maybe we want the quirk patch to be outside of IIO and enumerate the IIO drivers based on i2c/spi ID tables (there are also examples unde PDx86 folder for such tricks). Hans, Ilpo, what do you think? (Jonathan, please also include Hans in the similar cases in the future with ACPI IDs and related ambiguity.)
On Sunday, February 11, 2024 9:04:56 AM PST Andy Shevchenko wrote: > Something went wrong, please use `git send-email ...` to send patches. Will do once I can test the suggested updated table method. > Please, make this as the proper table (see many examples in > drivers/platform/x86/ folder on how to do that). This DMI board match and aborting of loading the driver is hopefully a temporary portion of this patch. The ideal fix is that BOSCH informs ASUS and other system builders of the proper and unique BOSCXXXX identifier so that BIOSes can be updated with those and this portion of the patch can be removed. As it stands now, this is the "band-aid" workaround of having conflicting (same) IDs for different chips. Best Regards, Jon LoBue
On Mon, Feb 12, 2024 at 9:21 AM Jonathan LoBue <jlobue10@gmail.com> wrote: > > On Sunday, February 11, 2024 9:04:56 AM PST Andy Shevchenko wrote: > > Something went wrong, please use `git send-email ...` to send patches. > > Will do once I can test the suggested updated table method. > > > Please, make this as the proper table (see many examples in > > drivers/platform/x86/ folder on how to do that). > > This DMI board match and aborting of loading the driver is hopefully > a temporary portion of this patch. The ideal fix is that BOSCH informs > ASUS and other system builders of the proper and unique BOSCXXXX > identifier so that BIOSes can be updated with those and this portion > of the patch can be removed. As it stands now, this is the "band-aid" > workaround of having conflicting (same) IDs for different chips. Even if fixed (which has to be done anyway) it can be undone in old firmwares — there is no solution to make all affected users update firmware. Do we have real products on the market with the wrong ID (I assume we do)?
On Monday, February 12, 2024 1:46:21 AM PST Andy Shevchenko wrote: > Even if fixed (which has to be done anyway) it can be undone in old > firmwares — there is no solution to make all affected users update > firmware. Do we have real products on the market with the wrong ID (I > assume we do)? After some conversations with other devs today, we retested and confirmed that the DMI quirks to abort loading of bmc150 is actually unnecessary. There was some confusion among us about why they had tried that approach in the past. The bmc150 driver does in fact start to load on ASUS ROG ALLY with a "BOSC0200" ACPI match, but when it gets to the chip id check portion it correctly aborts loading the driver for mismatched chip ID. This allows the bmi323 driver to pick it up properly with the "BOSC0200" ACPI match table match. Tested and confirmed working on my end with the submitted v1 patch. The DMI quirks and any modifications to bmc150 driver has been dropped. Thanks all for the feedback and help. Best Regards, Jon LoBue
diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c index 110591804b4c..576da9def8eb 100644 --- a/drivers/iio/accel/bmc150-accel-core.c +++ b/drivers/iio/accel/bmc150-accel-core.c @@ -10,6 +10,7 @@ #include <linux/delay.h> #include <linux/slab.h> #include <linux/acpi.h> +#include <linux/dmi.h> #include <linux/of_irq.h> #include <linux/pm.h> #include <linux/pm_runtime.h> @@ -1670,6 +1671,9 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq, struct iio_dev *indio_dev; int ret; + if (dmi_match(DMI_BOARD_NAME, "RC71L") || (dmi_match(DMI_BOARD_NAME, "AB05-AMD") && dmi_match(DMI_PRODUCT_NAME, "AIR Plus"))) + return -ENODEV; // Abort loading bmc150 for ASUS ROG ALLY, Ayaneo Air Plus + indio_dev = devm_iio_device_alloc(dev, sizeof(*data)); if (!indio_dev) return -ENOMEM;