| Message ID | 11281928.0BBlrNprhI@vostro.rjw.lan (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Nov 12, 2012 at 01:02:11PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Currently, whoever wants to use ACPI device resources has to call > acpi_walk_resources() to browse the buffer returned by the _CRS > method for the given device and create filters passed to that > routine to apply to the individual resource items. This generally > is cumbersome, time-consuming and inefficient. Moreover, it may > be problematic if resource conflicts need to be resolved, because > the different users of _CRS will need to do that in a consistent > way. > > For this reason, add code to the ACPI core to execute _CRS once, > when the struct acpi_device object is created for a given device > node, and attach a list of ACPI resources returned by _CRS to that > object for future processing. > > Convert the ACPI code that creates platform device objects to using > the new resources list instead of executing acpi_walk_resources() by > itself, which makes it much more straightforward and easier to > follow. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/acpi/acpi_platform.c | 90 ++++++++++++------------------------------- > drivers/acpi/resource.c | 12 +++++ > drivers/acpi/scan.c | 56 ++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 6 ++ > include/linux/acpi.h | 1 > 5 files changed, 102 insertions(+), 63 deletions(-) > > Index: linux/include/acpi/acpi_bus.h > =================================================================== > --- linux.orig/include/acpi/acpi_bus.h > +++ linux/include/acpi/acpi_bus.h > @@ -259,6 +259,11 @@ struct acpi_device_physical_node { > struct device *dev; > }; > > +struct acpi_resource_list_entry { > + struct list_head node; > + struct acpi_resource resource; > +}; > + > /* set maximum of physical nodes to 32 for expansibility */ > #define ACPI_MAX_PHYSICAL_NODE 32 > > @@ -268,6 +273,7 @@ struct acpi_device { > acpi_handle handle; /* no handle for fixed hardware */ > struct acpi_device *parent; > struct list_head children; > + struct list_head resources; /* Device resources. */ > struct list_head node; > struct list_head wakeup_list; > struct acpi_device_status status; > Index: linux/drivers/acpi/scan.c > =================================================================== > --- linux.orig/drivers/acpi/scan.c > +++ linux/drivers/acpi/scan.c > @@ -382,6 +382,52 @@ static void acpi_device_remove_files(str > ACPI Bus operations > -------------------------------------------------------------------------- */ > > +static void acpi_bus_drop_resources(struct acpi_device *adev) > +{ > + struct acpi_resource_list_entry *entry, *s; > + > + list_for_each_entry_safe(entry, s, &adev->resources, node) { > + list_del(&entry->node); > + kfree(entry); > + } > +} > + > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, > + void *context) > +{ > + struct list_head *list = context; > + struct acpi_resource_list_entry *entry; > + > + entry = kzalloc(sizeof(*entry), GFP_KERNEL); > + if (!entry) > + return AE_NO_MEMORY; > + > + entry->resource = *res; This does not work well with all resource types - specifically those that contain pointers, like acpi_resource_gpio and acpi_resource_source. The memory for the resources gets freed once acpi_walk_resources() is done. > + INIT_LIST_HEAD(&entry->node); > + list_add_tail(&entry->node, list); > + return AE_OK; > +} -- 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, November 12, 2012 04:46:21 PM Mika Westerberg wrote: > On Mon, Nov 12, 2012 at 01:02:11PM +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Currently, whoever wants to use ACPI device resources has to call > > acpi_walk_resources() to browse the buffer returned by the _CRS > > method for the given device and create filters passed to that > > routine to apply to the individual resource items. This generally > > is cumbersome, time-consuming and inefficient. Moreover, it may > > be problematic if resource conflicts need to be resolved, because > > the different users of _CRS will need to do that in a consistent > > way. > > > > For this reason, add code to the ACPI core to execute _CRS once, > > when the struct acpi_device object is created for a given device > > node, and attach a list of ACPI resources returned by _CRS to that > > object for future processing. > > > > Convert the ACPI code that creates platform device objects to using > > the new resources list instead of executing acpi_walk_resources() by > > itself, which makes it much more straightforward and easier to > > follow. > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > drivers/acpi/acpi_platform.c | 90 ++++++++++++------------------------------- > > drivers/acpi/resource.c | 12 +++++ > > drivers/acpi/scan.c | 56 ++++++++++++++++++++++++++ > > include/acpi/acpi_bus.h | 6 ++ > > include/linux/acpi.h | 1 > > 5 files changed, 102 insertions(+), 63 deletions(-) > > > > Index: linux/include/acpi/acpi_bus.h > > =================================================================== > > --- linux.orig/include/acpi/acpi_bus.h > > +++ linux/include/acpi/acpi_bus.h > > @@ -259,6 +259,11 @@ struct acpi_device_physical_node { > > struct device *dev; > > }; > > > > +struct acpi_resource_list_entry { > > + struct list_head node; > > + struct acpi_resource resource; > > +}; > > + > > /* set maximum of physical nodes to 32 for expansibility */ > > #define ACPI_MAX_PHYSICAL_NODE 32 > > > > @@ -268,6 +273,7 @@ struct acpi_device { > > acpi_handle handle; /* no handle for fixed hardware */ > > struct acpi_device *parent; > > struct list_head children; > > + struct list_head resources; /* Device resources. */ > > struct list_head node; > > struct list_head wakeup_list; > > struct acpi_device_status status; > > Index: linux/drivers/acpi/scan.c > > =================================================================== > > --- linux.orig/drivers/acpi/scan.c > > +++ linux/drivers/acpi/scan.c > > @@ -382,6 +382,52 @@ static void acpi_device_remove_files(str > > ACPI Bus operations > > -------------------------------------------------------------------------- */ > > > > +static void acpi_bus_drop_resources(struct acpi_device *adev) > > +{ > > + struct acpi_resource_list_entry *entry, *s; > > + > > + list_for_each_entry_safe(entry, s, &adev->resources, node) { > > + list_del(&entry->node); > > + kfree(entry); > > + } > > +} > > + > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, > > + void *context) > > +{ > > + struct list_head *list = context; > > + struct acpi_resource_list_entry *entry; > > + > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL); > > + if (!entry) > > + return AE_NO_MEMORY; > > + > > + entry->resource = *res; > > This does not work well with all resource types - specifically those that > contain pointers, like acpi_resource_gpio and acpi_resource_source. Good point. Well, this pretty much means we can't copy those things. > The memory for the resources gets freed once acpi_walk_resources() is done. I know that. Having to evaluate _CRS and creating a buffer, converting the output into ACPI resources and so on every time we need to look into the device's current resources is totally inefficient. We _need_ to cache the _CRS output. Now, because of the pointers in certain types of resources, we can't make copies of the resource objects used by acpi_walk_resources() which makes that function totally unuseful to us. I suppose we can just do acpi_get_current_resources() and play with the buffer returned by it. That won't be nice, but still better than what we have. Thanks, Rafael
On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote: > > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, > > > + void *context) > > > +{ > > > + struct list_head *list = context; > > > + struct acpi_resource_list_entry *entry; > > > + > > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL); > > > + if (!entry) > > > + return AE_NO_MEMORY; > > > + > > > + entry->resource = *res; > > > > This does not work well with all resource types - specifically those that > > contain pointers, like acpi_resource_gpio and acpi_resource_source. > > Good point. > > Well, this pretty much means we can't copy those things. Yeah. I only noticed this yesterday when I tested the GPIO translation in a custom driver (since it uses the acpi_resource_gpio). > > The memory for the resources gets freed once acpi_walk_resources() is done. > > I know that. > > Having to evaluate _CRS and creating a buffer, converting the output into > ACPI resources and so on every time we need to look into the device's current > resources is totally inefficient. We _need_ to cache the _CRS output. I agree and besides having adev->resources is much easier to use than calling acpi_walk_resources() everytime. > Now, because of the pointers in certain types of resources, we can't > make copies of the resource objects used by acpi_walk_resources() which > makes that function totally unuseful to us. > > I suppose we can just do acpi_get_current_resources() and play with the > buffer returned by it. That won't be nice, but still better than what we > have. I don't know any better option. Thanks. -- 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
> I suppose we can just do acpi_get_current_resources() and play with > the buffer returned by it. That won't be nice, but still better than > what we have. A couple of the reasons we created the ACPICA resource manager was to: 1) Simplify host access to the various resource fields, especially packed flags. 2) Avoid alignment issues, especially on machines that don't support misaligned transfers. If there are issues with the current resource manager, we can discuss them. But I would hope that you really don't want to be fussing around with the raw data coming back from the AML. It is not pretty and we have gone to some lengths to make the entire conversion table-driven to minimize bugs and simplify maintenance. Bob > -----Original Message----- > From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com] > Sent: Monday, November 12, 2012 11:12 PM > To: Rafael J. Wysocki > Cc: mathias.nyman@linux.intel.com; linux-acpi@vger.kernel.org; linux- > kernel@vger.kernel.org; lenb@kernel.org; Wysocki, Rafael J; > broonie@opensource.wolfsonmicro.com; grant.likely@secretlab.ca; > linus.walleij@linaro.org; khali@linux-fr.org; Bjorn Helgaas; Moore, Robert > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > objects > > On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote: > > > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, > > > > + void *context) > > > > +{ > > > > + struct list_head *list = context; > > > > + struct acpi_resource_list_entry *entry; > > > > + > > > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL); > > > > + if (!entry) > > > > + return AE_NO_MEMORY; > > > > + > > > > + entry->resource = *res; > > > > > > This does not work well with all resource types - specifically those > > > that contain pointers, like acpi_resource_gpio and > acpi_resource_source. > > > > Good point. > > > > Well, this pretty much means we can't copy those things. > > Yeah. I only noticed this yesterday when I tested the GPIO translation in > a custom driver (since it uses the acpi_resource_gpio). > > > > The memory for the resources gets freed once acpi_walk_resources() is > done. > > > > I know that. > > > > Having to evaluate _CRS and creating a buffer, converting the output > > into ACPI resources and so on every time we need to look into the > > device's current resources is totally inefficient. We _need_ to cache > the _CRS output. > > I agree and besides having adev->resources is much easier to use than > calling acpi_walk_resources() everytime. > > > Now, because of the pointers in certain types of resources, we can't > > make copies of the resource objects used by acpi_walk_resources() > > which makes that function totally unuseful to us. > > > > I suppose we can just do acpi_get_current_resources() and play with > > the buffer returned by it. That won't be nice, but still better than > > what we have. > > I don't know any better option. > > Thanks. -- 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, November 13, 2012 04:34:07 PM Moore, Robert wrote: > > I suppose we can just do acpi_get_current_resources() and play with > > the buffer returned by it. That won't be nice, but still better than > > what we have. > > A couple of the reasons we created the ACPICA resource manager was to: > 1) Simplify host access to the various resource fields, especially packed flags. > 2) Avoid alignment issues, especially on machines that don't support misaligned transfers. That's fine. > If there are issues with the current resource manager, we can discuss them. > But I would hope that you really don't want to be fussing around with the raw > data coming back from the AML. No, I don't. :-) I'd like to be able to do more things with struct acpi_resource objects. Pretty much the output of acpi_get_current_resources() is what I'm interested in, but there doesn't seem to be any convenient way to access things in the return buffer from the outside of ACPICA now. > It is not pretty and we have gone to some lengths to make the entire > conversion table-driven to minimize bugs and simplify maintenance. OK So what I would like to have, in general terms, is something like acpi_walk_resources() split into three parts: (1) One that processes the _CRS output and creates a list of struct acpi_resource objects for us to play with. I suppose it's OK if that's just a buffer filled with resource objects, but a linked list might be more convenient. (2) One that allows us to access (read/write) resources in the list returned by (1). We don't need to open code walking the list and I probably wouldn't event want to do that. What we need is to be able to walk the same list for a number of times and possibly to modify values in the resource objects if there are conflicts. (3) One allowing us to free the list returned by (1) if not needed any more. And it would be great if we could take the list returned by (1), modify the resources in it and feed it back to _SRS (after conversion back to the format that _SRS understands). Thanks, Rafael > > -----Original Message----- > > From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com] > > Sent: Monday, November 12, 2012 11:12 PM > > To: Rafael J. Wysocki > > Cc: mathias.nyman@linux.intel.com; linux-acpi@vger.kernel.org; linux- > > kernel@vger.kernel.org; lenb@kernel.org; Wysocki, Rafael J; > > broonie@opensource.wolfsonmicro.com; grant.likely@secretlab.ca; > > linus.walleij@linaro.org; khali@linux-fr.org; Bjorn Helgaas; Moore, Robert > > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > > objects > > > > On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote: > > > > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, > > > > > + void *context) > > > > > +{ > > > > > + struct list_head *list = context; > > > > > + struct acpi_resource_list_entry *entry; > > > > > + > > > > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL); > > > > > + if (!entry) > > > > > + return AE_NO_MEMORY; > > > > > + > > > > > + entry->resource = *res; > > > > > > > > This does not work well with all resource types - specifically those > > > > that contain pointers, like acpi_resource_gpio and > > acpi_resource_source. > > > > > > Good point. > > > > > > Well, this pretty much means we can't copy those things. > > > > Yeah. I only noticed this yesterday when I tested the GPIO translation in > > a custom driver (since it uses the acpi_resource_gpio). > > > > > > The memory for the resources gets freed once acpi_walk_resources() is > > done. > > > > > > I know that. > > > > > > Having to evaluate _CRS and creating a buffer, converting the output > > > into ACPI resources and so on every time we need to look into the > > > device's current resources is totally inefficient. We _need_ to cache > > the _CRS output. > > > > I agree and besides having adev->resources is much easier to use than > > calling acpi_walk_resources() everytime. > > > > > Now, because of the pointers in certain types of resources, we can't > > > make copies of the resource objects used by acpi_walk_resources() > > > which makes that function totally unuseful to us. > > > > > > I suppose we can just do acpi_get_current_resources() and play with > > > the buffer returned by it. That won't be nice, but still better than > > > what we have. > > > > I don't know any better option. > > > > Thanks. >
SSBtYXkgbm90IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IsIGJ1dCBJ IHdpbGwgdHJ5LiBJdCBzZWVtcyBsaWtlIHdlIGFscmVhZHkgaGF2ZSBtdWNoIG9mIHdoYXQgeW91 IHdhbnQvbmVlZCwgc28gbWF5YmUgSSdtIG1pc3Npbmcgc29tZXRoaW5nLg0KDQoNCg0KPiBTbyB3 aGF0IEkgd291bGQgbGlrZSB0byBoYXZlLCBpbiBnZW5lcmFsIHRlcm1zLCBpcyBzb21ldGhpbmcg bGlrZQ0KPiBhY3BpX3dhbGtfcmVzb3VyY2VzKCkgc3BsaXQgaW50byB0aHJlZSBwYXJ0czoNCj4g DQo+ICAoMSkgT25lIHRoYXQgcHJvY2Vzc2VzIHRoZSBfQ1JTIG91dHB1dCBhbmQgY3JlYXRlcyBh IGxpc3Qgb2YNCj4gICAgICBzdHJ1Y3QgYWNwaV9yZXNvdXJjZSBvYmplY3RzIGZvciB1cyB0byBw bGF5IHdpdGguICBJIHN1cHBvc2UNCj4gICAgICBpdCdzIE9LIGlmIHRoYXQncyBqdXN0IGEgYnVm ZmVyIGZpbGxlZCB3aXRoIHJlc291cmNlIG9iamVjdHMsDQo+ICAgICAgYnV0IGEgbGlua2VkIGxp c3QgbWlnaHQgYmUgbW9yZSBjb252ZW5pZW50Lg0KPiANCg0KVGhpcyBzb3VuZHMgbGlrZSBBY3Bp R2V0Q3VycmVudFJlc291cmNlcy4gSXQgZXhlY3V0ZXMgX0NSUyBhbmQgZm9ybWF0cyB0aGUgZGF0 YSBpbnRvIGFjcGlfcmVzb3VyY2Ugb2JqZWN0cy4NCg0KDQoNCj4gICgyKSBPbmUgdGhhdCBhbGxv d3MgdXMgdG8gYWNjZXNzIChyZWFkL3dyaXRlKSByZXNvdXJjZXMgaW4gdGhlDQo+ICAgICAgbGlz dCByZXR1cm5lZCBieSAoMSkuICBXZSBkb24ndCBuZWVkIHRvIG9wZW4gY29kZSB3YWxraW5nDQo+ ICAgICAgdGhlIGxpc3QgYW5kIEkgcHJvYmFibHkgd291bGRuJ3QgZXZlbnQgd2FudCB0byBkbyB0 aGF0LiAgV2hhdA0KPiAgICAgIHdlIG5lZWQgaXMgdG8gYmUgYWJsZSB0byB3YWxrIHRoZSBzYW1l IGxpc3QgZm9yIGEgbnVtYmVyIG9mDQo+ICAgICAgdGltZXMgYW5kIHBvc3NpYmx5IHRvIG1vZGlm eSB2YWx1ZXMgaW4gdGhlIHJlc291cmNlIG9iamVjdHMNCj4gICAgICBpZiB0aGVyZSBhcmUgY29u ZmxpY3RzLg0KDQpUaGlzIHNvdW5kcyBsaWtlIEFjcGlXYWxrUmVzb3VyY2VzLiBJIHN1cHBvc2Ug YSBwb3NzaWJsZSBpc3N1ZSBpcyB0aGF0IGN1cnJlbnRseSwgQWNwaVdhbGtSZXNvdXJjZXMgYWN0 dWFsbHkgaW52b2tlcyB0aGUgX0NSUywgX1BSUywgb3IgX0FFSSBtZXRob2Qgb24gYmVoYWxmIG9m IHRoZSBjYWxsZXIuIEl0IG1pZ2h0IG1ha2UgbW9yZSBzZW5zZSB0byBhbGxvdyB0aGUgY2FsbGVy IHRvIHBhc3MgaW4gdGhlIHJlc291cmNlIGJ1ZmZlciByZXR1cm5lZCBmcm9tIGEgY2FsbCB0byBf Q1JTLCBldGMuDQoNCg0KPiANCj4gICgzKSBPbmUgYWxsb3dpbmcgdXMgdG8gZnJlZSB0aGUgbGlz dCByZXR1cm5lZCBieSAoMSkgaWYgbm90IG5lZWRlZA0KPiAgICAgIGFueSBtb3JlLg0KPiANCg0K QWNwaUdldEN1cnJlbnRSZXNvdXJjZXM6IEN1cnJlbnRseSwgZXZlcnl0aGluZyBpcyByZXR1cm5l ZCBpbiBhIHNpbmdsZSBidWZmZXIgdG8gbWluaW1pemUgdGhlIG51bWJlciBvZiBhbGxvY2F0aW9u cy4gQSBidWZmZXIgeW91IGNhbiBmcmVlIHdoZW4geW91IGFyZSBkb25lIHdpdGggaXQuDQoNCkkg dGhpbmsgSSBzYXcgd2hlcmUgeW91IG1lbnRpb25lZCB0aGF0IHlvdSBjYW5ub3QgY29weSB0aGlz IGJ1ZmZlciBiZWNhdXNlIG9mIGludGVybmFsIHBvaW50ZXJzIHRvIG90aGVyIGFyZWFzIG9mIHRo ZSBidWZmZXIuIFllcy4gSG93ZXZlciwgd2UgY2FuIGJ1aWxkIGxpbmtlZCBsaXN0cyBhbGwgZGF5 IGlmIHlvdSByZWFsbHkgd2FudCB0aGVtIDotKQ0KDQoNCj4gQW5kIGl0IHdvdWxkIGJlIGdyZWF0 IGlmIHdlIGNvdWxkIHRha2UgdGhlIGxpc3QgcmV0dXJuZWQgYnkgKDEpLCBtb2RpZnkNCj4gdGhl IHJlc291cmNlcyBpbiBpdCBhbmQgZmVlZCBpdCBiYWNrIHRvIF9TUlMgKGFmdGVyIGNvbnZlcnNp b24gYmFjayB0byB0aGUNCj4gZm9ybWF0IHRoYXQgX1NSUyB1bmRlcnN0YW5kcykuDQo+IA0KDQpB Y3BpU2V0Q3VycmVudFJlc291cmNlcy4NCg0KVGhlIEFNTCBkZWJ1Z2dlciBhbHJlYWR5IGhhcyBh IGNvbW1hbmQgdGhhdCBpbGx1c3RyYXRlcyB0aGUgdXNlIG9mIHRoZSB2YXJpb3VzIHJlc291cmNl IGludGVyZmFjZXMsIHNlZSBkYmNtZHMuYw0KDQo+IFRoYW5rcywNCj4gUmFmYWVsDQoNCkJvYg0K DQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFmYWVsIEou IFd5c29ja2kgW21haWx0bzpyandAc2lzay5wbF0NCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIg MTMsIDIwMTIgMTI6NDQgUE0NCj4gVG86IE1vb3JlLCBSb2JlcnQNCj4gQ2M6IE1pa2EgV2VzdGVy YmVyZzsgbWF0aGlhcy5ueW1hbkBsaW51eC5pbnRlbC5jb207IGxpbnV4LQ0KPiBhY3BpQHZnZXIu a2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGVuYkBrZXJuZWwub3Jn Ow0KPiBXeXNvY2tpLCBSYWZhZWwgSjsgYnJvb25pZUBvcGVuc291cmNlLndvbGZzb25taWNyby5j b207DQo+IGdyYW50Lmxpa2VseUBzZWNyZXRsYWIuY2E7IGxpbnVzLndhbGxlaWpAbGluYXJvLm9y Zzsga2hhbGlAbGludXgtZnIub3JnOw0KPiBCam9ybiBIZWxnYWFzOyBaaGVuZywgTHYNCj4gU3Vi amVjdDogUmU6IFtQQVRDSCAzLzNdIEFDUEk6IEV2YWx1YXRlIF9DUlMgd2hpbGUgY3JlYXRpbmcg ZGV2aWNlIG5vZGUNCj4gb2JqZWN0cw0KPiANCj4gT24gVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIw MTIgMDQ6MzQ6MDcgUE0gTW9vcmUsIFJvYmVydCB3cm90ZToNCj4gPiA+IEkgc3VwcG9zZSB3ZSBj YW4ganVzdCBkbyBhY3BpX2dldF9jdXJyZW50X3Jlc291cmNlcygpIGFuZCBwbGF5IHdpdGgNCj4g PiA+IHRoZSBidWZmZXIgcmV0dXJuZWQgYnkgaXQuICBUaGF0IHdvbid0IGJlIG5pY2UsIGJ1dCBz dGlsbCBiZXR0ZXINCj4gPiA+IHRoYW4gd2hhdCB3ZSBoYXZlLg0KPiA+DQo+ID4gQSBjb3VwbGUg b2YgdGhlIHJlYXNvbnMgd2UgY3JlYXRlZCB0aGUgQUNQSUNBIHJlc291cmNlIG1hbmFnZXIgd2Fz IHRvOg0KPiA+IDEpIFNpbXBsaWZ5IGhvc3QgYWNjZXNzIHRvIHRoZSB2YXJpb3VzIHJlc291cmNl IGZpZWxkcywgZXNwZWNpYWxseQ0KPiBwYWNrZWQgZmxhZ3MuDQo+ID4gMikgQXZvaWQgYWxpZ25t ZW50IGlzc3VlcywgZXNwZWNpYWxseSBvbiBtYWNoaW5lcyB0aGF0IGRvbid0IHN1cHBvcnQNCj4g bWlzYWxpZ25lZCB0cmFuc2ZlcnMuDQo+IA0KPiBUaGF0J3MgZmluZS4NCj4gDQo+ID4gSWYgdGhl cmUgYXJlIGlzc3VlcyB3aXRoIHRoZSBjdXJyZW50IHJlc291cmNlIG1hbmFnZXIsIHdlIGNhbiBk aXNjdXNzDQo+IHRoZW0uDQo+ID4gQnV0IEkgd291bGQgaG9wZSB0aGF0IHlvdSByZWFsbHkgZG9u J3Qgd2FudCB0byBiZSBmdXNzaW5nIGFyb3VuZCB3aXRoDQo+ID4gdGhlIHJhdyBkYXRhIGNvbWlu ZyBiYWNrIGZyb20gdGhlIEFNTC4NCj4gDQo+IE5vLCBJIGRvbid0LiA6LSkNCj4gDQo+IEknZCBs aWtlIHRvIGJlIGFibGUgdG8gZG8gbW9yZSB0aGluZ3Mgd2l0aCBzdHJ1Y3QgYWNwaV9yZXNvdXJj ZSBvYmplY3RzLg0KPiANCj4gUHJldHR5IG11Y2ggdGhlIG91dHB1dCBvZiBhY3BpX2dldF9jdXJy ZW50X3Jlc291cmNlcygpIGlzIHdoYXQgSSdtDQo+IGludGVyZXN0ZWQgaW4sIGJ1dCB0aGVyZSBk b2Vzbid0IHNlZW0gdG8gYmUgYW55IGNvbnZlbmllbnQgd2F5IHRvIGFjY2Vzcw0KPiB0aGluZ3Mg aW4gdGhlIHJldHVybiBidWZmZXIgZnJvbSB0aGUgb3V0c2lkZSBvZiBBQ1BJQ0Egbm93Lg0KPiAN Cj4gPiBJdCBpcyBub3QgcHJldHR5IGFuZCB3ZSBoYXZlIGdvbmUgdG8gc29tZSBsZW5ndGhzIHRv IG1ha2UgdGhlIGVudGlyZQ0KPiA+IGNvbnZlcnNpb24gdGFibGUtZHJpdmVuIHRvIG1pbmltaXpl IGJ1Z3MgYW5kIHNpbXBsaWZ5IG1haW50ZW5hbmNlLg0KPiANCj4gT0sNCj4gDQo+IFNvIHdoYXQg SSB3b3VsZCBsaWtlIHRvIGhhdmUsIGluIGdlbmVyYWwgdGVybXMsIGlzIHNvbWV0aGluZyBsaWtl DQo+IGFjcGlfd2Fsa19yZXNvdXJjZXMoKSBzcGxpdCBpbnRvIHRocmVlIHBhcnRzOg0KPiANCj4g ICgxKSBPbmUgdGhhdCBwcm9jZXNzZXMgdGhlIF9DUlMgb3V0cHV0IGFuZCBjcmVhdGVzIGEgbGlz dCBvZg0KPiAgICAgIHN0cnVjdCBhY3BpX3Jlc291cmNlIG9iamVjdHMgZm9yIHVzIHRvIHBsYXkg d2l0aC4gIEkgc3VwcG9zZQ0KPiAgICAgIGl0J3MgT0sgaWYgdGhhdCdzIGp1c3QgYSBidWZmZXIg ZmlsbGVkIHdpdGggcmVzb3VyY2Ugb2JqZWN0cywNCj4gICAgICBidXQgYSBsaW5rZWQgbGlzdCBt aWdodCBiZSBtb3JlIGNvbnZlbmllbnQuDQo+IA0KPiAgKDIpIE9uZSB0aGF0IGFsbG93cyB1cyB0 byBhY2Nlc3MgKHJlYWQvd3JpdGUpIHJlc291cmNlcyBpbiB0aGUNCj4gICAgICBsaXN0IHJldHVy bmVkIGJ5ICgxKS4gIFdlIGRvbid0IG5lZWQgdG8gb3BlbiBjb2RlIHdhbGtpbmcNCj4gICAgICB0 aGUgbGlzdCBhbmQgSSBwcm9iYWJseSB3b3VsZG4ndCBldmVudCB3YW50IHRvIGRvIHRoYXQuICBX aGF0DQo+ICAgICAgd2UgbmVlZCBpcyB0byBiZSBhYmxlIHRvIHdhbGsgdGhlIHNhbWUgbGlzdCBm b3IgYSBudW1iZXIgb2YNCj4gICAgICB0aW1lcyBhbmQgcG9zc2libHkgdG8gbW9kaWZ5IHZhbHVl cyBpbiB0aGUgcmVzb3VyY2Ugb2JqZWN0cw0KPiAgICAgIGlmIHRoZXJlIGFyZSBjb25mbGljdHMu DQo+IA0KPiAgKDMpIE9uZSBhbGxvd2luZyB1cyB0byBmcmVlIHRoZSBsaXN0IHJldHVybmVkIGJ5 ICgxKSBpZiBub3QgbmVlZGVkDQo+ICAgICAgYW55IG1vcmUuDQo+IA0KPiBBbmQgaXQgd291bGQg YmUgZ3JlYXQgaWYgd2UgY291bGQgdGFrZSB0aGUgbGlzdCByZXR1cm5lZCBieSAoMSksIG1vZGlm eQ0KPiB0aGUgcmVzb3VyY2VzIGluIGl0IGFuZCBmZWVkIGl0IGJhY2sgdG8gX1NSUyAoYWZ0ZXIg Y29udmVyc2lvbiBiYWNrIHRvIHRoZQ0KPiBmb3JtYXQgdGhhdCBfU1JTIHVuZGVyc3RhbmRzKS4N Cj4gDQo+IFRoYW5rcywNCj4gUmFmYWVsDQo+IA0KPiANCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBNaWthIFdlc3RlcmJlcmcgW21haWx0bzptaWthLndlc3Rl cmJlcmdAbGludXguaW50ZWwuY29tXQ0KPiA+ID4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMiwg MjAxMiAxMToxMiBQTQ0KPiA+ID4gVG86IFJhZmFlbCBKLiBXeXNvY2tpDQo+ID4gPiBDYzogbWF0 aGlhcy5ueW1hbkBsaW51eC5pbnRlbC5jb207IGxpbnV4LWFjcGlAdmdlci5rZXJuZWwub3JnOw0K PiA+ID4gbGludXgtIGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxlbmJAa2VybmVsLm9yZzsgV3lz b2NraSwgUmFmYWVsIEo7DQo+ID4gPiBicm9vbmllQG9wZW5zb3VyY2Uud29sZnNvbm1pY3JvLmNv bTsgZ3JhbnQubGlrZWx5QHNlY3JldGxhYi5jYTsNCj4gPiA+IGxpbnVzLndhbGxlaWpAbGluYXJv Lm9yZzsga2hhbGlAbGludXgtZnIub3JnOyBCam9ybiBIZWxnYWFzOyBNb29yZSwNCj4gPiA+IFJv YmVydA0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzNdIEFDUEk6IEV2YWx1YXRlIF9DUlMg d2hpbGUgY3JlYXRpbmcgZGV2aWNlDQo+ID4gPiBub2RlIG9iamVjdHMNCj4gPiA+DQo+ID4gPiBP biBNb24sIE5vdiAxMiwgMjAxMiBhdCAxMDowMzo1NlBNICswMTAwLCBSYWZhZWwgSi4gV3lzb2Nr aSB3cm90ZToNCj4gPiA+ID4gPiA+ICtzdGF0aWMgYWNwaV9zdGF0dXMgYWNwaV9idXNfYWRkX3Jl c291cmNlKHN0cnVjdCBhY3BpX3Jlc291cmNlDQo+ICpyZXMsDQo+ID4gPiA+ID4gPiArCQkJCQkg dm9pZCAqY29udGV4dCkNCj4gPiA+ID4gPiA+ICt7DQo+ID4gPiA+ID4gPiArCXN0cnVjdCBsaXN0 X2hlYWQgKmxpc3QgPSBjb250ZXh0Ow0KPiA+ID4gPiA+ID4gKwlzdHJ1Y3QgYWNwaV9yZXNvdXJj ZV9saXN0X2VudHJ5ICplbnRyeTsNCj4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ICsJZW50cnkg PSBremFsbG9jKHNpemVvZigqZW50cnkpLCBHRlBfS0VSTkVMKTsNCj4gPiA+ID4gPiA+ICsJaWYg KCFlbnRyeSkNCj4gPiA+ID4gPiA+ICsJCXJldHVybiBBRV9OT19NRU1PUlk7DQo+ID4gPiA+ID4g PiArDQo+ID4gPiA+ID4gPiArCWVudHJ5LT5yZXNvdXJjZSA9ICpyZXM7DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBUaGlzIGRvZXMgbm90IHdvcmsgd2VsbCB3aXRoIGFsbCByZXNvdXJjZSB0eXBlcyAt IHNwZWNpZmljYWxseQ0KPiA+ID4gPiA+IHRob3NlIHRoYXQgY29udGFpbiBwb2ludGVycywgbGlr ZSBhY3BpX3Jlc291cmNlX2dwaW8gYW5kDQo+ID4gPiBhY3BpX3Jlc291cmNlX3NvdXJjZS4NCj4g PiA+ID4NCj4gPiA+ID4gR29vZCBwb2ludC4NCj4gPiA+ID4NCj4gPiA+ID4gV2VsbCwgdGhpcyBw cmV0dHkgbXVjaCBtZWFucyB3ZSBjYW4ndCBjb3B5IHRob3NlIHRoaW5ncy4NCj4gPiA+DQo+ID4g PiBZZWFoLiBJIG9ubHkgbm90aWNlZCB0aGlzIHllc3RlcmRheSB3aGVuIEkgdGVzdGVkIHRoZSBH UElPDQo+ID4gPiB0cmFuc2xhdGlvbiBpbiBhIGN1c3RvbSBkcml2ZXIgKHNpbmNlIGl0IHVzZXMg dGhlIGFjcGlfcmVzb3VyY2VfZ3BpbykuDQo+ID4gPg0KPiA+ID4gPiA+IFRoZSBtZW1vcnkgZm9y IHRoZSByZXNvdXJjZXMgZ2V0cyBmcmVlZCBvbmNlDQo+ID4gPiA+ID4gYWNwaV93YWxrX3Jlc291 cmNlcygpIGlzDQo+ID4gPiBkb25lLg0KPiA+ID4gPg0KPiA+ID4gPiBJIGtub3cgdGhhdC4NCj4g PiA+ID4NCj4gPiA+ID4gSGF2aW5nIHRvIGV2YWx1YXRlIF9DUlMgYW5kIGNyZWF0aW5nIGEgYnVm ZmVyLCBjb252ZXJ0aW5nIHRoZQ0KPiA+ID4gPiBvdXRwdXQgaW50byBBQ1BJIHJlc291cmNlcyBh bmQgc28gb24gZXZlcnkgdGltZSB3ZSBuZWVkIHRvIGxvb2sNCj4gPiA+ID4gaW50byB0aGUgZGV2 aWNlJ3MgY3VycmVudCByZXNvdXJjZXMgaXMgdG90YWxseSBpbmVmZmljaWVudC4gIFdlDQo+ID4g PiA+IF9uZWVkXyB0byBjYWNoZQ0KPiA+ID4gdGhlIF9DUlMgb3V0cHV0Lg0KPiA+ID4NCj4gPiA+ IEkgYWdyZWUgYW5kIGJlc2lkZXMgaGF2aW5nIGFkZXYtPnJlc291cmNlcyBpcyBtdWNoIGVhc2ll ciB0byB1c2UNCj4gPiA+IHRoYW4gY2FsbGluZyBhY3BpX3dhbGtfcmVzb3VyY2VzKCkgZXZlcnl0 aW1lLg0KPiA+ID4NCj4gPiA+ID4gTm93LCBiZWNhdXNlIG9mIHRoZSBwb2ludGVycyBpbiBjZXJ0 YWluIHR5cGVzIG9mIHJlc291cmNlcywgd2UNCj4gPiA+ID4gY2FuJ3QgbWFrZSBjb3BpZXMgb2Yg dGhlIHJlc291cmNlIG9iamVjdHMgdXNlZCBieQ0KPiA+ID4gPiBhY3BpX3dhbGtfcmVzb3VyY2Vz KCkgd2hpY2ggbWFrZXMgdGhhdCBmdW5jdGlvbiB0b3RhbGx5IHVudXNlZnVsIHRvDQo+IHVzLg0K PiA+ID4gPg0KPiA+ID4gPiBJIHN1cHBvc2Ugd2UgY2FuIGp1c3QgZG8gYWNwaV9nZXRfY3VycmVu dF9yZXNvdXJjZXMoKSBhbmQgcGxheQ0KPiA+ID4gPiB3aXRoIHRoZSBidWZmZXIgcmV0dXJuZWQg YnkgaXQuICBUaGF0IHdvbid0IGJlIG5pY2UsIGJ1dCBzdGlsbA0KPiA+ID4gPiBiZXR0ZXIgdGhh biB3aGF0IHdlIGhhdmUuDQo+ID4gPg0KPiA+ID4gSSBkb24ndCBrbm93IGFueSBiZXR0ZXIgb3B0 aW9uLg0KPiA+ID4NCj4gPiA+IFRoYW5rcy4NCj4gPg0KPiAtLQ0KPiBJIHNwZWFrIG9ubHkgZm9y IG15c2VsZi4NCj4gUmFmYWVsIEouIFd5c29ja2ksIEludGVsIE9wZW4gU291cmNlIFRlY2hub2xv Z3kgQ2VudGVyLg0K -- 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, November 13, 2012 10:06:03 PM Moore, Robert wrote: > I may not quite understand what you are asking for, but I will try. > It seems like we already have much of what you want/need, so maybe > I'm missing something. I think all of the necessary pieces are there. > > So what I would like to have, in general terms, is something like > > acpi_walk_resources() split into three parts: > > > > (1) One that processes the _CRS output and creates a list of > > struct acpi_resource objects for us to play with. I suppose > > it's OK if that's just a buffer filled with resource objects, > > but a linked list might be more convenient. > > > > This sounds like AcpiGetCurrentResources. It executes _CRS and formats > the data into acpi_resource objects. Yes, it does. However, it is not completely clear to me if/how the caller is supposed to prepare the buffer object pointed to by the second arg. If the buffer is initialized by AcpiGetCurrentResources, then that's what I need for (1). > > (2) One that allows us to access (read/write) resources in the > > list returned by (1). We don't need to open code walking > > the list and I probably wouldn't event want to do that. What > > we need is to be able to walk the same list for a number of > > times and possibly to modify values in the resource objects > > if there are conflicts. > > This sounds like AcpiWalkResources. I suppose a possible issue is that > currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI > method on behalf of the caller. Yes, that exactly is the problem. > It might make more sense to allow the caller to pass in the resource buffer > returned from a call to _CRS, etc. Yes! :-) > > > > (3) One allowing us to free the list returned by (1) if not needed > > any more. > > > > AcpiGetCurrentResources: Currently, everything is returned in a single buffer > to minimize the number of allocations. A buffer you can free when you are > done with it. I suppose I should use ACPI_FREE(buffer.pointer) for that, but isn't it for the ACPICA's internal use only? Besides, I would prefer to be able to pass just "buffer" for freeing, without having to touch its internals. No big deal, but it would be nicer. :-) > I think I saw where you mentioned that you cannot copy this buffer because > of internal pointers to other areas of the buffer. Yes. However, we can build > linked lists all day if you really want them :-) I really won't care if I can pass a resource buffer to a "walker" routine. :-) > > And it would be great if we could take the list returned by (1), modify > > the resources in it and feed it back to _SRS (after conversion back to the > > format that _SRS understands). > > > > AcpiSetCurrentResources. > > The AML debugger already has a command that illustrates the use of the > various resource interfaces, see dbcmds.c I will. Thanks, Rafael
UmFmYWVsLA0KDQpJIHNvdW5kcyBsaWtlIHdpdGggYSBmZXcgY2hhbmdlcywgd2UgY2FuIGVuaGFu Y2UgdGhpcyBtZWNoYW5pc20gdG8gYmUgbW9yZSB1c2VmdWwgdG8geW91IGFuZCBvdGhlcnMuIFNv bWUgY29tbWVudHMgYmVsb3cuIEkgbmVlZCB0byBsb29rIGF0IHRoZSBjb2RlIGluIHF1ZXN0aW9u IGEgYml0IG1vcmUsIGJ1dCBJIHNlZSBubyBpbnN1cm1vdW50YWJsZSBpc3N1ZXMuDQoNCkJvYg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFmYWVsIEouIFd5c29j a2kgW21haWx0bzpyandAc2lzay5wbF0NCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIw MTIgMjo1NyBQTQ0KPiBUbzogTW9vcmUsIFJvYmVydA0KPiBDYzogTWlrYSBXZXN0ZXJiZXJnOyBt YXRoaWFzLm55bWFuQGxpbnV4LmludGVsLmNvbTsgbGludXgtDQo+IGFjcGlAdmdlci5rZXJuZWwu b3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsZW5iQGtlcm5lbC5vcmc7DQo+IFd5 c29ja2ksIFJhZmFlbCBKOyBicm9vbmllQG9wZW5zb3VyY2Uud29sZnNvbm1pY3JvLmNvbTsNCj4g Z3JhbnQubGlrZWx5QHNlY3JldGxhYi5jYTsgbGludXMud2FsbGVpakBsaW5hcm8ub3JnOyBraGFs aUBsaW51eC1mci5vcmc7DQo+IEJqb3JuIEhlbGdhYXM7IFpoZW5nLCBMdg0KPiBTdWJqZWN0OiBS ZTogW1BBVENIIDMvM10gQUNQSTogRXZhbHVhdGUgX0NSUyB3aGlsZSBjcmVhdGluZyBkZXZpY2Ug bm9kZQ0KPiBvYmplY3RzDQo+IA0KPiBPbiBUdWVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMiAxMDow NjowMyBQTSBNb29yZSwgUm9iZXJ0IHdyb3RlOg0KPiA+IEkgbWF5IG5vdCBxdWl0ZSB1bmRlcnN0 YW5kIHdoYXQgeW91IGFyZSBhc2tpbmcgZm9yLCBidXQgSSB3aWxsIHRyeS4NCj4gPiBJdCBzZWVt cyBsaWtlIHdlIGFscmVhZHkgaGF2ZSBtdWNoIG9mIHdoYXQgeW91IHdhbnQvbmVlZCwgc28gbWF5 YmUgSSdtDQo+ID4gbWlzc2luZyBzb21ldGhpbmcuDQo+IA0KPiBJIHRoaW5rIGFsbCBvZiB0aGUg bmVjZXNzYXJ5IHBpZWNlcyBhcmUgdGhlcmUuDQo+IA0KPiA+ID4gU28gd2hhdCBJIHdvdWxkIGxp a2UgdG8gaGF2ZSwgaW4gZ2VuZXJhbCB0ZXJtcywgaXMgc29tZXRoaW5nIGxpa2UNCj4gPiA+IGFj cGlfd2Fsa19yZXNvdXJjZXMoKSBzcGxpdCBpbnRvIHRocmVlIHBhcnRzOg0KPiA+ID4NCj4gPiA+ ICAoMSkgT25lIHRoYXQgcHJvY2Vzc2VzIHRoZSBfQ1JTIG91dHB1dCBhbmQgY3JlYXRlcyBhIGxp c3Qgb2YNCj4gPiA+ICAgICAgc3RydWN0IGFjcGlfcmVzb3VyY2Ugb2JqZWN0cyBmb3IgdXMgdG8g cGxheSB3aXRoLiAgSSBzdXBwb3NlDQo+ID4gPiAgICAgIGl0J3MgT0sgaWYgdGhhdCdzIGp1c3Qg YSBidWZmZXIgZmlsbGVkIHdpdGggcmVzb3VyY2Ugb2JqZWN0cywNCj4gPiA+ICAgICAgYnV0IGEg bGlua2VkIGxpc3QgbWlnaHQgYmUgbW9yZSBjb252ZW5pZW50Lg0KPiA+ID4NCj4gPg0KPiA+IFRo aXMgc291bmRzIGxpa2UgQWNwaUdldEN1cnJlbnRSZXNvdXJjZXMuIEl0IGV4ZWN1dGVzIF9DUlMg YW5kIGZvcm1hdHMNCj4gPiB0aGUgZGF0YSBpbnRvIGFjcGlfcmVzb3VyY2Ugb2JqZWN0cy4NCj4g DQo+IFllcywgaXQgZG9lcy4gIEhvd2V2ZXIsIGl0IGlzIG5vdCBjb21wbGV0ZWx5IGNsZWFyIHRv IG1lIGlmL2hvdyB0aGUgY2FsbGVyDQo+IGlzIHN1cHBvc2VkIHRvIHByZXBhcmUgdGhlIGJ1ZmZl ciBvYmplY3QgcG9pbnRlZCB0byBieSB0aGUgc2Vjb25kIGFyZy4NCj4gDQo+IElmIHRoZSBidWZm ZXIgaXMgaW5pdGlhbGl6ZWQgYnkgQWNwaUdldEN1cnJlbnRSZXNvdXJjZXMsIHRoZW4gdGhhdCdz IHdoYXQNCj4gSSBuZWVkIGZvciAoMSkuDQoNCg0KSXQgbG9va3MgdG8gbWUgdGhhdCBhdCBsZWFz dCBBY3BpR2V0Q3VycmVudFJlc291cmNlcyBkb2VzIG5vdCBhY3R1YWxseSBldmVyIGFsbG9jYXRl IGEgYnVmZmVyIGZvciB0aGUgcmVzb3VyY2UgdGVtcGxhdGUsIGl0IGV4cGVjdHMgdGhlIGNhbGxl ciB0byBldmVudHVhbGx5IHByb3ZpZGUgb25lIG9mIGF0IGxlYXN0IHRoZSBzaXplIG9mIHRoZSBy ZXR1cm5lZCByZXNvdXJjZSB0ZW1wbGF0ZS4NCg0KVGhpcyBpcyByZWFsbHkgcXVpdGUgYSBiaXQg b3V0LW9mLWRhdGUgYXMgZmFyIGFzIHRoZSBtZW1vcnkgYWxsb2NhdGlvbiBtb2RlbC4gSXQgc2hv dWxkIGFsc28gc3VwcG9ydCB0aGUgb3B0aW9uIHRvIGp1c3QgYWxsb2NhdGUgdGhlIGJ1ZmZlciBv ZiB0aGUgYXBwcm9wcmlhdGUgc2l6ZSBiZWZvcmUgcmV0dXJuaW5nIGl0IHRvIHRoZSBjYWxsZXIu DQoNCg0KDQoNCj4gDQo+ID4gPiAgKDIpIE9uZSB0aGF0IGFsbG93cyB1cyB0byBhY2Nlc3MgKHJl YWQvd3JpdGUpIHJlc291cmNlcyBpbiB0aGUNCj4gPiA+ICAgICAgbGlzdCByZXR1cm5lZCBieSAo MSkuICBXZSBkb24ndCBuZWVkIHRvIG9wZW4gY29kZSB3YWxraW5nDQo+ID4gPiAgICAgIHRoZSBs aXN0IGFuZCBJIHByb2JhYmx5IHdvdWxkbid0IGV2ZW50IHdhbnQgdG8gZG8gdGhhdC4gIFdoYXQN Cj4gPiA+ICAgICAgd2UgbmVlZCBpcyB0byBiZSBhYmxlIHRvIHdhbGsgdGhlIHNhbWUgbGlzdCBm b3IgYSBudW1iZXIgb2YNCj4gPiA+ICAgICAgdGltZXMgYW5kIHBvc3NpYmx5IHRvIG1vZGlmeSB2 YWx1ZXMgaW4gdGhlIHJlc291cmNlIG9iamVjdHMNCj4gPiA+ICAgICAgaWYgdGhlcmUgYXJlIGNv bmZsaWN0cy4NCj4gPg0KPiA+IFRoaXMgc291bmRzIGxpa2UgQWNwaVdhbGtSZXNvdXJjZXMuIEkg c3VwcG9zZSBhIHBvc3NpYmxlIGlzc3VlIGlzIHRoYXQNCj4gPiBjdXJyZW50bHksIEFjcGlXYWxr UmVzb3VyY2VzIGFjdHVhbGx5IGludm9rZXMgdGhlIF9DUlMsIF9QUlMsIG9yIF9BRUkNCj4gPiBt ZXRob2Qgb24gYmVoYWxmIG9mIHRoZSBjYWxsZXIuDQo+IA0KPiBZZXMsIHRoYXQgZXhhY3RseSBp cyB0aGUgcHJvYmxlbS4NCj4gDQo+ID4gSXQgbWlnaHQgbWFrZSBtb3JlIHNlbnNlIHRvIGFsbG93 IHRoZSBjYWxsZXIgdG8gcGFzcyBpbiB0aGUgcmVzb3VyY2UNCj4gPiBidWZmZXIgcmV0dXJuZWQg ZnJvbSBhIGNhbGwgdG8gX0NSUywgZXRjLg0KPiANCj4gWWVzISA6LSkNCg0KDQpJJ2xsIHRha2Ug YSBjbG9zZXIgbG9vayBhdCB0aGlzIHRvbW9ycm93Lg0KDQoNCg0KDQo+IA0KPiA+ID4NCj4gPiA+ ICAoMykgT25lIGFsbG93aW5nIHVzIHRvIGZyZWUgdGhlIGxpc3QgcmV0dXJuZWQgYnkgKDEpIGlm IG5vdCBuZWVkZWQNCj4gPiA+ICAgICAgYW55IG1vcmUuDQo+ID4gPg0KPiA+DQo+ID4gQWNwaUdl dEN1cnJlbnRSZXNvdXJjZXM6IEN1cnJlbnRseSwgZXZlcnl0aGluZyBpcyByZXR1cm5lZCBpbiBh IHNpbmdsZQ0KPiA+IGJ1ZmZlciB0byBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIGFsbG9jYXRpb25z LiBBIGJ1ZmZlciB5b3UgY2FuIGZyZWUNCj4gPiB3aGVuIHlvdSBhcmUgZG9uZSB3aXRoIGl0Lg0K PiANCj4gSSBzdXBwb3NlIEkgc2hvdWxkIHVzZSBBQ1BJX0ZSRUUoYnVmZmVyLnBvaW50ZXIpIGZv ciB0aGF0LCBidXQgaXNuJ3QgaXQNCj4gZm9yIHRoZSBBQ1BJQ0EncyBpbnRlcm5hbCB1c2Ugb25s eT8NCj4gDQo+IEJlc2lkZXMsIEkgd291bGQgcHJlZmVyIHRvIGJlIGFibGUgdG8gcGFzcyBqdXN0 ICJidWZmZXIiIGZvciBmcmVlaW5nLA0KPiB3aXRob3V0IGhhdmluZyB0byB0b3VjaCBpdHMgaW50 ZXJuYWxzLiAgTm8gYmlnIGRlYWwsIGJ1dCBpdCB3b3VsZCBiZQ0KPiBuaWNlci4gOi0pDQoNCg0K VGhlIEFDUElfQlVGRkVSIHR5cGUgaXMgaW4gZmFjdCBhIHB1YmxpYyB0eXBlIHRoYXQgaXMgbWVh bnQgdG8gcmV0dXJuIGJvdGggdGhlIGJ1ZmZlciBhbmQgdGhlIChhY3R1YWwpIGxlbmd0aC4gWW91 IHdpbGwgZmluZCBtYW55IGluc3RhbmNlcyBvZiBBQ1BJX0ZSRUUoYnVmZmVyLnBvaW50ZXIpIHdp dGhpbiBleGlzdGluZyBsaW51eCBjb2RlLCBzaW5jZSBpdCBhbHNvIHVzZWQgZm9yIG9iamVjdHMg cmV0dXJuZWQgYnkgY29udHJvbCBtZXRob2QgZXhlY3V0aW9uL29iamVjdCBldmFsdWF0aW9uLg0K DQoNCj4gDQo+ID4gSSB0aGluayBJIHNhdyB3aGVyZSB5b3UgbWVudGlvbmVkIHRoYXQgeW91IGNh bm5vdCBjb3B5IHRoaXMgYnVmZmVyDQo+ID4gYmVjYXVzZSBvZiBpbnRlcm5hbCBwb2ludGVycyB0 byBvdGhlciBhcmVhcyBvZiB0aGUgYnVmZmVyLiBZZXMuDQo+ID4gSG93ZXZlciwgd2UgY2FuIGJ1 aWxkIGxpbmtlZCBsaXN0cyBhbGwgZGF5IGlmIHlvdSByZWFsbHkgd2FudCB0aGVtIDotKQ0KPiAN Cj4gSSByZWFsbHkgd29uJ3QgY2FyZSBpZiBJIGNhbiBwYXNzIGEgcmVzb3VyY2UgYnVmZmVyIHRv IGEgIndhbGtlciIgcm91dGluZS4NCj4gOi0pDQo+IA0KPiA+ID4gQW5kIGl0IHdvdWxkIGJlIGdy ZWF0IGlmIHdlIGNvdWxkIHRha2UgdGhlIGxpc3QgcmV0dXJuZWQgYnkgKDEpLA0KPiA+ID4gbW9k aWZ5IHRoZSByZXNvdXJjZXMgaW4gaXQgYW5kIGZlZWQgaXQgYmFjayB0byBfU1JTIChhZnRlcg0K PiA+ID4gY29udmVyc2lvbiBiYWNrIHRvIHRoZSBmb3JtYXQgdGhhdCBfU1JTIHVuZGVyc3RhbmRz KS4NCj4gPiA+DQo+ID4NCj4gPiBBY3BpU2V0Q3VycmVudFJlc291cmNlcy4NCj4gPg0KPiA+IFRo ZSBBTUwgZGVidWdnZXIgYWxyZWFkeSBoYXMgYSBjb21tYW5kIHRoYXQgaWxsdXN0cmF0ZXMgdGhl IHVzZSBvZiB0aGUNCj4gPiB2YXJpb3VzIHJlc291cmNlIGludGVyZmFjZXMsIHNlZSBkYmNtZHMu Yw0KPiANCj4gSSB3aWxsLg0KPiANCj4gVGhhbmtzLA0KPiBSYWZhZWwNCj4gDQo+IA0KPiAtLQ0K PiBJIHNwZWFrIG9ubHkgZm9yIG15c2VsZi4NCj4gUmFmYWVsIEouIFd5c29ja2ksIEludGVsIE9w ZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyLg0K -- 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 Wednesday, November 14, 2012 02:23:51 AM Moore, Robert wrote: > Rafael, > > I sounds like with a few changes, we can enhance this mechanism to > be more useful to you and others. Some comments below. I need to look > at the code in question a bit more, but I see no insurmountable issues. Great, thanks! > > -----Original Message----- > > From: Rafael J. Wysocki [mailto:rjw@sisk.pl] > > Sent: Tuesday, November 13, 2012 2:57 PM > > To: Moore, Robert > > Cc: Mika Westerberg; mathias.nyman@linux.intel.com; linux- > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; lenb@kernel.org; > > Wysocki, Rafael J; broonie@opensource.wolfsonmicro.com; > > grant.likely@secretlab.ca; linus.walleij@linaro.org; khali@linux-fr.org; > > Bjorn Helgaas; Zheng, Lv > > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > > objects > > > > On Tuesday, November 13, 2012 10:06:03 PM Moore, Robert wrote: > > > I may not quite understand what you are asking for, but I will try. > > > It seems like we already have much of what you want/need, so maybe I'm > > > missing something. > > > > I think all of the necessary pieces are there. > > > > > > So what I would like to have, in general terms, is something like > > > > acpi_walk_resources() split into three parts: > > > > > > > > (1) One that processes the _CRS output and creates a list of > > > > struct acpi_resource objects for us to play with. I suppose > > > > it's OK if that's just a buffer filled with resource objects, > > > > but a linked list might be more convenient. > > > > > > > > > > This sounds like AcpiGetCurrentResources. It executes _CRS and formats > > > the data into acpi_resource objects. > > > > Yes, it does. However, it is not completely clear to me if/how the caller > > is supposed to prepare the buffer object pointed to by the second arg. > > > > If the buffer is initialized by AcpiGetCurrentResources, then that's what > > I need for (1). > > > It looks to me that at least AcpiGetCurrentResources does not actually ever > allocate a buffer for the resource template, it expects the caller to > eventually provide one of at least the size of the returned resource template. > > This is really quite a bit out-of-date as far as the memory allocation model. > It should also support the option to just allocate the buffer of the appropriate > size before returning it to the caller. Yes, that would be really useful. Ideally, I'd like to be able to pass a pointer to an uninitialized buffer structure to it (or to a wrapper around it) and get a buffer full of struct acpi_resource objects (if _CRS returns any) back from it. :-) > > > > (2) One that allows us to access (read/write) resources in the > > > > list returned by (1). We don't need to open code walking > > > > the list and I probably wouldn't event want to do that. What > > > > we need is to be able to walk the same list for a number of > > > > times and possibly to modify values in the resource objects > > > > if there are conflicts. > > > > > > This sounds like AcpiWalkResources. I suppose a possible issue is that > > > currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI > > > method on behalf of the caller. > > > > Yes, that exactly is the problem. > > > > > It might make more sense to allow the caller to pass in the resource > > > buffer returned from a call to _CRS, etc. > > > > Yes! :-) > > > I'll take a closer look at this tomorrow. Cool, thanks! > > > > (3) One allowing us to free the list returned by (1) if not needed > > > > any more. > > > > > > > > > > AcpiGetCurrentResources: Currently, everything is returned in a single > > > buffer to minimize the number of allocations. A buffer you can free > > > when you are done with it. > > > > I suppose I should use ACPI_FREE(buffer.pointer) for that, but isn't it > > for the ACPICA's internal use only? > > > > Besides, I would prefer to be able to pass just "buffer" for freeing, > > without having to touch its internals. No big deal, but it would be > > nicer. :-) > > > The ACPI_BUFFER type is in fact a public type that is meant to return both the > buffer and the (actual) length. You will find many instances of > ACPI_FREE(buffer.pointer) within existing linux code, since it also used for > objects returned by control method execution/object evaluation. Well, I suppose I only wanted to say that acpi_free_buffer(buffer) would look a bit more straightforward than ACPI_FREE(buffer.pointer). :-) Thanks, Rafael
On Wednesday, November 14, 2012 10:18:46 AM Rafael J. Wysocki wrote: > On Wednesday, November 14, 2012 02:23:51 AM Moore, Robert wrote: > > Rafael, > > > > I sounds like with a few changes, we can enhance this mechanism to > > be more useful to you and others. Some comments below. I need to look > > at the code in question a bit more, but I see no insurmountable issues. > > Great, thanks! > > > > > -----Original Message----- > > > From: Rafael J. Wysocki [mailto:rjw@sisk.pl] > > > Sent: Tuesday, November 13, 2012 2:57 PM > > > To: Moore, Robert > > > Cc: Mika Westerberg; mathias.nyman@linux.intel.com; linux- > > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; lenb@kernel.org; > > > Wysocki, Rafael J; broonie@opensource.wolfsonmicro.com; > > > grant.likely@secretlab.ca; linus.walleij@linaro.org; khali@linux-fr.org; > > > Bjorn Helgaas; Zheng, Lv > > > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > > > objects > > > > > > On Tuesday, November 13, 2012 10:06:03 PM Moore, Robert wrote: > > > > I may not quite understand what you are asking for, but I will try. > > > > It seems like we already have much of what you want/need, so maybe I'm > > > > missing something. > > > > > > I think all of the necessary pieces are there. > > > > > > > > So what I would like to have, in general terms, is something like > > > > > acpi_walk_resources() split into three parts: > > > > > > > > > > (1) One that processes the _CRS output and creates a list of > > > > > struct acpi_resource objects for us to play with. I suppose > > > > > it's OK if that's just a buffer filled with resource objects, > > > > > but a linked list might be more convenient. > > > > > > > > > > > > > This sounds like AcpiGetCurrentResources. It executes _CRS and formats > > > > the data into acpi_resource objects. > > > > > > Yes, it does. However, it is not completely clear to me if/how the caller > > > is supposed to prepare the buffer object pointed to by the second arg. > > > > > > If the buffer is initialized by AcpiGetCurrentResources, then that's what > > > I need for (1). > > > > > > It looks to me that at least AcpiGetCurrentResources does not actually ever > > allocate a buffer for the resource template, it expects the caller to > > eventually provide one of at least the size of the returned resource template. > > > > This is really quite a bit out-of-date as far as the memory allocation model. > > It should also support the option to just allocate the buffer of the appropriate > > size before returning it to the caller. > > Yes, that would be really useful. > > Ideally, I'd like to be able to pass a pointer to an uninitialized buffer > structure to it (or to a wrapper around it) and get a buffer full of > struct acpi_resource objects (if _CRS returns any) back from it. :-) Of course, I can add such a wrapper in the Linux-specific code just fine. > > > > > (2) One that allows us to access (read/write) resources in the > > > > > list returned by (1). We don't need to open code walking > > > > > the list and I probably wouldn't event want to do that. What > > > > > we need is to be able to walk the same list for a number of > > > > > times and possibly to modify values in the resource objects > > > > > if there are conflicts. > > > > > > > > This sounds like AcpiWalkResources. I suppose a possible issue is that > > > > currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI > > > > method on behalf of the caller. > > > > > > Yes, that exactly is the problem. > > > > > > > It might make more sense to allow the caller to pass in the resource > > > > buffer returned from a call to _CRS, etc. > > > > > > Yes! :-) > > > > > > I'll take a closer look at this tomorrow. > > Cool, thanks! > > > > > > > (3) One allowing us to free the list returned by (1) if not needed > > > > > any more. > > > > > > > > > > > > > AcpiGetCurrentResources: Currently, everything is returned in a single > > > > buffer to minimize the number of allocations. A buffer you can free > > > > when you are done with it. > > > > > > I suppose I should use ACPI_FREE(buffer.pointer) for that, but isn't it > > > for the ACPICA's internal use only? > > > > > > Besides, I would prefer to be able to pass just "buffer" for freeing, > > > without having to touch its internals. No big deal, but it would be > > > nicer. :-) > > > > > > The ACPI_BUFFER type is in fact a public type that is meant to return both the > > buffer and the (actual) length. You will find many instances of > > ACPI_FREE(buffer.pointer) within existing linux code, since it also used for > > objects returned by control method execution/object evaluation. > > Well, I suppose I only wanted to say that acpi_free_buffer(buffer) would look > a bit more straightforward than ACPI_FREE(buffer.pointer). :-) And I can define acpi_free_buffer() in the Linux-specific code too. Thanks, Rafael
PiBBbmQgSSBjYW4gZGVmaW5lIGFjcGlfZnJlZV9idWZmZXIoKSBpbiB0aGUgTGludXgtc3BlY2lm aWMgY29kZSB0b28uDQo+IA0KPiBUaGFua3MsDQo+IFJhZmFlbA0KDQpJJ2xsIGJlIGdsYWQgdG8g YWRkIGFuIEFDUElfRlJFRV9CVUZGRVIgbWFjcm8sIGFsdGhvdWdoIHdlJ3ZlIGhhZCBjb21wbGFp bnRzIG92ZXIgdGhlIHllYXJzIHRoYXQgQUNQSUNBIHVzZXMgdG9vIG1hbnkgbWFjcm9zLiAoTm90 IHNvIG1hbnkgY29tcGxhaW50cyBpbiB0aGUgbGFzdCA1IHllYXJzLCBob3dldmVyLikNCg0KQm9i DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhZWwgSi4gV3lz b2NraSBbbWFpbHRvOnJqd0BzaXNrLnBsXQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE0 LCAyMDEyIDE6MzMgQU0NCj4gVG86IE1vb3JlLCBSb2JlcnQNCj4gQ2M6IE1pa2EgV2VzdGVyYmVy ZzsgbWF0aGlhcy5ueW1hbkBsaW51eC5pbnRlbC5jb207IGxpbnV4LQ0KPiBhY3BpQHZnZXIua2Vy bmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGVuYkBrZXJuZWwub3JnOw0K PiBXeXNvY2tpLCBSYWZhZWwgSjsgYnJvb25pZUBvcGVuc291cmNlLndvbGZzb25taWNyby5jb207 DQo+IGdyYW50Lmxpa2VseUBzZWNyZXRsYWIuY2E7IGxpbnVzLndhbGxlaWpAbGluYXJvLm9yZzsg a2hhbGlAbGludXgtZnIub3JnOw0KPiBCam9ybiBIZWxnYWFzOyBaaGVuZywgTHYNCj4gU3ViamVj dDogUmU6IFtQQVRDSCAzLzNdIEFDUEk6IEV2YWx1YXRlIF9DUlMgd2hpbGUgY3JlYXRpbmcgZGV2 aWNlIG5vZGUNCj4gb2JqZWN0cw0KPiANCj4gT24gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNCwgMjAx MiAxMDoxODo0NiBBTSBSYWZhZWwgSi4gV3lzb2NraSB3cm90ZToNCj4gPiBPbiBXZWRuZXNkYXks IE5vdmVtYmVyIDE0LCAyMDEyIDAyOjIzOjUxIEFNIE1vb3JlLCBSb2JlcnQgd3JvdGU6DQo+ID4g PiBSYWZhZWwsDQo+ID4gPg0KPiA+ID4gSSBzb3VuZHMgbGlrZSB3aXRoIGEgZmV3IGNoYW5nZXMs IHdlIGNhbiBlbmhhbmNlIHRoaXMgbWVjaGFuaXNtIHRvDQo+ID4gPiBiZSBtb3JlIHVzZWZ1bCB0 byB5b3UgYW5kIG90aGVycy4gU29tZSBjb21tZW50cyBiZWxvdy4gSSBuZWVkIHRvDQo+ID4gPiBs b29rIGF0IHRoZSBjb2RlIGluIHF1ZXN0aW9uIGEgYml0IG1vcmUsIGJ1dCBJIHNlZSBubyBpbnN1 cm1vdW50YWJsZQ0KPiBpc3N1ZXMuDQo+ID4NCj4gPiBHcmVhdCwgdGhhbmtzIQ0KPiA+DQo+ID4N Cj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogUmFmYWVs IEouIFd5c29ja2kgW21haWx0bzpyandAc2lzay5wbF0NCj4gPiA+ID4gU2VudDogVHVlc2RheSwg Tm92ZW1iZXIgMTMsIDIwMTIgMjo1NyBQTQ0KPiA+ID4gPiBUbzogTW9vcmUsIFJvYmVydA0KPiA+ ID4gPiBDYzogTWlrYSBXZXN0ZXJiZXJnOyBtYXRoaWFzLm55bWFuQGxpbnV4LmludGVsLmNvbTsg bGludXgtDQo+ID4gPiA+IGFjcGlAdmdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5r ZXJuZWwub3JnOw0KPiA+ID4gPiBsZW5iQGtlcm5lbC5vcmc7IFd5c29ja2ksIFJhZmFlbCBKOw0K PiA+ID4gPiBicm9vbmllQG9wZW5zb3VyY2Uud29sZnNvbm1pY3JvLmNvbTsNCj4gPiA+ID4gZ3Jh bnQubGlrZWx5QHNlY3JldGxhYi5jYTsgbGludXMud2FsbGVpakBsaW5hcm8ub3JnOw0KPiA+ID4g PiBraGFsaUBsaW51eC1mci5vcmc7IEJqb3JuIEhlbGdhYXM7IFpoZW5nLCBMdg0KPiA+ID4gPiBT dWJqZWN0OiBSZTogW1BBVENIIDMvM10gQUNQSTogRXZhbHVhdGUgX0NSUyB3aGlsZSBjcmVhdGlu ZyBkZXZpY2UNCj4gPiA+ID4gbm9kZSBvYmplY3RzDQo+ID4gPiA+DQo+ID4gPiA+IE9uIFR1ZXNk YXksIE5vdmVtYmVyIDEzLCAyMDEyIDEwOjA2OjAzIFBNIE1vb3JlLCBSb2JlcnQgd3JvdGU6DQo+ ID4gPiA+ID4gSSBtYXkgbm90IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIGFza2luZyBm b3IsIGJ1dCBJIHdpbGwNCj4gdHJ5Lg0KPiA+ID4gPiA+IEl0IHNlZW1zIGxpa2Ugd2UgYWxyZWFk eSBoYXZlIG11Y2ggb2Ygd2hhdCB5b3Ugd2FudC9uZWVkLCBzbw0KPiA+ID4gPiA+IG1heWJlIEkn bSBtaXNzaW5nIHNvbWV0aGluZy4NCj4gPiA+ID4NCj4gPiA+ID4gSSB0aGluayBhbGwgb2YgdGhl IG5lY2Vzc2FyeSBwaWVjZXMgYXJlIHRoZXJlLg0KPiA+ID4gPg0KPiA+ID4gPiA+ID4gU28gd2hh dCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSwgaW4gZ2VuZXJhbCB0ZXJtcywgaXMgc29tZXRoaW5nDQo+ ID4gPiA+ID4gPiBsaWtlDQo+ID4gPiA+ID4gPiBhY3BpX3dhbGtfcmVzb3VyY2VzKCkgc3BsaXQg aW50byB0aHJlZSBwYXJ0czoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgKDEpIE9uZSB0aGF0 IHByb2Nlc3NlcyB0aGUgX0NSUyBvdXRwdXQgYW5kIGNyZWF0ZXMgYSBsaXN0IG9mDQo+ID4gPiA+ ID4gPiAgICAgIHN0cnVjdCBhY3BpX3Jlc291cmNlIG9iamVjdHMgZm9yIHVzIHRvIHBsYXkgd2l0 aC4gIEkNCj4gc3VwcG9zZQ0KPiA+ID4gPiA+ID4gICAgICBpdCdzIE9LIGlmIHRoYXQncyBqdXN0 IGEgYnVmZmVyIGZpbGxlZCB3aXRoIHJlc291cmNlDQo+IG9iamVjdHMsDQo+ID4gPiA+ID4gPiAg ICAgIGJ1dCBhIGxpbmtlZCBsaXN0IG1pZ2h0IGJlIG1vcmUgY29udmVuaWVudC4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGlzIHNvdW5kcyBsaWtlIEFjcGlHZXRDdXJyZW50 UmVzb3VyY2VzLiBJdCBleGVjdXRlcyBfQ1JTIGFuZA0KPiA+ID4gPiA+IGZvcm1hdHMgdGhlIGRh dGEgaW50byBhY3BpX3Jlc291cmNlIG9iamVjdHMuDQo+ID4gPiA+DQo+ID4gPiA+IFllcywgaXQg ZG9lcy4gIEhvd2V2ZXIsIGl0IGlzIG5vdCBjb21wbGV0ZWx5IGNsZWFyIHRvIG1lIGlmL2hvdw0K PiA+ID4gPiB0aGUgY2FsbGVyIGlzIHN1cHBvc2VkIHRvIHByZXBhcmUgdGhlIGJ1ZmZlciBvYmpl Y3QgcG9pbnRlZCB0byBieQ0KPiB0aGUgc2Vjb25kIGFyZy4NCj4gPiA+ID4NCj4gPiA+ID4gSWYg dGhlIGJ1ZmZlciBpcyBpbml0aWFsaXplZCBieSBBY3BpR2V0Q3VycmVudFJlc291cmNlcywgdGhl bg0KPiA+ID4gPiB0aGF0J3Mgd2hhdCBJIG5lZWQgZm9yICgxKS4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4gSXQgbG9va3MgdG8gbWUgdGhhdCBhdCBsZWFzdCBBY3BpR2V0Q3VycmVudFJlc291cmNlcyBk b2VzIG5vdA0KPiA+ID4gYWN0dWFsbHkgZXZlciBhbGxvY2F0ZSBhIGJ1ZmZlciBmb3IgdGhlIHJl c291cmNlIHRlbXBsYXRlLCBpdA0KPiA+ID4gZXhwZWN0cyB0aGUgY2FsbGVyIHRvIGV2ZW50dWFs bHkgcHJvdmlkZSBvbmUgb2YgYXQgbGVhc3QgdGhlIHNpemUgb2YNCj4gdGhlIHJldHVybmVkIHJl c291cmNlIHRlbXBsYXRlLg0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgcmVhbGx5IHF1aXRlIGEgYml0 IG91dC1vZi1kYXRlIGFzIGZhciBhcyB0aGUgbWVtb3J5IGFsbG9jYXRpb24NCj4gbW9kZWwuDQo+ ID4gPiBJdCBzaG91bGQgYWxzbyBzdXBwb3J0IHRoZSBvcHRpb24gdG8ganVzdCBhbGxvY2F0ZSB0 aGUgYnVmZmVyIG9mIHRoZQ0KPiA+ID4gYXBwcm9wcmlhdGUgc2l6ZSBiZWZvcmUgcmV0dXJuaW5n IGl0IHRvIHRoZSBjYWxsZXIuDQo+ID4NCj4gPiBZZXMsIHRoYXQgd291bGQgYmUgcmVhbGx5IHVz ZWZ1bC4NCj4gPg0KPiA+IElkZWFsbHksIEknZCBsaWtlIHRvIGJlIGFibGUgdG8gcGFzcyBhIHBv aW50ZXIgdG8gYW4gdW5pbml0aWFsaXplZA0KPiA+IGJ1ZmZlciBzdHJ1Y3R1cmUgdG8gaXQgKG9y IHRvIGEgd3JhcHBlciBhcm91bmQgaXQpIGFuZCBnZXQgYSBidWZmZXINCj4gPiBmdWxsIG9mIHN0 cnVjdCBhY3BpX3Jlc291cmNlIG9iamVjdHMgKGlmIF9DUlMgcmV0dXJucyBhbnkpIGJhY2sgZnJv bQ0KPiA+IGl0LiA6LSkNCj4gDQo+IE9mIGNvdXJzZSwgSSBjYW4gYWRkIHN1Y2ggYSB3cmFwcGVy IGluIHRoZSBMaW51eC1zcGVjaWZpYyBjb2RlIGp1c3QgZmluZS4NCj4gDQo+IA0KPiA+ID4gPiA+ ID4gICgyKSBPbmUgdGhhdCBhbGxvd3MgdXMgdG8gYWNjZXNzIChyZWFkL3dyaXRlKSByZXNvdXJj ZXMgaW4gdGhlDQo+ID4gPiA+ID4gPiAgICAgIGxpc3QgcmV0dXJuZWQgYnkgKDEpLiAgV2UgZG9u J3QgbmVlZCB0byBvcGVuIGNvZGUgd2Fsa2luZw0KPiA+ID4gPiA+ID4gICAgICB0aGUgbGlzdCBh bmQgSSBwcm9iYWJseSB3b3VsZG4ndCBldmVudCB3YW50IHRvIGRvIHRoYXQuDQo+IFdoYXQNCj4g PiA+ID4gPiA+ICAgICAgd2UgbmVlZCBpcyB0byBiZSBhYmxlIHRvIHdhbGsgdGhlIHNhbWUgbGlz dCBmb3IgYSBudW1iZXIgb2YNCj4gPiA+ID4gPiA+ICAgICAgdGltZXMgYW5kIHBvc3NpYmx5IHRv IG1vZGlmeSB2YWx1ZXMgaW4gdGhlIHJlc291cmNlIG9iamVjdHMNCj4gPiA+ID4gPiA+ICAgICAg aWYgdGhlcmUgYXJlIGNvbmZsaWN0cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgc291bmRz IGxpa2UgQWNwaVdhbGtSZXNvdXJjZXMuIEkgc3VwcG9zZSBhIHBvc3NpYmxlIGlzc3VlDQo+ID4g PiA+ID4gaXMgdGhhdCBjdXJyZW50bHksIEFjcGlXYWxrUmVzb3VyY2VzIGFjdHVhbGx5IGludm9r ZXMgdGhlIF9DUlMsDQo+ID4gPiA+ID4gX1BSUywgb3IgX0FFSSBtZXRob2Qgb24gYmVoYWxmIG9m IHRoZSBjYWxsZXIuDQo+ID4gPiA+DQo+ID4gPiA+IFllcywgdGhhdCBleGFjdGx5IGlzIHRoZSBw cm9ibGVtLg0KPiA+ID4gPg0KPiA+ID4gPiA+IEl0IG1pZ2h0IG1ha2UgbW9yZSBzZW5zZSB0byBh bGxvdyB0aGUgY2FsbGVyIHRvIHBhc3MgaW4gdGhlDQo+ID4gPiA+ID4gcmVzb3VyY2UgYnVmZmVy IHJldHVybmVkIGZyb20gYSBjYWxsIHRvIF9DUlMsIGV0Yy4NCj4gPiA+ID4NCj4gPiA+ID4gWWVz ISA6LSkNCj4gPiA+DQo+ID4gPg0KPiA+ID4gSSdsbCB0YWtlIGEgY2xvc2VyIGxvb2sgYXQgdGhp cyB0b21vcnJvdy4NCj4gPg0KPiA+IENvb2wsIHRoYW5rcyENCj4gPg0KPiA+DQo+ID4gPiA+ID4g PiAgKDMpIE9uZSBhbGxvd2luZyB1cyB0byBmcmVlIHRoZSBsaXN0IHJldHVybmVkIGJ5ICgxKSBp ZiBub3QNCj4gbmVlZGVkDQo+ID4gPiA+ID4gPiAgICAgIGFueSBtb3JlLg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFjcGlHZXRDdXJyZW50UmVzb3VyY2VzOiBDdXJyZW50bHks IGV2ZXJ5dGhpbmcgaXMgcmV0dXJuZWQgaW4gYQ0KPiA+ID4gPiA+IHNpbmdsZSBidWZmZXIgdG8g bWluaW1pemUgdGhlIG51bWJlciBvZiBhbGxvY2F0aW9ucy4gQSBidWZmZXINCj4gPiA+ID4gPiB5 b3UgY2FuIGZyZWUgd2hlbiB5b3UgYXJlIGRvbmUgd2l0aCBpdC4NCj4gPiA+ID4NCj4gPiA+ID4g SSBzdXBwb3NlIEkgc2hvdWxkIHVzZSBBQ1BJX0ZSRUUoYnVmZmVyLnBvaW50ZXIpIGZvciB0aGF0 LCBidXQNCj4gPiA+ID4gaXNuJ3QgaXQgZm9yIHRoZSBBQ1BJQ0EncyBpbnRlcm5hbCB1c2Ugb25s eT8NCj4gPiA+ID4NCj4gPiA+ID4gQmVzaWRlcywgSSB3b3VsZCBwcmVmZXIgdG8gYmUgYWJsZSB0 byBwYXNzIGp1c3QgImJ1ZmZlciIgZm9yDQo+ID4gPiA+IGZyZWVpbmcsIHdpdGhvdXQgaGF2aW5n IHRvIHRvdWNoIGl0cyBpbnRlcm5hbHMuICBObyBiaWcgZGVhbCwgYnV0DQo+ID4gPiA+IGl0IHdv dWxkIGJlIG5pY2VyLiA6LSkNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIEFDUElfQlVGRkVSIHR5 cGUgaXMgaW4gZmFjdCBhIHB1YmxpYyB0eXBlIHRoYXQgaXMgbWVhbnQgdG8NCj4gPiA+IHJldHVy biBib3RoIHRoZSBidWZmZXIgYW5kIHRoZSAoYWN0dWFsKSBsZW5ndGguIFlvdSB3aWxsIGZpbmQg bWFueQ0KPiA+ID4gaW5zdGFuY2VzIG9mDQo+ID4gPiBBQ1BJX0ZSRUUoYnVmZmVyLnBvaW50ZXIp IHdpdGhpbiBleGlzdGluZyBsaW51eCBjb2RlLCBzaW5jZSBpdCBhbHNvDQo+ID4gPiB1c2VkIGZv ciBvYmplY3RzIHJldHVybmVkIGJ5IGNvbnRyb2wgbWV0aG9kIGV4ZWN1dGlvbi9vYmplY3QNCj4g ZXZhbHVhdGlvbi4NCj4gPg0KPiA+IFdlbGwsIEkgc3VwcG9zZSBJIG9ubHkgd2FudGVkIHRvIHNh eSB0aGF0IGFjcGlfZnJlZV9idWZmZXIoYnVmZmVyKQ0KPiA+IHdvdWxkIGxvb2sgYSBiaXQgbW9y ZSBzdHJhaWdodGZvcndhcmQgdGhhbiBBQ1BJX0ZSRUUoYnVmZmVyLnBvaW50ZXIpLg0KPiA+IDot KQ0KPiANCj4gQW5kIEkgY2FuIGRlZmluZSBhY3BpX2ZyZWVfYnVmZmVyKCkgaW4gdGhlIExpbnV4 LXNwZWNpZmljIGNvZGUgdG9vLg0KPiANCj4gVGhhbmtzLA0KPiBSYWZhZWwNCj4gDQo+IA0KPiAt LQ0KPiBJIHNwZWFrIG9ubHkgZm9yIG15c2VsZi4NCj4gUmFmYWVsIEouIFd5c29ja2ksIEludGVs IE9wZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyLg0K -- 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
Index: linux/include/acpi/acpi_bus.h =================================================================== --- linux.orig/include/acpi/acpi_bus.h +++ linux/include/acpi/acpi_bus.h @@ -259,6 +259,11 @@ struct acpi_device_physical_node { struct device *dev; }; +struct acpi_resource_list_entry { + struct list_head node; + struct acpi_resource resource; +}; + /* set maximum of physical nodes to 32 for expansibility */ #define ACPI_MAX_PHYSICAL_NODE 32 @@ -268,6 +273,7 @@ struct acpi_device { acpi_handle handle; /* no handle for fixed hardware */ struct acpi_device *parent; struct list_head children; + struct list_head resources; /* Device resources. */ struct list_head node; struct list_head wakeup_list; struct acpi_device_status status; Index: linux/drivers/acpi/scan.c =================================================================== --- linux.orig/drivers/acpi/scan.c +++ linux/drivers/acpi/scan.c @@ -382,6 +382,52 @@ static void acpi_device_remove_files(str ACPI Bus operations -------------------------------------------------------------------------- */ +static void acpi_bus_drop_resources(struct acpi_device *adev) +{ + struct acpi_resource_list_entry *entry, *s; + + list_for_each_entry_safe(entry, s, &adev->resources, node) { + list_del(&entry->node); + kfree(entry); + } +} + +static acpi_status acpi_bus_add_resource(struct acpi_resource *res, + void *context) +{ + struct list_head *list = context; + struct acpi_resource_list_entry *entry; + + entry = kzalloc(sizeof(*entry), GFP_KERNEL); + if (!entry) + return AE_NO_MEMORY; + + entry->resource = *res; + INIT_LIST_HEAD(&entry->node); + list_add_tail(&entry->node, list); + return AE_OK; +} + +static int acpi_bus_get_resources(struct acpi_device *adev) +{ + acpi_status status; + acpi_handle not_used; + int ret = 0; + + status = acpi_get_handle(adev->handle, METHOD_NAME__CRS, ¬_used); + if (ACPI_FAILURE(status)) + return 0; + + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS, + acpi_bus_add_resource, &adev->resources); + if (ACPI_FAILURE(status)) { + acpi_bus_drop_resources(adev); + ret = status == AE_NO_MEMORY ? -ENOMEM : -EIO; + } + + return ret; +} + static const struct acpi_device_id *__acpi_match_device( struct acpi_device *device, const struct acpi_device_id *ids) { @@ -681,6 +727,7 @@ static void acpi_device_unregister(struc acpi_device_remove_files(device); device_unregister(&device->dev); + acpi_bus_drop_resources(device); } /* -------------------------------------------------------------------------- @@ -1412,6 +1459,15 @@ static int acpi_add_single_object(struct acpi_device_set_id(device); /* + * Device Resources + * ---------------- + */ + INIT_LIST_HEAD(&device->resources); + result = acpi_bus_get_resources(device); + if (result) + goto end; + + /* * Power Management * ---------------- */ Index: linux/drivers/acpi/resource.c =================================================================== --- linux.orig/drivers/acpi/resource.c +++ linux/drivers/acpi/resource.c @@ -391,3 +391,15 @@ bool acpi_dev_resource_interrupt(struct return true; } EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt); + +unsigned int acpi_dev_resource_count(struct acpi_resource *ares) +{ + switch (ares->type) { + case ACPI_RESOURCE_TYPE_IRQ: + return ares->data.irq.interrupt_count; + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ: + return ares->data.extended_irq.interrupt_count; + } + return 1; +} +EXPORT_SYMBOL_GPL(acpi_dev_resource_count); Index: linux/drivers/acpi/acpi_platform.c =================================================================== --- linux.orig/drivers/acpi/acpi_platform.c +++ linux/drivers/acpi/acpi_platform.c @@ -19,59 +19,26 @@ ACPI_MODULE_NAME("platform"); -struct resource_info { - struct device *dev; - struct resource *res; - size_t n, cur; -}; - -static acpi_status acpi_platform_count_resources(struct acpi_resource *res, - void *data) +static unsigned int acpi_platform_add_resource(struct acpi_resource *res, + struct resource *r) { - struct acpi_resource_extended_irq *acpi_xirq; - struct acpi_resource_irq *acpi_irq; - struct resource_info *ri = data; - - switch (res->type) { - case ACPI_RESOURCE_TYPE_IRQ: - acpi_irq = &res->data.irq; - ri->n += acpi_irq->interrupt_count; - break; - case ACPI_RESOURCE_TYPE_EXTENDED_IRQ: - acpi_xirq = &res->data.extended_irq; - ri->n += acpi_xirq->interrupt_count; - break; - default: - ri->n++; - } - - return AE_OK; -} - -static acpi_status acpi_platform_add_resources(struct acpi_resource *res, - void *data) -{ - struct resource_info *ri = data; - struct resource *r; - - r = ri->res + ri->cur; if (acpi_dev_resource_memory(res, r) || acpi_dev_resource_io(res, r) || acpi_dev_resource_address_space(res, r) - || acpi_dev_resource_ext_address_space(res, r)) { - ri->cur++; - return AE_OK; - } + || acpi_dev_resource_ext_address_space(res, r)) + return 1; + if (acpi_dev_resource_interrupt(res, 0, r)) { - int i; + unsigned int i; r++; for (i = 1; acpi_dev_resource_interrupt(res, i, r); i++) r++; - ri->cur += i; + return i; } - return AE_OK; + + return 0; } /** @@ -89,35 +56,32 @@ struct platform_device *acpi_create_plat struct platform_device *pdev = NULL; struct acpi_device *acpi_parent; struct device *parent = NULL; - struct resource_info ri; - acpi_status status; + struct acpi_resource_list_entry *entry; + struct resource *resources; + unsigned int count; /* If the ACPI node already has a physical device attached, skip it. */ if (adev->physical_node_count) return NULL; - memset(&ri, 0, sizeof(ri)); - /* First, count the resources. */ - status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS, - acpi_platform_count_resources, &ri); - if (ACPI_FAILURE(status) || !ri.n) + count = 0; + list_for_each_entry(entry, &adev->resources, node) + count += acpi_dev_resource_count(&entry->resource); + + if (!count) return NULL; /* Next, allocate memory for all the resources and populate it. */ - ri.dev = &adev->dev; - ri.res = kzalloc(ri.n * sizeof(struct resource), GFP_KERNEL); - if (!ri.res) { - dev_err(&adev->dev, - "failed to allocate memory for resources\n"); + resources = kzalloc(count * sizeof(struct resource), GFP_KERNEL); + if (!resources) { + dev_err(&adev->dev, "No memory for resources\n"); return NULL; } - status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS, - acpi_platform_add_resources, &ri); - if (ACPI_FAILURE(status)) { - dev_err(&adev->dev, "failed to walk resources\n"); - goto out; - } + count = 0; + list_for_each_entry(entry, &adev->resources, node) + count += acpi_platform_add_resource(&entry->resource, + resources + count); /* * If the ACPI node has a parent and that parent has a physical device @@ -139,8 +103,9 @@ struct platform_device *acpi_create_plat } mutex_unlock(&acpi_parent->physical_node_lock); } + pdev = platform_device_register_resndata(parent, dev_name(&adev->dev), - -1, ri.res, ri.cur, NULL, 0); + -1, resources, count, NULL, 0); if (IS_ERR(pdev)) { dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); @@ -150,8 +115,7 @@ struct platform_device *acpi_create_plat dev_name(&pdev->dev)); } - out: - kfree(ri.res); + kfree(resources); return pdev; } Index: linux/include/linux/acpi.h =================================================================== --- linux.orig/include/linux/acpi.h +++ linux/include/linux/acpi.h @@ -260,6 +260,7 @@ bool acpi_dev_resource_ext_address_space unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable); bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index, struct resource *res); +unsigned int acpi_dev_resource_count(struct acpi_resource *ares); int acpi_check_resource_conflict(const struct resource *res);