[Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices
Hans de Goede
j.w.r.degoede at gmail.com
Fri Apr 21 10:50:04 UTC 2017
Hi,
On 21-04-17 12:40, Rafael J. Wysocki wrote:
> On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote:
>> HI,
>>
>
> [cut]
>
>>>>> And in that path, which I seem to have overlooked before, the
>>>>> acpi_set_device_status() call is too early for invoking
>>>>> acpi_device_always_present(adev), so the latter should be called
>>>>> directly from acpi_add_single_object() like
>>>>>
>>>>> acpi_init_device_object(device, handle, type, sta);
>>>>> if (acpi_device_always_present(adev))
>>>>> acpi_set_device_status(adev, ACPI_STA_DEFAULT);
>>>>
>>>> That is not necessary, the place(s) where we care about status being
>>>> fixed-up for always-present devices, so that they get scanned / their
>>>> platform device initiated, is in acpi_bus_attach() which
>>>> already calls acpi_bus_get_status() and thus gets the
>>>> acpi_device_always_present() check applied before checking.
>>>>
>>>> For hotplugged devices there are acpi_scan_bus_check and
>>>> acpi_scan_device_check but those both also already call
>>>> acpi_bus_get_status() before checking adev->status.
>>>
>>> OK
>>>
>>> Which probably means that we don't need to initialize adev->status
>>> in acpi_init_device_object() to anything meaningful, do we?
>>
>> Right, I don't think that is necessary. But maybe it is necessary
>> for some special cases (e.g. power resources) ?
>
> For power resources _STA is defined differently at all and we don't
> even call acpi_add_single_object() for them. :-)
>
> Are there any other special cases in which that may matter?
Not that I'm aware of, but I'm in no way an expert when it comes
to the ACPI subsystem.
Regards,
Hans
More information about the Intel-gfx
mailing list