public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Hans de Goede <hdegoede@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present
Date: Fri, 17 Nov 2017 16:09:04 +0200	[thread overview]
Message-ID: <20171117140904.GH17200@lahna.fi.intel.com> (raw)
In-Reply-To: <2395808.6y9gh4NH3i@aspire.rjw.lan>

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.

  reply	other threads:[~2017-11-17 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15 19:24 [PATCH] ACPI / device_sysfs: Leave modalias empty for devices which are not present Hans de Goede
2017-10-15 23:47 ` Rafael J. Wysocki
2017-10-16 11:44   ` Hans de Goede
2017-10-30 13:14     ` Hans de Goede
2017-10-30 22:23       ` Rafael J. Wysocki
2017-11-17 13:42     ` Rafael J. Wysocki
2017-11-17 14:09       ` Mika Westerberg [this message]
2017-11-18 13:32         ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171117140904.GH17200@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox