On 19/09/15 20:03, Mike Mestnik wrote:
> 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.
Cc'd Bastien Nocera.
>
>>
>>> 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
>
--
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
