[PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Hans de Goede]

Most Bay and Cherry Trail devices use a generic DSDT with all possible
peripheral devices present in the DSDT, with their _STA returning 0x00 or
0x0f based on AML variables which describe what is actually present on
the board.

Since ACPI device objects with a 0x00 status (not present) still get an
entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
modalias, userspace would end up loading modules for non present hardware.

This commit fixes this by leaving the modalias empty for non present
devices. This results in 10 modules less being loaded with a generic
distro kernel config on my Cherry Trail test-device (a GPD pocket).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/device_sysfs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
index 24418932612e..a041689e5701 100644
--- a/drivers/acpi/device_sysfs.c
+++ b/drivers/acpi/device_sysfs.c
@@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
 	int count;
 	struct acpi_hardware_id *id;
 
+	/* Avoid unnecessarily loading modules for non present devices. */
+	if (!acpi_device_is_present(acpi_dev))
+		return 0;
+
 	/*
 	 * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
 	 * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
-- 
2.14.2

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Rafael J. Wysocki]

On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Most Bay and Cherry Trail devices use a generic DSDT with all possible
> peripheral devices present in the DSDT, with their _STA returning 0x00 or
> 0x0f based on AML variables which describe what is actually present on
> the board.
>
> Since ACPI device objects with a 0x00 status (not present) still get an
> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
> modalias, userspace would end up loading modules for non present hardware.
>
> This commit fixes this by leaving the modalias empty for non present
> devices. This results in 10 modules less being loaded with a generic
> distro kernel config on my Cherry Trail test-device (a GPD pocket).

Well, what about hotplug?

On some systems _STA may change from 0 to nonzero for some devices, so
what's going to happen to the modalias then?

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/acpi/device_sysfs.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> index 24418932612e..a041689e5701 100644
> --- a/drivers/acpi/device_sysfs.c
> +++ b/drivers/acpi/device_sysfs.c
> @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
>         int count;
>         struct acpi_hardware_id *id;
>
> +       /* Avoid unnecessarily loading modules for non present devices. */
> +       if (!acpi_device_is_present(acpi_dev))
> +               return 0;
> +
>         /*
>          * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
>          * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
> --

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Hans de Goede]

Hi,

On 16-10-17 01:47, Rafael J. Wysocki wrote:
> On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Most Bay and Cherry Trail devices use a generic DSDT with all possible
>> peripheral devices present in the DSDT, with their _STA returning 0x00 or
>> 0x0f based on AML variables which describe what is actually present on
>> the board.
>>
>> Since ACPI device objects with a 0x00 status (not present) still get an
>> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
>> modalias, userspace would end up loading modules for non present hardware.
>>
>> This commit fixes this by leaving the modalias empty for non present
>> devices. This results in 10 modules less being loaded with a generic
>> distro kernel config on my Cherry Trail test-device (a GPD pocket).
> 
> Well, what about hotplug?
> 
> On some systems _STA may change from 0 to nonzero for some devices, so
> what's going to happen to the modalias then?

A good question. I would expect a change uevent to be generated in
this case and when the device has become present in this new uvent the
modalias will no longer be empty and the module will get loaded, so
the module will not get loaded until the actual hotplug.

The actual generation of this uevent should be done by the various
subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
adev->status is already updated and then when the subsys calls
acpi_device_uevent_modalias() for the new uevent it will return a
non-empty modalias.

Regards,

Hans


> 
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/acpi/device_sysfs.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
>> index 24418932612e..a041689e5701 100644
>> --- a/drivers/acpi/device_sysfs.c
>> +++ b/drivers/acpi/device_sysfs.c
>> @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
>>          int count;
>>          struct acpi_hardware_id *id;
>>
>> +       /* Avoid unnecessarily loading modules for non present devices. */
>> +       if (!acpi_device_is_present(acpi_dev))
>> +               return 0;
>> +
>>          /*
>>           * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
>>           * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
>> --

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Hans de Goede]

Hi,

On 16-10-17 13:44, Hans de Goede wrote:
> Hi,
> 
> On 16-10-17 01:47, Rafael J. Wysocki wrote:
>> On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Most Bay and Cherry Trail devices use a generic DSDT with all possible
>>> peripheral devices present in the DSDT, with their _STA returning 0x00 or
>>> 0x0f based on AML variables which describe what is actually present on
>>> the board.
>>>
>>> Since ACPI device objects with a 0x00 status (not present) still get an
>>> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
>>> modalias, userspace would end up loading modules for non present hardware.
>>>
>>> This commit fixes this by leaving the modalias empty for non present
>>> devices. This results in 10 modules less being loaded with a generic
>>> distro kernel config on my Cherry Trail test-device (a GPD pocket).
>>
>> Well, what about hotplug?
>>
>> On some systems _STA may change from 0 to nonzero for some devices, so
>> what's going to happen to the modalias then?
> 
> A good question. I would expect a change uevent to be generated in
> this case and when the device has become present in this new uvent the
> modalias will no longer be empty and the module will get loaded, so
> the module will not get loaded until the actual hotplug.
> 
> The actual generation of this uevent should be done by the various
> subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
> adev->status is already updated and then when the subsys calls
> acpi_device_uevent_modalias() for the new uevent it will return a
> non-empty modalias.

Rafael, how do you want to move forward with this patch ?

Regards,

Hans




> 
> 
>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>>   drivers/acpi/device_sysfs.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
>>> index 24418932612e..a041689e5701 100644
>>> --- a/drivers/acpi/device_sysfs.c
>>> +++ b/drivers/acpi/device_sysfs.c
>>> @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
>>>          int count;
>>>          struct acpi_hardware_id *id;
>>>
>>> +       /* Avoid unnecessarily loading modules for non present devices. */
>>> +       if (!acpi_device_is_present(acpi_dev))
>>> +               return 0;
>>> +
>>>          /*
>>>           * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
>>>           * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
>>> -- 

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Rafael J. Wysocki]

On Mon, Oct 30, 2017 at 2:14 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 16-10-17 13:44, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 16-10-17 01:47, Rafael J. Wysocki wrote:
>>>
>>> On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com>
>>> wrote:
>>>>
>>>> Most Bay and Cherry Trail devices use a generic DSDT with all possible
>>>> peripheral devices present in the DSDT, with their _STA returning 0x00
>>>> or
>>>> 0x0f based on AML variables which describe what is actually present on
>>>> the board.
>>>>
>>>> Since ACPI device objects with a 0x00 status (not present) still get an
>>>> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
>>>> modalias, userspace would end up loading modules for non present
>>>> hardware.
>>>>
>>>> This commit fixes this by leaving the modalias empty for non present
>>>> devices. This results in 10 modules less being loaded with a generic
>>>> distro kernel config on my Cherry Trail test-device (a GPD pocket).
>>>
>>>
>>> Well, what about hotplug?
>>>
>>> On some systems _STA may change from 0 to nonzero for some devices, so
>>> what's going to happen to the modalias then?
>>
>>
>> A good question. I would expect a change uevent to be generated in
>> this case and when the device has become present in this new uvent the
>> modalias will no longer be empty and the module will get loaded, so
>> the module will not get loaded until the actual hotplug.
>>
>> The actual generation of this uevent should be done by the various
>> subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
>> adev->status is already updated and then when the subsys calls
>> acpi_device_uevent_modalias() for the new uevent it will return a
>> non-empty modalias.
>
>
> Rafael, how do you want to move forward with this patch ?

Not sure yet, sorry.

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Rafael J. Wysocki]

[+Mika & Andy]

On Monday, October 16, 2017 1:44:40 PM CET Hans de Goede wrote:
> Hi,
> 
> On 16-10-17 01:47, Rafael J. Wysocki wrote:
> > On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> >> Most Bay and Cherry Trail devices use a generic DSDT with all possible
> >> peripheral devices present in the DSDT, with their _STA returning 0x00 or
> >> 0x0f based on AML variables which describe what is actually present on
> >> the board.
> >>
> >> Since ACPI device objects with a 0x00 status (not present) still get an
> >> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
> >> modalias, userspace would end up loading modules for non present hardware.
> >>
> >> This commit fixes this by leaving the modalias empty for non present
> >> devices. This results in 10 modules less being loaded with a generic
> >> distro kernel config on my Cherry Trail test-device (a GPD pocket).
> > 
> > Well, what about hotplug?
> > 
> > On some systems _STA may change from 0 to nonzero for some devices, so
> > what's going to happen to the modalias then?
> 
> A good question. I would expect a change uevent to be generated in
> this case and when the device has become present in this new uvent the
> modalias will no longer be empty and the module will get loaded, so
> the module will not get loaded until the actual hotplug.
> 
> The actual generation of this uevent should be done by the various
> subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
> adev->status is already updated and then when the subsys calls
> acpi_device_uevent_modalias() for the new uevent it will return a
> non-empty modalias.

Mika, I need your input here.

I have to say I'm not quite sure about possible implications of this change,
what do you think?

> > 
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>   drivers/acpi/device_sysfs.c | 4 ++++
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> >> index 24418932612e..a041689e5701 100644
> >> --- a/drivers/acpi/device_sysfs.c
> >> +++ b/drivers/acpi/device_sysfs.c
> >> @@ -146,6 +146,10 @@ static int create_pnp_modalias(struct acpi_device *acpi_dev, char *modalias,
> >>          int count;
> >>          struct acpi_hardware_id *id;
> >>
> >> +       /* Avoid unnecessarily loading modules for non present devices. */
> >> +       if (!acpi_device_is_present(acpi_dev))
> >> +               return 0;
> >> +
> >>          /*
> >>           * Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
> >>           * be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
> >> --
> --

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Mika Westerberg]

On Fri, Nov 17, 2017 at 02:42:44PM +0100, Rafael J. Wysocki wrote:
> [+Mika & Andy]
> 
> On Monday, October 16, 2017 1:44:40 PM CET Hans de Goede wrote:
> > Hi,
> > 
> > On 16-10-17 01:47, Rafael J. Wysocki wrote:
> > > On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > >> Most Bay and Cherry Trail devices use a generic DSDT with all possible
> > >> peripheral devices present in the DSDT, with their _STA returning 0x00 or
> > >> 0x0f based on AML variables which describe what is actually present on
> > >> the board.
> > >>
> > >> Since ACPI device objects with a 0x00 status (not present) still get an
> > >> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
> > >> modalias, userspace would end up loading modules for non present hardware.
> > >>
> > >> This commit fixes this by leaving the modalias empty for non present
> > >> devices. This results in 10 modules less being loaded with a generic
> > >> distro kernel config on my Cherry Trail test-device (a GPD pocket).
> > > 
> > > Well, what about hotplug?
> > > 
> > > On some systems _STA may change from 0 to nonzero for some devices, so
> > > what's going to happen to the modalias then?
> > 
> > A good question. I would expect a change uevent to be generated in
> > this case and when the device has become present in this new uvent the
> > modalias will no longer be empty and the module will get loaded, so
> > the module will not get loaded until the actual hotplug.
> > 
> > The actual generation of this uevent should be done by the various
> > subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
> > adev->status is already updated and then when the subsys calls
> > acpi_device_uevent_modalias() for the new uevent it will return a
> > non-empty modalias.
> 
> Mika, I need your input here.
> 
> I have to say I'm not quite sure about possible implications of this change,
> what do you think?

I think this could work because we are actually interested in physical
Linux devices, not the struct acpi_device things. So to my understanding
whenever _STA of an ACPI device goes from 0x0 to 0xf the corresponding
physical device (platform, spi, i2c) gets created. Userspace is then
notified by a uevent and it then reads attributes including updated
modalias of that physical device.

Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present

[Rafael J. Wysocki]

On Friday, November 17, 2017 3:09:04 PM CET Mika Westerberg wrote:
> On Fri, Nov 17, 2017 at 02:42:44PM +0100, Rafael J. Wysocki wrote:
> > [+Mika & Andy]
> > 
> > On Monday, October 16, 2017 1:44:40 PM CET Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 16-10-17 01:47, Rafael J. Wysocki wrote:
> > > > On Sun, Oct 15, 2017 at 9:24 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > > >> Most Bay and Cherry Trail devices use a generic DSDT with all possible
> > > >> peripheral devices present in the DSDT, with their _STA returning 0x00 or
> > > >> 0x0f based on AML variables which describe what is actually present on
> > > >> the board.
> > > >>
> > > >> Since ACPI device objects with a 0x00 status (not present) still get an
> > > >> entry under /sys/bus/acpi/devices, and those entry had an acpi:PNPID
> > > >> modalias, userspace would end up loading modules for non present hardware.
> > > >>
> > > >> This commit fixes this by leaving the modalias empty for non present
> > > >> devices. This results in 10 modules less being loaded with a generic
> > > >> distro kernel config on my Cherry Trail test-device (a GPD pocket).
> > > > 
> > > > Well, what about hotplug?
> > > > 
> > > > On some systems _STA may change from 0 to nonzero for some devices, so
> > > > what's going to happen to the modalias then?
> > > 
> > > A good question. I would expect a change uevent to be generated in
> > > this case and when the device has become present in this new uvent the
> > > modalias will no longer be empty and the module will get loaded, so
> > > the module will not get loaded until the actual hotplug.
> > > 
> > > The actual generation of this uevent should be done by the various
> > > subsystems based on ACPI_RECONFIG_DEVICE_ADD messages, at which point
> > > adev->status is already updated and then when the subsys calls
> > > acpi_device_uevent_modalias() for the new uevent it will return a
> > > non-empty modalias.
> > 
> > Mika, I need your input here.
> > 
> > I have to say I'm not quite sure about possible implications of this change,
> > what do you think?
> 
> I think this could work because we are actually interested in physical
> Linux devices, not the struct acpi_device things. So to my understanding
> whenever _STA of an ACPI device goes from 0x0 to 0xf the corresponding
> physical device (platform, spi, i2c) gets created. Userspace is then
> notified by a uevent and it then reads attributes including updated
> modalias of that physical device.

OK, I'll queue this up, then.

Thanks,
Rafael