| Message ID | 1393405874-3266-7-git-send-email-rui.zhang@intel.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
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(); >
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----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... Thanks, rui > Rafael
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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();
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(-)