On Sat, Sep 19, 2015 at 1:48 PM, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote:
> On Fri, Sep 18, 2015 at 12:07 AM, Mike Mestnik <cheako@xxxxxxxxxxxxxxx> wrote:
>> Hello,
>> I'm looking to know the result of adding ACPI support for a new
>> tablet, the existing support shouldn't work because of a misplaced
>> __init that causes the function to be removed prior to being called.
>
> Are you sure about this? It seems that the existing support doesn't work
> because you have different product ids.
>
The driver worked much better prior to me adding the product ids. The
sensors were exposed to sysfs and all the data they collected seemed
correct to me. The big issue is that there is no software, even
iio-sensor-proxy didn't know how to access the data.
>
>> After applying this patch I feel that I've moved support for the
>> T300CHI backwards. What should be the intended effect of using the
>> ACPI interface?
>>
>> Index: linux-4.1.3/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>> ===================================================================
>> --- linux-4.1.3.orig/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>> +++ linux-4.1.3/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>> @@ -23,27 +23,44 @@
>> enum inv_mpu_product_name {
>> INV_MPU_NOT_MATCHED,
>> INV_MPU_ASUS_T100TA,
>> + INV_MPU_ASUS_T300CHI,
>> };
>>
>> static enum inv_mpu_product_name matched_product_name;
>>
>> -static int __init asus_t100_matched(const struct dmi_system_id *d)
>> +static int asus_t100ta_matched(const struct dmi_system_id *d)
>> {
>> matched_product_name = INV_MPU_ASUS_T100TA;
>>
>> return 0;
>> }
>>
>> +static int asus_t300chi_matched(const struct dmi_system_id *d)
>> +{
>> + matched_product_name = INV_MPU_ASUS_T300CHI;
>> +
>> + return 0;
>> +}
>> +
>> static const struct dmi_system_id inv_mpu_dev_list[] = {
>> {
>> - .callback = asus_t100_matched,
>> - .ident = "Asus Transformer Book T100",
>> + .callback = asus_t100ta_matched,
>> + .ident = "Asus Transformer Book T100TA",
>> .matches = {
>> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC"),
>> DMI_MATCH(DMI_PRODUCT_NAME, "T100TA"),
>> DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
>> },
>> },
>> + {
>> + .callback = asus_t300chi_matched,
>> + .ident = "Asus Transformer Book T300CHI",
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "T300CHI"),
>> + DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
>> + },
>> + },
>> /* Add more matching tables here..*/
>> {}
>> };
>> @@ -154,6 +171,7 @@ int inv_mpu_acpi_create_mux_client(struc
>> dmi_check_system(inv_mpu_dev_list);
>> switch (matched_product_name) {
>> case INV_MPU_ASUS_T100TA:
>> + case INV_MPU_ASUS_T300CHI:
>> ret = asus_acpi_get_sensor_info(adev, st->client,
>> &info);
>> break;
>
> This looks good to me. Care to send a formal patch?
>
I would if the changes do what they are intended to do. With this
patch applied there is no longer entries for the device in sysfs and
iio-sensor-proxy is still unable to access the device. I'm wondering
how I'd be able to know if this change worked?
> thanks,
> Daniel.
--
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
