On 04/08/15 10:58, Bastien Nocera wrote: > On Mon, 2015-08-03 at 13:09 -0700, Srinivas Pandruvada wrote: >> On Sun, 2015-08-02 at 18:18 +0100, Jonathan Cameron wrote: >>> On 23/07/15 16:21, Bastien Nocera wrote: >>>> Instead of using the I2C or ACPI ID to determine which variant of >>>> the chipset to use, determine that from the chip ID. >>>> >>>> Under Windows, the same driver is used for those variants and, >>>> despite >>>> incorrect ACPI data, it is able to load and operate the >>>> accelerometer. >>>> >>>> Fixes the accelerometer failing with: >>>> bmc150_accel i2c-BMA250E:00: Invalid chip f8 >>>> on the WinBook TW100 >>>> >>>> Signed-off-by: Bastien Nocera <hadess@xxxxxxxxxx> >>> I'll start by saying I hate that this change is necessary down >>> at the driver level. >>> >>> Is there no way to catch it as an ACPI quirk? (I know next to >>> nothing about >>> ACPI and a quick a google isn't pointing me in the right >>> direction!) >>> Seems irritating that we have to deal with this but such is life I >>> guess >>> (anyone want to take the bet that at some point the windows driver >>> will break >>> horribly as well for these machines?) >>> >>> Anyhow, Srinivas, could you also take a look at this one. >>> >>> I suppose I'll cope with the horribleness :) >> We have seen where manufactures replaces a part for some reason, >> without >> modifying ACPI tables. So matching chip id makes sense logically. But >> even this is not fail proof. Some parts have same chip id with >> different >> features (clones), in that case ACPI match makes more sense. >> There is a way to patch ACPI tables but that also need to be based on >> some DMI information. >> I am not aware of such issue with Bosch parts. So I think this would >> be >> OK to use chip id here instead of acpi id here. But what about using >> this only when the current logic fails? In this way we can still have >> another entry in the table for clones, if required. > > For clones which don't advertise the right chip ID, I'd just have a > separate quirk table, "use this chip ID for that hardware". > > Seems simpler, and I'm happy to write that code when we encounter the > problem. I'm convinced. Applied to the togreg branch of iio.git (too large to push out as a fix at this point in the cycle as it's not fixing a regression). Note that it didn't apply cleanly so please take a quick look to check I haven't messed it up! Will be pushed out as testing as soon as my local sanity check build is done so the autobuilders can hit it harder. Thanks, Jonathan > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
