Q: acpi-cpufreq module auto-loading after processor driver change

Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

Hi Greg,

I've noticed during recent testing that with this commit applied:

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc

on my openSUSE (and Tubmbleweed) installations I need to modify
/etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
initramfs or otherwise it won't be loaded automatically.

I think I understand why it needs to be present in the initramfs along the
processor module for the automatic loading to work (acpi_processor_load_module()
seems to need that), but before the above commit it wasn't necessary to make
any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
anyway.

Unfortunately, my experience with udev and related things is kind of limited
and I have no idea what exactly makes the difference.  Can you please have a
look and help me understand that?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

On Thursday, May 30, 2013 11:38:37 PM Rafael J. Wysocki wrote:
> Hi Greg,
> 
> I've noticed during recent testing that with this commit applied:
> 
> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> 
> on my openSUSE (and Tubmbleweed) installations I need to modify
> /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> initramfs or otherwise it won't be loaded automatically.
> 
> I think I understand why it needs to be present in the initramfs along the
> processor module for the automatic loading to work (acpi_processor_load_module()
> seems to need that), but before the above commit it wasn't necessary to make
> any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> anyway.

To be precise, before the commit in question acpi-cpufreq doesn't need to be
present in the initramfs at all to be loaded automatically (and I don't really
know how that works).

> Unfortunately, my experience with udev and related things is kind of limited
> and I have no idea what exactly makes the difference.  Can you please have a
> look and help me understand that?

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Greg Kroah-Hartman]

On Thu, May 30, 2013 at 11:38:37PM +0200, Rafael J. Wysocki wrote:
> Hi Greg,
> 
> I've noticed during recent testing that with this commit applied:
> 
> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> 
> on my openSUSE (and Tubmbleweed) installations I need to modify
> /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> initramfs or otherwise it won't be loaded automatically.
> 
> I think I understand why it needs to be present in the initramfs along the
> processor module for the automatic loading to work (acpi_processor_load_module()
> seems to need that), but before the above commit it wasn't necessary to make
> any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> anyway.
> 
> Unfortunately, my experience with udev and related things is kind of limited
> and I have no idea what exactly makes the difference.  Can you please have a
> look and help me understand that?

Don't you need a MODULE_DEVICE_TABLE() macro in that module somewhere so
that udev and the like know to load it when it sees the hardware?

thanks,

greg k-h

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

On Thursday, June 06, 2013 01:24:19 PM Greg Kroah-Hartman wrote:
> On Thu, May 30, 2013 at 11:38:37PM +0200, Rafael J. Wysocki wrote:
> > Hi Greg,
> > 
> > I've noticed during recent testing that with this commit applied:
> > 
> > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> > 
> > on my openSUSE (and Tubmbleweed) installations I need to modify
> > /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> > initramfs or otherwise it won't be loaded automatically.
> > 
> > I think I understand why it needs to be present in the initramfs along the
> > processor module for the automatic loading to work (acpi_processor_load_module()
> > seems to need that), but before the above commit it wasn't necessary to make
> > any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> > anyway.
> > 
> > Unfortunately, my experience with udev and related things is kind of limited
> > and I have no idea what exactly makes the difference.  Can you please have a
> > look and help me understand that?
> 
> Don't you need a MODULE_DEVICE_TABLE() macro in that module somewhere so
> that udev and the like know to load it when it sees the hardware?

Well, that was my first thought about that, but there is one already and my
commit hasn't changed it. :-)

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

On Thursday, June 06, 2013 11:51:54 PM Rafael J. Wysocki wrote:
> On Thursday, June 06, 2013 01:24:19 PM Greg Kroah-Hartman wrote:
> > On Thu, May 30, 2013 at 11:38:37PM +0200, Rafael J. Wysocki wrote:
> > > Hi Greg,
> > > 
> > > I've noticed during recent testing that with this commit applied:
> > > 
> > > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> > > 
> > > on my openSUSE (and Tubmbleweed) installations I need to modify
> > > /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> > > initramfs or otherwise it won't be loaded automatically.
> > > 
> > > I think I understand why it needs to be present in the initramfs along the
> > > processor module for the automatic loading to work (acpi_processor_load_module()
> > > seems to need that), but before the above commit it wasn't necessary to make
> > > any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> > > anyway.
> > > 
> > > Unfortunately, my experience with udev and related things is kind of limited
> > > and I have no idea what exactly makes the difference.  Can you please have a
> > > look and help me understand that?
> > 
> > Don't you need a MODULE_DEVICE_TABLE() macro in that module somewhere so
> > that udev and the like know to load it when it sees the hardware?
> 
> Well, that was my first thought about that, but there is one already and my
> commit hasn't changed it. :-)

My understanding of this is that on x86 (which is the case here)
topology_init() calls arch_register_cpu() for all available CPUs which
calls register_cpu() and that causes the uevent to be emitted through
device_register().  But then, the commit above doesn't change that (at least
I don't see how).

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Greg Kroah-Hartman]

On Fri, Jun 07, 2013 at 12:13:58AM +0200, Rafael J. Wysocki wrote:
> On Thursday, June 06, 2013 11:51:54 PM Rafael J. Wysocki wrote:
> > On Thursday, June 06, 2013 01:24:19 PM Greg Kroah-Hartman wrote:
> > > On Thu, May 30, 2013 at 11:38:37PM +0200, Rafael J. Wysocki wrote:
> > > > Hi Greg,
> > > > 
> > > > I've noticed during recent testing that with this commit applied:
> > > > 
> > > > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> > > > 
> > > > on my openSUSE (and Tubmbleweed) installations I need to modify
> > > > /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> > > > initramfs or otherwise it won't be loaded automatically.
> > > > 
> > > > I think I understand why it needs to be present in the initramfs along the
> > > > processor module for the automatic loading to work (acpi_processor_load_module()
> > > > seems to need that), but before the above commit it wasn't necessary to make
> > > > any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> > > > anyway.
> > > > 
> > > > Unfortunately, my experience with udev and related things is kind of limited
> > > > and I have no idea what exactly makes the difference.  Can you please have a
> > > > look and help me understand that?
> > > 
> > > Don't you need a MODULE_DEVICE_TABLE() macro in that module somewhere so
> > > that udev and the like know to load it when it sees the hardware?
> > 
> > Well, that was my first thought about that, but there is one already and my
> > commit hasn't changed it. :-)
> 
> My understanding of this is that on x86 (which is the case here)
> topology_init() calls arch_register_cpu() for all available CPUs which
> calls register_cpu() and that causes the uevent to be emitted through
> device_register().  But then, the commit above doesn't change that (at least
> I don't see how).

At first glance, I don't see how either, sorry.

greg k-h

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

On Thursday, June 06, 2013 03:21:13 PM Greg Kroah-Hartman wrote:
> On Fri, Jun 07, 2013 at 12:13:58AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, June 06, 2013 11:51:54 PM Rafael J. Wysocki wrote:
> > > On Thursday, June 06, 2013 01:24:19 PM Greg Kroah-Hartman wrote:
> > > > On Thu, May 30, 2013 at 11:38:37PM +0200, Rafael J. Wysocki wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > I've noticed during recent testing that with this commit applied:
> > > > > 
> > > > > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc
> > > > > 
> > > > > on my openSUSE (and Tubmbleweed) installations I need to modify
> > > > > /etc/sysconfig/kernel to make mkinitrd put the acpi-cpufreq module into the
> > > > > initramfs or otherwise it won't be loaded automatically.
> > > > > 
> > > > > I think I understand why it needs to be present in the initramfs along the
> > > > > processor module for the automatic loading to work (acpi_processor_load_module()
> > > > > seems to need that), but before the above commit it wasn't necessary to make
> > > > > any changes to /etc/sysconfig/kernel and acpi-cpufreq was loaded automatically
> > > > > anyway.
> > > > > 
> > > > > Unfortunately, my experience with udev and related things is kind of limited
> > > > > and I have no idea what exactly makes the difference.  Can you please have a
> > > > > look and help me understand that?
> > > > 
> > > > Don't you need a MODULE_DEVICE_TABLE() macro in that module somewhere so
> > > > that udev and the like know to load it when it sees the hardware?
> > > 
> > > Well, that was my first thought about that, but there is one already and my
> > > commit hasn't changed it. :-)
> > 
> > My understanding of this is that on x86 (which is the case here)
> > topology_init() calls arch_register_cpu() for all available CPUs which
> > calls register_cpu() and that causes the uevent to be emitted through
> > device_register().  But then, the commit above doesn't change that (at least
> > I don't see how).
> 
> At first glance, I don't see how either, sorry.

Well, thanks for looking. :-)

This is not a big deal, because the module is loaded when present in the
initramfs, but then I'm slightly concerned that people will complain "Oh, why
do I need to have this module in my initramfs now and I didn't before?! It
must be broken somehow!".

And besides, I'm just curious what's going on here. :-)

So far I have verified that topology_init() is executed before acpi_init()
(which appears to be pure coincidence, but oh well), so even the *ordering*
is the same as before.  The only difference is that the device in question
now has a driver bound to it and it didn't before (the driver was bound to
something else).

Hmm. I suspect udev just thinks "ok, I have found a driver for that device,
so I don't need to look for one any more" and that's why it doesn't load
acpi_cpufreq.  If that's the case, is there any way to make it load all
matching modules anyway?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Greg Kroah-Hartman]

On Fri, Jun 07, 2013 at 12:44:44AM +0200, Rafael J. Wysocki wrote:
> So far I have verified that topology_init() is executed before acpi_init()
> (which appears to be pure coincidence, but oh well), so even the *ordering*
> is the same as before.  The only difference is that the device in question
> now has a driver bound to it and it didn't before (the driver was bound to
> something else).
> 
> Hmm. I suspect udev just thinks "ok, I have found a driver for that device,
> so I don't need to look for one any more" and that's why it doesn't load
> acpi_cpufreq.  If that's the case, is there any way to make it load all
> matching modules anyway?

udev should call modprobe with an alias for the device which _should_
try to load all modules that match the alias.  So take a look at kmod to
see if something is odd there.

sorry,

greg k-h

Re: Q: acpi-cpufreq module auto-loading after processor driver change

[Rafael J. Wysocki]

On Thursday, June 06, 2013 04:09:47 PM Greg Kroah-Hartman wrote:
> On Fri, Jun 07, 2013 at 12:44:44AM +0200, Rafael J. Wysocki wrote:
> > So far I have verified that topology_init() is executed before acpi_init()
> > (which appears to be pure coincidence, but oh well), so even the *ordering*
> > is the same as before.  The only difference is that the device in question
> > now has a driver bound to it and it didn't before (the driver was bound to
> > something else).
> > 
> > Hmm. I suspect udev just thinks "ok, I have found a driver for that device,
> > so I don't need to look for one any more" and that's why it doesn't load
> > acpi_cpufreq.  If that's the case, is there any way to make it load all
> > matching modules anyway?
> 
> udev should call modprobe with an alias for the device which _should_
> try to load all modules that match the alias.  So take a look at kmod to
> see if something is odd there.

Interesting.

If I add ACPI device aliases to acpi-cpufreq, like in the appended patch,
it *is* loaded automatically even if it isn't present in the initramfs.

Well, those aliases actually make more sense that the x86cpu ones, because the
ACPI processor objects are required for the driver to work, so I think I'll
just apply this patch, but quite frankly that makes me feel a bit uneasy.

Thanks,
Rafael


Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -1034,4 +1034,11 @@ static const struct x86_cpu_id acpi_cpuf
 };
 MODULE_DEVICE_TABLE(x86cpu, acpi_cpufreq_ids);
 
+static const struct acpi_device_id processor_device_ids[] = {
+	{ACPI_PROCESSOR_OBJECT_HID, 0},
+	{ACPI_PROCESSOR_DEVICE_HID, 0},
+	{"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, processor_device_ids);
+
 MODULE_ALIAS("acpi");

[PATCH] ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

After commit ac212b6 (ACPI / processor: Use common hotplug
infrastructure) the acpi-cpufreq module is not loaded automatically
by udev which fails to match it against the x86cpu modalias.  Still,
it can be matched against ACPI processor device IDs, which even
makes more sense, because it depends on the ACPI processor driver
that uses those device IDs to bind to processor devices.

For this reason, add ACPI processor device IDs to acpi-cpufreq.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

This patch is against the acpi-hotplug branch of the linux-pm.git tree which
is part of linux-next.

Thanks,
Rafael

---
 drivers/cpufreq/acpi-cpufreq.c |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -1034,4 +1034,11 @@ static const struct x86_cpu_id acpi_cpuf
 };
 MODULE_DEVICE_TABLE(x86cpu, acpi_cpufreq_ids);
 
+static const struct acpi_device_id processor_device_ids[] = {
+	{ACPI_PROCESSOR_OBJECT_HID, },
+	{ACPI_PROCESSOR_DEVICE_HID, },
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, processor_device_ids);
+
 MODULE_ALIAS("acpi");

Re: [PATCH] ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq

[Viresh Kumar]

On Fri, Jun 7, 2013 at 7:38 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> After commit ac212b6 (ACPI / processor: Use common hotplug
> infrastructure) the acpi-cpufreq module is not loaded automatically
> by udev which fails to match it against the x86cpu modalias.  Still,
> it can be matched against ACPI processor device IDs, which even
> makes more sense, because it depends on the ACPI processor driver
> that uses those device IDs to bind to processor devices.
>
> For this reason, add ACPI processor device IDs to acpi-cpufreq.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> This patch is against the acpi-hotplug branch of the linux-pm.git tree which
> is part of linux-next.
>
> Thanks,
> Rafael
>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |    7 +++++++
>  1 file changed, 7 insertions(+)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>