From patchwork Fri Jun 7 01:01:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rafael Wysocki X-Patchwork-Id: 2683871 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 42B52DF23A for ; Fri, 7 Jun 2013 00:52:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754552Ab3FGAwz (ORCPT ); Thu, 6 Jun 2013 20:52:55 -0400 Received: from hydra.sisk.pl ([212.160.235.94]:59213 "EHLO hydra.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754317Ab3FGAwy (ORCPT ); Thu, 6 Jun 2013 20:52:54 -0400 Received: from vostro.rjw.lan (aavi21.neoplus.adsl.tpnet.pl [83.6.42.21]) by hydra.sisk.pl (Postfix) with ESMTPSA id 1DEA4E3D98; Fri, 7 Jun 2013 02:49:41 +0200 (CEST) From: "Rafael J. Wysocki" To: Greg Kroah-Hartman Cc: Linux PM list , ACPI Devel Maling List Subject: Re: Q: acpi-cpufreq module auto-loading after processor driver change Date: Fri, 07 Jun 2013 03:01:59 +0200 Message-ID: <2456209.UJDSHpYIkx@vostro.rjw.lan> User-Agent: KMail/4.9.5 (Linux/3.10.0-rc4+; KDE/4.9.5; x86_64; ; ) In-Reply-To: <20130606230947.GA31618@kroah.com> References: <1511440.Xd41mcOoEa@vostro.rjw.lan> <3155099.bCeEkuSrim@vostro.rjw.lan> <20130606230947.GA31618@kroah.com> MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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 --- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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");