linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: "Zhang, Rui" <rui.zhang@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"matthew.garrett@nebula.com" <matthew.garrett@nebula.com>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>
Subject: Re: [RFC PATCH 6/8] ACPI: use platform bus as the default bus for _HID enumeration
Date: Tue, 04 Mar 2014 01:35:00 +0100	[thread overview]
Message-ID: <53151FB4.60502@intel.com> (raw)
In-Reply-To: <744357E9AAD1214791ACBA4B0B909263011E907E@SHSMSX101.ccr.corp.intel.com>

On 3/4/2014 1:27 AM, Zhang, Rui wrote:
>
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
>> Sent: Tuesday, March 04, 2014 7:23 AM
>> To: Zhang, Rui
>> Cc: linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org;
>> bhelgaas@google.com; matthew.garrett@nebula.com; Wysocki, Rafael J;
>> dmitry.torokhov@gmail.com
>> Subject: Re: [RFC PATCH 6/8] ACPI: use platform bus as the default bus
>> for _HID enumeration
>> Importance: High
>>
>> On Monday, March 03, 2014 10:11:48 PM Zhang Rui wrote:
>>> On Mon, 2014-03-03 at 00:51 +0100, Rafael J. Wysocki wrote:
>>>> On Wednesday, February 26, 2014 05:11:12 PM Zhang Rui wrote:
>>>>> Because of the growing demand for enumerating ACPI devices to
>>>>> platform bus, this patch changes the code to enumerate ACPI
>>>>> devices with _HID/_CID to platform bus by default, unless the
>> device already has a scan handler attached.
>>>>> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>>>>> ---
>>>>>   drivers/acpi/acpi_platform.c |   28 ----------------------------
>>>>>   drivers/acpi/scan.c          |   12 ++++++------
>>>>>   2 files changed, 6 insertions(+), 34 deletions(-)
>>>>>
>>>>> diff --git a/drivers/acpi/acpi_platform.c
>>>>> b/drivers/acpi/acpi_platform.c index dbfe49e..33376a9 100644
>>>>> --- a/drivers/acpi/acpi_platform.c
>>>>> +++ b/drivers/acpi/acpi_platform.c
>>>>> @@ -22,24 +22,6 @@
>>>>>
>>>>>   ACPI_MODULE_NAME("platform");
>>>>>
>>>>> -/*
>>>>> - * The following ACPI IDs are known to be suitable for
>>>>> representing as
>>>>> - * platform devices.
>>>>> - */
>>>>> -static const struct acpi_device_id acpi_platform_device_ids[] =
>> {
>>>>> -
>>>>> -	{ "PNP0D40" },
>>>>> -	{ "ACPI0003" },
>>>>> -	{ "VPC2004" },
>>>>> -	{ "BCM4752" },
>>>>> -
>>>>> -	/* Intel Smart Sound Technology */
>>>>> -	{ "INT33C8" },
>>>>> -	{ "80860F28" },
>>>>> -
>>>>> -	{ }
>>>>> -};
>>>>> -
>>>>>   /**
>>>>>    * acpi_create_platform_device - Create platform device for ACPI
>> device node
>>>>>    * @adev: ACPI device node to create a platform device for.
>>>>> @@ -125,13 +107,3 @@ int acpi_create_platform_device(struct
>> acpi_device *adev,
>>>>>   	kfree(resources);
>>>>>   	return 1;
>>>>>   }
>>>>> -
>>>>> -static struct acpi_scan_handler platform_handler = {
>>>>> -	.ids = acpi_platform_device_ids,
>>>>> -	.attach = acpi_create_platform_device,
>>>>> -};
>>>>> -
>>>>> -void __init acpi_platform_init(void) -{
>>>>> -	acpi_scan_add_handler(&platform_handler);
>>>>> -}
>>>>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index
>>>>> 5967338..61af32e 100644
>>>>> --- a/drivers/acpi/scan.c
>>>>> +++ b/drivers/acpi/scan.c
>>>>> @@ -2022,14 +2022,15 @@ static int
>> acpi_scan_attach_handler(struct acpi_device *device)
>>>>>   		handler = acpi_scan_match_handler(hwid->id, &devid);
>>>>>   		if (handler) {
>>>>>   			ret = handler->attach(device, devid);
>>>>> -			if (ret > 0) {
>>>>> +			if (ret > 0)
>>>>>   				device->handler = handler;
>>>>> -				break;
>>>>> -			} else if (ret < 0) {
>>>>> -				break;
>>>>> -			}
>>>>> +			if (ret)
>>>>> +				goto end;
>>>>>   		}
>>>>>   	}
>>>>> +end:
>>>>> +	if (!list_empty(&device->pnp.ids) && !device->handler)
>>>> I'm a bit concerned that this check will create platform devices
>> for
>>>> too many ACPI device objects.
>>> agreed. there are some devices created unexpected by this patch, e.g.
>>> on my test machine, I can see
>>>
>>> /sys/bus/platform/devices/LNXSYSTM:00 (ACPI system bus/root node)
>>> /sys/bus/platform/devices/PNP0000:00  (PIC)
>>> /sys/bus/platform/devices/PNP0100:00  (system timer?)
>>>
>>>>    Shouldn't we require that _HID or at least _CID is present for
>>>> that?
>>>>
>>> I do not think so.
>>> only devices that invoke acpi_add_ids() may have pnp.ids but no
>>> _HID/_CID, right?
>>> I did a check in the code, those devices include:
>> Well, I did that too.
>>
>>> ACPI root node
>>> ACPI video
>>> ACPI bay
>>> ACPI dock
>>> IBM SMBus
>>> ACPI Power resource
>>> ACPI processor
>>> ACPI thermal
>>> ACPI fixed power/sleep button
>>>
>>> IMO, only the ACPI root node, ACPI power resource, possibly ACPI
>>> processor are the ones that we do not want to see in platform bus.
>> No, we don't want any of them.  So pretty much as I said, only if
>> _HID/_CID is present, please?
>>
> Why? We will convert the drivers for most of those devices from ACPI bus to platform bus sooner or later.
> We need to see them in platform bus...

No, we don't.

I'm not sure about IBM SMBus to be honest, but as for the rest:

Why would we want one for the ACPI root?

And for video?  Those things are PCI usually devices anyway and we just 
add "artificial" HIDs for them.

ACPI docks and bays are handled by the dock driver which creates 
platform devices for them already if needed and we don't want duplicates 
there.

ACPI processor has its own scan handler that binds those objects to 
system devices.

Power resources - no need.

Do we need platform devices for ACPI thermal zones?

Yes, we will need them for fixed buttons, but that's a special case anyway.

Thanks,
Rafael


  reply	other threads:[~2014-03-04  0:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26  9:11 [RFC PATCH 0/8] ACPI: change the way of enumerating PNPACPI/Platform devices Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 1/8] ACPI: introduce .match() callback for ACPI scan handler Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 2/8] PNPACPI: use whilte list for pnpacpi device enumeration Zhang Rui
2014-03-07  1:44   ` Rafael J. Wysocki
2014-03-09  5:29     ` Zhang Rui
2014-03-09 17:49       ` Rafael J. Wysocki
2014-03-10  2:24         ` Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 3/8] PNPACPI: remove ids that does not comply with the ACPI PNP id rule Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 4/8] PNPACPI: remove unsupported serial PNP ids from PNPACPI id list Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 5/8] PNPACPI: check and enumerate CMOS RTC devices explicitly Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 6/8] ACPI: use platform bus as the default bus for _HID enumeration Zhang Rui
2014-03-02 23:51   ` Rafael J. Wysocki
2014-03-03 14:11     ` Zhang Rui
2014-03-03 23:23       ` Rafael J. Wysocki
2014-03-04  0:27         ` Zhang, Rui
2014-03-04  0:35           ` Rafael J. Wysocki [this message]
2014-03-07  1:46             ` Rafael J. Wysocki
2014-03-09  5:33               ` Zhang Rui
2014-03-09 17:50                 ` Rafael J. Wysocki
2014-03-09 15:50   ` Zhang Rui
2014-03-09 18:04     ` Rafael J. Wysocki
2014-03-10  2:44       ` Zhang Rui
2014-03-10  2:45       ` Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 7/8] Revert "ACPI / PNP: skip ACPI device nodes associated with physical nodes already" Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 8/8] PNPACPI: create both PNP and Platform device nodes for PNP0C01/PNP0C02 Zhang Rui
2014-03-03 14:17   ` Zhang Rui
2014-03-03 16:17     ` Bjorn Helgaas
2014-02-26 16:47 ` [RFC PATCH 0/8] ACPI: change the way of enumerating PNPACPI/Platform devices Matthew Garrett
2014-03-03 13:50   ` Zhang Rui

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=53151FB4.60502@intel.com \
    --to=rafael.j.wysocki@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).