[RFC,6/8] ACPI: use platform bus as the default bus for _HID enumeration
diff mbox series

Message ID 1393405874-3266-7-git-send-email-rui.zhang@intel.com
State New, archived
Headers show
Series
  • ACPI: change the way of enumerating PNPACPI/Platform devices
Related show

Commit Message

Zhang, Rui Feb. 26, 2014, 9:11 a.m. UTC
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(-)

Comments

Rafael J. Wysocki March 2, 2014, 11:51 p.m. UTC | #1
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.  Shouldn't we require that _HID or at least _CID is
present for that?

> +		acpi_create_platform_device(device, NULL);
>  	return ret;
>  }
>  
> @@ -2185,7 +2186,6 @@ int __init acpi_scan_init(void)
>  	acpi_pci_root_init();
>  	acpi_pci_link_init();
>  	acpi_processor_init();
> -	acpi_platform_init();
>  	acpi_lpss_init();
>  	acpi_cmos_rtc_init();
>  	acpi_container_init();
>
Zhang, Rui March 3, 2014, 2:11 p.m. UTC | #2
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:
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.

Thus IMO, we can have an exclude list for those devices.

thanks,
rui
> > +		acpi_create_platform_device(device, NULL);
> >  	return ret;
> >  }
> >  
> > @@ -2185,7 +2186,6 @@ int __init acpi_scan_init(void)
> >  	acpi_pci_root_init();
> >  	acpi_pci_link_init();
> >  	acpi_processor_init();
> > -	acpi_platform_init();
> >  	acpi_lpss_init();
> >  	acpi_cmos_rtc_init();
> >  	acpi_container_init();
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki March 3, 2014, 11:23 p.m. UTC | #3
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?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki March 4, 2014, 12:35 a.m. UTC | #4
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki March 7, 2014, 1:46 a.m. UTC | #5
On Tuesday, March 04, 2014 01:35:00 AM Rafael J. Wysocki wrote:
> 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.

So, why don't we add an ACPI device object flag, say hid_device, such that if
set, the ACPI core will create a struct platform device for that device object.
Then, we can set hid_device for buttons and other stuff we care about.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Zhang, Rui March 9, 2014, 5:33 a.m. UTC | #6
On Fri, 2014-03-07 at 02:46 +0100, Rafael J. Wysocki wrote:
> On Tuesday, March 04, 2014 01:35:00 AM Rafael J. Wysocki wrote:
> > 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.
> 
> So, why don't we add an ACPI device object flag, say hid_device, such that if
> set, the ACPI core will create a struct platform device for that device object.
> Then, we can set hid_device for buttons and other stuff we care about.
> 
agreed. I will do this in next version.
But anyway, the exclude list is still needed for the _HID devices that
we do not want to see in platform, e.g.
/sys/bus/platform/devices/PNP0000:00  (PIC)
/sys/bus/platform/devices/PNP0100:00  (system timer?)


thanks,
rui

> Thanks,
> Rafael
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Zhang, Rui March 9, 2014, 3:50 p.m. UTC | #7
On Wed, 2014-02-26 at 17:11 +0800, 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)
> +		acpi_create_platform_device(device, NULL);

I just found a big problem in this proposal, which affects all the
optional scan handlers.
The problem is that, if we disable a scan handler, platform device nodes
would be created instead by the code above, because there is no scan
handler attached for those ACPI nodes.

If we still want to use this proposal, in order to fix the problem, I
think we can
1. add an ACPI device object flag, as Rafael proposed, but with a
different name, say need_enumerate.
2. set the flag for the ACPI device objects with _HID/_CID, and other
specified devices like thermal, video, etc.
3. clear the need_enumerate flag for devices that HAVE MATCHED SCAN
HANDLER, no matter the return value of the .attach() callback.
4. introduce dummy scan handlers instead of stub functions for those
optional scan handlers, say, if CONFIG_X86_INTEL_LPSS is cleared, a
dummy lpss_handler is registered in acpi_lpss_init().
5. invoke acpi_create_platform_device() for the ACPI device objects with
need_enumerate flag set.

thanks,
rui

>  	return ret;
>  }
>  
> @@ -2185,7 +2186,6 @@ int __init acpi_scan_init(void)
>  	acpi_pci_root_init();
>  	acpi_pci_link_init();
>  	acpi_processor_init();
> -	acpi_platform_init();
>  	acpi_lpss_init();
>  	acpi_cmos_rtc_init();
>  	acpi_container_init();


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki March 9, 2014, 5:50 p.m. UTC | #8
On Sunday, March 09, 2014 01:33:27 PM Zhang Rui wrote:
> On Fri, 2014-03-07 at 02:46 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, March 04, 2014 01:35:00 AM Rafael J. Wysocki wrote:
> > > 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.
> > 
> > So, why don't we add an ACPI device object flag, say hid_device, such that if
> > set, the ACPI core will create a struct platform device for that device object.
> > Then, we can set hid_device for buttons and other stuff we care about.
> > 
> agreed. I will do this in next version.
> But anyway, the exclude list is still needed for the _HID devices that
> we do not want to see in platform, e.g.
> /sys/bus/platform/devices/PNP0000:00  (PIC)
> /sys/bus/platform/devices/PNP0100:00  (system timer?)

I see.

OK

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Rafael J. Wysocki March 9, 2014, 6:04 p.m. UTC | #9
On Sunday, March 09, 2014 11:50:37 PM Zhang Rui wrote:
> On Wed, 2014-02-26 at 17:11 +0800, 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)
> > +		acpi_create_platform_device(device, NULL);
> 
> I just found a big problem in this proposal, which affects all the
> optional scan handlers.

What do you mean by "optional"?  Such that can be compiled out?

> The problem is that, if we disable a scan handler, platform device nodes
> would be created instead by the code above, because there is no scan
> handler attached for those ACPI nodes.

If "we disable a scan handled" means "we compile it out", I'm not sure
why creating platform devices for the device objects in question will
be incorrect?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Zhang, Rui March 10, 2014, 2:44 a.m. UTC | #10
On Sun, 2014-03-09 at 19:04 +0100, Rafael J. Wysocki wrote:
> On Sunday, March 09, 2014 11:50:37 PM Zhang Rui wrote:
> > On Wed, 2014-02-26 at 17:11 +0800, 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)
> > > +		acpi_create_platform_device(device, NULL);
> > 
> > I just found a big problem in this proposal, which affects all the
> > optional scan handlers.
> 
> What do you mean by "optional"?  Such that can be compiled out?
> 
yes.

> > The problem is that, if we disable a scan handler, platform device nodes
> > would be created instead by the code above, because there is no scan
> > handler attached for those ACPI nodes.
> 
> If "we disable a scan handled" means "we compile it out", I'm not sure
> why creating platform devices for the device objects in question will
> be incorrect?
> 
take lpss scan handler and 80860F0A device for example,
acpi_lpss_create_device() would invoke lpss_uart_setup() first and then
register 80860F0A as a platform device.
if the lpss scan handler is compiled out, we would do nothing but
register a platform device directly, thus the dw8250_platform_driver
driver is still loaded, but probably breaks.

IMO, we should either have a full functional platform device (if the
scan handler is compiled in) or nothing (if the scan handler is compiled
out).

thanks,
rui
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Zhang, Rui March 10, 2014, 2:45 a.m. UTC | #11
On Sun, 2014-03-09 at 19:04 +0100, Rafael J. Wysocki wrote:
> On Sunday, March 09, 2014 11:50:37 PM Zhang Rui wrote:
> > On Wed, 2014-02-26 at 17:11 +0800, 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)
> > > +		acpi_create_platform_device(device, NULL);
> > 
> > I just found a big problem in this proposal, which affects all the
> > optional scan handlers.
> 
> What do you mean by "optional"?  Such that can be compiled out?
> 
yes.

> > The problem is that, if we disable a scan handler, platform device nodes
> > would be created instead by the code above, because there is no scan
> > handler attached for those ACPI nodes.
> 
> If "we disable a scan handled" means "we compile it out", I'm not sure
> why creating platform devices for the device objects in question will
> be incorrect?
> 
take lpss scan handler and 80860F0A device for example,
acpi_lpss_create_device() would invoke lpss_uart_setup() first and then
register 80860F0A as a platform device.
if the lpss scan handler is compiled out, we would do nothing but
register a platform device directly, thus the dw8250_platform_driver
driver is still loaded, but probably breaks.

IMO, we should either have a full functional platform device (if the
scan handler is compiled in) or nothing (if the scan handler is compiled
out).

thanks,
rui
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch
diff mbox series

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)
+		acpi_create_platform_device(device, NULL);
 	return ret;
 }
 
@@ -2185,7 +2186,6 @@  int __init acpi_scan_init(void)
 	acpi_pci_root_init();
 	acpi_pci_link_init();
 	acpi_processor_init();
-	acpi_platform_init();
 	acpi_lpss_init();
 	acpi_cmos_rtc_init();
 	acpi_container_init();