Re: [PATCH 1/1] asus-wireless: Use the correct HSWC parameter for each HID

[JoÃo Paulo Rechi Vita]

On 7 February 2017 at 18:37, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> On Tue, Feb 7, 2017 at 11:44 PM, JoÃo Paulo Rechi Vita
> <jprvita@xxxxxxxxx> wrote:
>> On 4 February 2017 at 10:02, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
>>> On Wed, Feb 1, 2017 at 2:20 PM, JoÃo Paulo Rechi Vita <jprvita@xxxxxxxxx> wrote:
>>>> On 27 January 2017 at 10:26, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
>>>>> On Thu, Jan 26, 2017 at 5:00 PM, JoÃo Paulo Rechi Vita
>>>>> <jprvita@xxxxxxxxx> wrote:
>>>
>>>>>> +static const struct acpi_device_id device_ids[] = {
>>>>>> +       {"ATK4001", 0},
>>>>>> +       {"ATK4002", 0},
>>>>>
>>>>> ...and use it as a parameter here.
>>>>>
>>>>
>>>> I'm not exactly sure how to do that, as driver_data is a
>>>> kernel_ulong_t. Can you please elaborate a bit more?
>>>
>>> {"ATK4001", (kernel_ulong_t)atk4001_id_params},
>>>
>>
>> The code you suggested:
>>
>> static const struct hswc_params atk4001_id_params = {0x0, 0x1, 0x2};
>> static const struct acpi_device_id device_ids[] = {
>>        {"ATK4001", (kernel_ulong_t)atk4001_id_params},
>>        {"", 0},
>> };
>>
>> does not compile: "drivers/platform/x86/asus-wireless.c:44:2: error:
>> aggregate value used where an integer was expected", so I guess you
>> meant the address of that struct (&atk4001_id_params), right? I don't
>> see any way how we could have the actual data in .driver_data.
>
> Yes, you are right. I kept in mind array when was suggesting this.
>
>> Even after moving the parameters in the driver_data field of
>> device_ids[], I'm not able retrieve them with acpi_match_device(),
>> because the "struct device" from the "struct acpi_device" that comes
>> as an input parameter in asus_wireless_add() does not have a acpi
>> companion device associated with it, so acpi_match_device() returns
>> NULL. I still need to manually loop through device_ids[] in order to
>> retrieve the .driver_data associated with the HID, and I see the same
>> pattern in the i2c-scmi driver.
>
> And what prevents us to set companion device?
>

Assuming this in the scope of a platform driver (genuine question, as
I don't see anything under drivers/platform/ doing so), nothing
prevents us to set it. But when doing so, acpi_match_device() still
fails, because acpi_get_first_physical_node() returns a different
"struct dev *" in acpi_primary_dev_companion().

--
JoÃo Paulo Rechi Vita
http://about.me/jprvita